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. A zonal RI (scoped to a specific Availability Zone) additionally provides a capacity reservation in that AZ; a regional RI provides only the discount but applies more flexibly across the Region.

RIs come in two offering classes:

• Standard RIs — the largest discount, but limited flexibility. You can modify some attributes (such as instance size within the same family, for regional Linux RIs), 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.

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 in a specific Availability Zone for any duration — no one- or three-year term required, and you can cancel anytime. It guarantees you can launch the reserved instances when you need them (think disaster-recovery capacity or a planned traffic event). 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.

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.

Consider the standard exam setup: Account A owns a three-year RI for an m5.large in us-east-1 but stopped its matching instance this month, while Account B in the same organization runs an identical m5.large in us-east-1 at On-Demand rates. Under consolidated billing, Account B's instance receives Account A'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, and "discounts are shared across the organization" is the answer the exam expects.

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 from EC2 to many AWS services within the same Region (for example, EC2 to S3 in the same Region) is generally free.

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 follows one shared model: you pay per GB-month for what you store — no pre-purchase, no charge for unused space — plus, depending on the service, request charges, retrieval fees, and data transfer out per the rules above. The tiering principle is the exam's real target: the less frequently you access data, the cheaper the per-GB-month rate, but the more you pay to get it back. Hot tiers charge the highest storage rate with little or no retrieval cost; infrequent-access tiers cut the storage rate but add per-GB retrieval fees and minimum storage durations; archive tiers (the Glacier family in S3) drive the GB-month rate to a small fraction of the hot tier's in exchange for retrieval fees and waits from minutes to hours. Block (EBS) and file (EFS) storage follow the same shape with lower-cost infrequent-access options. So when a question says "compliance archives accessed once a year", the archive tier minimizes cost; flip it to "read many times per day" and the hot tier wins, because repeated retrieval fees would erase the storage savings. Cost follows access frequency.