AWS Billing and Cost Management Tools: Budgets, Cost Explorer, CUR and More

All of the services in this lesson live in or around the AWS Billing and Cost Management console. That console is where you view your monthly bill, manage payment methods, download invoices, and activate cost allocation tags.

Getting help with a charge never requires a paid support plan. Every AWS account, including those on the free Basic plan, can open account and billing support cases at no charge, and AWS staff on that case can look at your actual invoice and account. Community channels such as AWS re:Post are useful for general pricing questions, but nobody there can see your account or explain a specific line on your bill. The details of the paid support plans belong to Task 4.3 (see the lesson on AWS Support plans and technical resources).

Pricing information is public; your cost data is private. Every AWS service publishes a pricing page, and AWS Pricing Calculator turns those published rates into architecture-level estimates. Two APIs are easy to confuse, and they answer different questions:

The fastest way to organize the tools is by tense — where you are in the cost lifecycle:

• Before you deploy anything: AWS Pricing Calculator estimates what an architecture will cost.
• During the month, as spend accumulates: AWS Budgets watches thresholds and alerts you proactively.
• After spend has happened: AWS Cost Explorer visualizes and analyzes it, and can forecast forward from that history.
• At maximum depth: the AWS Cost and Usage Report (CUR) delivers the raw, line-item data behind everything else.

Multi-account structures add two more: consolidated billing in AWS Organizations produces one bill for many accounts, and AWS Billing Conductor lets you present customized, pro-forma versions of that billing data. Cost allocation tags cut across all of it, attributing spend to the people and projects that generated it. Keep this map in your head; nearly every Task 4.2 question is a matching exercise against it.

AWS Pricing Calculator is a free tool for modeling what an architecture will cost before you build it. The public web version needs no AWS account and works purely from published pricing. You add services to an estimate, configure them the way you plan to run them (instance types, storage volumes, data transfer, Region), and the calculator produces monthly and 12-month cost projections.

Estimates can be organized into groups — for example, one group per application tier or per department — so a single estimate can model a whole solution. When you finish, you can share the estimate as a link or export it (for example, to CSV or PDF) to circulate with stakeholders. This makes it the standard answer for scenarios about planning a migration, comparing the cost of two candidate designs, or preparing a cloud budget proposal for management.

A newer version also lives inside the Billing and Cost Management console. Signed in, you can still build workload estimates, and you can also create bill estimates: start from your account's current usage and commitments, model a change (a new workload, a Savings Plans purchase, a migration), and see the effect on your bill. Either way, the output is an estimate of a planned change, not a record of what happened.

Keep the boundaries crisp, because the exam tests them. Pricing Calculator is not an analysis or alerting tool: it does not chart or break down what you spent last month (that is Cost Explorer) and it cannot alert you when spending crosses a limit (that is AWS Budgets). Conversely, no other tool in this lesson can price a workload that does not exist yet. The moment a question says estimate, planned workload, before migrating, or compare the projected cost of two configurations, the answer is AWS Pricing Calculator.

One adjacent fact: choosing how to buy compute (On-Demand, Reserved Instances, Savings Plans, Spot) is a separate pricing-models topic; the calculator simply lets you plug those options into an estimate.

AWS Budgets is the proactive tool. You define a budget — a limit you care about — and AWS watches your account against it continuously, sending alerts by email or Amazon SNS when a threshold is crossed. This is the only tool in the set that reaches out to you; everything else waits for you to look.

You can budget more than raw dollars. AWS Budgets supports four budget types:

• Cost budgets — alert when spend (actual or forecasted) exceeds an amount, e.g. $500 per month.
• Usage budgets — track consumption of one or more usage types, such as EC2 running hours or data transfer volume.
• Reserved Instance and Savings Plans utilization budgets — alert when the commitments you bought are sitting idle below a target percentage.
• RI and Savings Plans coverage budgets — alert when too much of your usage is running outside a commitment at On-Demand rates.

The detail the exam probes hardest: alerts can fire on actual values or on forecasted values. A forecasted alert warns you that you are on track to blow through the limit before it actually happens — the strongest form of proactive cost control. Budgets can also be scoped with filters (by service, linked account, or tag) and can repeat monthly, quarterly, or annually.

