by Gary Worthington, More Than Monkeys

Ask most startup founders about their AWS bill and you’ll either get a shrug (“the tech team has it under control”) or a grimace that says we got stung.

Cloud costs aren’t an accounting footnote. They’re one of the clearest signals of whether your engineering team is building for the business, or just building. The problem is that bills rarely scale neatly with users. They scale with design choices, bad defaults, and forgotten services that keep running in the background.

This isn’t about penny-pinching. It’s about not looking like an amateur when investors ask about burn.

The Big Traps Everyone Falls Into

Orphaned resources
Infrastructure sprawl is one of the most common problems in startups. Engineers spin up test environments, create temporary databases, take backups “just in case”, and then move on. The resources get forgotten, but AWS doesn’t forget to bill for them. The classic culprits are RDS snapshots, unattached EBS volumes, and stray EC2 instances. None of them individually cost much, but they accumulate over time and eat away at your runway. It’s the cloud equivalent of death by a thousand cuts.

Data transfer surprises
Most first-time founders underestimate how expensive bandwidth can be. AWS charges very little to move data in, but it charges plenty to move data out. If your product serves large files, media, or runs APIs without caching, you can see costs rise at a rate that has nothing to do with user adoption. It feels unfair until you realise the model is designed to make you architect carefully. Products that skip CloudFront or design overly chatty microservices quickly learn this the hard way.

Over-provisioning
Startups often convince themselves they need production-grade horsepower from day one. It’s common to see oversized EC2 instances running workloads that barely tickle the CPU. The instinct is understandable(nobody wants downtime on demo day) but buying capacity you don’t use is pure waste. Worse, it creates a false sense of security, because when real scaling issues hit, they won’t be solved by just throwing bigger machines at the problem.

Free tier illusions
The free tier is fantastic for experimenting. It’s not a long-term cost control mechanism. Teams often assume “this thing was free last month, so it’ll be free next month too”. Then they hit the usage thresholds and costs start appearing with no warning. By that point, the service is usually tied deeply into the product, making it difficult to switch or optimise. The free tier should be treated as a marketing gimmick, not a business model.

Accounts, Tags, and Budgets That Actually Work

If you want cost visibility, you need structure. Startups often dump everything into a single AWS account and hope the bill will somehow be easy to interpret. It won’t.

A basic three-account setup (production, staging, sandbox) immediately gives you a cleaner picture. Costs tied to experiments or staging won’t blur into the production bill, and you won’t have to waste time trying to disentangle them later.

Tagging is equally important. Tags are metadata you attach to resources to say who owns them, what environment they belong to, and what they’re for. Without tagging, you’re essentially looking at a line item on a bill that says “EC2 instance” and trying to guess why it exists. With tagging, you can trace it back to the team, environment, or project responsible. Startups that take tagging seriously from the beginning save themselves hours of detective work.

Then there are budgets and alarms. AWS Budgets let you define a threshold (say £500 a month) and send alerts if you approach or exceed it. CloudWatch anomalies can flag when costs jump unexpectedly. These aren’t luxury extras. They’re essential guardrails. They stop you discovering runaway spend in your credit card statement after the damage is done.

Finally, focus where the money really goes. In early-stage products, most spend comes from EC2, RDS, and S3. Don’t waste energy obsessing over pennies in Lambda while ignoring the oversized database instance sitting idle.

Picking the Right Models

AWS has a menu of services longer than most restaurant chains. Knowing which pricing model to pick is half the battle.

For storage, S3 offers multiple classes. Standard is designed for frequent access, Infrequent Access is cheaper but slower, and Glacier is long-term archival at rock-bottom prices. If you’re storing logs or backups in Standard, you’re paying too much. If you’re storing user-facing images in Glacier, your product will crawl. A basic understanding of these tiers avoids both extremes.

For compute, the default is on-demand pricing, where you pay per hour (or second) of usage. That’s fine while you’re figuring things out. Once usage patterns are stable, reserved instances or savings plans can cut costs by a third or more. Many startups miss this step entirely and end up paying premium rates for steady workloads.

For databases, Aurora is AWS’s flagship offering and it scales beautifully , however it’s normally overkill for most early products. Standard RDS Postgres or MySQL can handle more load than most startups will ever see pre-Series A, at a fraction of the cost. Jumping to Aurora too soon is a form of over-engineering that locks in higher spend unnecessarily.

For serverless, the model is attractive: pay per execution. But design matters. A Lambda function that loops inefficiently or hammers DynamoDB can cost far more than a simple, well-sized EC2 instance. Serverless can save money, but only if you use it with discipline.

Cost-Aware Architecture

A lot of startup infrastructure is built with an eye to “what if we have ten million users next month”. That mindset leads to wasted spend long before scale is an issue. The right goal is to build an architecture that avoids waste at today’s scale while leaving headroom for tomorrow.

For example, Static Assets……Serving them directly from EC2 is a rookie mistake. Put them in S3 and shoving CloudFront in front of it is a much better idea. It’s cheaper, faster, and instantly more reliable.

Data pipelines are another trap. AWS offers Kinesis, Glue, Athena, Redshift, and more. They’re all powerful and amazing products, but wiring them together for dashboards before you’ve nailed product-market fit is financial self-harm. More than one startup has ended up spending more on its analytics stack than its core product.

Third-party integrations also deserve scrutiny. Tools like Datadog, New Relic, or even Slack-based monitoring integrations can quietly inflate AWS bills. These services often charge per metric, per host, or per event. The costs multiply as your infrastructure grows, and suddenly your observability stack is eating more budget than the app itself.

A cost-aware architecture doesn’t mean under-building. It means asking whether every component earns its place, and whether the costs it generates scale in line with the value it provides.

The Monthly Review Ritual

Most founders don’t want to spend their evenings dissecting AWS billing dashboards. The good news is they don’t have to. What matters is setting up a simple habit.

Once a month, block thirty minutes to review spend with your team. Look at the trend; is it growing faster than user adoption? Dig into the big services driving the bill. Ask whether those increases are making the product better for customers, or whether they’re symptoms of engineering convenience.

This isn’t about micromanaging engineers or second-guessing every design decision. It’s about showing discipline and keeping spend connected to business outcomes. Investors notice when founders treat infrastructure spend with the same seriousness as headcount.

You don’t need a FinOps consultant or a six-figure SaaS tool to do this. Just a calendar reminder, some curiosity, and a willingness to ask awkward questions when the numbers don’t make sense. Remember, use Tags on your resourced and this is a much easier job for all involved.

Closing

Most startups don’t fail because of cloud costs. But plenty lose credibility with investors by looking like they can’t run a tight ship. AWS is powerful, but it doesn’t forgive sloppiness.

Treat your cloud bill like a reflection of your engineering culture, because that’s exactly what it is.

Gary Worthington is a software engineer, delivery consultant, and Fractional CTO who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.