AWS Pricing Models Explained: On-Demand, Reserved, Spot & Savings Plans

Every AWS compute pricing question comes down to one trade: flexibility versus discount. The less you commit — in time, money, or tolerance for interruption — the more you pay per hour. The more you commit, the deeper the discount. AWS prices EC2 usage per second (with a minimum, and per hour for some operating systems), so you only ever pay for what runs; the purchasing options change the rate, not the metering.

There are three ways to earn a discount, and each defines a family of options. First, commit to time: promise AWS one or three years of usage and get Reserved Instances or Savings Plans, with discounts AWS frames as up to 72% versus On-Demand. Second, accept interruption: run on spare capacity that AWS can reclaim at short notice and get Spot Instances at up to 90% off. Third, commit to nothing: pay the full On-Demand rate and keep total freedom to start, stop, and resize at any moment.

Alongside these sit three options that answer different questions than "how do I pay less?": Dedicated Hosts and Dedicated Instances answer "how do I get isolated physical hardware?", and Capacity Reservations answer "how do I guarantee capacity will exist when I need it?". Keeping those purposes separate — discount options versus isolation options versus capacity assurance — is the single most useful mental model for this task statement, because the exam deliberately mixes them in the same answer lists.

Work through each option below, then use the comparison table to lock in the triggers.

On-Demand is the default way to pay for EC2. You launch an instance, pay the published rate per second or per hour while it runs, and stop paying the moment you stop or terminate it. There is no upfront payment, no minimum commitment, and no long-term contract. You can change instance types, scale to zero, or walk away entirely — nothing binds you.

That freedom is exactly why On-Demand carries the highest effective price of all the purchasing options over the long run. Every discount mechanism AWS offers requires you to give something up — a time commitment or interruption tolerance — and On-Demand gives up neither.

On-Demand is the right answer when the workload is:

• Unpredictable or spiky — you cannot forecast usage well enough to commit to a baseline.
• Short-term — a project measured in days or weeks, where a one-year commitment makes no sense.
• New or being tested — a first-time application whose steady-state usage is still unknown. A common pattern is to run new workloads On-Demand first, measure real usage, and only then commit that measured baseline to a Reserved Instance or Savings Plan.
• Business-critical but irregular — it cannot tolerate Spot interruption, yet it does not run steadily enough to justify a commitment.

On the exam, phrases like "unpredictable workload", "cannot commit", "short-term project", or "developing and testing a new application" all point to On-Demand. If a question describes traffic spikes on top of a steady baseline, the spike portion is typically served On-Demand while the baseline is covered by a commitment — a pattern you will see in the scenario later in this lesson.

A Reserved Instance (RI) is a commitment to a specific amount of EC2 usage for a one-year or three-year term in exchange for a significant discount — up to 72% compared with On-Demand pricing in AWS's published framing. The three-year term earns a deeper discount than the one-year term.

The most misunderstood point, and a favorite exam distinction: an RI is a billing discount, not a physical instance. You do not "launch" a Reserved Instance. You purchase the reservation, and the discount is automatically applied to any running instance in your account that matches the reservation's attributes (instance type, Region, platform, tenancy). If no matching instance is running, you pay for the reservation anyway — an unused RI is wasted money.

RIs come in two offering classes:

• Standard RIs — the largest discount, but limited flexibility. You can modify some attributes — the Availability Zone, the scope, and (for Linux/Unix RIs) the instance size within the same family — but you cannot change the instance family or operating system.
• Convertible RIs — a smaller discount, but you can exchange them for other Convertible RIs with a different instance family, type, OS, or tenancy during the term. Choose Convertible when you expect your needs to change.

Three payment options control how much of the commitment you pay upfront — and the more you pay upfront, the bigger the discount:

• All Upfront — pay the entire term at purchase; largest discount.
• Partial Upfront — pay part now, the rest monthly; middle discount.
• No Upfront — pay nothing at purchase, everything monthly; smallest discount.

