Billing, Pricing, and Support

Assuming only that everything you run on AWS has a price, by the end of this domain you can place a billing scenario at the right stage of one continuous money story rather than treating it as three unrelated topics. First, architectural choices set the price: purchasing options and where data flows decide the rate you pay before anything is built. Next, AWS gives a tool for each stage of the spend lifecycle: estimate it before launch, analyze and attribute it after the fact, and alert or act when it drifts. Finally, support plans and technical resources determine how much human and automated help you can call on, including the AWS Trusted Advisor checks that loop back to recommend further savings. The exam tests whether you can place a scenario at the correct stage of that flow.

Almost every question in this domain is really asking you to map a need onto exactly one offering. The four core cost tools split by time orientation: estimate before building points to the AWS Pricing Calculator, analyze past spend points to AWS Cost Explorer, alert at a threshold points to AWS Budgets, and most-detailed line-item data points to the AWS Cost and Usage Report (CUR). The Cost Explorer–versus–Budgets pair is the most-confused: Cost Explorer shows spend, forecast included, while Budgets acts when spend crosses a line (analyze versus react). AWS Trusted Advisor sits alongside those four as the recommend-an-action service: cutting spend on idle resources points to Trusted Advisor, not a time-oriented reporting tool. The same one-answer logic applies to support: the lowest tier that still meets the response-time and proactive-help requirement is the correct one.

Reducing the AWS bill is not one action but a stack of them. At the architecture layer, the deal is that the more you commit, the more you save: accepting a one- or three-year commitment (Savings Plans, Reserved Instances) trades flexibility for a discount, while Spot inverts the deal (no commitment, but you accept interruption) and keeping data inside a single Availability Zone avoids cross-boundary transfer charges. At the operations layer, tagging attributes spend to a team or project, Cost Explorer and the CUR make it visible, and AWS Budgets enforces a ceiling: a budget action can apply an IAM or Service Control Policy to stop provisioning when spend crosses the threshold. AWS positions Savings Plans as the default compute-savings mechanism over Reserved Instances because the discount follows usage automatically.

Several distinct levers in this domain all amplify through AWS Organizations consolidated billing, which produces a single bill paid by the management account at no extra charge. Combining usage across member accounts shares volume pricing tiers, pools the AWS Free Tier, and by default spreads unused Reserved Instance and Savings Plan discounts across the organization, so a reservation bought in one account benefits matching usage anywhere. The same organization boundary is where the Budgets action from the previous principle attaches its Service Control Policy as a hard guardrail. Treat consolidated billing as the setting that makes individual cost levers work at scale.