💸 AWS Cost Optimization With AI: Rightsizing and Savings Plans

The finance team asked why the AWS bill jumped 20% quarter over quarter, and the honest first answer was “I don’t know yet.” That’s the nature of cloud spend — it grows in a hundred small places at once, and the bill is a 40-line summary that hides where the money actually went. The traditional fix is a week of squinting at Cost Explorer, exporting CSVs, and building a spreadsheet nobody will ever open again. AI changes the economics of that work: it can read the cost breakdown, spot the anomalies, and reason about rightsizing and commitment trade-offs far faster than I can — as long as I keep it anchored to real billing data and own the commitment decisions myself.

The line I hold: AI analyzes the spend and proposes rightsizing and Savings Plan moves with the trade-offs spelled out. I make the actual purchase and resize decisions, because the model doesn’t know our growth plans, our risk tolerance, or which workloads are about to be deprecated.

Pull the real spend, broken down

Start with the shape of the bill, not the total. Group cost by service and by usage type so you can see where it concentrates:

aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-06-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[].{month:TimePeriod.Start,groups:Groups[].{svc:Keys[0],cost:Metrics.UnblendedCost.Amount}}' \
  --output json

Hand that to AI and ask it to find the change, not just the size:

Here’s monthly AWS spend by service for the last 3 months. Identify which services grew the most in absolute dollars and in percentage, and which look like anomalies (sudden jumps) versus steady growth. Rank by where the biggest savings opportunity likely is, and tell me what to investigate next for each.

The model cut through the noise:

EC2 grew $4,200/mo (steady ~8% — likely real load growth, look at rightsizing). NAT Gateway data processing jumped $1,800 in one month with no traffic change — that’s an anomaly worth investigating, possibly a misrouted high-volume flow through NAT instead of a VPC endpoint. RDS is flat. Investigate NAT first (likely a quick fix), then EC2 rightsizing for the durable savings.

That NAT-gateway catch is the kind of thing buried in a usage-type line that I’d never eyeball, and it pointed at a real misconfiguration — an S3-bound data flow going over NAT instead of a gateway endpoint.

Rightsizing: feed it utilization, not guesses

Never resize an instance on intuition. Compute Optimizer already crunches the CloudWatch utilization and recommends sizes; AI’s job is to help you interpret and prioritize its output, especially the risk:

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].{id:instanceArn,current:currentInstanceType,rec:recommendationOptions[0].instanceType,risk:recommendationOptions[0].performanceRisk,savings:recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value}' \
  --output table

Here’s Compute Optimizer’s rightsizing recommendations with the performance risk score for each. Sort by savings, but flag any recommendation with a performance risk above 2 or that downsizes a production instance by more than one tier — those need load testing before I trust them. Give me the safe, high-confidence resizes I can do now versus the ones that need validation.

This is the right division: the model sorts the safe wins from the risky ones, but it explicitly tells me which need a human to load-test first. A 4xlarge → large drop on a database is not something to apply because a recommendation said so, and the model is good at flagging exactly those. The safe ones (over-provisioned dev boxes, idle instances) I action immediately.

Savings Plans: model the commitment, then commit deliberately

This is the highest-stakes call, because a Savings Plan is a 1- or 3-year financial commitment. AWS gives you a recommendation based on historical usage; AI helps you stress-test it against your future, which AWS can’t know:

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[].{commit:HourlyCommitmentToPurchase,savings:EstimatedMonthlySavingsAmount,util:EstimatedUtilizationPercentage}'

AWS recommends an hourly Compute Savings Plan commitment of $X based on 60 days of usage, projecting Y% utilization. We’re planning to migrate two services off EC2 to Fargate in the next quarter, which will reduce EC2 usage. Walk me through the risk: if my baseline drops, what happens to the unused commitment, and would you recommend committing to the full amount, a conservative fraction, or waiting? Explain the break-even.

The model explained the key trap — that you pay for committed-but-unused capacity, so committing to your current baseline when you know it’s about to drop means paying for nothing — and recommended committing to a conservative fraction (the stable floor of usage) rather than the full recommendation. That’s exactly the reasoning I want surfaced. But the actual commitment is mine to make, with the migration context the model can’t independently verify. Compute Savings Plans (over EC2 Instance SPs) for the flexibility was also its call, and a sound one given the Fargate migration.

Verify the savings actually landed

After rightsizing and any commitment, confirm against the bill, not the projection:

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity DAILY --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --query 'ResultsByTime[].{date:TimePeriod.Start,cost:Total.UnblendedCost.Amount}' \
  --output table

Watch the daily EC2 line bend after the resizes. Set a budget alert too, so the next quiet 20% creep pages you instead of finance. AI will draft the aws budgets config from a plain-English threshold if you ask.

The control line

Cloud cost optimization is a place where AI’s speed at reading dense billing data is genuinely transformative — it finds the NAT anomaly buried in usage types, sorts safe resizes from risky ones, and stress-tests a Savings Plan against your future. But every commitment is a financial decision the model can’t make for you, because it doesn’t know your roadmap or risk tolerance. So AI analyzes and proposes with trade-offs; you decide the resizes and the commitments; and you verify every saving against the real bill, never the projection.

This measure-against-reality habit ties the whole AWS series together, and the Cost Explorer and Savings Plan analysis prompts are in the prompts collection.