Cost Governance at Scale

When an organization scales from a handful of AWS accounts to hundreds under AWS Organizations, informal cost tracking collapses. Spreadsheets, ad hoc naming conventions, and per-team billing workarounds cannot sustain financial accountability across business units that share networking infrastructure, centralized logging, and common data platforms. Architects are expected to design layered cost governance that combines preventive controls, detective controls, and cost-attribution mechanisms rather than relying on a single tool. This lesson establishes the governance foundation: standardized tagging, enforcement policies, and cost-allocation models that make cloud spending transparent and attributable across organizational units.

The AWS services that underpin this governance layer include AWS Organizations for consolidated billing and OU structure, tag policies for tag standardization, SCPs for preventive guardrails, AWS Config for detective compliance, and the Cost and Usage Report (CUR)The most granular AWS billing dataset, delivered as CSV or Parquet files to S3, containing line-item detail for every charge across all accounts in an organization., paired with Cost Explorer for analytics. This lesson focuses on governance structure and cost attribution. The next lesson, Financial Optimization Models, addresses purchasing strategies, Savings Plans, and budgeting tools that build on the visibility established here.

A guiding principle from the Well-Architected Cost Optimization pillar frames every design decision ahead: cost attribution must be designed centrally but consumed decentrally. Central teams define the tagging taxonomy and enforcement policies, while individual business units consume dashboards and reports that reflect their own spending.

Enterprise tagging strategy design

Effective cost governance begins with a standardized tagging taxonomy that every account in the organization follows. Without consistent tags, cost-allocation reports produce incomplete or misleading data, and chargeback models fail.

Mandatory vs. optional tags

The design principle is to keep the mandatory tag set small, typically four to six tags, to reduce operational friction. A bloated mandatory set slows developer velocity, breaks infrastructure-as-code pipelines, and increases the surface area for governance violations. The following tags represent a common enterprise baseline:

• CostCenter maps each resource to the internal ...