The cost of building AWS for a million users you do not have
The expensive mistake is not staying on your current host. It is buying Kubernetes, multi-region, and reserved capacity for a load you have never seen.
The expensive mistake is not staying on your current host. It is treating a hypothetical peak as today's bill. You pay for idle clusters, oversized databases, NAT gateways, and a platform your team cannot operate. I have watched founders hire a lead solutions architect to move a startup to AWS for a million concurrent users, then spend the year funding an end state nobody has earned. The costly move is buying that end state on day one.
The mistake: buying the end state on day one
A migration quote that starts with EKS, Aurora Global, and a second region is not a scale plan. It is a catalog dump. You asked for safety. You got a platform that assumes traffic you have never measured.
What the quote is really selling
The vendor, the hire, or the internal architect is selling comfort. Kubernetes looks like what a grown company runs. Multi-region looks like what a grown company survives. Reserved instances look like a discount. None of those choices are wrong at the right time. All of them are wrong when last month's peak still fits on a managed service in one region.
Why this is a judgment failure
AWS did not force the spend. The brief did. If you skipped the measurement work in one million concurrent users is the wrong number, the architecture fills the gap with hardware. That is the opposite of cost and reliability work that matches spend to workload shape.
The AWS Well-Architected Cost Optimization design principles say it directly. "Implement a consumption model." Pay for the compute you require, and change it when the business changes. Do not buy a forecast.
What that bill looks like before you have the users
Idle spend hides in places that look responsible on a diagram.
The line items that show up first
- A Kubernetes control plane and a node group that never drops below a "production-like" floor.
- A database sized for a launch-day stampede, running on the largest instance the quote allowed.
- NAT gateways in every AZ, left on because the reference architecture drew them.
- Reserved or Savings Plan commitments signed before any environment has a week of real traffic.
The waste is not a rounding error
Flexera's 2025 State of the Cloud Report estimated that 27 percent of IaaS and PaaS spend is wasted. Startups copy the same pattern faster. You have fewer workloads, so one oversized cluster is a larger share of the bill. Open Cost Explorer by service and environment. If compute stays flat at 2 a.m., you are paying for a crowd that went home.
Kubernetes and multi-region as status, not need
EKS is a product. Multi-region is a recovery choice. Neither is a badge.
When Kubernetes earns its keep
Use Kubernetes when you already have many services, a platform team, and a reason the managed options fail. A startup with one API and a worker does not have that problem. ECS Fargate or Lambda will carry that shape farther than people expect. I encoded the defaults I actually ship in the ECS Fargate Terraform starter.
When a second region is theater
A second region helps when you must survive a full regional outage, and you have already tested failover. Most 1 million user briefs have not tested failover in the region they have. Active-active doubles the data problem before it doubles the capacity. Stay in one region, use multi-AZ managed services, and write the trigger that would open a second region later.
Always-on capacity in environments that sleep
The quiet version of the same mistake is leaving every environment up all week.
You pay for hours nobody uses
Development and staging often see real traffic for a workday and sit idle the rest of the week. Left running, they bill like production. I cut recurring ECS spend on one platform by scaling those environments to zero overnight and on weekends. The write-up is in scheduled scale-to-zero. The Fargate cost case is the same pattern in production language.
Production is the exception
Production stays up. Everything else should declare whether it is allowed to sleep. Parameterize that flag in Terraform so a staging copy cannot inherit production's always-on setting by accident.
What I refuse to provision until the numbers appear
I will stand up a boring, managed, single-region stack. I will not stand up a million-user replica until the traffic asks for it.
Build now
- Multi-AZ defaults on the data store and the compute you actually run.
- A queue in front of any write that can wait.
- Health checks and alarms that reach a human, so you know when the cheap stack is in trouble.
- Tags and Cost Explorer views that show spend by environment on day one.
Leave on paper
Reserved capacity for a peak you have not seen. EKS because a future hire might want it. A second region. Global databases. A platform team of one pretending to be five. Those belong on a scale path, with a traffic number next to each one.
Frequently asked questions
What is the most expensive AWS mistake for a startup?
Buying the architecture of a company you are not yet. Idle clusters, oversized databases, and multi-region before you have traffic will outspend a simpler stack for a long time.
Is Kubernetes required to handle a traffic spike?
No. Kubernetes helps when you already operate many services. A spike on one API is an Auto Scaling and bottleneck problem, not a container-orchestrator problem.
When is reserved capacity worth it?
After you have stable, well-understood usage. Commit to a baseline you already pay every month. Do not reserve a launch-day guess.
Do I need multi-region to be ready for a million users?
No. Multi-AZ managed services cover the common failures. Multi-region is for a regional outage you have practiced, or for a latency need you can measure.
How do I tell unused capacity from headroom I should keep?
Headroom shows up as a short burst above a busy baseline. Unused capacity is a flat line at 2 a.m. and all weekend. Cost Explorer and CPU, memory, and connection metrics will separate the two.
What should I send if I already have a million-user AWS quote?
Send the diagram, the monthly estimate, and last month's peak requests per second. I will mark what I would cut before go-live, and what I would keep as a seam.