AWS Cloud Practitioner Study Notes · Part 1
Choosing an AWS Pricing Model by Workload Behaviour
AWS Cloud Practitioner study notes on On-Demand, Savings Plans, Reserved Instances, Spot, Dedicated Hosts, and Capacity Reservations.
Choosing an AWS pricing model is a workload decision, not a simple search for the largest percentage discount. The right option depends on how predictable the workload is, whether it can tolerate interruption, how much configuration flexibility is needed, and whether the requirement is a lower bill or guaranteed capacity.
These notes focus on the main Amazon EC2 purchasing options that commonly appear in Cloud Practitioner study material. The same idea applies more broadly: AWS services do not all support the same pricing models, so always check the service-specific pricing page before assuming that an option is available.
Start with the trade-off: flexibility, commitment, or capacity
The options can be grouped by the problem they solve:
| Option | Main trade-off | Typical fit |
|---|---|---|
| On-Demand Instances | Maximum flexibility, no commitment discount | Unpredictable or short-lived workloads |
| Savings Plans | Lower rates in exchange for a one- or three-year hourly spend commitment | Predictable compute spend that may change shape |
| Reserved Instances | Lower rates in exchange for a one- or three-year commitment to instance characteristics | Stable, known configurations |
| Spot Instances | Deep discounts in exchange for accepting interruption | Fault-tolerant and flexible workloads |
| Dedicated Hosts | Pay for an entire physical host | Server-bound licensing or host-level requirements |
| Capacity Reservations | Pay On-Demand rates to hold capacity in an Availability Zone | A known need for launch capacity |
This distinction prevents a common exam mistake: treating every “reserved” option as the same thing. A Reserved Instance is primarily a billing commitment. A Capacity Reservation is primarily a capacity-availability commitment. They can be used together, but they answer different questions.
On-Demand Instances: pay for flexibility
On-Demand is the default model. There is no long-term commitment or upfront commitment to a particular usage level. You launch an instance, pay for eligible usage, and can stop or terminate it as the workload changes. Billing granularity depends on the service and operating system; EC2 documentation describes per-second billing for supported configurations, with a minimum charge in applicable cases.
On-Demand is a strong fit for:
- Development and test environments
- Short-term workloads
- New products with uncertain demand
- Workloads that cannot make a useful commitment yet
The important point is not that On-Demand is always expensive. It is that the premium buys optionality. A new application may have very uncertain traffic, so committing to a three-year pattern before usage stabilises can create more risk than savings.
For an exam question that emphasises unpredictable usage and no commitment, On-Demand is usually the intended answer.
Savings Plans: commit to spend, keep more flexibility
Savings Plans reduce eligible usage rates when you commit to a consistent amount of compute usage, measured in dollars per hour, for one or three years. The commitment is monetary: for example, a plan might commit to USD 10 of eligible compute usage per hour. Usage above the commitment is billed at the applicable On-Demand rate.
There are two important types:
- Compute Savings Plans provide the broadest flexibility. They can apply across EC2, AWS Fargate, and AWS Lambda, including changes in instance family, size, Region, operating system, or tenancy within the plan’s rules.
- EC2 Instance Savings Plans provide a larger potential discount but apply to a chosen EC2 instance family in a Region. They still allow flexibility across sizes, operating systems, and tenancy for that family.
AWS documents maximum savings of up to 66% for Compute Savings Plans and up to 72% for EC2 Instance Savings Plans compared with On-Demand pricing. These are maximums, not a promise that every workload will receive that saving.
Savings Plans are useful when the amount of compute is reasonably predictable but the exact EC2 shape may change. For example, a team might move from general-purpose instances to compute-optimised instances as its application evolves. A Compute Savings Plan can follow more of that change than a commitment tied to one instance configuration.
The exam shortcut is: if the workload is steady enough for a commitment but the question highlights flexibility across compute usage, consider Savings Plans. Remember that Savings Plans do not themselves reserve EC2 capacity.
Reserved Instances: commit to a configuration
Reserved Instances reduce the rate for a consistent instance configuration over a one- or three-year term. For EC2, the relevant attributes can include instance type or family, Region, tenancy, platform, and scope, depending on the RI type.
Standard RIs generally offer the deepest RI discount but have less flexibility. Convertible RIs allow exchanges for configurations with equal or greater value, which provides more flexibility but requires an explicit exchange. Regional RIs can also provide instance-size flexibility under their rules.
RIs are therefore a better fit when the configuration is stable and the organisation understands the commitment it is making. They are not automatically the best answer for every always-on production server. A stable workload may still change instance families, Regions, operating systems, or deployment architecture during the term.
RIs also exist for services such as Amazon RDS, Amazon ElastiCache, and Amazon OpenSearch Service, with service-specific rules. Do not transfer EC2 RI assumptions to another AWS service without checking its documentation.
Spot Instances: trade interruption for a lower price
Spot Instances use spare EC2 capacity and can provide discounts of up to 90% compared with On-Demand pricing. AWS can interrupt a Spot Instance when it needs the capacity back, so the application must be designed for that possibility.
Good candidates include batch processing, rendering, distributed data analysis, container workers, and machine-learning jobs that can checkpoint and resume. Poor candidates include a single database server or a stateful service that cannot recover when its instance disappears.
Spot is not simply “cheap EC2”. It changes the availability contract. A resilient design may use multiple instance types and Availability Zones, a capacity-aware queue, checkpointing, graceful shutdown handling, and On-Demand capacity for the parts that must remain available.
For exam questions, “the workload can tolerate interruption” is the key clue for Spot.
Dedicated Hosts: solve licensing and host-isolation requirements
A Dedicated Host is a physical EC2 server dedicated to one AWS account. It provides visibility into the host’s physical sockets and cores and can support software licences that are tied to physical hardware, such as certain bring-your-own-licence arrangements.
Dedicated Hosts can also help with regulatory or operational requirements that call for dedicated hardware. They are not the normal answer when a workload merely needs better performance. They are priced per physical host, so utilisation matters: paying for an entire host while using only a small portion can be inefficient.
Keep Dedicated Hosts distinct from Dedicated Instances. Dedicated Instances run on hardware dedicated to an account, but do not provide the same host visibility and placement control.
Capacity Reservations: guarantee capacity, not a discount
An On-Demand Capacity Reservation reserves EC2 capacity for matching instances in a specific Availability Zone. This is useful when a workload must be able to launch during a capacity-constrained event, such as a planned traffic spike.
Capacity Reservations are billed at the equivalent On-Demand rate whether the reserved capacity is running an instance or sitting unused. That means a reservation can guarantee capacity without reducing the price. Savings Plans or Regional Reserved Instances may apply to eligible usage layered on top of the Capacity Reservation, but the reservation itself is not a discount.
This is the exam distinction to remember:
- Reserved Instance: primarily a pricing commitment.
- Capacity Reservation: primarily a capacity guarantee.
If the question says “the company needs EC2 capacity available in a particular Availability Zone”, think Capacity Reservation. If it says “the company wants a lower rate for a predictable configuration”, think Reserved Instance or Savings Plan depending on the flexibility described.
A practical decision sequence
When comparing options, ask these questions in order:
- Can the workload be interrupted? If yes, evaluate Spot.
- Is the workload short-lived or genuinely unpredictable? If yes, use On-Demand while the pattern is unknown.
- Is compute spend predictable for one or three years? If yes, compare Savings Plans and RIs using actual usage data.
- Is the exact configuration stable? If yes, an RI may fit; if the compute shape can change, Savings Plans usually preserve more flexibility.
- Is the requirement guaranteed capacity in a particular Availability Zone? Add a Capacity Reservation.
- Is physical host visibility or server-bound licensing required? Evaluate Dedicated Hosts.
In real cost optimisation, this is a portfolio decision rather than a single choice. A service might use a baseline Savings Plan, Spot workers for interruptible jobs, and On-Demand capacity for unpredictable peaks. AWS Cost Explorer recommendations and workload-level usage analysis can help estimate a commitment, but the commitment should be reviewed as the workload changes.
Conclusion
The most useful way to remember AWS pricing models is to connect each one to the risk it accepts. On-Demand accepts a higher rate for flexibility. Savings Plans and Reserved Instances accept a longer commitment for lower rates. Spot accepts interruption for a deeper discount. Dedicated Hosts accept host-level cost for licensing or isolation requirements. Capacity Reservations accept On-Demand charges to secure launch capacity.
For the Cloud Practitioner exam, identify the constraint in the question first. For real systems, validate the decision against usage history, failure handling, configuration changes, capacity requirements, and the AWS service’s current pricing rules.