Beyond notification, budget actions make a budget enforce something when a threshold is crossed. An action can be triggered by an actual or a forecasted threshold, and it can run automatically or wait for someone to approve it. There are three action types, and the difference between them is what a scenario tests:

In short, a policy action (IAM policy or SCP) blocks further provisioning and leaves everything already running untouched, while an instance action stops the specific instances you chose. One boundary on the SCP option: SCPs never restrict the organization's management account, so an SCP action is useful only when it targets member accounts or OUs (SCPs themselves are covered in Domain 2).

Don't confuse budgets with AWS Cost Anomaly Detection. It uses machine-learning monitors to spot unusual spend patterns (no fixed threshold needed) and sends alerts by email or SNS, but it takes no enforcement action. Related one-liners: AWS Free Tier usage alerts warn you as you approach free-tier limits, and Amazon CloudWatch billing alarms are an older mechanism for alarming on total estimated charges. If the scenario says notify me, alert when spending exceeds, or keep the team under a limit, the answer is AWS Budgets.

AWS Cost Explorer is the interactive analysis tool for costs you have already incurred. It renders your historical spend and usage as charts and tables, defaulting to roughly the past thirteen months, and lets you slice the data by the dimensions that matter: service, linked account, Region, instance type, purchase option, and cost allocation tag. Filtering and grouping are the core moves — show me last quarter's spend grouped by service, or this month's EC2 cost split by the team tag.

Cost Explorer is retrospective first, but it also looks forward: from your usage history it produces a forecast of future spend (up to about twelve months out) with a confidence band. That forecast is derived from past behavior — contrast it with Pricing Calculator, which prices a hypothetical architecture from scratch with no history at all. Cost Explorer also offers finer granularity when you need it, including daily views and opt-in hourly and resource-level detail.

Two recommendation features ride along and are worth one line each: rightsizing recommendations identify underused instances you could downsize or terminate, and Reserved Instance / Savings Plans purchase recommendations suggest commitments based on your steady-state usage. Evaluating those purchase options in depth is the pricing-models topic; here you only need to know Cost Explorer is where the recommendations surface.

Exam triggers: visualize, analyze, which service cost the most last month, view spending trends, forecast next month's bill from history. If the question wants a chart, a breakdown, or an explanation of past spend, the answer is Cost Explorer — not Budgets (which alerts rather than analyzes) and not the CUR (which is raw data, not an interactive view).

When a question asks for the most detailed, most granular, or most comprehensive billing data available, the answer is the AWS Cost and Usage Report (CUR) — full stop. The CUR is not a dashboard; it is a data set. It contains line items for every charge in your account, broken down as finely as per resource, per hour, including the metadata attached to each line: service, operation, Region, pricing details, linked account, and your activated cost allocation tags as their own columns.

You configure the CUR to be delivered to an Amazon S3 bucket that you own, where AWS refreshes it at least daily as the month's charges finalize. Because it is raw data at scale, you analyze it with query and BI tools rather than reading it by hand — the classic pattern is Amazon Athena for SQL queries directly against the files in S3, with Amazon QuickSight (or Amazon Redshift) for dashboards. One housekeeping note for currency: AWS now delivers this data through the newer Data Exports feature (sometimes called CUR 2.0), but the exam and most documentation still call it the Cost and Usage Report, and the concept is unchanged.

Position it against Cost Explorer and the distinction writes itself: Cost Explorer is an interactive, visual summary with built-in charts and forecasts, ideal for humans exploring spend; the CUR is exhaustive raw detail, ideal for finance teams, chargeback pipelines, and custom analytics that need every line item. A scenario about auditing exactly which resource generated a charge at 3 a.m., feeding billing data into a data warehouse, or producing tag-level chargeback reports at line-item precision points to the CUR.

AWS Organizations lets a company manage many AWS accounts centrally, and its consolidated billing feature is a Task 4.2 staple. One account — the management account — receives a single bill covering itself and every member account. Consolidated billing carries four benefits the exam tests repeatedly:

