Pricing Models

The same EC2 capacity can cost wildly different amounts depending on one choice: how much commitment you make to it. That trade, more commitment for a deeper discount, is the spine of every pricing question here, so reading a workload's tolerance for commitment is how you pick the cheapest option that fits. AWS charges pay-as-you-go across three dimensions: compute (time resources run), storage (data you keep), and data transfer (moving data out of and across AWS); the figure below groups those three fundamentals. The most-tested is how you buy compute, because the same EC2 capacity costs very different prices depending on how much commitment you make.

The core idea is a trade: the more you commit, the more you save.

• On-Demand is the no-commitment baseline. You pay the published per-second or per-hour rate with no upfront payment and no contract, starting and stopping whenever you like. It is the most expensive per hour but the most flexible.
• Reserved Instances (RIs) and Savings Plans are the commitment options: a one-year or three-year term buys a large discount versus On-Demand, and the three-year term plus larger upfront payments yield the biggest discounts. Note up front: an RI is a billing discount applied to matching usage, not a physical server you reserve.
• Spot Instances invert the deal: no commitment, but you accept that AWS can take the capacity back, for the deepest discount of all. Because the work simply resumes elsewhere, Spot is suitable (not unreliable) for interruption-tolerant jobs, including production ones.

The exam heuristic follows from that spectrum: steady and predictable → commit; interruptible → Spot; spiky, new, or short-term → On-Demand. AWS describes these EC2 purchase options together on the EC2 pricing overview^[1], and the deeper Reserved Instance mechanics live in the Reserved Instances overview^[2].

Both Reserved Instances and Savings Plans buy a discount with a one- or three-year commitment, but they commit to different things, and the exam tests the distinction. The figure below groups each family with its two variants so the split reads at a glance.

A Reserved Instance is a billing discount tied to specific instance attributes, never a physical server you reserve, as the previous section noted. The discount applies to On-Demand usage that matches attributes you choose: instance type, Region, tenancy (whether the hardware is shared with other AWS customers or single-tenant, see the next section), and platform/OS. There are two offering classes that trade discount for flexibility, per the Reserved Instances overview^[2]:

• Standard RIs give the biggest discount but can only be modified, not exchanged.
• Convertible RIs give a smaller discount but can be exchanged for another Convertible RI with different attributes, so they suit changing needs.

RIs also have a scope, regional or zonal, and the regional vs zonal documentation^[3] spells out the contrast the exam loves:

• A regional RI does not reserve capacity, but it gives Availability Zone flexibility (the discount applies in any AZ in the Region) and instance size flexibility (the discount applies across sizes within the same instance family, on Linux/Unix with default tenancy).
• A zonal RI reserves capacity in one specified Availability Zone, but has no AZ flexibility and no size flexibility: the discount applies only to that exact type and size in that AZ.

A Savings Plan commits to an amount of spend, not a configuration. Instead of pinning attributes, a Savings Plan commits you to a consistent dollar-per-hour amount for a one- or three-year term, and AWS automatically applies the discount to matching usage. The Savings Plans FAQ^[4] describes the two compute-relevant types:

• Compute Savings Plans are the most flexible: the discount automatically applies to EC2 usage regardless of instance family, size, Availability Zone, Region, OS, or tenancy, and also covers AWS Fargate and AWS Lambda.
• EC2 Instance Savings Plans give a larger discount but lock you to a specific instance family in a chosen Region: you can still change size, OS, AZ, and tenancy within that family and Region.

The exam's default guidance follows AWS's own: Savings Plans are recommended over Reserved Instances for most compute savings because they are simpler and more flexible, and they cover Fargate and Lambda, which RIs do not.

RIs and Savings Plans in AWS Organizations: with consolidated billing, an unused RI or Savings Plan discount is shared across all accounts in the organization by default, so a reservation bought in one account can benefit matching usage in a sibling account, maximizing utilization. The management account can turn this discount sharing off per account if needed.

Beyond the commitment spectrum, a few specialized options answer specific stems.

Spot Instances, interruptible spare capacity. Spot uses AWS's unused EC2 capacity at the deepest discount, but AWS can reclaim it when it needs the capacity back, giving only a two-minute interruption notice before the instance is stopped or terminated. As the opening section noted, this does not make Spot "unreliable": it makes it correct precisely for workloads that tolerate interruption: batch processing, big-data analytics, CI/CD, image/video rendering, and stateless or containerized jobs that can resume, including production ones. It is the wrong answer only for a steady production database, a stateful single server, or anything that cannot be safely stopped. AWS lists Spot among the EC2 purchase options on the EC2 pricing page^[1].

Dedicated Hosts vs Dedicated Instances, single-tenant hardware. This is the tenancy attribute the previous section referenced: both run your instances on hardware not shared with other AWS customers, usually to satisfy compliance/regulatory isolation or licensing rules, but they differ:

• A Dedicated Host is a whole physical server allocated to you, with visibility into its sockets and physical cores, which is what lets you reuse server-bound, per-socket or per-core bring-your-own-license (BYOL) software.
• A Dedicated Instance runs on hardware dedicated to your account but without that host-level visibility into sockets/cores.

