Virtual Waiting Room on AWS has been retired: what to do now

AWS retired Virtual Waiting Room on AWS in November 2025. If you deployed it before then, nothing suddenly stopped working: the waiting room is still running inside your AWS account.

What has changed is that AWS no longer updates the solution, supports it or lists it in the AWS Solutions Library. From now on, keeping it working is entirely your responsibility.

This guide explains what the retirement actually means, the risks of continuing to run it, and the options for replacing it.

First: your existing waiting room hasn't been switched off

AWS launched Virtual Waiting Room on AWS in February 2022 as a free, open-source reference architecture.

It was never a managed AWS service. Customers deployed it into their own AWS accounts using CloudFormation, and from that point the deployment, configuration, updates and maintenance were always the customer's responsibility.

That's the most important thing to understand about the retirement: AWS never ran your waiting room for you, so AWS stepping back doesn't switch anything off.

What actually changes after retirement

Your existing stack keeps running. AWS Solutions deploy into your own account, so retiring the solution doesn't remove anything you've already deployed.

What disappears is everything AWS provided around the code.

There are no further releases, no fixes and no support. The Solutions Library page now shows a discontinuation notice instead of the deployment guide.

The bigger issue is what happens over time.

A waiting room built on AWS services depends on runtimes, APIs and other components that AWS continues to change. AWS periodically deprecates older Lambda runtimes, for example. A stack that nobody updates will eventually depend on components that are outdated or no longer supported.

Security patches to the solution's own code are now your team's responsibility too.

And waiting rooms have an awkward characteristic: they often sit unused until the exact moment you desperately need them.

A stack that hasn't been tested for months is most likely to reveal a problem during the traffic spike it exists to handle.

Your three main options

1. Keep running it and maintain it yourself

This can be perfectly reasonable if your team is comfortable owning the code, has the capacity to keep its dependencies current, and can regularly test the waiting room.

It's also the option with the lowest immediate cost.

The trade-off is that the cost moves into engineering time. Your team now owns upgrades, security, compatibility and testing, and that maintenance burden is likely to increase the longer the original code goes without AWS updates.

For organisations that only use the waiting room occasionally and already have the AWS expertise in-house, that may still be worthwhile.

2. Build your own using CloudFront Functions

AWS now points customers towards AWS Marketplace alternatives or building a waiting room pattern themselves using CloudFront Functions.

Building your own gives you maximum control and keeps the entire solution inside AWS.

But it also turns the waiting room into your own software product.

You'll need to design and maintain queue logic, fairness rules, visitor admission, the waiting page, monitoring and failure handling. You'll then own all of it afterwards.

For many organisations, that's a much bigger commitment than deploying AWS's original reference architecture.

3. Move to a managed waiting room

A managed provider runs the waiting room as a service. Updates, patching, infrastructure and support remain the vendor's responsibility rather than yours.

The main choice is between a standalone waiting room and one bundled into a larger platform you may already use.

If you're staying on AWS, integration with CloudFront is one of the most important things to check. Three standalone providers document CloudFront integration:

Cloudflare Waiting Room is another option, but it's bundled into Cloudflare and requires your site to run on Cloudflare's CDN.

If you're currently serving your site through CloudFront, moving to Cloudflare means changing CDN as well as replacing the waiting room. That's a significantly larger project.

Our comparison of virtual waiting room providers covers pricing, queue limits and integration options for each.

How to decide which route makes sense

There isn't one right answer for every AWS deployment. These are the questions that matter most.

How often do you run high-traffic events?

If you only need a waiting room for occasional, predictable events, maintaining the existing AWS stack may be perfectly defensible.

If traffic spikes are frequent or unpredictable, a managed service becomes easier to justify because somebody else is responsible for keeping it ready.

Who would actually own the code?

This is probably the most important question.

If nobody on your team would pick up an alert about the waiting room at 2am, maintaining it yourself isn't really an option.

How large are your traffic peaks?

Some managed waiting-room providers limit the number of visitors who can wait in the queue on each plan.

Compare those limits with your largest expected traffic event, not your average daily traffic.

Do you need to remain entirely within AWS?

If that's a hard requirement, either maintaining your existing deployment, building your own solution or using a provider that integrates with CloudFront will keep the rest of your infrastructure on AWS.

When is your next major traffic event?

This should influence how quickly you make the decision.

Whatever route you choose, don't let the next major launch, ticket sale or registration event become the first real test. Load-test the waiting room before you need it.

So, should you replace Virtual Waiting Room on AWS?

Not necessarily immediately.

If your existing deployment is stable, regularly tested and owned by a team capable of maintaining it, AWS's retirement doesn't create an urgent need to migrate.

But the risk increases over time. The code is no longer being maintained by AWS, while the AWS services underneath it will continue to evolve.

That means the real decision isn't whether your waiting room still works today. It's whether you want your team to be responsible for making sure it still works when your next traffic spike arrives.

For some organisations, continuing to maintain the AWS deployment will make sense. For others, moving that responsibility to a managed waiting-room provider will be the simpler long-term option.