AWS CRI study materials
AWS CRI study resources

AWS Certified Cloud Practitioner (CRI series): Billing, Pricing, and Support: Cost Drivers and Plan Selection

AWS CRI · Work through your exam, one topic at a time.

All guide sections

Billing, Pricing, and Support: Cost Drivers and Plan Selection

How pricing works

Candidates must reason about what drives cost rather than memorize prices. Compute is billed by time and instance size; storage by volume stored plus requests and retrieval in some classes; data transfer out to the internet is charged while inbound is typically free; and managed services add per-request or per-resource charges. The most common trap is ignoring data transfer, especially cross-Region or egress traffic, when comparing designs. A second trap is assuming stopped instances cost nothing; attached storage and some addresses continue to bill.

Pricing models

Know the trade-off triangle: on-demand for flexibility, savings commitments for predictable steady usage in exchange for a term, and spot capacity for interruptible work at a discount. Reserved commitments apply to a family and attributes, so a mismatch between the commitment and the actual instance type can waste the discount. A frequent question asks which model suits a variable, spiky workload; the answer is usually on-demand plus spot for the interruptible portion, not a large commitment.

Tools and support

Be able to distinguish cost exploration and forecasting from budgeting and alerting, and from consolidated billing across accounts. Consolidated billing pools usage, which can unlock volume discounts, but it does not automatically allocate costs to teams; tagging and cost allocation do that. Support plans differ in response times, access channels, and whether a technical account manager or proactive guidance is included. A trap is choosing the cheapest plan for a production system with a strict response requirement, or assuming all plans include the same access to architectural guidance.

Worked example

A team must run a predictable baseline of 10 servers continuously plus burst capacity for month-end peaks. Rule of thumb: commit only to the baseline, cover the burst with on-demand, and use spot for any batch work that can be interrupted. Committing to peak capacity is the classic over-purchase error, and questions often present it as a tempting distractor.