We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.
If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”
Customize cookie preferences
We use cookies and similar tools (collectively, "cookies") for the following purposes.
Essential
Essential cookies are necessary to provide our site and services and cannot be deactivated. They are usually set in response to your actions on the site, such as setting your privacy preferences, signing in, or filling in forms.
Performance
Performance cookies provide anonymous statistics about how customers navigate our site so we can improve site experience and performance. Approved third parties may perform analytics on our behalf, but they cannot use the data for their own purposes.
Allowed
Functional
Functional cookies help us provide useful site features, remember your preferences, and display relevant content. Approved third parties may set these cookies to provide certain site features. If you do not allow these cookies, then some or all of these services may not function properly.
Allowed
Advertising
Advertising cookies may be set through our site by us or our advertising partners and help us deliver relevant marketing content. If you do not allow these cookies, you will experience less relevant advertising.
Allowed
Blocking some types of cookies may impact your experience of our sites. You may review and change your choices at any time by selecting Cookie preferences in the footer of this site. We and selected third-parties use cookies or similar technologies as specified in the AWS Cookie Notice.
Your privacy choices
We display ads relevant to your interests on AWS sites and on other properties, including cross-context behavioral advertising. Cross-context behavioral advertising uses data from one site or app to advertise to you on a different company’s site or app.
To not allow AWS cross-context behavioral advertising based on cookies or similar technologies, select “Don't allow” and “Save privacy choices” below, or visit an AWS site with a legally-recognized decline signal enabled, such as the Global Privacy Control. If you delete your cookies or visit this site from a different browser or device, you will need to make your selection again. For more information about cookies and how we use them, please read our AWS Cookie Notice.
I contenuti di questa pagina non sono al momento disponibili nella lingua selezionata. Il nostro impegno è tuttavia di fornire più contenuti localizzati possibili. Grazie per la pazienza.
The Virtual Waiting Room on AWS solution helps buffer incoming user requests to your website during large bursts of traffic. It creates a cloud infrastructure designed to temporarily offload incoming traffic to your website, and it provides options to customize and integrate a virtual waiting room. The waiting room acts as a holding area for visitors to your website and allows traffic to pass through when there is enough capacity.
Examples of large-scale events that could produce a surge in website traffic include:
Start of sale for concert or sporting event tickets
Fire sale or other large retail sale, such as Black Friday
New product launch with broad marketing announcements
Exam access and class attendance for online testing and lessons
Release of medical appointment slots
Launch of a new direct-to-customer service that requires account creation and payments
Benefits
Structured queue
Users are assigned a queue number when they enter the waiting room. They maintain their position in the queue and only leave the waiting room to enter the target site when it’s their turn.
Scalability
The solution can control traffic for large-scale events. Traffic spikes won’t overwhelm your systems, keeping your website up and running for your customers.
Protect downstream systems
The solution generates signed, time-limited JSON web tokens (JWTs), which allow the downstream system's APIs to validate users have successfully gone through the waiting room before processing any requests.
Standalone integration or use with OpenID
The solution’s OpenID adapter provides a set of OpenID Connect (OIDC)-compatible APIs that can be used with existing web hosting software that support OIDC identity providers.
Sample waiting room
The solution provides a sample waiting room website to demonstrate a minimal end-to-end waiting room solution for customization.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.
Step 8 Amazon DynamoDB tables to store token, queue position, and serving counter data.
Step 9 AWS Secrets Manager to store keys for token operations and other sensitive data.
Step 10 (Optional) Authorizer component consisting of an AWS Identity and Access Management (IAM) role and a Lambda function to validate signatures for your API calls. The only requirement for the authorizer to protect your API is to use API Gateway.
Step 12 (Optional) OpenID adaptor component with API Gateway and Lambda functions to allow an OpenID provider to authenticate users to your website. CloudFront distribution with an Amazon Simple Storage Service (Amazon S3) bucket for the waiting room page for this component.
Step 13 (Optional) A CloudFront distribution with S3 origin bucket for the optional sample waiting room web application.
Step 2 Amazon API Gateway public API resources to process queue requests from the virtual waiting room, track the queue position, and support validation of tokens that allow access to the target website.
Step 3 An Amazon Simple Queue Service (Amazon SQS) queue to regulate traffic to the AWS Lambda function that processes the queue messages. Instead of invoking the Lambda function for each request, the AmazonSQS queue batches the incoming bursts of requests.
Step 4 API Gateway private API resources to support administrative functions.
Step 5 Lambda functions to validate and process public and private API requests, and return the appropriate responses.
Step 6 Amazon Virtual Private Cloud (Amazon VPC) to host the Lambda functions that interact directly with the Amazon ElastiCache for Redis cluster. VPC endpoints allow Lambda functions in the VPC to communicate with services within the solution.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.
Step 8 Amazon DynamoDB tables to store token, queue position, and serving counter data.
Step 9 AWS Secrets Manager to store keys for token operations and other sensitive data.
Step 10 (Optional) Authorizer component consisting of an AWS Identity and Access Management (IAM) role and a Lambda function to validate signatures for your API calls. The only requirement for the authorizer to protect your API is to use API Gateway.
Step 12 (Optional) OpenID adaptor component with API Gateway and Lambda functions to allow an OpenID provider to authenticate users to your website. CloudFront distribution with an Amazon Simple Storage Service (Amazon S3) bucket for the waiting room page for this component.
Step 13 (Optional) A CloudFront distribution with S3 origin bucket for the optional sample waiting room web application.
Step 2 Amazon API Gateway public API resources to process queue requests from the virtual waiting room, track the queue position, and support validation of tokens that allow access to the target website.
Step 3 An Amazon Simple Queue Service (Amazon SQS) queue to regulate traffic to the AWS Lambda function that processes the queue messages. Instead of invoking the Lambda function for each request, the AmazonSQS queue batches the incoming bursts of requests.
Step 4 API Gateway private API resources to support administrative functions.
Step 5 Lambda functions to validate and process public and private API requests, and return the appropriate responses.
Step 6 Amazon Virtual Private Cloud (Amazon VPC) to host the Lambda functions that interact directly with the Amazon ElastiCache for Redis cluster. VPC endpoints allow Lambda functions in the VPC to communicate with services within the solution.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.
Step 8 Amazon DynamoDB tables to store token, queue position, and serving counter data.
Step 9 AWS Secrets Manager to store keys for token operations and other sensitive data.
Step 10 (Optional) Authorizer component consisting of an AWS Identity and Access Management (IAM) role and a Lambda function to validate signatures for your API calls. The only requirement for the authorizer to protect your API is to use API Gateway.
Step 12 (Optional) OpenID adaptor component with API Gateway and Lambda functions to allow an OpenID provider to authenticate users to your website. CloudFront distribution with an Amazon Simple Storage Service (Amazon S3) bucket for the waiting room page for this component.
Step 13 (Optional) A CloudFront distribution with S3 origin bucket for the optional sample waiting room web application.
Step 2 Amazon API Gateway public API resources to process queue requests from the virtual waiting room, track the queue position, and support validation of tokens that allow access to the target website.
Step 3 An Amazon Simple Queue Service (Amazon SQS) queue to regulate traffic to the AWS Lambda function that processes the queue messages. Instead of invoking the Lambda function for each request, the AmazonSQS queue batches the incoming bursts of requests.
Step 4 API Gateway private API resources to support administrative functions.
Step 5 Lambda functions to validate and process public and private API requests, and return the appropriate responses.
Step 6 Amazon Virtual Private Cloud (Amazon VPC) to host the Lambda functions that interact directly with the Amazon ElastiCache for Redis cluster. VPC endpoints allow Lambda functions in the VPC to communicate with services within the solution.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.
Step 8 Amazon DynamoDB tables to store token, queue position, and serving counter data.
Step 9 AWS Secrets Manager to store keys for token operations and other sensitive data.
Step 10 (Optional) Authorizer component consisting of an AWS Identity and Access Management (IAM) role and a Lambda function to validate signatures for your API calls. The only requirement for the authorizer to protect your API is to use API Gateway.
Step 12 (Optional) OpenID adaptor component with API Gateway and Lambda functions to allow an OpenID provider to authenticate users to your website. CloudFront distribution with an Amazon Simple Storage Service (Amazon S3) bucket for the waiting room page for this component.
Step 13 (Optional) A CloudFront distribution with S3 origin bucket for the optional sample waiting room web application.
Step 2 Amazon API Gateway public API resources to process queue requests from the virtual waiting room, track the queue position, and support validation of tokens that allow access to the target website.
Step 3 An Amazon Simple Queue Service (Amazon SQS) queue to regulate traffic to the AWS Lambda function that processes the queue messages. Instead of invoking the Lambda function for each request, the AmazonSQS queue batches the incoming bursts of requests.
Step 4 API Gateway private API resources to support administrative functions.
Step 5 Lambda functions to validate and process public and private API requests, and return the appropriate responses.
Step 6 Amazon Virtual Private Cloud (Amazon VPC) to host the Lambda functions that interact directly with the Amazon ElastiCache for Redis cluster. VPC endpoints allow Lambda functions in the VPC to communicate with services within the solution.
Step 7 An Amazon CloudWatch rule to invoke a Lambda function that works with a custom Amazon EventBridge bus to periodically broadcast status updates.