SAP-C03 Pricing Models: Savings Plans, Reserved and Spot Capacity, Graviton, Step Functions, Rightsizing and AI Cost Optimization

You match purchase options to usage by splitting a workload's capacity into layers and buying each layer differently: a commitment (Savings Plans or Reserved Instances) for the floor that runs every hour of the term, On-Demand for peaks that must not be interrupted but do not run all the time, and Spot for work that tolerates interruption. Capacity guarantees (On-Demand Capacity Reservations, EC2 Capacity Blocks for ML) are a separate decision from discounts and are added only where the workload must be able to launch at a given place or time.

A worked layering: an order-processing API that never runs fewer than 40 instances, and grows to 90 during a four-hour evening sales window, commits only to the 40-instance floor and runs the extra 50 On-Demand. A commitment sized to the peak would sit idle for the other twenty hours of every day. Because the evening peak serves customers, it should not run on Spot; a weekend image-resizing job that can resume from where it stopped is the part that belongs on Spot. A Spot maximum price only caps what you pay; it never stops AWS reclaiming capacity.

The same floor-versus-variable logic applies to managed services that offer a provisioned capacity mode alongside on-demand pricing: provision (and, where offered, reserve) the predictable baseline and leave spiky or unknown traffic on on-demand. Choosing capacity modes for databases and streams is covered in the Task 3.4 lesson; Bedrock Provisioned Throughput is covered later in this lesson.

Choose the commitment type by how much the fleet will change over the term: the more flexibility you need, the smaller the discount. A Compute Savings Plan applies to EC2 in any instance family, size, operating system, tenancy and Region, and also to AWS Fargate and AWS Lambda. An EC2 Instance Savings Plan is bound to one instance family in one Region (any size, operating system or tenancy within it) and gives a deeper discount. Reserved Instances describe a specific instance configuration and are the least flexible.

The decision follows the plan for the fleet. A fleet that will move between families, between Regions, or from EC2 to Fargate and Lambda needs a Compute Savings Plan; nothing else follows it through all of those changes. A fleet that will stay in one family and Region for the whole term, even if sizes and operating systems vary, gets the largest discount without any exchanges from an EC2 Instance Savings Plan. Zonal RIs do not follow size changes, and Convertible RIs need manual exchanges each time the fleet changes.

Savings Plans come in 1-year and 3-year terms with No Upfront, Partial Upfront or All Upfront payment. Longer terms and more upfront payment raise the discount.

How Savings Plans commitments are consumed (and wasted)

A Savings Plan is a commitment to spend a fixed amount per hour, measured at Savings Plans rates, for every hour of its term. AWS applies it automatically to eligible usage in each hour, starting with the usage that gets the highest discount. Commitment not used in an hour is lost; it does not roll over to the next hour.

• Use it or lose it, hour by hour. A plan sized to an average spend is fully used in busy hours and partly idle in quiet ones. The Savings Plans utilization report shows the idle share.
• It cannot be changed. A Savings Plan cannot be reduced, modified, exchanged or resold. AWS allows a recently purchased plan to be returned only within a short window after purchase, subject to conditions. Unlike Standard Reserved Instances, there is no marketplace for unused plans.
• It never applies to Spot. Spot usage is billed at Spot prices and does not consume commitment. Moving work from On-Demand to Spot during hours when commitment is idle makes the commitment waste worse, because the idle commitment is still paid and the Spot usage is billed on top.
• It is measured at discounted rates. A $10 hourly commitment covers more than $10 of On-Demand usage. To cover a planned end state of, say, $30 per hour of On-Demand-equivalent spend, the commitment is the cost of that usage at Savings Plans rates, which is noticeably less than $30.

When commitment is idle in some hours, the remaining lever is to move time-flexible On-Demand usage (batch jobs, reports, test runs) into those hours, where it is absorbed by commitment you pay for anyway. Future purchases should be sized to the floor, not the average. Savings Plans purchase recommendations (in AWS Cost Explorer and Cost Optimization Hub) analyse recent usage to suggest a commitment.

