4. AWS Cost Management

These tools focus on financial governance, providing visibility into usage and commitment-based discounts.

AWS Budgets

Service Introduction: A service to set custom budgets that alert you when costs or usage exceed (or are forecasted to exceed) your thresholds.

Common Usage: Establishing cost guardrails at the account or project level to prevent billing surprises.

Project Examples:

• Alerting the DevOps team when monthly EC2 spend reaches 80% of the $5,000 budget.
• Monitoring forecasted usage of S3 storage to ensure it stays within quarterly limits.

AWS Cost and Usage Report (CUR)

Service Introduction: The most granular data set available for AWS costs, providing hourly or daily line items across all accounts.

Common Usage: Deep-dive financial analysis and ingestion into Redshift or Athena for custom BI reporting.

Project Examples:

• Identifying the exact cost of every S3 "PUT" request for a specific project tag.
• Generating internal "chargeback" reports for different business departments.

AWS Cost Explorer

Service Introduction: A visual tool that allows you to analyze your historical and forecasted AWS cost and usage.

Common Usage: Identifying spend trends, identifying underutilized resources, and receiving RI/Savings Plan recommendations.

Project Examples:

• Visualizing the month-over-month increase in Lambda execution costs.
• Comparing the cost-effectiveness of different instance families in production.

Savings Plans

Service Introduction: A flexible pricing model that provides significant savings (up to 72%) on compute usage in exchange for a 1- or 3-year commitment.

Common Usage: Reducing costs for steady-state workloads across EC2, Lambda, and Fargate.

Project Examples:

• Committing to $10/hour of compute usage to lower global production costs.
• Applying a SageMaker Savings Plan to a fleet of persistent ML inference instances.

Cost Allocation Tags (exam-critical, easy to overlook)

Service Introduction: Key-value tags applied to resources (e.g., Project: Phoenix, Department: Marketing) that, once activated in the Billing console, let costs be broken down and attributed per tag in Cost Explorer and the CUR.

Common Usage: The standard answer whenever a question asks "how do we track/attribute costs by project, team, or environment across shared accounts?" There are two types: AWS-generated tags (e.g., aws:createdBy, automatic) and user-defined tags (custom, must be manually activated before they appear in billing reports — a common gotcha: tagging a resource alone doesn't make it show up in cost reports until the tag is activated).

Project Examples:

• Tagging all resources with a CostCenter tag to generate accurate departmental chargeback reports.
• Using an Environment: Production vs Environment: Dev tag to compare spend between environments in Cost Explorer.

4.1 Choosing the Right Cost Tool (exam-critical decision framework)

Need	Tool
"Alert me before/when I exceed a spending threshold"	AWS Budgets
"Visualize trends, forecast future spend, get RI/SP recommendations"	AWS Cost Explorer
"The most granular, hourly line-item data for custom BI/chargeback"	Cost and Usage Report (CUR)
"Attribute shared-account costs to a specific project/team"	Cost Allocation Tags
"Commit to steady-state compute spend for a discount"	Savings Plans

The tell: "notify/alert" → Budgets. "Analyze/visualize/forecast" → Cost Explorer. "Raw, most-detailed export for a data warehouse" → CUR. "Break costs down by project/team" → Cost Allocation Tags.

4.2 How to Reason Through "MOST Cost-Effective" Questions (exam-critical mindset, applies across every domain)

This question type is deliberately unmemorizable — you can't build a lookup table of "requirement X → cheapest service Y" because the same requirement (e.g., "40,000 IOPS") maps to a different cheap answer depending on other details in the scenario (see the EC2 Instance Store vs. Provisioned IOPS EBS worked example in 04_Compute). What's testable instead is a reasoning checklist — run every "MOST cost-effective" question through these questions, in order, before picking an answer:

1. Does the requirement actually need to survive the resource being stopped/restarted/terminated? If the scenario explicitly says data is temporary, discarded, scratch, cache, or re-creatable, any answer choice built around durability guarantees (Provisioned IOPS EBS, Multi-AZ RDS, cross-Region replication, S3 Standard) is almost certainly overpaying for a guarantee nothing needs. Look for the option that gets the same performance number without paying for persistence.
2. Is there already a "bundled for free" way to get this, before reaching for a named premium feature? AWS often already includes strong performance/capability in a base offering (instance store IOPS bundled into storage-optimized instance pricing; S3 Standard already replicates across 3 AZs at no extra "Multi-AZ" charge unlike RDS). A named add-on feature (io1/io2, Multi-AZ, Global Accelerator) usually means "pay more for a specific extra guarantee" — check whether the scenario actually needs that specific guarantee before assuming the feature-matching answer is the cost-effective one.
3. Does the workload's time/access pattern match a discount mechanism? Predictable + steady-state → Reserved Instances/Savings Plans. Interruptible + flexible → Spot. Rarely accessed → the coldest storage class whose fastest tier still meets any stated retrieval-time requirement (see the S3 Glacier retrieval-time comparison in 16_Storage) — never just "the cheapest storage class overall" without checking the time constraint first.
4. Is a fully-managed/serverless option being compared against a self-managed one for a spiky or low-utilization workload? At low, unpredictable utilization, pay-per-use serverless (Fargate, Lambda, DynamoDB On-Demand, Aurora Serverless) usually beats provisioned capacity sitting idle. At high, steady utilization, the reverse can be true — provisioned/reserved capacity, tightly packed, often beats per-request serverless pricing.
5. Eliminate every option that fails a hard functional requirement first, then pick the cheapest survivor. Cost is the tie-breaker among options that actually work — not the first filter. A dirt-cheap option that misses a stated RTO/IOPS/retrieval-time/durability requirement is wrong regardless of price; the trap runs the other way too — the most fully-featured, safest-sounding option is often not the answer once you've confirmed a cheaper option still satisfies every hard requirement.

Why this beats memorizing service names: exam writers construct these questions specifically to bait the "recognize the keyword, pick the matching named feature" reflex (IOPS number → Provisioned IOPS; "warehouse" → Redshift; "cache" → ElastiCache). The MOST-cost-effective correct answer is frequently the other option that meets the same functional bar without paying for a guarantee the scenario doesn't actually need. Train yourself to ask "what is this extra cost buying me, and does the scenario actually need to buy it?" before matching on keywords.