AWS Scenarios
Multi-Account Cost Governance
Design AWS cost governance across accounts using Organizations, cost allocation tags, Cost Explorer, Budgets, CUR/Data Exports, SCPs, Service Catalog, Savings Plans, and Compute Optimizer.
After this, you will understand
This scenario turns cost optimization from scattered cleanup into account, tag, budget, commitment, and guardrail design.
Use Organizations for account structure, tags for ownership, Cost Explorer for analysis, Budgets for alerts, CUR for detailed analytics, and SCPs or Service Catalog for preventive guardrails.
Learners rely on monthly invoices, untagged resources, or budgets as if they were hard caps.
Define account ownership, require tags, analyze spend, alert early, publish approved products, restrict dangerous actions, and right-size before buying commitments.
Think before readingWhy are budgets not enough for cost governance?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Multi-account cost governance
- AWS Organizations and consolidated billing
- Cost allocation tags
- Cost Explorer analysis
- AWS Budgets alerts and actions
- CUR/Data Exports analytics
- SCP preventive guardrails
- Service Catalog approved products
- Savings Plans and Compute Optimizer
- SAA-C03 cost traps
1. Situation
An organization has many AWS accounts: production, development, sandbox, shared services, security, and data accounts. Costs are growing, and finance cannot map spend cleanly to teams or products.
The goal is not only to reduce cost. The goal is to make spend explainable, owned, alerted, and governed without blocking every team through manual tickets.
The architecture question is:
how do we let teams move fast without letting cost become invisible?
For SAA-C03, this scenario combines Organizations, billing tools, tags, budgets, SCPs, Service Catalog, and optimization recommendations.
2. Naive Design
The naive design uses one shared AWS account:
all teams -> one account -> one bill
Everyone launches resources. Few resources have tags. Finance sees a total bill but cannot attribute ownership.
Another naive design creates accounts but no standards. Every account has different tags, Regions, budgets, and permissions.
A third mistake is creating a budget and assuming cost is now controlled. Budgets help, but they are delayed feedback. They are not universal real-time hard caps.
3. What Breaks
Ownership breaks when accounts and tags do not map to teams.
Budgets become noisy when thresholds are generic and no team owns the response.
Cost Explorer cannot answer business questions if resources are untagged or account structure is muddy.
Developers can accidentally launch expensive resources in wrong Regions or use unapproved services.
Finance may buy Savings Plans before engineering right-sizes waste, locking in inefficient usage.
Cost governance needs both visibility and prevention.
4. AWS Architecture
Use AWS Organizations to structure accounts by workload, environment, or team. Consolidated billing gives a payer-level view while accounts remain security and ownership boundaries.
Define cost allocation tags such as Application, Environment, Owner, CostCenter, or DataClassification. Activate billing tags and enforce them through provisioning workflows where possible.
Use Cost Explorer for interactive analysis by service, linked account, Region, usage type, and tag.
Use AWS Budgets for actual and forecasted cost alerts, usage budgets, and Savings Plans or RI utilization alerts.
Use CUR/Data Exports to deliver detailed billing data to S3 for Athena, QuickSight, or finance systems.
Use SCPs to prevent dangerous or unapproved actions. Use Service Catalog to offer approved self-service products.
Use Compute Optimizer before buying Savings Plans.
5. Request Or Data Flow
A team requests a new environment through an approved path, such as Service Catalog or infrastructure-as-code pipeline.
The environment lands in the right account with required tags and standard controls.
Cost data flows into billing systems. Cost Explorer gives interactive views. CUR/Data Exports deliver detailed line items to S3 for analytics.
Budgets alert team owners when actual or forecasted spend crosses thresholds.
Compute Optimizer recommends rightsizing. After waste is removed and baseline usage is stable, finance considers Savings Plans.
SCPs prevent account-level policy violations such as unapproved Regions or high-risk services.
6. Security Controls
Cost governance overlaps with security because permissions create spend.
Use SCPs as maximum-permission guardrails. They do not grant permissions, but they can prevent member accounts from using disallowed actions.
Use Service Catalog to let users launch approved patterns without broad direct permissions.
Limit billing visibility. Cost data can reveal business scale, product priorities, and account structure.
Protect CUR/Data Export buckets with encryption, least privilege, and Block Public Access.
Use CloudTrail to audit changes to budgets, billing exports, SCPs, and account settings.
7. Resilience Controls
Cost controls should not accidentally break production.
Do not automatically stop production resources just because a budget alert fires. Alert humans, route tickets, and require review.
Use stricter budget actions in sandbox accounts where spend containment matters more than availability.
Test SCPs in a small OU before attaching broadly. AWS documentation strongly recommends careful testing because SCP mistakes can block critical actions.
Keep break-glass processes for billing, security, and operations.
Use AWS Health and CloudWatch separately for operational health. Cost governance is not incident monitoring.
8. Performance Controls
Cost governance should expose performance-cost tradeoffs.
Compute Optimizer can identify underprovisioned resources as well as overprovisioned ones. Not every cost recommendation is a downsizing recommendation.
Cost Explorer can show rising spend, but service metrics explain whether the rise is caused by real traffic, inefficient design, or waste.
CUR analytics can identify shared costs such as NAT gateways, data transfer, observability, and security tooling that need allocation rules.
Dashboards should be scoped by owner and actionability. A global cost chart that no team owns is theater.
9. Cost Controls
Use account boundaries for ownership. Use tags for finer attribution.
Use Budgets for forecasted alerts before the month ends.
Use Cost Explorer for weekly investigation and trend review.
Use CUR/Data Exports for durable finance analytics and chargeback.
Use Service Catalog to standardize instance sizes, storage options, and approved products.
Use SCPs to prevent unapproved Regions or high-risk services.
Use Savings Plans only after rightsizing stable baseline usage.
10. Exam Variants
"Analyze cost by service, account, or tag" points to Cost Explorer.
"Alert when forecasted spend exceeds budget" points to AWS Budgets.
"Detailed billing data in S3 for Athena" points to CUR/Data Exports.
"Prevent member accounts from using unapproved services" points to SCPs.
"Let users launch approved infrastructure only" points to Service Catalog.
"Right-size resources before commitments" points to Compute Optimizer.
11. Common Traps
Do not call Budgets a hard cap.
Do not use SCPs as permission grants. They only limit maximum permissions.
Do not buy Savings Plans before rightsizing.
Do not expect Cost Explorer to replace detailed billing exports.
Do not rely on tags unless they are activated and enforced.
Do not apply broad SCPs at the organization root without testing.
12. Related Topics
Review AWS Organizations, AWS Cost Explorer, AWS Budgets, AWS Cost And Usage Report, Service Control Policies, and AWS Service Catalog.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.