Capacity-based options guarantee that instances can launch; they are separate from, and can be combined with, discount-based commitments. Use them only when a workload cannot tolerate an insufficient-capacity error at launch time.

ODCR plus a Savings Plan separates capacity from discount: the ODCR guarantees instances in the required zone (for example, the zone that hosts a latency-sensitive database primary), and a Savings Plan discounts the reserved capacity exactly as it discounts running instances. Because an ODCR names one instance type, a planned move to another family means recreating the reservation for the new type; a Compute Savings Plan keeps discounting it, whereas a zonal RI or an EC2 Instance Savings Plan stays tied to the original family.

Capacity Blocks for ML fit a short, scheduled accelerator need: book the instance count, start date and duration in advance, and the capacity is yours for that window with no commitment afterwards. Compare the alternatives by how they bill and what they guarantee: an ODCR bills from the moment it is created, Spot capacity can be reclaimed, and a Savings Plan is a discount rather than a reservation.

Spot is economical when the workload is spread over many Spot capacity pools, because AWS reclaims capacity pool by pool. A pool is one instance type in one Availability Zone, so a group that uses one type in one zone depends on a single pool and suffers frequent interruptions and long waits for capacity.

• Diversify. Add several similar-sized instance types (across families and generations) to an Auto Scaling group mixed instances policy or an EC2 Fleet, and span every Availability Zone the workload can use. Attribute-based instance type selection (vCPU and memory ranges) keeps the list broad automatically.
• Use price-capacity-optimized allocation. It launches into pools that are both deep and low-priced. The lowest-price strategy chases the cheapest pools regardless of depth and raises interruption rates.
• Protect a baseline with On-Demand. In a mixed instances policy, OnDemandBaseCapacity sets how many instances are always On-Demand, and OnDemandPercentageAboveBaseCapacity sets the On-Demand share of everything above that base. A base of 4 with 0% above it keeps four non-reclaimable instances and makes every additional instance Spot.
• Replace before the reclaim. Capacity Rebalancing lets the group act on EC2 rebalance recommendations, which usually arrive before the two-minute interruption notice: it launches a replacement and then terminates the at-risk instance, so capacity does not dip.

Interruption frequency is a property of the pools you draw from, so the fixes are about breadth and allocation, not bidding: the maximum price only limits what you pay. Graceful shutdown handling for containers is covered in the containers lesson for Task 1.2.

AWS Graviton (arm64) processors deliver better price performance than comparable x86 instances, so moving compatible workloads to Graviton is one of the few savings that needs no commitment. The work is a compatibility question: interpreted code (Python, Node.js, Java, .NET on Linux) usually runs unchanged, while native binaries and architecture-specific dependencies must be rebuilt for arm64.

• AWS Lambda: each function has an architecture setting, x86_64 or arm64. Changing it to arm64 runs the function on Graviton at a lower price per GB-second. Functions with no native or architecture-specific packages need only the setting change, redeployment and testing.
• Containers: build each image for linux/amd64 and linux/arm64 and push a multi-architecture manifest list (image index) to Amazon ECR under one tag. Each host pulls the variant that matches its processor, so services can migrate one at a time while sharing tags. On AWS Fargate, a task definition's runtimePlatform with cpuArchitecture set to ARM64 places that service's tasks on Graviton; on Amazon EKS or ECS on EC2, Graviton node groups or capacity providers do the same.
• EC2: Graviton families carry a g in the name (for example m7g, c7g, r7g). They run Linux, not Windows, so Windows instances stay on x86 families.

Graviton also interacts with commitments. A Compute Savings Plan keeps applying across an x86-to-Graviton move; an EC2 Instance Savings Plan or RI for the old x86 family does not. And because arm64 lowers the cost of the same work, a commitment should be sized to the post-migration spend, not today's.