Scope: regional or zonal

An RI's scope decides where its discount lands, and it is a separate choice from the offering class: Standard and Convertible RIs can each be bought as regional or zonal.

Size flexibility works through a normalization factor: within a family, a large counts as two mediums, so one regional t3.large RI fully covers two running t3.medium instances, or half of a t3.xlarge, with no action on your part. That is why a regional RI suits an Auto Scaling group that launches whatever size and zone has room, while a zonal RI suits a fixed instance that must be able to launch in one particular AZ.

Scope is not locked for the term. You can modify an existing Standard or Convertible RI from regional to zonal and back, or move a zonal RI to another AZ in the same Region, at no charge. Each move has a cost in flexibility: switching to zonal gains the capacity reservation but pins the discount to one AZ and drops size flexibility; switching to regional regains that flexibility but gives up the capacity reservation. If you need capacity in one AZ and want the discount to keep floating across the Region, keep the regional RI (or Savings Plan) and add an On-Demand Capacity Reservation in that AZ, covered below.

Exam trigger: a workload described as steady-state, predictable, running continuously for at least a year — a production database server is the classic example — points to Reserved Instances (or Savings Plans, covered next).

Savings Plans are AWS's newer, more flexible commitment model. Instead of committing to a particular instance configuration, you commit to a consistent amount of compute spend, measured in dollars per hour, for a one- or three-year term. Any eligible usage up to that hourly commitment is billed at the discounted Savings Plans rate; usage above it is billed at normal On-Demand rates. Discounts reach the same headline level as RIs — up to 72% versus On-Demand.

Two types matter for CLF-C02:

• Compute Savings Plans — the most flexible commitment AWS sells. The discount automatically applies to EC2 usage regardless of instance family, size, operating system, tenancy, or Region — and it also covers AWS Fargate and AWS Lambda usage. Flexibility costs a little: the maximum discount is somewhat lower than the less flexible options.
• EC2 Instance Savings Plans — commit to a specific instance family in a specific Region (for example, M5 usage in us-east-1) for a larger discount. Within that family and Region you keep flexibility across size, OS, and tenancy.

How do Savings Plans compare with Reserved Instances? Both offer 1- or 3-year terms, the same All/Partial/No Upfront payment options, and comparable maximum discounts. The difference is what you commit to: RIs lock in instance attributes, while Savings Plans lock in an hourly spend and let usage move freely underneath it. A Compute Savings Plan keeps its discount if you migrate from one instance family to another, move Regions, or shift workloads to Fargate or Lambda — changes that would strand a Standard RI. Note that Savings Plans do not reserve capacity; if you need a capacity guarantee, pair them with a Capacity Reservation.

Exam trigger: "consistent compute usage but wants flexibility to change instance types or Regions" or "also uses Fargate or Lambda" points to a Compute Savings Plan rather than a Reserved Instance.

Spot Instances let you run on AWS's spare, unused EC2 capacity at discounts of up to 90% off the On-Demand price — the deepest discount of any purchasing option. The catch defines everything about when to use them: when AWS needs that capacity back, it can interrupt your Spot Instance with a two-minute warning. Spot capacity availability and pricing also fluctuate with supply and demand, so instances may not always be available in the size and place you want.

Because interruption can happen at any time, Spot is only appropriate for workloads that are fault-tolerant, stateless or checkpointed, and time-flexible — work that can stop, lose an individual node, and resume or restart without business impact.

Good candidates for Spot:

• Batch processing and overnight jobs
• Big data and analytics processing
• CI/CD build and test fleets
• Image, video, and media rendering or transcoding
• Scientific computing, simulations, and machine-learning training that checkpoints progress
• Stateless, horizontally scaled workers behind a queue

Never use Spot for:

• Production databases or anything stateful that cannot lose a node
• Business-critical applications with strict availability requirements
• Workloads that cannot tolerate interruption or must finish by a hard deadline on fixed capacity

