AWS cost optimization means paying only for the cloud capacity your product actually uses. For most startups, the order matters more than the tactics: first find out who is spending what, then switch off what nobody uses, then shrink what is too big, and only after that sign up for long-term discounts. Doing it the other way round locks you into paying for waste at a lower rate.
This guide is written for founders and business owners, not engineers. You don’t need to know how AWS works to follow it. You need to know which questions to ask your team.
AWS charges for what is switched on, not for what is used. A server that sat idle all weekend costs the same as one that was busy. A test environment someone set up for a demo in March keeps billing until someone deletes it.
This is common, not a sign your team is careless. Flexera’s 2026 State of the Cloud report puts wasted cloud spend at 29%, and says it rose this year for the first time in five years. The reason it gives is AI workloads growing faster than anyone’s ability to watch them.
You can’t cut a bill you can’t read. Most startup AWS bills arrive as one number with a long list of service names underneath. Nobody can say which part belongs to the product, which to testing and which to that experiment from last year.
Ask your team to do two things:
The question to ask your team: “If our bill jumped 30% next month, how many days would it take us to notice, and could we say why?”
This is the cheapest saving, because it needs no redesign. Things to look for:
AWS’s own cost optimization guidance lists deleting unused resources as a starting point for the same reason: it’s pure saving with no downside.
The question to ask: “What is running right now that we would not set up again today?”
Teams usually pick a server size when they launch, add a margin “to be safe,” and never look again. Months later, the product runs comfortably on half.
AWS has a tool for this, Compute Optimizer, which compares what each server is using against what you are paying for and suggests a smaller size.
There’s often a second saving here. AWS says its own Graviton processors cost up to 20% less than comparable standard servers. Many modern apps can move to them with little change, though your team needs to test first.
The question to ask: “When did we last check whether our servers are the right size?”
AWS gives large discounts if you promise to keep paying. Savings Plans cut prices by up to 72% compared to normal on-demand rates, in exchange for a one or three year commitment.
That’s a real saving, and it’s why many guides put it first. We put it last on purpose. If you commit before steps 2 and 3, you are promising to pay for servers you were about to switch off or shrink. The discount makes the waste cheaper. It doesn’t remove it.
Two more things founders should weigh:
AWS sells spare capacity as Spot Instances at up to 90% off on-demand prices. The catch is that AWS can take them back at short notice.
That makes Spot a poor fit for your live product and a good fit for work that can pause and resume: overnight data jobs, test runs, and AI model training that saves progress as it goes.
Some of the most confusing lines on an AWS bill aren’t servers at all. They’re charges for moving data.
A NAT gateway, a common piece of network plumbing, is billed both per hour and per gigabyte of data that passes through it. AWS’s own pricing example shows $0.045 for each. For a product that moves a lot of data, that line alone can surprise you. Data leaving AWS to the internet is also charged.
The question to ask: “What are the three biggest non-server lines on our bill, and do we know what causes them?”
AI workloads change the order a little, because GPU servers are among the most expensive things you can rent on AWS. An idle one burns money quickly.
The usual culprits:
A simple rule helps: every GPU resource has a named owner and an end date. If nobody can say who owns it, it’s the first thing to review.
Buying commitments first. Covered above. It’s the most common expensive mistake because the discount looks like an instant win.
Treating cost as a one-off project. A cleanup in January is undone by June if nobody is watching. Cost needs a monthly look, even a short one.
Cutting what protects you. Backups, monitoring and a second copy of your database cost money. Removing them saves a little until the day you need them.
Leaving it to whoever has time. When cost belongs to everybody, it belongs to nobody. One person should own the monthly review.
You can do most of this in-house if your team has the time. Many startup teams don’t, because the same engineers are shipping the product.
Infranexa runs managed cloud and DevOps for AWS and Azure on a fixed monthly fee, and offers a free cloud assessment that goes through your account in this order and tells you what to fix first.
No. New projects, new team members and new features keep adding resources. A short monthly review stops the bill drifting back up.
It depends on the account, but switching off unused resources and right-sizing usually come first, because they cost nothing to do and carry no long-term commitment.
Usually, once usage has been cleaned up and is stable. Start with a one year plan covering the part of your usage you are sure about.
