Cut AWS Costs Without Slowing Down Engineering

Every AWS bill holds a few dollars that nobody would choose to spend. Almost nobody looks straight at them. The invoice arrives after the month closes, spread across hundreds of line items. Once it is readable, the engineering decisions behind it are old. The fix is to see cost early enough to act. Then use a short list of levers that do not trade dollars for velocity. This post lists them, roughly in order of effort to payoff.

Start with what’s simply idle

Before you touch an instance type, find the resources that run and cost money while doing nothing useful:

• Unattached EBS volumes. A terminated instance can leave its volume behind. The volume keeps billing by the gigabyte-month until someone notices.
• Idle load balancers and NAT gateways. A NAT gateway charges an hourly rate and a per-GB processing fee. It is easy to miss. It is expensive to leave running against a subnet that nothing uses.
• Old snapshots and AMIs. Snapshots from a retired pipeline often outlive it by months.
• Dev and staging environments that never sleep. Say a dev cluster is sized and billed like production, but people use it nine hours a day, five days a week. You pay full-time for part-time work.

None of this needs a redesign. Someone needs to look on a schedule. That person also needs the “orphaned” category as its own line, not buried in the “EC2” or “EBS” totals. Idle resources usually take the least effort to remove on an AWS account. They are also the easiest to ignore. None of them hurts anything. They only cost money, day after day.

Rightsize before you commit

Reserved Instances and Savings Plans commit you to your current shape of usage. If you commit before you rightsize, you lock in the waste with the workload. First, pull CPU, memory, and network use for your steady-state fleet. Many teams find instances sized two steps larger than they ever needed. Often “we’ll grow into it” felt safer than a follow-up ticket that nobody filed. Rightsize first, then commit. The commitment is more accurate, and the discount applies to a smaller, truer number.

Savings Plans vs. Reserved Instances

Once usage is stable, ask how much flexibility you will give up for how much discount:

• Reserved Instances are tied to an instance family and region. Convertible versions are more flexible and carry a lower discount. They suit workloads that rarely move, such as a fixed-size database tier.
• Savings Plans commit to a dollar amount per hour, not an instance shape. They apply across instance families and sizes. Compute Savings Plans also cover Fargate and Lambda. The ceiling discount is slightly lower than an inflexible RI. The risk of outgrowing the commitment in six months is much lower too.

For most teams past their first year, layers work well. Size a Compute Savings Plan to your true steady-state floor. Leave anything above that floor on-demand or on spot. Nobody needs to get this perfect on day one. Revisit it each quarter as usage shifts. Do not treat it as a one-time purchase.

Before you commit, run the numbers both ways. The commitment discount calculator shows the break-even utilization. Below that level, a commitment costs more than on-demand. It also shows the stranded spend if usage drops after you buy.

This advice does not apply cleanly to a Kubernetes cluster. A node’s bill and a pod’s request are two accounting systems stacked on each other. If that is your fleet, use the Kubernetes cost allocation & idle capacity calculator. It splits the node bill into used, workload idle, cluster idle, and system-reserved before you change a single request.

Storage tiering is compounding, not one-time

Storage cost grows quietly. On any given day, nothing about an S3 bucket looks expensive. Lifecycle policies exist for data that you write once and rarely read. Move objects from Standard to Infrequent Access to Glacier as they age. The marginal cost per byte then keeps falling, even as the bucket grows. The same logic applies to EBS snapshots and RDS backups that age past their useful recovery window. Check your largest buckets for a lifecycle policy. It needs no application change. You set it once.

Egress is the tax nobody budgets for

Data transfer is the line item most likely to surprise a team that is otherwise careful about compute. It scales with product success, not with infrastructure choices. More users mean more egress and a bigger bill. Did a cryptic code like NatGateway-Bytes or DataTransfer-Regional-Bytes bring you to this post? The AWS Bill Decoder is the fastest way to translate it. These levers move egress itself:

• CDN in front of anything public. Each asset served from a caching edge does not cross a paid egress boundary.
• Same-region traffic where possible. Cross-region and cross-AZ transfer carry a cost. Same-AZ, same-region traffic does not.
• Compress before you transfer. Teams often skip this for internal service-to-service traffic that “isn’t the hot path.”

The part that keeps it fixed

Most FinOps teams already know the levers above. Bills still creep, and the cause is rarely a lack of knowledge. AWS Cost Explorer shows the aggregate, in AWS’s categories and not yours. AWS refreshes it at least once every 24 hours, but the invoice arrives only after the month closes. An idle NAT gateway can sit in the console unnoticed until someone matches it to a cost.

CostMon closes that gap. It pulls your AWS Cost Explorer data on a schedule and normalizes it with whatever else you run. You get trends and breakdowns you can watch continuously, instead of rebuilding them once a month from a CSV. CostMon also lists recommendation findings, such as “Possible idle resource on Amazon RDS”. A finding like that gives you a specific thing to check. Then “we should clean that up” can become a task.

Spend on infrastructure that earns its keep is fine. The goal is to stop paying for infrastructure that does not, and to know which is which before the invoice tells you.