Exam trigger: the words "fault-tolerant", "can be interrupted", "flexible start and end times", or "batch" combined with "lowest cost" point to Spot. Conversely, if a question pairs "critical" or "cannot be interrupted" with a Spot answer choice, that choice is a distractor.

These three options solve problems other than "pay less per hour", and the exam loves to test the boundaries between them.

A Dedicated Host is an entire physical server allocated to your account. You control instance placement on it and — critically — you get visibility into the physical sockets and cores. That visibility is what makes Dedicated Hosts the answer for Bring Your Own License (BYOL) scenarios where existing server-bound software licenses (per-socket, per-core, or per-VM licenses such as certain Windows Server or SQL Server agreements) must be tied to identifiable physical hardware. It also satisfies strict compliance regimes that demand a dedicated physical machine. Dedicated Hosts are the most expensive EC2 option: you pay for the whole host, though On-Demand and reservation-style pricing exist for the host itself.

A Dedicated Instance runs on hardware dedicated to a single AWS account — no other customer's instances share the underlying physical server — but you get no visibility into or control over that host. AWS may move the instance to different dedicated hardware after a stop/start, and you cannot target placement or count sockets and cores. Choose Dedicated Instances when you need physical isolation from other customers but do not need host-level licensing visibility.

The contrast in one line: Dedicated Host = you manage the physical server (placement, socket/core visibility, BYOL); Dedicated Instance = isolated hardware, but AWS manages the host and you see nothing below the instance.

An On-Demand Capacity Reservation is different again: it reserves compute capacity for a specific instance type in a specific Availability Zone, with no one- or three-year term. It guarantees you can launch the reserved instances when you need them (think disaster-recovery capacity or a planned traffic event). There are two ways to create one. An immediate reservation starts as soon as you create it, has no commitment at all, and can be modified or canceled at any time. A future-dated reservation is requested ahead of time for a start date and carries a minimum commitment duration (14 days for most instance types): you can keep it longer, but canceling inside that window can incur a cancellation charge. Two exam-critical facts: a Capacity Reservation provides no billing discount by itself — you pay the On-Demand rate for the reserved capacity whether or not you use it — and it can be combined with Savings Plans or regional RIs so the discount and the capacity guarantee stack. (A zonal RI is the one single product that gives both a discount and AZ capacity, at the price of pinning its discount to that AZ.)

Use this table as your exam cheat sheet. If you can reproduce the "best for" and "exam trigger" columns from memory, you can answer nearly every purchasing-option question CLF-C02 asks.

Now apply it. A media company runs a customer-facing web platform with a steady baseline of application servers 24/7, processes uploaded videos in overnight batch transcoding jobs that can restart if a node dies, and sees unpredictable traffic spikes during viral events. The cost-optimal design maps each behavior to a model: a Compute Savings Plan (or RIs) covers the always-on baseline at up to 72% off; Spot Instances run the interruptible transcoding fleet at up to 90% off; and On-Demand absorbs the spikes, because the excess above the Savings Plan commitment simply bills at On-Demand rates with no penalty. One workload, three pricing models, each earning exactly the discount its behavior allows — that layered pattern is precisely what scenario questions reward.

Task 4.1 explicitly tests Reserved Instance behavior in AWS Organizations, so know this cold. When multiple AWS accounts are joined into an organization with consolidated billing, the management account receives one bill for all member accounts — and commitment discounts become a shared, organization-wide resource.

By default, RI and Savings Plans discount sharing is turned on: if one account purchases a Reserved Instance but is not running a matching instance in a given hour, the discount is automatically applied to a matching instance in any other account in the organization. The purchasing account always gets first claim on its own reservation; only unused discount capacity floats to other accounts. The same sharing applies to Savings Plans — unused hourly commitment in one account offsets eligible compute usage elsewhere in the organization.

