Savings Plans, Reserved Instances, Coverage, and Sharing

Commitments are not architecture, but they change the bill

Purchase options sit on every SAP-C02 cost task, with different verbs. For a new solution (Task 2.6) you choose On-Demand, Spot, Savings Plans, or RIs to match how stable the design will be. For an existing estate (Task 3.5) you measure what already runs, then cover the baseline without over-committing a family you are about to rightsize or migrate. For organizational visibility (Task 1.5) you decide which account buys the commitment and whether RI and Savings Plans discount sharing is on so unused hours help other members.

A Savings Plan is a dollar-per-hour commitment for a one-year or three-year term, with All upfront, Partial upfront, or No upfront payment (deeper discounts typically follow longer terms and more upfront cash). You are not buying a specific instance. An EC2 Reserved Instance is a commitment to a specific configuration (and, for zonal RIs, a capacity reservation in an Availability Zone). That distinction drives almost every professional-level tradeoff.

AWS currently publishes four Savings Plans types. This exam chapter focuses on the three that dominate SAP-C02 compute and ML stems; Database Savings Plans additionally discount eligible database usage (for example Amazon RDS and Amazon Aurora families). Confirm current eligible services in the Savings Plans user guide before you memorize a SKU list.

Compute versus EC2 Instance versus SageMaker Savings Plans

Compute Savings Plans apply to Amazon EC2, AWS Fargate, and AWS Lambda. AWS documents savings of up to 66% off On-Demand, in the same band as Convertible RIs. The discount follows you across instance family, size, operating system, tenancy, and Region, and it follows you from EC2 into Fargate and Lambda. Use Compute plans when the new architecture might move to Graviton, another Region, or containers/serverless during the term, or when the existing estate is already a mix of those compute types.

EC2 Instance Savings Plans apply only to EC2, and only to a chosen instance family in a chosen Region. AWS documents savings of up to 72% off On-Demand, in the same band as Standard RIs. Inside that family and Region you still get automatic flexibility across size, OS, and tenancy (for example m7i.large to m7i.2xlarge). You do not get Fargate, Lambda, or another family. Use this plan when the workload is a stable EC2 standard (same family, same Region for the term) and you want the deeper rate without managing RI exchanges.

SageMaker Savings Plans (SageMaker AI Savings Plans in current docs) apply to Amazon SageMaker instance usage. They exist because Compute Savings Plans do not cover SageMaker. If training and inference hosts are a steady hourly dollars figure but instance types and Regions may change as models evolve, SageMaker plans keep the discount without a manual exchange. They never rescue an EC2 bill.

None of these plans is a capacity reservation. If the stem requires guaranteed EC2 capacity in an AZ (a product launch, a DR drill, a license-heavy footprint), add On-Demand Capacity Reservations (ODCR) or a zonal Standard RI. Savings Plans can still discount ODCR usage; they do not create the reservation.

Amazon EC2 Spot Instances are also not covered by Savings Plans. Spot spend does not eat the hourly commitment, and the plan does not stack extra discount on top of Spot.

Standard versus Convertible Reserved Instances

Standard RIs buy the deeper rate. Regional Standard RIs for Linux/UNIX with default tenancy offer instance size flexibility within the family (normalized units), which is why they still appear on SAP-C02 even after Savings Plans launched. Zonal Standard RIs reserve capacity in one AZ but give up that size flexibility. You can sell unused Standard RIs on the RI Marketplace if the term and offering match marketplace rules.

Convertible RIs buy the more flexible rate (AWS documents up to 66% off On-Demand). You can exchange them into a different instance family or OS as architecture changes, which is why they resemble Compute Savings Plans. You generally cannot sell Convertible RIs on the marketplace. If the stem is “we might move from m5 to m7g during the year and we already hold Convertible RIs,” exchanging those RIs or letting Compute Savings Plans cover the new usage is the design conversation—do not buy more Standard RIs of the old family first.

RDS, ElastiCache, Redshift, and other services still offer service-specific RIs (and, where available, Database Savings Plans). Compute Savings Plans will not discount an Amazon RDS instance. When the stem is a database fleet, look at that service's commitment instruments, not an EC2 Instance plan.

How discounts apply each hour, including across accounts

AWS applies matching EC2 RIs first, then EC2 Instance Savings Plans, then Compute Savings Plans. Remaining eligible usage is On-Demand. Within Savings Plans, AWS applies the commitment to the usage with the highest savings percentage first (ties break toward the lower Savings Plans rate). Unused commitment in one hour does not roll to the next hour.

In a consolidated billing family with sharing enabled (the default), a Savings Plan applies first to the owner account's usage, then to other accounts. Unused RI benefits similarly attach to matching usage in other members. You can turn sharing off per account when a member must not consume another team's commitment (a regulated tenant, a resale customer, an account whose showback must stand alone). Turning sharing off is a Task 1.5 visibility/chargeback decision; it can lower utilization for the buyer and lower coverage for everyone else.

Buy commitments in the account that owns the baseline when you want simple showback of the hourly charge, or buy in the management account when FinOps wants a central pool. Neither pattern is universally cheaper; sharing is what makes a central pool work.

Coverage versus utilization (existing spend) versus sizing the buy (new spend)

Utilization asks: of the commitment we already purchased, what fraction was consumed? Low utilization means you over-bought or the workload moved (rightsized, migrated to Fargate, shifted Region, or died). The Task 3.5 move is to stop the bleeding—exchange Convertible RIs, change architecture back into the covered shape only if that is still the right architecture, or simply not renew—not to purchase more of the same.

Coverage asks: of eligible On-Demand usage, what fraction was discounted? Low coverage means you are still paying On-Demand for a stable baseline. The Task 3.5 move is to cover that baseline after you have rightsized, because committing to oversized r5.4xlarge usage locks in waste for one or three years.

AWS Budgets can alert on both metrics. Cost Explorer recommendations are a starting point, not a purchase order: they look backward, they do not know you are about to move the fleet to Graviton next quarter, and they do not know a product is being retired.

For a new 24/7 service (Task 2.6), estimate the always-on floor, commit only to that floor, and leave burst on On-Demand or Spot. For a new batch pipeline with no steady hourly dollars, do not buy a three-year EC2 Instance plan “just in case.” For an existing mixed estate that will keep changing families, prefer Compute Savings Plans for the remaining uncovered baseline rather than stacking Standard RIs of today's family.