Choose the Step Functions workflow type by execution length, volume and delivery semantics, because the two types are priced on different units. Standard Workflows are billed per state transition; Express Workflows are billed per request and by duration and memory. High-volume, short, idempotent workflows are far cheaper as Express; long-running or human-in-the-loop workflows need Standard.

• The type is fixed at creation. You cannot change an existing state machine from Standard to Express. To switch, create a new state machine of the other type from the same definition and point the event source at it.
• Mix them. A Standard parent can wait days for an approval callback with .waitForTaskToken, then use a Distributed Map state whose item processing runs as Express child workflows, so thousands of short, idempotent item steps are billed by Express pricing instead of by transitions. Concurrency settings change how fast items are processed, not how they are billed.
• Fewer, larger states also mean fewer transitions, but moving orchestration into function code trades away the visibility, retries and error handling Step Functions provides. Prefer changing the workflow type when the cost problem is transition volume.

Lambda has two compute types with different cost shapes, and the right one depends on how steady the traffic is. Default Lambda charges for requests and execution duration (per millisecond, by memory) and scales to zero, so it is cheapest for spiky or mostly idle traffic. Lambda Managed Instances run functions on EC2 instances that Lambda provisions, patches and scales in your account through a capacity provider; you pay EC2 instance prices plus a management fee, so it suits steady, high-volume functions.

Lambda Managed Instances keep the Lambda programming model and event source integrations, which is what distinguishes them from rebuilding the function as containers on ECS. An EC2 Instance Savings Plan never covers default Lambda; it can cover the instances behind a capacity provider of the matching family (for example, a Graviton family when the functions are built for arm64).

Provisioned concurrency keeps execution environments initialized to remove cold starts. It is billed while configured, whether or not requests arrive, so it is a latency control, not a saving. Reserved concurrency is a scaling limit with no pricing effect.

Lambda also replaces lightly used servers: an internal API with short requests, bursty working-hours traffic and idle nights pays for idle EC2, Fargate tasks or managed instances, while default Lambda pays only when requests run. Lambda's 15-minute maximum timeout rules it out for longer jobs.

For a steady Lambda spend floor that you want to keep on default Lambda, two levers stack: switch to arm64 (lower duration price), then buy a Compute Savings Plan sized to the new, lower floor at Savings Plans rates.

AWS Compute Optimizer recommends better-sized resources from observed utilization: EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, Amazon ECS services on Fargate (task CPU and memory), RDS DB instances and commercial software licenses. Its recommendations are only as good as the metrics and lookback it sees, so know its preferences.

Preferences can be set at the organization, account or resource level. Note that metric resolution and metric coverage are different things: one-minute EC2 metrics still contain no memory data and no longer history.

Rightsize first, then commit. A 3-year Savings Plan bought for an oversized fleet commits money that will go unused once the fleet shrinks, and the commitment cannot be lowered. The sequence is: rightsize (smaller sizes, newer or Graviton families, smaller Fargate task sizes), measure the new steady baseline, then buy commitment for that baseline. If saving must start before a migration finishes, commit only to the end-state spend at Savings Plans rates, using a Compute Savings Plan that is consumed by the old fleet now and the new fleet later, and add commitment afterwards from purchase recommendations based on the new usage.

Scaling saves money by matching capacity to demand, and the policy should match how predictable the demand is. Each policy type answers a different pattern:

• Reactive policies cannot hide initialization time. If instances take ten minutes to become ready, target tracking adds them after the ramp has started. Lowering the target value to compensate keeps extra capacity all day. Predictive scaling launches ahead of the forecast (a scheduling buffer lets instances finish initializing), and it follows a cycle whose start time drifts, which fixed scheduled actions cannot.
• Queue workers scale on backlog per instance. CPU is a poor signal when messages wait in Amazon SQS while instances sit idle. Track ApproximateNumberOfMessagesVisible divided by the number of InService instances, built with metric math in the target tracking policy (no custom metric needed). The target is the acceptable backlog per instance: acceptable latency divided by average processing time per message (for example, 20 s ÷ 0.5 s = 40 messages per instance). Tracking raw queue depth ignores fleet size.