• One bill for the whole organization: one invoice, one payment, far less accounting overhead.
• Combined usage for volume discounts: usage from all accounts is aggregated when AWS applies tiered pricing, so ten accounts each using a little can together reach discount tiers none would reach alone. The same aggregation applies to free-tier-style thresholds and tiered rates for services like S3 and data transfer.
• Shared Reserved Instance and Savings Plans discounts: an unused commitment discount purchased in one account can automatically apply to matching usage in another account in the organization (this sharing can be turned off per account). The mechanics of RIs themselves are a pricing-models topic; know here that discounts flow across the organization. These commitment discounts apply only to the usage they were bought for: a Compute Savings Plan to eligible EC2, Fargate and Lambda compute, a Database or SageMaker Savings Plan to its own database or machine-learning usage, and an RI to matching instance usage (for example EC2, RDS or ElastiCache). No commitment ever reduces data transfer charges, which get cheaper in an organization only through the combined volume tiers in the previous point.
• Per-account visibility at no extra charge: the combined bill still itemizes costs by member account, and consolidated billing itself costs nothing.

AWS Billing Conductor solves a different problem: the real bill is not always the bill you want to show. Resellers and solution providers who manage AWS for customers, and enterprises running internal chargeback, often need to present billing data at custom rates — list price where AWS gave them a discount, a margin added on top, or a negotiated internal rate. Billing Conductor lets you group accounts into billing groups and apply custom pricing rules to produce pro-forma billing data — an alternate view of costs that members or customers see, which does not change what AWS actually charges the organization. Recognition is all you need: consolidated billing = one real bill for all accounts; Billing Conductor = customized, pro-forma rates layered on top for chargeback or resale.

A single AWS bill answers how much you spent, but not who spent it. Cost allocation tags answer that second question. A tag is a simple key-value label on a resource — project = atlas, team = data-eng, environment = production — and once a tag is designated for cost allocation, AWS breaks out billing data along it.

There are two types, and the exam guide names them explicitly:

• AWS-generated tags — created automatically by AWS, with keys prefixed aws: (for example, aws:createdBy, which records who created a resource). You cannot edit these.
• User-defined tags — created by you with your own keys and values, conventionally prefixed user: in billing data. These carry your organizational meaning: cost center, application, owner.

The step candidates forget — and examiners love — is activation. Tagging a resource is not enough: a tag key must be activated as a cost allocation tag in the Billing and Cost Management console before it appears in billing tools, and it can take up to 24 hours to show up.

Who activates: in AWS Organizations, only the management account can activate cost allocation tags (a standalone account activates its own). A member account can tag its resources but cannot activate the key. Once the management account activates a key, resources carrying it in every member account are broken out by it on the consolidated bill.

What about spend from before activation? By default, a newly activated tag breaks out usage from the activation point forward. To see earlier months by tag, the management account can request a cost allocation tag backfill, which applies current tag activation status to up to the previous 12 months of cost data. Backfill only helps for months when the resources actually carried the tag; it cannot invent tags that were never applied.

Once activated, tags surface in exactly the tools you have already met: as filter and group-by dimensions in Cost Explorer, as columns in the Cost and Usage Report, and as scoping filters in AWS Budgets (so a team can have its own budget alert). A disciplined tagging strategy — consistent keys, enforced at resource creation — is what makes per-project cost reporting and chargeback possible. AWS also offers cost categories to group costs by rules when tags alone are not enough; a one-line recognition of that term suffices.

Task 4.2 questions are matching exercises. Read the scenario, find the tense and the need, and pick the tool. Commit this table to memory:

Now run a realistic scenario through it. A company has five AWS accounts under AWS Organizations — one per product team. Finance wants one invoice, each team must be charged back for its own usage, team leads want a warning before overspending, and leadership wants a monthly spend review. The mapping: consolidated billing already gives finance one bill with per-account line items and lets the teams' combined usage reach volume-discount tiers. Each team tags its resources with team and project keys, which the management account activates as cost allocation tags (requesting a backfill if finance wants earlier months broken out too). Each lead gets an AWS Budgets cost budget filtered to their account and tag, alerting at 80% forecasted. Leadership's monthly review runs in Cost Explorer, grouped by linked account and tag. When finance later builds a precise chargeback pipeline, they enable the CUR to S3 and query it with Athena. And when the company plans a sixth product next quarter, they price its architecture in Pricing Calculator before writing a line of code. If they instead resold AWS to external clients at marked-up rates, Billing Conductor would generate those pro-forma bills. One scenario, seven tools, no overlap — that is exactly how the exam thinks.