Skip to main content

Guidance for Queue Depth Management on AWS

Overview

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.

How it works

Monitor the passenger and guest queues using cameras, use computer vision to measure queue depth, and provide alerts about bottlenecks and unreasonable queue depths to customer service managers, improving the traveler experience.

Well-Architected Pillars

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

Disclaimer

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.