Fargate Spot runs ECS tasks on spare Fargate capacity at a discount. Tasks get a two-minute warning (a task state change event and SIGTERM) before they stop, and when Spot capacity is unavailable ECS does not fall back to regular Fargate: tasks wait until capacity returns. It fits stateless, interruption-tolerant work such as queue-fed workers, CI test runs that are rerun automatically, and batch jobs without hard deadlines. It does not fit a single-task service that must always run, a job with a fixed deadline that restarts from the beginning, or tasks that keep session state in memory. With no servers and no commitment, it is also the cheapest choice for short-lived workloads that may be retired soon. (Splitting a service between FARGATE and FARGATE_SPOT with base and weight is covered in the Task 1.2 lesson.)

AI/ML inference cost is driven by which tier or instance runs each request, whether work is batched, and whether repeated work is cached. Bedrock inference cost depends on three choices: the service tier a request runs on, whether work is sent as batch jobs, and whether repeated content is cached. Choose a tier from the latency and capacity the workload needs, then remove repeated work with caching.

Some options are easy to confuse. Flex vs batch: both are discounted for latency-tolerant work, but batch requires reworking calls into S3-based jobs, while Flex keeps synchronous Converse or InvokeModel calls. Reserved vs Priority vs a quota increase: only Reserved guarantees capacity at a fixed price; Priority speeds requests but still shares the on-demand quota, and a quota increase permits more traffic without reserving any.

Bedrock caching patterns

• Prompt caching discounts repeated input. Put static content (system prompt, documents, tool definitions) first and place a cache checkpoint after it, so the variable part (the user's question) follows the cached prefix; content after a change in the prefix is not a cache hit. The cache has a time to live (commonly five minutes, with longer TTLs, such as one hour, on models that support them; check the model's documentation), and every hit resets it. If requests arrive further apart than the TTL, choose the longer TTL or the cache expires between calls. Prompt caching is not supported with the batch inference API, so the two discounts do not stack.
• Application-level response caching avoids the model call entirely. When a large share of requests repeat exactly and the underlying data changes predictably, store whole responses in a cache (for example an in-memory store) with an expiry that matches how often the data changes, so a repeat costs no input or output tokens. Semantic caching extends this to near-duplicate questions using vector similarity. Prompt caching discounts only input tokens, so it saves little where most of the bill is generated output.

Other levers include choosing the smallest model that meets quality needs, model distillation, and intelligent prompt routing between models in a family. Cross-Region inference and its data-transfer effects belong to Task 3.2, and Bedrock token-usage chargeback to Task 3.3.

Amazon SageMaker AI inference costs

SageMaker AI inference cost is set by the instance an endpoint runs on, whether the endpoint runs when idle, and whether steady usage is committed. Pick the inference option from the traffic pattern and latency requirement, then the cheapest instance that meets it.

• Accelerator choice: models that compile with the AWS Neuron SDK can run on AWS Inferentia2 (ml.inf2) instances, which are built for low cost per inference. Moving a compatible model off general-purpose GPU instances lowers cost with no commitment and no change to how clients call a real-time endpoint.
• Option fit: real-time endpoints for steady, synchronous, low-latency traffic; serverless inference for intermittent traffic that tolerates cold starts (priced for idle-heavy use, not steady high volume); asynchronous inference for large payloads or long processing, which can scale to zero; batch transform for offline datasets. Inference components and multi-model endpoints share instances between models. (Choosing between these options for functional reasons is covered in the Task 1.3 lesson.)
• SageMaker AI Savings Plans discount SageMaker AI instance usage (endpoints, training, notebooks and other components) across instance families, sizes and Regions, for 1 or 3 years. They are a separate product: a Compute Savings Plan does not cover SageMaker AI, and a SageMaker AI Savings Plan does not cover EC2. Size each plan to its own service's steady baseline; one plan sized to the combined spend commits money the other service cannot consume.