Cutting your AWS bill without cutting corners
Most over-spend isn't waste you can see — it's architecture decisions made months ago. Here's where the money actually goes.
When a cloud bill starts climbing, the instinct is to hunt for idle instances and call it a day. That helps, but the real savings are structural. The biggest line items are usually doing exactly what they were designed to do — the design just wasn't optimized for cost.
Start with the data transfer you can't see
Cross-AZ traffic, NAT gateway processing, and egress to the internet quietly add up. They rarely show on a dashboard until you go looking. Map your traffic flows before you touch instance sizes — a single chatty service crossing availability zones can cost more than a fleet of right-sized servers.
Right-size with usage, not guesses
Provisioning for peak load 'just in case' is the most common and most expensive habit. Use real utilization data over a representative window, then size for the p95 and let autoscaling handle the spikes. Compute Optimizer and a week of honest metrics beat a year of conservative guessing.
Commit to what's stable, stay flexible on the rest
Baseline load that you know you'll run for a year belongs on Savings Plans or Reserved capacity — that's 30-60% off for a commitment you were going to make anyway. Keep variable and experimental workloads on-demand or spot. The mistake is treating the whole estate as one risk profile.
Make cost a property of the architecture
The durable fix is to make cost visible at design time: tag everything, attribute spend to teams, and review it like any other non-functional requirement. Cost isn't a cleanup task you do once — it's a property you design for, the same way you design for latency or availability.
Working on something like this?
This is the kind of problem we solve every day. If it’s on your plate, let’s talk.
Get in touch