Cost optimization: purchase options, egress, idle waste, and visibility

Lever 1: compute purchase options — match commitment to baseline

The same EC2 capacity has four prices, and the gap between the cheapest and the priciest is enormous. On-Demand is the default: maximum flexibility, no commitment, and the highest per-hour rate. You pay it for every hour an instance runs whether it is busy or idle. It is the right price for unpredictable or short-lived work — and the wrong price for a baseline that runs around the clock.

Savings Plans trade flexibility for a discount: you commit to a steady amount of compute spend (measured in dollars per hour) for a one- or three-year term, and in return you save up to ~72% versus On-Demand. There are two shapes worth knowing. A Compute Savings Plan is the flexible one — its discount (up to ~66% off) applies automatically across instance family, size, Region, OS, and across EC2, Fargate, and Lambda, so you can re-architect underneath it without losing the rate. An EC2 Instance Savings Plan is cheaper (up to ~72% off) but narrower: you commit to a specific instance family in a chosen Region, and the discount only follows size and OS changes within that family. Reserved Instances are the older mechanism that predates Savings Plans; they bundle a discount with optional capacity reservation and are largely superseded by Savings Plans for pure cost savings.

At the far end, Spot Instances sell AWS’s spare capacity at up to ~90% off On-Demand — with one catch: AWS can reclaim the instance at any time, giving only a two-minute interruption notice (delivered via instance metadata and an EventBridge event). Spot is a gift for interruptible, stateless, fault-tolerant work — batch jobs, CI runners, big-data processing, anything that can checkpoint and resume — and a trap for anything stateful that cannot survive being killed mid-flight.

The senior rule is to match commitment to the shape of demand: cover the steady 24/7 baseline with a Savings Plan or RI, absorb the unpredictable burst on top with On-Demand, and run interruptible batch on Spot. Pricing is region-dependent and changes over time — always confirm current numbers on the EC2 pricing page; the percentages here are AWS’s published up-to maximums, not a quote.

Lever 2: data transfer and NAT — the silent line items

Compute is the bill everyone watches; data transfer is the bill that surprises them. The rough mental model: ingress from the internet is generally free, egress is not, and traffic that crosses an Availability Zone boundary or a Region boundary is metered even when it never leaves AWS. A microservice architecture that gossips constantly between services in different AZs can rack up cross-AZ transfer charges that dwarf the compute doing the talking. The fix is architectural: keep chatty traffic in-AZ (co-locate the talkers), front internet egress with CloudFront so the origin serves bytes once and the CDN serves them cheaply thereafter, and reach AWS services like S3 and DynamoDB through VPC endpoints instead of routing that traffic out through a gateway.

That gateway is the second silent line item. A NAT gateway is billed two ways at once: a per-hour charge for every hour it is provisioned, plus a per-GB charge for every gigabyte it processes — both region-dependent (see NAT gateway pricing). The classic surprise is a private-subnet workload whose only “external” traffic is to S3: every byte is being metered through the NAT for no reason. AWS’s own guidance is to put resources in the same AZ as the NAT gateway to avoid stacking cross-AZ charges on top, and to use VPC interface or gateway endpoints for AWS-service traffic so it bypasses the NAT entirely.

# Find your top spend movers fast with Cost Explorer, grouped by usage type
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[0].Groups[?Metrics.UnblendedCost.Amount>`100`]'
# Look for *-DataTransfer-Out-Bytes, NatGateway-Bytes, and *-DataTransfer-Regional-Bytes

Lever 3: idle and waste — you pay for what you forgot

When you audit a bill for the first time, this category usually shocks people the most — because nothing is broken, it just wasn’t noticed. A large share of most bills is pure waste: capacity that is provisioned, billed, and doing nothing. The usual suspects are unattached EBS volumes left behind after instances were terminated, old snapshots nobody prunes, over-provisioned instances sized for a peak that never comes, idle RDS databases kept “just in case,” forgotten dev/test environments that run nights and weekends, and load balancers wired to nothing. Two tools attack this directly: Compute Optimizer analyzes utilization and recommends right-sizing (down a size, or to a cheaper family), and a simple scheduler that stops non-production instances outside working hours can cut a dev account’s compute bill by more than half — those environments are idle ~128 of the 168 hours in a week.

Lever 4: visibility — you can’t optimize what you can’t attribute

Every lever above is invisible without measurement, and the foundation is cost allocation tags. Tagging resources by team, env, and service lets you slice the bill by who owns what — but there is a sharp gotcha: a user-defined tag does not show up in cost reports until you activate it in the Billing and Cost Management console, and after you apply it, AWS notes a new tag key can take up to 24 hours to appear in the Billing console for activation, and once activated it only applies to costs going forward, not retroactively. Around the tags sit three tools: Cost Explorer to analyze and forecast spend, AWS Budgets to fire alerts (or even automated actions) when spend crosses a threshold, and Cost Anomaly Detection to catch a spike the day it starts instead of on the first of the month.

{
  "BudgetName": "monthly-prod-ceiling",
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "BudgetLimit": { "Amount": "5000", "Unit": "USD" },
  "CostFilters": { "TagKeyValue": ["user:env$prod"] },
  "NotificationsWithSubscribers": [
    {
      "Notification": { "NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80 },
      "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "platform-oncall@example.com" }]
    }
  ]
}