Here is how it plays out: the production account holds a one-year regional RI for a c6i.xlarge in eu-west-1, but the workload it was bought for was retired mid-term. Meanwhile a test account in the same organization runs a c6i.xlarge in eu-west-1 at On-Demand rates. Under consolidated billing, the test account's instance receives the production account's RI discount for those hours — no configuration required. The organization's management account can disable RI and Savings Plans discount sharing for specific accounts, but sharing is the default behavior. Only the discount is shared: a zonal RI's capacity reservation stays with the account that owns it. Unless the management account has turned sharing off, an unused RI in one member account reduces the bill for matching usage in another.

Consolidated billing brings a second pricing benefit: aggregated usage. AWS applies volume-based tiered pricing to several services (data transfer and S3 storage among them), and the combined usage of all accounts is what counts toward those tiers. Ten accounts that individually would never reach a cheaper tier can reach it together, so every account effectively pays the lower blended rate. Managing Organizations itself and tools like Cost Explorer belong to other task statements — here, remember only what consolidated billing does to prices: shared commitment discounts and pooled volume tiers.

Data transfer pricing follows a small set of directional rules, and CLF-C02 tests them directly. The master rule: data coming into AWS is generally free; data going out costs money — and the farther it travels, the more it costs.

Generally free:

• Inbound data transfer from the internet into AWS — uploading data to EC2, S3, or virtually any service costs nothing for the transfer itself.
• Traffic between resources in the same Availability Zone over private IP addresses — typically free.
• Transfer between EC2 and many AWS services within the same Region is generally free: an application reading from or writing to an S3 bucket in its own Region pays no data transfer charge (S3 request and any retrieval fees still apply).

Charged:

• Outbound data transfer from AWS to the internet — billed per GB, with rates that vary by Region (a small monthly free allowance exists, but treat internet egress as chargeable).
• Cross-Region transfer — moving data from one Region to another (replication, cross-Region backups) is billed per GB.
• Cross-AZ transfer within the same Region — traffic between instances in different Availability Zones generally incurs a per-GB charge, which surprises people who assume "same Region = free".

Exam questions compare directions: uploading 10 TB into S3 is free, downloading 1 TB back to on-premises is charged. Anchor on direction (in = free, out = paid) and distance (same AZ < cross-AZ < cross-Region < out to internet) and these items become mechanical.

Storage pricing trades a lower per-GB-month storage rate against higher costs to read the data back: the less often you access data, the cheaper it is to keep and the more each read costs. Every AWS storage service follows one base model — you pay per GB-month for what you store, with no pre-purchase and no charge for unused space — plus, depending on the class, request charges, per-GB retrieval fees, minimum storage durations and data transfer out per the rules above.

Amazon S3 shows the whole spectrum. The classes below are listed from the highest storage rate to the lowest:

Two charges explain most surprise bills. A retrieval fee is billed per GB every time data in an infrequent-access or archive class is read, so moving frequently read objects from S3 Standard to Standard-IA can raise the bill even though the storage rate fell. A minimum storage duration bills an object for at least that many days: delete or transition a Standard-IA object after 10 days and you still pay for 30, but an object kept longer than the minimum never incurs that charge. Standard-IA and Glacier Instant Retrieval also bill each object as at least 128 KB, which matters only for very small objects. When access patterns are unknown or change, S3 Intelligent-Tiering moves objects between access tiers automatically for a small per-object monitoring fee and charges no retrieval fees.

Block (Amazon EBS) and file (Amazon EFS) storage follow the same shape: EBS bills provisioned GB-months whether or not the volume is full, with cheaper HDD-backed and snapshot archive options, and EFS offers Infrequent Access and Archive storage classes with lower storage rates plus per-GB access charges. The decision rule is the same everywhere: cost follows access frequency. Records read once a year with an acceptable wait of hours belong in the cheapest archive class; data read many times a day belongs in the hot tier, because repeated retrieval fees would erase the storage savings.