This Guidance for queue depth management shows how you can improve customer experience by monitoring queues using cameras, use computer vision to measure queue depth, and provide alerts about bottlenecks and unreasonable queue depths to customer service managers. Travel & Hospitality organizations can apply this solution to improve employee productivity, streamline lobby management, gain customer insights, reduce walkaways and negative perceptions of wait times.

Architecture Diagram

Download the architecture diagram PDF 

Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

  • This Guidance has been written using the AWS Cloud Development Kit (AWS CDK) for infrastructure as code wherever possible. It can be easily redeployed into new environments with minimal setup. It has also been created with examples of how to route data for analysis purposes, in addition to having IoT rules established for the publishing of metrics and notifications.

    Read the Operational Excellence whitepaper 
  • By default, all AWS IoT data in transit and at rest is encrypted. Data in transit is encrypted using TLS, and data at rest is encrypted using AWS owned keys. In addition, the frontend uses authentication through Amazon Cognito, which helps you control which users are able to access the system.

    Read the Security whitepaper 
  • All communications within the system are handled through AWS IoT Core MQTT messaging protocol, which allows for “At Least Once” delivery of messages. The edge device (simulated by an Amazon Elastic Compute Cloud (Amazon EC2) instance) is managed through the AWS Lambda runtime. Updates to those components are continuously version controlled and managed through deployments within AWS IoT Greengrass.

    Read the Reliability whitepaper 
  • The computer vision model is developed to capitalize the resources available on the host system. Where GPU processing is available, it will use that to speed up processing. Images are automatically downscaled to decrease processing time. 

    Read the Performance Efficiency whitepaper 
  • To ensure that costs are kept low, the Guidance only uses a single EC2 instance to simulate an edge device and illustrate the function of the computer vision model. In addition, only the minimal usage of other AWS services is present within the system. These include a single Amazon S3 bucket for uploading pictures, a single DynamoDB table for storing queue vertices, and a minimal set of examples of using IoT rules to route data to CloudWatch. To further reduce costs, users can remove all of the IoT rules that route incoming data and run the model on their edge device.

    Read the Cost Optimization whitepaper 
  • This Guidance focuses on reducing environmental impact by only ever using the minimal set of resources required to make the system operate. There is very little resource usage throughout the system because it does not need to operate frequently or interact with many other services. For most of the time, the system will be inert until it is manually initiated by the user.

    Read the Sustainability whitepaper 

Implementation Resources

A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.

The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.

[Content Type]


This [blog post/e-book/Guidance/sample code] demonstrates how [insert short description].


The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.

References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.

Was this page helpful?