Cost Explorer, Budgets & Savings Plans
Understanding, controlling, and optimizing what you actually spend on AWS — visibility tools, proactive alerts, and commitment-based discounts.
Want a visual for this topic?
Generate a diagram tailored to Cost Explorer, Budgets & Savings Plans — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain how Cost Explorer helps identify where money is actually being spent
- •Set up an AWS Budget with an alert before spending exceeds expectations
- •Explain the difference between Reserved Instances and Savings Plans
- •Explain what Compute Optimizer recommends and why right-sizing matters
What is it?
AWS's cost management tooling includes Cost Explorer (visualizing and analyzing historical spend by service, account, tag, and more), AWS Budgets (setting spend thresholds with proactive alerts before they're exceeded), Savings Plans and Reserved Instances (commitment-based discounts for predictable usage), and Compute Optimizer (recommendations for right-sizing resources based on actual observed utilization).
Why it exists
Cloud billing's pay-as-you-go model, while flexible, also means costs can grow — sometimes significantly and unexpectedly — without anyone noticing until the bill arrives, unlike a fixed monthly cost for owned hardware. This tooling exists to give ongoing visibility into where money is actually going, catch cost growth before it becomes a surprise, and provide structured ways to reduce cost for workloads whose usage is well-understood and predictable.
Problem it solves
Cost Explorer solves the visibility problem (understanding which service, team, or resource is actually driving spend, not just the total bill). Budgets solves the surprise-bill problem (proactive alerts when spend is trending toward or exceeding a threshold, before the monthly bill arrives). Savings Plans/Reserved Instances solve the overpaying-for-predictable-usage problem (committing to steady-state usage in exchange for a substantial discount versus On-Demand rates). Compute Optimizer solves the over-provisioning problem (data-driven right-sizing recommendations based on actual observed utilization, rather than guesswork).
Intuition
Cost Explorer is like a detailed bank statement with categorized spending, letting you see exactly which categories (services, teams, projects) are driving your total spend, rather than just seeing one lump total. Budgets is like a proactive text alert from your bank when you're approaching your monthly spending limit, rather than only finding out you overspent when the statement arrives. Savings Plans are like a gym membership discount for committing to a year instead of paying full price per visit — worthwhile if you know you'll actually go regularly.
Analogy
A household managing its finances: Cost Explorer is the itemized breakdown showing exactly how much went to groceries, utilities, and entertainment last month; Budgets is the automatic alert when you're on pace to exceed your monthly grocery budget partway through the month; a Savings Plan is like pre-paying for a year of gym membership at a discount because you know for certain you'll use it consistently, versus paying the higher drop-in rate every single visit.
Technical explanation
Cost Explorer uses AWS Cost and Usage data, allowing filtering and grouping by dimensions including service, linked account, Region, and cost allocation tags (which must be explicitly activated and applied to resources to be usable for this kind of grouping — untagged resources show up as an undifferentiated bucket, a common visibility gap). AWS Budgets supports cost budgets (total spend), usage budgets (e.g. EC2 instance-hours), and Savings Plans/RI utilization and coverage budgets, each capable of triggering an SNS notification (or even an automated action) when actual or forecasted spend crosses a defined threshold. Reserved Instances commit to a specific instance type/Region for a 1 or 3 year term; Savings Plans instead commit to a dollar-per-hour spend level, automatically applying the discount to whatever matching usage occurs — including, for Compute Savings Plans, flexibly across instance families, sizes, and even Lambda/Fargate usage, making them more flexible than traditional RIs for most use cases today.
Architecture
A company's FinOps practice reviews Cost Explorer weekly, broken down by cost allocation tags representing each team/project, immediately surfacing which team's spend is growing unexpectedly. AWS Budgets are configured per team with alerts at 80% and 100% of each team's allocated monthly budget, notifying that team's lead directly via SNS/Slack integration. For steady-state production workloads with well-understood, stable usage over the past several months, the company purchases Compute Savings Plans sized to that stable baseline, while burst/variable capacity above that baseline remains On-Demand.
Workflow
- Activate and consistently apply cost allocation tags across resources (e.g. team, project, environment) to enable meaningful cost breakdown in Cost Explorer. 2) Review Cost Explorer regularly to understand actual spend drivers, not just the total bill. 3) Set AWS Budgets with alerts well before a threshold would actually be exceeded, giving time to investigate and respond. 4) Use Compute Optimizer's recommendations to right-size over-provisioned resources based on real observed utilization. 5) Once usage patterns are well-understood and stable (typically after a few months of Cost Explorer data), purchase Savings Plans sized to that confirmed steady-state baseline, leaving genuinely variable capacity on On-Demand or Spot.
Example
A startup notices via a Cost Explorer review that RDS spend has grown 3x over two months without a corresponding growth in actual traffic. Investigating further (filtered by tag), they discover a forgotten, oversized RDS instance from an abandoned proof-of-concept project that was never terminated — caught within weeks via routine cost review rather than accumulating for months unnoticed. Separately, having confirmed six months of stable EC2 usage for their core production fleet via Cost Explorer, they purchase a 1-year Compute Savings Plan sized to that confirmed baseline, immediately reducing their steady-state compute cost by roughly 30% with zero application changes.
Real-world usage
Cost Explorer and Budgets are foundational tools in virtually every organization's FinOps (cloud financial operations) practice, cited throughout AWS's own cost optimization best-practice guidance; Savings Plans have become the standard recommended commitment-discount mechanism over traditional Reserved Instances for most customers today, specifically due to their flexibility across instance types and even compute services.
Trade-offs
Committing to Savings Plans locks in a discount but reduces flexibility — a 1 or 3 year commitment assumes your usage stays reasonably stable over that period; a shorter commitment (1 year) or staying entirely On-Demand preserves more flexibility for genuinely uncertain or rapidly evolving workloads, at the cost of a higher effective price. Investing time in detailed cost allocation tagging and regular Cost Explorer review has a real ongoing operational cost, but pays for itself by catching cost issues (forgotten resources, unexpected growth) far earlier than they'd otherwise be noticed.
Visual explanation
Picture Cost Explorer's interface: a graph of spend over time, filterable and groupable by service, linked account, tag, or Region, letting you drill from 'total AWS spend is trending up' down to 'specifically, EC2 spend in the Production account grew 40% this month.' Separately, picture a Budget as a threshold line on a chart of month-to-date spend — when the trend line is forecast to cross that threshold, an alert fires, ideally with enough lead time to actually investigate and respond before the month ends.
Advantages
- —
Cost Explorer's tag-based breakdown turns an opaque total bill into actionable, attributable spend visibility
- —
Budget alerts catch cost growth proactively, often before a full billing cycle passes, rather than only discovering it after the fact
- —
Savings Plans provide substantial discounts (often 30-70%) for well-understood, stable usage with minimal commitment complexity compared to traditional RIs
- —
Compute Optimizer's recommendations are based on actual observed utilization data, not guesswork, giving confidence that right-sizing suggestions are grounded in reality
Disadvantages
- —
Cost allocation tags must be deliberately and consistently applied to be useful — untagged resources remain an undifferentiated, hard-to-attribute cost bucket
- —
Committing to Savings Plans/RIs based on usage that later changes (e.g. a workload migrated to a different instance family, or decommissioned) can leave you paying for an unused commitment
- —
Cost Explorer and Budgets are reactive/observational tools — they don't themselves prevent overspending, only surface and alert on it, requiring someone to actually act on that information
- —
Overly aggressive right-sizing based on Compute Optimizer recommendations without accounting for planned future growth can cause a resource to become genuinely undersized soon after
Common mistakes
- —
Not applying cost allocation tags consistently, leaving a large fraction of spend in Cost Explorer as an undifferentiated 'no tag' bucket that provides no actionable attribution
- —
Purchasing Savings Plans or Reserved Instances based on a short, unrepresentative window of usage data, later finding actual steady-state usage was different and the commitment doesn't match well
- —
Setting Budget alerts only at 100% of the threshold, leaving no lead time to investigate and respond before spend has already exceeded expectations — set earlier warning thresholds too (e.g. 80%)
- —
Ignoring Compute Optimizer or Cost Explorer's own recommendations for months at a time, letting easily-identifiable savings opportunities go unrealized
- —
Forgetting to terminate resources from a proof-of-concept, demo, or abandoned project, letting them silently accumulate cost for months without anyone noticing
In the AWS Console
- 1
AWS Console → Billing and Cost Management → Cost Allocation Tags
Activate the specific tags you use for cost attribution (e.g. team, project, environment) so they become available as grouping dimensions in Cost Explorer.
Newly activated tags only apply going forward — historical spend on resources tagged before activation may not retroactively appear grouped by that tag.
- 2
Billing and Cost Management → Cost Explorer
Filter and group by service, linked account, or tag to understand what's actually driving spend, and compare month-over-month trends.
Start broad (total spend trend) and progressively filter/group narrower to identify the specific driver of any unexpected change.
- 3
Billing and Cost Management → Budgets → Create budget
Define a cost or usage budget with a threshold, and configure alert notifications at multiple percentages (e.g. 80% and 100% of the forecasted or actual amount).
Setting an earlier warning threshold (not just 100%) gives meaningful lead time to investigate before the month's spend has already exceeded expectations.
- 4
AWS Console → Compute Optimizer → Recommendations
Review right-sizing recommendations for EC2, EBS, and Lambda based on actual observed utilization over the lookback period.
Compute Optimizer needs a reasonable amount of historical utilization data (typically at least 14 days, ideally longer) before its recommendations are reliably meaningful.
🎤 Interview questions
How would you figure out which team or service is driving an unexpected increase in your AWS bill? (Listen for: Cost Explorer, filtered and grouped by cost allocation tags and service, drilling from the total trend down to the specific driver.)
What's the difference between Reserved Instances and Savings Plans? (Listen for: RIs commit to a specific instance type/Region/term; Savings Plans commit to a dollar-per-hour spend level, applying flexibly across instance types/families and even Lambda/Fargate — generally more flexible.)
Why would you set a Budget alert at 80% of a threshold instead of only at 100%? (Listen for: gives lead time to investigate and respond to a spending trend before it's actually exceeded expectations, rather than only finding out after the fact.)
What does AWS Compute Optimizer actually recommend, and what's it based on? (Listen for: right-sizing recommendations for over- or under-provisioned resources, based on actual observed utilization data over a lookback period, not guesswork.)
What's a real risk of committing to a large Savings Plan based on only a few weeks of usage data? (Listen for: if that short window wasn't representative of actual steady-state usage, you may end up committed to (and paying for) capacity that doesn't match your real, ongoing needs.)