This Guidance demonstrates how to deploy and configure DeepRacer Event Manager (DREM), a set of tools that simplify the hosting of AWS DeepRacer events. DREM automates multiple event operations including user registration, model loading, leaderboard updates, timing, and car management. It allows events to be produced faster and with less effort, less staff, and less technological resources to get race cars on the track, faster! 

AWS DeepRacer is an autonomous race car, 1/18th the size of a vehicle, driven by machine learning and designed to test reinforcement learning (RL) models when racing the cars on a physical track. Using cameras to view the track and an RL model to control throttle and steering, the car shows how a model trained in a simulated environment can be transferred to the real-world.

Please note: [Disclaimer]

Architecture Diagram

Download the architecture diagram PDF 


This architecture diagram provides an overview of how to automate the multiple operations that are entailed for AWS DeepRacer events. These events include website hosting, access management, race management, model management, fleet management, and car management. For architecture diagrams highlighting these events, open the dropdown options below.

  • DREM consists of a number of web-based applications, hosted using Amazon S3 and Amazon CloudFront, which are accessed by event staff, racers, and spectators.

    • Access Management
    • User accounts are created and stored in Amazon Cognito. Access to model management and event functionality requires an account. Leaderboards and streaming overlays are publicly accessible.

    • User Registration
    • DREM has two racer registration flows: Racers sign up independently or event staff members facilitate racer sign-up. 

    • Privileged Access
    • For an event staff member to gain privileged access to DREM, their users need to belong to certain Amazon Cognito groups. DREM comes with a default admin user which is created during deployment. This admin user can then be used to grant privileged access to other members of the event staff.

    • Leaderboard
    • Leaderboards allow racers to see how they rank against other competitors and are accessible to anyone with the link for the event.

    • Event Manager
    • Events (races) are stored in Amazon DynamoDB and are managed by DREM users with operator or admin group membership.

    • Race Manager
    • Lap times are recorded for events using the race manager. Times can be recorded either manually or automatically by using a Raspberry Pi and timing strips for improved timing accuracy.

  • Getting models from the racers to the car is the main function of DREM. Users upload their models into an Amazon S3 bucket for storage. Event staff members can see all of the uploaded models and select specific models to send to particular cars in order to facilitate an efficient racing queue.

  • The fleet feature allows event organizers to designate a collection of cars in the DREM application. One use case is tracking cars associated with specific event hardware kits.

  • Event staff members use the car manager feature to add cars to DREM via car activation. It’s also used to remotely restart the AWS DeepRacer service on a car.

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.

  • Amazon CloudWatch RUM and AWS X-Ray help you run and monitor your systems effectively, so you can gain key insights into events. For example, CloudWatch RUM helps you collect and view web application performance in near real-time. This includes page load times, errors, and user behavior. Also, it can help you to understand how the application is used, patterns of usage, and to determine when a response or change is required. Additionally, the debug information from X-Ray helps to determine when a response is required and to assist you in identifying the factors contributing to a platform issue.

    Read the Operational Excellence whitepaper 
  • CloudFront, AWS Shield Standard, Cognito, and AWS Identity and Access Management (IAM) work in tandem to protect data, systems, and assets in a way that improves your security posture. CloudFront improves website security with traffic encryption and access controls and integrates with Shield Standard, which defends against distributed denial-of-service (DDoS) attacks at no additional charge. Also, by scoping IAM policies to the minimum permissions required, you limit unauthorized access to resources. Moreover, Cognito provides authentication and authorization for the web application, including securing the AWS AppSync APIs. Cognito also has a central location for identity verification, making it easier to manage access while reducing the requirements for multiple credentials.

    Read the Security whitepaper 
  • All services configured in this Guidance are monitored by Amazon CloudWatch, which collects metrics and helps you to visualize those metrics through dashboards so that you can understand the health and status of the application. CloudWatch also helps you to more easily analyze and debug distributed systems so you know how your applications and its underlying services are performing.

    Additionally, you can provision highly scalable and reliable workloads through small components within a microservices' architecture using an AWS Cloud Development Kit (AWS CDK), which can help you to build microservices through domains (essentially building constructs).

    Read the Reliability whitepaper 
  • Lambda, DynamoDB, and AWS AppSync collectively work to enhance the performance efficiency of your workloads. For example, Lambda provides a scalable, serverless solution to enhance the performance of the application, it can scale up and down when needed, and only consumes the necessary resources. While with DynamoDB, you get a mechanism for storing data at scale, with millisecond latency. Finally, AWS AppSync provides multiple options for data retrieval that are evaluated to ensure the most optimum way is returned for the user and the application.

    Read the Performance Efficiency whitepaper 
  • Lambda, Amazon S3, AWS Budgets, and AWS CDK all help you to avoid unnecessary costs and maximize your return on investment. For example, Lambda functions are only billed when called, and therefore you are only paying for the minimum required compute to run the application. Also, there are multiple lifecycle policies applied to the storage within Amazon S3 that remove files based on the age of the files. Furthermore, AWS Budgets are set to ensure that costs do not go beyond what is expected, and also helps to govern usage. Finally, by utilizing infrastructure as code through AWS CDK, resources can be automatically provisioned and terminated.

    Read the Cost Optimization whitepaper 
  • Lambda, Amazon S3, and AWS CDK help to minimize the environmental impacts of running cloud workloads. Specifically, Lambda supports user sustainability by only scaling with user load. And by utilizing Amazon S3, the application can minimize the use of data processing and storage requirements, as the central repository of storage can be consumed by all services. Furthermore, AWS CDK allows for rapid application testing and deployment through infrastructure as code.

    Read the Sustainability whitepaper 

Implementation Resources

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?