One million concurrent users is the wrong number

You do not have a 1 million concurrent user problem. You have a measurement problem. Founders tell me they need AWS so the app can survive a million people online at once. Then I ask what they measured last Tuesday, and the room goes quiet. Concurrent users, registered users, and peak requests are different numbers. Moving the same code to a new cloud does not change any of them.

What people mean when they say 1 million concurrent users

The phrase shows up in decks, investor updates, and job posts for a lead solutions architect. It rarely means what it says.

Three numbers hiding in one phrase

I hear the same sentence from three different briefs.

1. One million registered accounts, with a few thousand people active on a busy day.
2. A launch-day fantasy, with no traffic history to support it.
3. A board slide that swapped users for concurrent users because it sounded more serious.

Why the mix-up is expensive

If you treat a registered-user goal as a concurrency target, you buy a platform sized for a load you will not see. That is how a SaaS production readiness conversation turns into a migration quote before anyone has opened CloudWatch.

The New York Lottery platform served millions of public users. The work that mattered was identity, audit, and boundaries, not a concurrency trophy.

Concurrent users are not registered users

A concurrent user is someone generating work right now. A registered user is a row in a table. Monthly actives sit in the middle. None of those equal requests per second.

Translate users into work

Capacity is work. Ask how many requests a busy user sends, how large the payload is, and which calls wait on a database. One thousand people refreshing a feed is a different machine than one thousand people opening a static page.

Operators who run real traffic talk in requests per second. Cloudflare processed a peak of 99.8 million HTTP requests per second on Cyber Monday 2024. They did not report that day as concurrent users. Read their Cyber Week 2024 traffic review.

Use the Well-Architected test

The AWS Well-Architected Performance Efficiency design principles put it plainly. "Take a data-driven approach." If you cannot show last month's peak requests per second, you do not have a scale brief. You have a guess.

Why a lift to AWS does not buy you that number

AWS gives you services that can grow. It does not rewrite a synchronous monolith, a single-writer database, or a session store that lives on one box.

The cloud copies your bottlenecks

Lift the same app onto larger instances and you still serialize on the same lock. Auto Scaling adds hosts. It does not add a queue, a cache, or a read replica you never designed. AWS documents how EC2 Auto Scaling adds capacity. It assumes you already know what to add.

What a managed stack already covers

A single-region stack on API Gateway, Lambda or ECS, and a managed database already clears more traffic than most startups will see, if the app shape is right. I covered that reliability floor in how to meet a 98% uptime SLA. The gap is almost never that you are not on AWS. The gap is that you cannot name the hot path.

What actually fails first when traffic jumps

Traffic does not flatten a well-shaped app all at once. It finds the first synchronous thing that cannot keep up.

The usual first break

1. The database connection pool, because every request opens work that should have been cached or queued.
2. A write path that cannot shard, because you stored the popular object in one row.
3. A deploy or alarm gap, because you learn you are down from a user, not from a health check. I wrote about that failure mode in CloudWatch alarms nobody reads.

Why more hosts do not fix it

If the bottleneck is a single writer, ten more containers wait in line with the first one. That is why I start with shape, not instance size. Fix the path that cannot scale horizontally. Then capacity is a purchase you can defend.

The number I ask for instead

When a founder asks me to make the app safe for a million concurrent users, I do not start with a service list. I ask for three facts.

1. Peak requests per second on the busiest endpoint from the last 90 days.
2. Daily active users, not lifetime signups.
3. Which calls are synchronous, and which can wait in a queue.

If you do not have those numbers, we measure before we migrate. That is the same diagnosis before build sequence I use on every engagement. Once the load is real, we can talk about the cost of building AWS for a million users you do not have.

Frequently asked questions

Is 1 million concurrent users a realistic startup target?

For most products, no. A million registered users is a growth goal. A million people generating work at the same second is a rare event, and you will see the traffic climb for a long time before you get there.

What is the difference between concurrent users and requests per second?

Concurrent users count people. Requests per second count work. One user can generate many requests. Capacity planning uses the work number.

Will moving to AWS make my app scale automatically?

No. AWS can add hosts and managed services. It will not remove a single-writer database or a synchronous path you designed into the product.

What should I measure before I hire a lead solutions architect?

Peak requests per second on the hottest endpoint, daily actives, error rate, and p99 latency. Bring those to the first call. Leave the deck number in the deck.

Do I still need AWS if my concurrency number is much smaller?

Choose AWS for isolation, compliance, or a cleaner deploy path. Do not choose it as a magic capacity upgrade. If production already breaks under real tenants, start with SaaS production readiness, not a lift and shift.

How do I convert a user goal into a load number?

Take daily actives, estimate the share online in the peak minute, and multiply by requests per user in that minute. Then check it against logs. A guess you can test beats a round number in a slide.