Purchase Options and Commitments

What it is

Every AWS workload is billed under a purchase option. The same instance can cost very different amounts depending on whether it runs On-Demand, under a commitment, or on spare Spot capacity.

At the professional level the question is rarely "what is a Savings Plan". It is which mix of options covers a multi-account estate with a steady baseline, a seasonal peak and some interruptible batch work, at the lowest cost and the least management effort.

How it works

Compute purchase options

Savings Plans are commitments to a dollar amount per hour, not to specific instances. Compute Savings Plans apply across instance families, sizes, Regions, operating systems and tenancy, and also to Fargate and Lambda. They do not cover RDS, EBS or data transfer.

In an organization with consolidated billing, Savings Plans and Reserved Instance discounts are shared across member accounts by default. Buying commitments centrally in one account and letting sharing spread them is usually the lowest effort design. Sharing can be turned off for accounts that must keep their own discounts.

Capacity versus discount

Discounts and capacity are separate ideas. Regional Reserved Instances and Savings Plans give a discount but reserve no capacity. Zonal Reserved Instances reserve capacity in one Availability Zone.

On-Demand Capacity Reservations hold capacity in a specific AZ without a term, billed at the On-Demand rate whether you use them or not. Pair them with a Savings Plan or regional RI to get the discount as well. For short GPU needs, such as a training run, EC2 Capacity Blocks for ML reserve accelerated instances for a defined future window.

Spot done well

Spot suits stateless tiers, containers, CI, batch and checkpointed training. Diversify across many instance types and AZs, and use the price capacity optimized allocation strategy in an Auto Scaling group or EC2 Fleet. Handle the two minute notice and rebalance recommendations so work drains cleanly.

Database capacity modes and commitments

DynamoDB reserved capacity applies only to provisioned mode. On-demand is now the default and recommended mode for most tables, so a commitment only makes sense for steady, well forecast provisioned throughput.

Aurora I/O-Optimized removes per request I/O charges in exchange for higher instance and storage rates. You can switch from Standard to I/O-Optimized once every 30 days, and back to Standard at any time.

Database Savings Plans are a 1 year commitment with no upfront payment. AWS documents coverage across services including Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS and OpenSearch Service, including serverless options and DynamoDB on-demand and provisioned throughput. Instance coverage applies to the latest instance generations only, the plan reserves no capacity, and it cannot be combined with RIs or DynamoDB reserved capacity on the same usage.

Turning things off

Non production databases cost money while idle. An RDS instance can be stopped, but it restarts automatically after seven days. Aurora is stopped at the cluster level, because individual Aurora instances cannot be stopped.

For test environments used a few hours a day, Aurora Serverless v2 is often simpler than a stop and start schedule.

How the exam asks about this

• "A company runs a steady EC2 baseline but plans to move part of it to Fargate and Lambda next year." -> Compute Savings Plans, because the commitment follows the usage across services.
• "Nightly batch jobs can restart if interrupted and must cost as little as possible." -> Spot Instances, diversified across instance types with checkpointing.
• "A DynamoDB table has unpredictable bursts and no capacity planning team." -> On-demand mode, not provisioned capacity with reserved capacity.