Cost Explorer, Budgets, CUR, and Allocation Tags
Key Takeaways
- SAP-C02 Task 1.5 is organizational visibility: who can see which dollars, how spend is attributed, and how consolidated billing shares discounts—not picking instance families for a new app
- The management account pays the Organizations invoice and can see org-wide Cost Explorer data; a member account sees only its own usage and cannot inspect sibling-account spend, refunds, or other accounts' RI recommendations
- Resource tags do not appear in Cost Explorer, Budgets, or CUR until the management account activates them as cost allocation tags, and activation is not instant
- CUR (or Data Exports) is the line-item warehouse; Cost Explorer is interactive analysis and forecasting; Budgets are thresholds, coverage/utilization monitors, and optional automated actions
- Billing Conductor builds pro forma showback or chargeback rates in billing groups; it does not change the payable AWS invoice
Three SAP-C02 cost tasks that must stay distinct
The AWS Certified Solutions Architect - Professional (SAP-C02) exam repeats cost language in three places, and treating those stems as interchangeable is a common miss. Task 1.5 asks you to determine cost optimization and visibility strategies for organizational complexity: who pays, who can open Cost Explorer, how finance attributes dollars to products, and how AWS Organizations consolidated billing changes discount sharing. Task 2.6 is a new-solution problem—you model purchase options, storage tiering, and data transfer before you deploy, often with the AWS Pricing Calculator. Task 3.5 is continuous improvement of existing solutions: the workload is already running, the bill already exists, and you hunt waste with Cost Explorer, AWS Trusted Advisor, AWS Compute Optimizer, and Amazon S3 Storage Lens.
Visibility tools do not choose a Graviton family for a greenfield API. Compute Optimizer does not produce a CFO-ready showback file. Keep the intent of the stem in front of the service name.
Independent SAP-C02 study material by OpenExamPrep treats AWS Well-Architected Framework Cost Optimization as the official design vocabulary AWS uses on the exam. That is the name of AWS's framework, not a claim that this guide is an AWS partner document.
Consolidated billing: one invoice is not one view
Every Organization has a management account (still called the payer account in older blogs) that pays charges incurred by member accounts. AWS documents these consolidated-billing benefits: a single bill, combined cost-and-usage data you can download, and combined usage so volume pricing, Amazon EC2 Reserved Instances (RIs), and Savings Plans can be shared. Consolidated billing itself has no extra fee.
Payment is not visibility:
| Identity | What they can typically see | What they typically cannot see |
|---|---|---|
| Management account | Chargeable cost and usage for every member in AWS Cost Explorer, invoices, commitments, refunds/credits, and organization-level RI/Savings Plans recommendations. If AWS Billing Conductor is in use, the management account can also inspect pro forma amounts. | Nothing org-wide is hidden by default, but IAM and Cost Management preferences still apply. |
| Member account | Its own cost and usage after Cost Explorer is enabled for the organization. | Other members' spend, organization refunds and credits, and RI recommendations that belong to other accounts. |
| IAM user or role | Only what IAM allows and only if the account has Activate IAM Access enabled for Billing and Cost Management. | Root-only billing screens until that setting is on. |
Enabling Cost Explorer from the management account enables it for all accounts in the organization. You cannot enable it for Retail and hide it from Sandbox through that control. Linked account access on the Cost Management preferences page is likewise all or none: every member may open its own Cost Explorer data, or none of them may. That all-or-none switch is not a per-account ACL, and it never lets a member see a sibling OU's invoice.
When finance sits in a dedicated FinOps member account and needs a cross-account pane, the exam-correct pattern is still management-account reporting, a custom billing view the management account shares, or Billing Conductor billing-group views—not ce:GetCostAndUsage on an application role in a workload account.
Cost Explorer, Budgets, CUR, and Cost Categories
Match the tool to the artifact the scenario asks for.
AWS Cost Explorer is the interactive console: filter and group by service, account, Region, usage type, tag, and cost category; compare time ranges; forecast future spend; and consume RI/Savings Plans recommendations. It is the right first click for an architect who needs to know why last month jumped. It is not the most detailed export, and it is a poor substitute for a nightly finance warehouse.
AWS Budgets tracks cost, usage, RI utilization, RI coverage, Savings Plans utilization, and Savings Plans coverage. Alerts can fire on actual amounts (already accrued) or forecasted amounts (before the period closes). Budget actions can apply an IAM policy, an SCP, or target-specific resources when a threshold is crossed—use that as a governance brake, not as a tagging strategy. Scope a budget to a cost category or a linked account when the stem is about one product team, not the whole payer invoice.
AWS Cost and Usage Reports (CUR) and successor Data Exports are the most comprehensive cost-and-usage dataset. You publish hourly or daily reports to an Amazon S3 bucket you own, in CSV or Apache Parquet, then query with Amazon Athena, Amazon QuickSight, or an external warehouse. Resource IDs, line-item types, unblended and net-unblended amounts, activated tag columns, and cost-category columns all show up here. Choose CUR when the CFO wants showback that survives an audit, not a screenshot.
AWS Cost Categories are rule sets the management account (or a standalone account) creates to map accounts, services, charge types, and tags into business names such as BusinessUnit=Retail. Only that management (or standalone) context can create and manage categories for the organization. After they process, categories appear as a dimension in Cost Explorer, Budgets, CUR, and AWS Cost Anomaly Detection. Use split-charge rules when a central platform—Transit Gateway, NAT, shared logging—has no honest single-application tag.
AWS Cost Anomaly Detection watches services, linked accounts, cost categories, or tags and notifies through Amazon SNS. It is a visibility alarm for unexpected spend. It does not rightsize an instance and it does not allocate shared networking.
Allocation tags, account tags, and billing alarms
A tag is a key-value pair on a resource. Cost allocation tags are the subset you activate in Billing and Cost Management so they become columns and filters in Explorer, Budgets, and CUR. AWS documents two families: user-defined tags your builders create (CostCenter, Application, Environment, Owner) and AWS-generated tags AWS attaches to certain resources. Until activation, tagging in the EC2 console is operationally useful and financially invisible.
Activation is a management-account step. AWS documents that the Active status can take up to 24 hours to appear, and reporting then fills forward. Tagging yesterday's untagged NAT Gateway does not rewrite last quarter's CUR. A Task 1.5 stem that says “tags exist but finance cannot group by team” is almost always activation (and Cost Categories for leftovers), not “create more tags” in isolation.
Account tags on Organizations accounts can now be activated for allocation as well. Use them for charges that never receive a resource tag: some support fees, refunds, credits, and other account-level line items. Do not put the literal prefix accountTag in your own keys; AWS adds that prefix in reports.
Billing alarms in exam language usually mean one of two controls. CloudWatch billing alarms on estimated charges are account-level and the billing metric lives in US East (N. Virginia) (us-east-1). AWS Budgets is the organization-friendly, dimension-aware control when the stem mentions forecasted spend, a cost category, RI coverage, or a member-account filter. Prefer Budgets for SAP-C02 org scenarios; mention CloudWatch when the stem is a single account and an estimated-charges alarm.
Showback versus chargeback, and when Billing Conductor belongs
Showback means each product, OU, or tenant can see attributed cloud cost. Chargeback means someone internally invoices that amount. Neither action requires AWS to split the payable invoice.
The ordinary Task 1.5 showback path is: publish a tagging standard (often with tag policies and AWS Config), activate those keys as cost allocation tags, wrap untagged and shared spend in Cost Categories with split charges, export CUR, and put finance on the management account or a shared billing view. Member accounts keep seeing their usage so application teams can still debug their own bill without reading the whole company.
AWS Billing Conductor is current and in-scope when the scenario needs custom rates, billing groups, custom line items (internal fees or credits), or a pro forma CUR that does not match AWS list/discounted rates. Channel partners and organizations with formal chargeback logic use it to model the relationship between the payer and internal customers. Conductor does not change how AWS bills you. If the only requirement is “finance wants to see last month by Application tag,” activating tags and grouping in Cost Explorer is the smaller, correct move. If the requirement is “bill the banking tenant at a 10 percent internal uplift and emit a tenant CUR,” Conductor is the service that exists for that job.
Same tools, three intents
| Exam intent | Typical stem | First move |
|---|---|---|
| Org visibility (Task 1.5) | Finance, showback, OU, who can see bills, consolidated invoice, untagged shared platform | Organizations, Cost Explorer access model, activate tags, Cost Categories, CUR, Budgets, Billing Conductor only if custom rates are required |
| New solution (Task 2.6) | You are designing, Pricing Calculator, choose a purchase model, model data transfer | Size and price the architecture; still attach allocation tags at launch so next month's CUR can attribute it |
| Existing spend (Task 3.5) | The bill increased, idle, overprovisioned, coverage versus utilization | Cost Explorer, Trusted Advisor, Compute Optimizer, Storage Lens, anomaly monitors |
A new three-tier application still needs Application and CostCenter on every billable resource at launch. That is design-time tagging in service of organizational visibility. It is not a substitute for selecting a gateway VPC endpoint or a Compute Savings Plan, and it is not rightsizing a fleet that has already been oversized for six months.
A retailer runs 40 member accounts under AWS Organizations with consolidated billing. Product teams already tag most Amazon EC2 and Amazon S3 resources with CostCenter and Application, but finance cannot group those keys in Cost Explorer. Shared AWS Transit Gateway and logging costs have no single product owner. The CFO wants monthly showback by product, including a fair split of the shared network platform. Which approach should the solutions architect recommend first?
An application owner in a member account must compare Amazon S3 spend in that account with S3 spend in a sibling OU that runs a related product. The organization already enabled Cost Explorer from the management account. What should the architect tell the owner?
A bank is launching a new payments API next week and, separately, noticed unexplained Amazon EC2 growth last quarter in an existing lending account. Leadership wants both the new API to be attributable on day one and the lending growth explained. How should the architect separate the work?