Exam tell: 'must reuse our existing per-socket / per-core licenses' → Dedicated Host; 'isolated single-tenant hardware for compliance' with no licensing-visibility requirement → Dedicated Instance.

On-Demand Capacity Reservations, guarantee capacity, separate from discounts. A Capacity Reservation reserves EC2 capacity in a specific Availability Zone for any duration, so the capacity is there when you need it (for example, ahead of a known launch event or for disaster-recovery standby). Crucially, it is independent of any pricing discount: by itself it is billed at On-Demand rates whether or not you run instances in it, though it can be combined with a Savings Plan or regional RI to get both the guarantee and the discount. Don't confuse it with a regional RI, which gives a discount but no capacity guarantee.

Two non-compute pricing rules recur on the exam because they drive real bills.

Data transfer, you pay to move data out and across boundaries, not in. The directional rules, summarized from the EC2 On-Demand pricing page^[5] and traced in the figure below:

• Data transfer IN to AWS from the internet is free.
• Data transfer OUT to the internet is charged per GB above a small monthly free allowance (AWS provides 100 GB of free data-transfer-out to the internet each month, aggregated across services and Regions outside China and GovCloud).
• Between AWS Regions (inter-Region) data transfer is charged.
• Between Availability Zones within the same Region (inter-AZ) data transfer is charged in both directions per GB.
• Within a single Availability Zone over private IP addresses, traffic is generally free.

The cost-optimization takeaway the exam rewards: to lower the bill, reduce data egress to the internet and avoid unnecessary cross-Region and cross-AZ traffic (for example, keep chatty components in the same AZ, and serve repeat downloads from Amazon CloudFront so they don't re-egress from the origin each time).

Storage tier pricing, cheaper storage in exchange for less-frequent access. Amazon S3 offers a range of storage classes that are, per the S3 storage classes page^[6], "purpose-built to provide the lowest cost storage for different access patterns." The trade-off is consistent: the rarer the access, the lower the per-GB storage price, but the higher the retrieval cost and latency.

• S3 Standard, frequently accessed data; highest storage price, no retrieval fee.
• S3 Standard-Infrequent Access (Standard-IA) and S3 One Zone-IA, cheaper storage for infrequently accessed data (One Zone-IA stores in a single AZ, so it is even cheaper but less resilient).
• S3 Glacier Instant / Flexible Retrieval and S3 Glacier Deep Archive, archival classes with the lowest storage prices; Deep Archive is S3's lowest-cost class, intended for data accessed extremely rarely, with the longest retrieval times.
• S3 Intelligent-Tiering, for unknown or changing access patterns, it automatically moves objects to the most cost-effective tier based on access frequency with no retrieval fees, for a small per-object monitoring charge.

Exam tell: 'access pattern unknown or unpredictable' → S3 Intelligent-Tiering; 'rarely accessed, lowest cost, retrieval delay acceptable' → an S3 Glacier class (Deep Archive for the absolute cheapest, long-term archive).

Pricing-model questions are highly pattern-matchable once you anchor on the keywords in the stem. The diagram below traces the same predictability-and-interruption-tolerance test from the opening section down to a single purchase option; the keyword list then fills in the finer distinctions.

Compute purchasing, keyword to option:

• 'steady-state / runs 24x7 / predictable for the next year(s) / lowest cost without losing the instance' → Reserved Instance or Savings Plan. If the answer must span instance families, Regions, or include Fargate/Lambda, pick Compute Savings Plans; if it's a fixed, known instance family, an RI or EC2 Instance Savings Plan fits.
• 'flexible / changing usage / want savings but not to commit to a specific instance type' → Savings Plan (commit to spend, not config). AWS recommends Savings Plans over RIs as the default.
• 'fault-tolerant / batch / can be interrupted / stateless / cheapest possible compute' → Spot Instances.
• 'no commitment / unpredictable / short-term / spiky / just getting started' → On-Demand.
• 'must reserve capacity in a specific AZ ahead of a launch / DR standby' → On-Demand Capacity Reservation (note: it does not give a discount by itself).
• 'reuse existing per-core / per-socket software licenses (BYOL) on physical hardware' → Dedicated Host.
• 'single-tenant hardware for compliance/regulatory isolation' (no license-visibility need) → Dedicated Instance.

Distractor traps to expect:

1. RI vs Savings Plan precision. A stem stressing flexibility across families/Regions or coverage of Fargate/Lambda points to Compute Savings Plans, not a Reserved Instance. RIs don't cover Fargate or Lambda.
2. Capacity vs discount confusion. If the requirement is guaranteed capacity in an AZ, the answer is a Capacity Reservation (or a zonal RI, which does reserve capacity); a regional RI gives a discount but no capacity guarantee.
3. Spot for the wrong workload. Spot is the cheapest, but it is wrong whenever the workload cannot tolerate a two-minute interruption. Eliminate Spot for production databases and stateful single servers.
4. Cost optimization via data and storage. When a question asks how to reduce the bill, watch for answers about cutting data-transfer-out, avoiding cross-Region/cross-AZ traffic, and moving cold data to a cheaper S3 storage class, not just changing the compute purchase option.