Introduction
AWS is the default many founders inherit without ever deciding on it. The first developer set it up, the bill was small, and nobody revisited the choice once it stopped being small.
AWS bills compound in ways that are hard to predict: usage-based pricing, data-egress charges and dozens of small services that each cost a little. Most early startups overpay, and a single VPS or managed platform covers far more scale than founders expect. The question is rarely "is AWS good"; it is "is AWS what this stage actually needs".
This framework helps you decide whether to stay on AWS, optimise what you already run, or move to something simpler, without confusing the default with the right answer.
What it solves
What a deliberate AWS decision delivers
-
A bill you can predict
Reviewing the AWS decision forces you to see where the money actually goes. Whether you stay or leave, you end up with a cost you can forecast instead of one that surprises you every month.
-
Freedom from accidental lock-in
Knowing which proprietary services you depend on lets you choose lock-in deliberately, where it pays off, instead of inheriting it by accident across the whole stack.
-
Right-sized infrastructure
Most AWS accounts run instances and services sized for a peak that never arrives. A deliberate review right-sizes the account to today's real load and stops paying for headroom you do not use.
-
A clearer operating model
Fewer, better-understood services are easier to monitor, secure and hand to a new hire. Clarity about what you run beats owning every service AWS offers.
-
Honest scaling headroom
Once you know what your workload actually demands, you know how much runway your current setup has, and what the next step genuinely is. That beats guessing at both ends.
What it does not solve
What leaving (or staying on) AWS will not fix
-
An application that is slow by design
Moving off AWS does not make a slow query fast or an N+1 disappear. Slow code is slow on any provider; it just costs differently.
-
Missing cost monitoring
If you do not watch the bill today, you will not watch it on a VPS either. Cost surprises come from blind spots, not from the provider's logo.
-
Weak deployment discipline
Staging, testing and rollback are habits, not features of a cloud. A platform migration without that discipline moves the same risk to a new address.
-
An over-architected system
If the design needs five services to do the work of one, AWS is not the problem. Simplify the architecture first; the hosting decision gets easier afterwards.
-
A business model that cannot cover costs
Infrastructure spend only matters relative to revenue. Cutting the AWS bill in half does not help if the unit economics never worked in the first place.
Decision tree
Six questions before you stay, optimise or leave
Run your account through these questions. The honest answers point at staying, optimising, or moving to something simpler.
- Question 01
Do you actually use AWS-specific managed services?
No → If you mostly run EC2 instances and an RDS database, you are using AWS as an expensive VPS. A VPS or managed platform likely does the same job for less, with less lock-in.Yes → Name the specific services (S3, SQS, Lambda, DynamoDB, etc.) and what each one buys you. If they solve real problems, that is a genuine reason to stay. - Question 02
Is the monthly bill predictable, or does it surprise you?
No → If the bill jumps without an obvious cause, you do not understand your cost drivers. Find the top three before deciding anything; the surprise is usually egress, idle resources or one over-sized service.Yes → Confirm the prediction holds at your next traffic spike. Predictable today is not predictable under load if the pricing is usage-based. - Question 03
How much data leaves AWS each month?
No → Low egress means data-transfer cost is not driving the bill. The decision is then about compute and managed-service pricing, not network charges.Yes → High egress is a classic hidden AWS cost. Quantify it. Heavy egress workloads (media, large APIs) often run dramatically cheaper on providers with generous or flat bandwidth. - Question 04
Does your team have real AWS operational expertise?
No → Without expertise, AWS is a footgun: misconfigured security groups, forgotten resources and over-provisioned instances. A managed platform or VPS asks less of a team that is not AWS-fluent.Yes → Use it deliberately. Expertise makes AWS workable, but a team that loves AWS tends to adopt more of it than the product needs. - Question 05
Do you have a compliance or scale requirement that AWS uniquely meets?
No → If no regulation, certification or genuine scale demands AWS specifically, the choice is open. Most early products have no such requirement.Yes → Verify it is real and AWS-specific, not just convenient. Many compliance needs are met by simpler providers; confirm before treating AWS as mandatory. - Question 06
What would change if you moved one workload off AWS tomorrow?
No → If the honest answer is 'just a smaller bill', that workload does not belong on AWS. Move it and keep the parts that earn their place.Yes → Name the specific service or guarantee you would lose. That is what AWS is buying for that workload, and what migrating it would cost you.
Common mistakes
Five common mistakes founders make
- 01
Treating AWS as the default, not a decision
AWS is where many startups start because someone set it up, not because anyone chose it. Inheriting infrastructure is not the same as needing it; the bill grows whether or not the choice was ever made.
- 02
Ignoring data-egress costs
Compute and storage are easy to see; the cost of moving data out of AWS is not. Egress charges quietly become one of the largest lines on the bill, especially for media-heavy or API-heavy products.
- 03
Accidental lock-in via proprietary services
Lambda, DynamoDB, SQS and friends are convenient and deeply AWS-specific. Adopting them by default makes leaving expensive later. Lock-in is fine when chosen for real value; it hurts when inherited by accident.
- 04
Leaving idle and over-sized resources running
Forgotten instances, unattached volumes, oversized databases and dev environments that never sleep are the most common waste in any AWS account. The bill keeps paying for capacity nobody uses.
- 05
Confusing 'industry standard' with 'right for us'
AWS is the standard for companies with AWS-shaped problems: real scale, dedicated infra teams, specific managed services. Copying their setup into an early startup imports the cost without the underlying need.
Alternatives
Five paths compared
From simplest to staying put. Most early startups that feel AWS pain belong in one of the first two.
-
VPS (virtual private server)
A single machine you control on Hetzner, DigitalOcean, OVH or similar. Fixed monthly price, generous bandwidth, debuggable in an SSH session. Scales far further than founders expect, especially with caching and a CDN, and removes egress and per-service billing entirely.
-
Managed platform (Render, Fly.io, Railway, Heroku)
Push code, the platform handles infrastructure, databases, scaling and monitoring. More predictable than AWS at small scale and much cheaper per engineer-hour. The right default when the team wants to focus on the product rather than on operations.
-
Hybrid (keep specific AWS services, move the rest)
Run compute on a VPS or platform while keeping the one or two AWS services that genuinely earn their place, S3 for storage, for example. Captures the value without paying for the whole ecosystem.
-
Stay on AWS but optimise
If AWS-specific services are core, the answer is to optimise, not leave: reserved instances and savings plans for steady load, right-sizing every instance and database, deleting idle resources, and putting a CDN in front of egress-heavy traffic.
-
European cloud (Scaleway, Hetzner Cloud, OVHcloud)
Cloud-style services with simpler pricing, generous bandwidth and EU data residency. Worth a look when you want managed pieces and predictable cost, or when data location matters for compliance reasons.
Ronald's rule of thumb
Stay on AWS only for the specific services that solve a real problem; run everything else on the simplest thing that works.
AWS earns its keep when you genuinely use its managed services, operate at real scale, or face a compliance need it uniquely meets. Outside those cases it is usually an expensive VPS with a confusing bill. Keep the parts that pay for themselves; move the rest before the lock-in deepens.
, Ronald · YourStartup.Expert
Summary
Summary
The AWS decision comes down to two facts: which AWS-specific services you actually depend on, and how predictable your bill is. The six questions above turn both into a choice between staying, optimising, or moving the parts that do not belong there. Most early startups overpay because nobody ever decided on AWS in the first place.
Keep AWS for the services that solve real problems, real managed services, real scale, a genuine compliance need. Optimise what you keep with savings plans, right-sizing and by turning off what is idle. Move the rest to a VPS or managed platform before accidental lock-in makes leaving expensive. The bill rarely kills a startup; the surprise of not understanding it sometimes does.
Common questions
AWS decisions, answered.
The questions founders ask before they stay on AWS, optimise it, or move on.
- Is AWS too expensive for a startup?
- Not inherently, but most early startups overpay because they use AWS as an expensive VPS, leave resources idle and ignore egress charges. If you mostly run EC2 and RDS, a VPS or managed platform usually does the same work for a fraction of the cost. AWS becomes worth its price when you genuinely use its managed services or operate at real scale.
- When does AWS genuinely make sense?
- When you depend on specific managed services that solve real problems (S3, SQS, Lambda, DynamoDB), when you operate at real scale with a dedicated infrastructure team, when a compliance or certification requirement points specifically at AWS, or when your existing team has deep AWS expertise. Outside those cases, simpler hosting usually fits an early startup better.
- What is AWS lock-in and how do I avoid it?
- Lock-in happens when you build on proprietary services like Lambda, DynamoDB or SQS that have no direct equivalent elsewhere, making migration expensive. Avoid it by preferring portable building blocks (containers, standard databases) for the core, and adopting proprietary services deliberately only where the value clearly outweighs the future cost of leaving.
- Why is my AWS bill higher than I expected?
- The usual culprits are data-egress charges, idle or over-sized resources, and many small per-service costs that add up. Egress in particular is easy to miss. Start by finding your three biggest cost drivers in Cost Explorer; the surprise almost always lives in one of them, and right-sizing plus deleting idle resources usually recovers a large share quickly.
- How do I cut my AWS costs without leaving?
- Buy reserved instances or savings plans for steady, predictable load. Right-size every instance and database to actual usage rather than guessed peaks. Delete idle resources, unattached volumes and dev environments that run overnight for no reason. Put a CDN in front of egress-heavy traffic. These levers often cut a bill substantially before any migration is even considered.