A Letter to SaaS Founders: Why Your AWS Bill is Bleeding You Dry
Dear Founder,
I've been watching several SaaS companies, and I see something most people don't talk about openly. Your AWS bill is probably bleeding you dry, and you don't even realize it. Not because you're making catastrophic mistakes, but because nobody ever explained the tradeoffs in language that actually matters to you—runway, hiring, and survival.
I'm writing this letter to change that. Your CTO knows the technical details. They probably even optimize occasionally. But you? You need to understand the business impact of these decisions because you're the one signing the checks and deciding whether to hire another developer or extend your runway another quarter.
Here's what I've seen happen more times than I can count: a founder like you, running lean, raising a seed round or bootstrapping carefully. They're watching every dollar. And then, at the end of the month, they see an AWS bill for $12,000, then $15,000, then $18,000. They ask their CTO about it. The CTO explains something about servers and databases and Reserved Instances, and the founder's eyes glaze over. They say, 'Okay, sounds reasonable,' and move on. But it's not reasonable. Most of the time, it's 40 to 60 percent more than necessary.
The worst part? You never find out. The money just keeps flowing out every month, and you convince yourself that's just the cost of doing business. That this is what cloud infrastructure costs. That your CTO knows what they're doing so it must be fine.
But here's the thing that keeps me up at night: that $7,000 difference between what you're spending and what you should be spending? That's a full-time marketer. That's a contractor who could hustle growth while your core team builds product. That's three more months of runway when you're bootstrapped and hungry. That's the difference between hitting product-market fit and running out of money just before you would have made it.
This letter is about closing that gap. Not by turning you into a cloud engineer. But by helping you understand the decisions, ask the right questions, and have a quarterly conversation that saves you real money. I'm going to explain this in plain English, with examples, and with a process you can actually use.
Let's start with the basics. AWS is essentially a massive company that rents you computers and storage space. You only pay for what you use—in theory. In practice, it's more like renting an apartment where the landlord offers you different sized units, and most tenants pick way too big a unit because they don't want to risk running out of space. So they end up paying for closet space they never use.
Your AWS bill has four main components, and understanding these four things will help you understand where the waste usually lives. Think of them as the four places where money leaks out of your budget every month.
The first one is servers. In AWS language, they call them EC2 instances. These are the computers that actually run your application. When someone visits your website or uses your app, it's running on one of these servers. Your CTO picks the size of these servers. They come in different flavors: small, medium, large, extra large. It's like picking between a Honda Civic, a Toyota Camry, and a Mercedes S-Class. They all get you where you need to go. But they cost wildly different amounts.
A small server (they call it t3.micro) costs about $9 per month. A medium server costs about $30 per month. A large costs about $60. An even bigger one costs $100 or more. Same software running on all of them. Same customers getting the same experience. But different costs every single month, forever.
Here's what I've learned: most CTOs start with a medium or large server 'just to be safe.' They don't want their app to slow down. They don't want to get blamed for bad performance. So they overprovision. They pick a server size for the traffic they might have someday, not the traffic they have today. And that decision costs you real money, every single day, whether you're actually using that capacity or not.
The second big cost is your database. This is where all your customer data lives—their account information, their settings, their history, everything. Your database also needs a server to run on, and like the application server, it has sizes. Your CTO picks a size here too. And like the application server, they often pick bigger than they need.
Database servers are often the most oversized component I see. A CTO will put their database on a db.t3.small or db.t3.medium because 'databases are critical infrastructure and they need power.' Except most early-stage SaaS companies could run on the smallest tier for years. Your database isn't processing millions of queries per second. It's handling normal business. But you're paying premium prices anyway.
The third piece is storage. This is where you keep files—customer uploads, documents, images, whatever. AWS calls this S3. Here's the good news: storage is cheap. Really cheap. Like, almost free cheap. A hundred gigabytes of storage costs about two dollars per month. A terabyte costs about twenty-three dollars. Storage alone is rarely your problem.
What can be expensive is data transfer. Every time your customer downloads a file, or you move data between servers, AWS charges you. This is where I see companies accidentally blow up their bills. A company thinks they're managing storage efficiently, but they're transferring petabytes of data every month and nobody realized it until the bill came.
The fourth bucket is everything else. Load balancers. Backup services. Monitoring tools. Additional services that integrate with your main system. CloudFront for delivering content faster. NAT gateways. These pieces add up to 10 to 20 percent of most bills, and they're where you find the mystery costs. The things your CTO set up six months ago for a 'just in case' scenario and forgot to take down.
So here's the reality. You're overspending on AWS right now. I'm pretty confident about this. Not because your CTO is incompetent. They're not. They're being cautious. They're making reasonable engineering decisions. But they're not optimizing for your business, which is cash runway and growth. They're optimizing for reliability and safety. Those things conflict when you're early stage.
Most of the companies I've looked at are spending 40 to 60 percent more on AWS than they need to. That typically means they're overspending by $3,000 to $10,000 per month. For a bootstrapped company, that's life or death money.
Let me give you a real example. I worked with a SaaS company running at $40,000 per month in burn rate. They had $300,000 in the bank. That's seven and a half months of runway. Tight, but workable. Their AWS bill was $15,000 per month. We spent an afternoon auditing their infrastructure. We found: their application server was way too big, their database was running at 10 percent capacity, they had orphaned resources from old experiments sitting around, and they had unnecessary data transfer costs from using multiple regions when they didn't need to.
We cut their AWS bill to $8,000 per month. That cut their burn rate from $40,000 to $33,000. That $300,000 in the bank suddenly bought them ten months of runway instead of seven and a half. They hit product-market fit in month nine. If we hadn't done that audit, they would have run out of money just before success.
That's not unusual. That's the norm.
Now I want to talk about something that will probably come up with your CTO. Reserved Instances. This is where I'm going to tell you something your CTO might not want to hear.
Reserved Instances are AWS's version of a long-term contract. Instead of paying month to month, you pay upfront for one year or three years, and AWS gives you a discount. Usually 30 to 50 percent off the monthly price. It sounds amazing. It IS mathematically amazing. You could save $1,000 or more per month over three years.
But here's what your CTO might not tell you: you're locked in. If your architecture changes, if you want to try something new, if you optimize away that server, if you get acquired, if you pivot your product—you're stuck with that contract. You can try to sell it on AWS's marketplace, but usually at a significant loss. You're betting three years of infrastructure costs on your ability to predict the future. For a growing company, that's a terrible bet.
I know CTOs who push Reserved Instances hard. They frame it as cost optimization. What they're really doing is lock-in. They're reducing the bill in exchange for reducing your flexibility. And when you're early stage, flexibility is worth more than savings.
Here's my honest take: for the first two or three years, use on-demand instances. Pay the extra 30 percent for flexibility. That extra cost is cheap insurance. Once your business is stable and predictable, once your architecture has settled down, then revisit Reserved Instances. Most bootstrapped founders should skip them entirely.
The only exception is if you've identified one specific, critical, unchanging cost that you're 100 percent sure will be the same in three years. Maybe your core database server. Maybe your primary application server. But even then, be skeptical. You'll grow faster and innovate better with flexibility than you will with savings.
Let me give you some real numbers so you know what to expect. These are based on actual SaaS companies I've worked with. Your numbers might be different, but this gives you a baseline.
If you're completely early stage, not generating revenue yet, your AWS bill should be tiny. Maybe $100 to $300 per month. One small server, one small database, maybe some monitoring tools. That's it.
When you start getting revenue—let's say you're at $5,000 to $20,000 per month—your AWS bill should be around $500 to $1,500 per month. You might have a slightly bigger server now. A dedicated database server. Some backup infrastructure. But still modest.
If you're doing $50,000 per month in revenue, $1,500 to $3,000 per month for AWS is reasonable. Maybe multiple servers. Database replicas for redundancy. CDN for faster content delivery. Still under 5 percent of revenue.
At $200,000 per month in revenue, you might be at $4,000 to $8,000 per month for AWS. Again, 2 to 4 percent of revenue. This is healthy. This is what good engineering looks like.
Here's the key metric: your AWS bill should never be more than 10 percent of your monthly revenue. If it is, you're overspending. Period. Most healthy SaaS companies run at 5 to 8 percent. Some really lean companies run at 2 to 3 percent. But 10 percent or above? That's a warning sign.
So if you're doing $100,000 per month in revenue and your AWS bill is $15,000, you're in trouble. You should be at $5,000 to $8,000. That $7,000 difference? That's money that could be hiring, marketing, or extending your runway.
The exciting part is that this is fixable. And it's not that complicated. You need one conversation with your CTO per quarter. Thirty minutes. That's it.
Here's how the conversation should go. First, ask your CTO to pull your detailed AWS bill from something called Cost Explorer. It takes five minutes. It should show you clearly: how much you're spending on servers, how much on databases, how much on storage, how much on data transfer, and what else is in there.
Then ask: 'What was our bill last quarter? Are we trending up or down?' Your AWS costs should grow slower than your revenue. If they're growing faster, something is wrong.
Next: 'What server sizes are we running, and are we actually using that capacity?' Your CTO can pull CPU and memory metrics. If a server is running at 10 percent capacity, it's too big. If it's running at 30 percent, it's probably too big. You should be comfortable running at 50 to 70 percent capacity, which means you have buffer for growth but aren't wasteful.
Then ask: 'Are there any unused resources we should clean up?' Old databases from experiments. Forgotten snapshots. Elastic IPs that aren't attached to anything. Unused load balancers. These accumulate. One company I looked at was paying $800 per month for resources that didn't exist anymore. They'd just forgotten to turn them off.
Then ask: 'What's our data transfer bill, and is it necessary?' This should be small. If it's large, you might be doing something inefficient with how data moves between regions or between your servers and customers.
Finally, ask: 'What's one thing we could rightsize this quarter?' Not everything at once. One thing. You could downsize one server. Consolidate some infrastructure. Kill one unused service. One change, one month, then see what happens. If nothing breaks, you've found real savings. If performance gets weird, you size back up the next week. It's low risk.
That conversation will probably save you $1,000 to $3,000 per month. Sometimes way more.
I want to give you some specific red flags to watch for. If you see these, push back on your CTO.
First red flag: 'We don't really look at AWS costs.' If your CTO doesn't know what you're spending and why, something is wrong. It takes five minutes to pull a bill. They should be doing it at least monthly. If they say 'I don't worry about that, it's what it is,' that's a problem. Caring about efficiency is not being cheap. It's being professional.
Second red flag: Your AWS bill is growing faster than your revenue. If you're growing revenue at 20 percent but AWS costs are growing at 30 percent, you're adding infrastructure faster than you're adding value. That's not sustainable. Ask why. Usually it's because of unnecessary provisioning. Fix it.
Third red flag: AWS is more than 15 percent of your revenue. You're probably overspending. Healthy SaaS companies run at 5 to 10 percent. If you're above that, do an audit. Seriously.
Fourth red flag: 'We need Reserved Instances to optimize costs.' Be skeptical here. Especially if you're early stage. Optimization shouldn't require lock-in. If your CTO is pushing this hard, they might be optimizing for the wrong metric. Push back. 'Why do we need to lock in for three years right now? Aren't we still figuring out our architecture?'
Fifth red flag: You're paying for services you don't understand. Your bill has more than 10 line items and you can't explain 5 of them. That means there's waste. Complexity breeds waste. Simple infrastructure is usually cheaper and more reliable.
Now, I want to talk about how to actually have this conversation with your CTO without making them feel attacked or distrusted. This is important because engineers can be sensitive about infrastructure decisions.
Start by acknowledging that they've made good decisions. 'I'm impressed with how we've maintained reliability as we've grown.' That's probably true. They've probably done solid work. Then frame this as you learning, not them failing. 'I realized I don't actually understand our AWS bill, and I should. Can we spend thirty minutes next week going through it together? I want to understand what we're paying for and whether there are easy wins we're missing.'
That frame accomplishes something important: it's collaborative, not accusatory. You're not saying they're wasteful. You're saying you want to understand better. Most CTOs will actually be excited about this. Infrastructure optimization is genuinely interesting to engineers. They just don't always do it if nobody is pushing.
When you meet, lead with curiosity. 'I don't understand what this line item is. Can you explain?' Listen for tradeoffs. 'Why did we choose that server size?' Make suggestions, not demands. 'What would happen if we tried downsizing for a week?' The key is: you're exploring together, not interrogating.
Give credit for what's working. Your CTO might have done a bunch of things right already. Say that. Then suggest one thing to optimize. One thing. Not a list. One experiment. One week. Then measure.
If you approach it this way, you're not the cost-cutting founder they're wary of. You're a founder who cares about the business and wants to work together. And most CTOs respond really well to that.
Let me paint a picture of what this actually means for your business. Not in the abstract. In real terms.
Let's say you're bootstrapped. You have $300,000 in the bank. You're spending $50,000 per month total: salaries, marketing, tools, office, everything. That's six months of runway. You're hungry but not desperate.
Your AWS bill is $12,000 per month. That's 24 percent of your burn. It's too high, but you've never really looked at it.
You have the conversation with your CTO. You audit your infrastructure. You downsize servers, kill unused resources, consolidate databases. You get AWS down to $7,000 per month.
Your burn rate is now $45,000 per month instead of $50,000. That $300,000 now buys you six and a half months instead of six. But here's the real magic: you now have $5,000 per month extra. What do you do with that?
Maybe you hire a contractor for growth and marketing. $5,000 a month might get you two days a week of a really good growth person. That person runs experiments, improves your sign-up flow, optimizes your email sequence. They might bring in $15,000 of extra revenue per month. You've just multiplied that $5,000 five times.
Or maybe you use it to hire another developer for a few hours a week. They build features faster. You ship product faster. Your velocity increases. Customers love the new features. Revenue grows. You're not stuck optimizing AWS bills, you're building.
Or maybe you just let it extend your runway another month. That month is the difference between hitting product-market fit and running out of money just before success. I've seen this happen. It's scary. It's also avoidable.
That's what AWS optimization really means. It's not about being cheap. It's about runway. It's about survival. It's about having the cash to keep building until you've figured it out.
Okay, here's what I want you to do in the next 48 hours. Not someday. Not next quarter. Now.
First, forward this letter to your CTO. Or just the important parts if you want to be selective. Tell them you want to understand the AWS bill better and want to work together on optimization. Frame it as collaboration.
Second, schedule a 30-minute meeting for next week. Pull your AWS bill. Look at it together. Ask the five questions I mentioned: What was our bill last quarter? Are we growing faster than revenue? What server sizes are we running? Are there unused resources? What's one thing we could rightsize?
Third, identify one thing to optimize in the next month. One thing. Downsize a server. Kill a unused database. Consolidate infrastructure. One experiment.
Fourth, commit to doing this quarterly. Set a calendar reminder. Last week of every quarter, you and your CTO spend 30 minutes on this. That's four hours per year to save potentially thousands of dollars per month. It's the best ROI on your time you'll get.
That's it. Four things. The first one takes two minutes. The others are just showing up and asking good questions. And I genuinely believe this conversation will save you $3,000 to $10,000 per month, conservatively.
I'm writing this because I've seen too many good founders run out of money just before they would have made it. Not because their product wasn't good. Not because they weren't executing. But because infrastructure costs slowly crept up and nobody questioned it.
Your runway isn't determined by how much money you raised or how frugally you live. It's determined by how intentionally you spend. Every dollar in your AWS bill is a dollar not going to growth, not going to hiring, not going to extending your ability to experiment and iterate until you figure it out.
I'm not telling you to cheap out on infrastructure. Reliability matters. Performance matters. You should spend what you need to spend. But you should spend what you need, not what makes engineers feel safe. And the only way to know the difference is to have this conversation regularly.
Your CTO is smart. They care about your success. But they also think like an engineer, which means they optimize for reliability over cost. That's their job. Your job is to optimize for survival and growth. Those aren't in conflict if you talk about it regularly.
So talk about it. Have the conversation. Understand your bill. Question the expensive decisions. Run experiments. Build the habit of quarterly reviews. And use the money you save to hire, to grow, to build.
You've got a real shot at building something great. Don't let AWS costs be the thing that stops you. You're too close to let that happen.
You've got this.
Your friend in the trenches,
Saurabh