DeepRacer on AWS

A user accesses the DeepRacer on AWS user interface through an Amazon CloudFront distribution, which delivers the static web assets from the UI assets bucket.

The user interface assets are hosted in an Amazon S3 bucket that stores the static web assets comprising the user interface.

An Amazon Cognito user pool manages users and user group membership.

An Amazon Cognito identity pool manages federation and authorization.

AWS Identity and Access Management user group roles define permissions and levels of access for each type of user in the system, used for access control and authorization.

AWS Lambda Cognito trigger functions run at points in the user lifecycle, such as sign-up, confirmation, and outgoing email.

The pre-signup trigger applies new-user limits and creates the profile, and the post-confirmation trigger assigns the default racer group.

AWS WAF provides intelligent protection for the API against common attack vectors and allows customers to define custom rules based on individual use cases and usage patterns.

Amazon API Gateway routes API requests to their appropriate handler using a defined Smithy model.

An Amazon DynamoDB table serves as a single table for storing and managing profiles, training jobs, models, evaluation jobs, submissions, leaderboards, events, tracks, runs, laps, rankings, fleets, devices, and deployments.

AWS Lambda API functions back the API, with one function per operation.

One function backs each API operation, covering profiles, models, races, events, devices, model import and export, and global settings.

AWS AppConfig hosted configuration stores application-level settings, such as usage quotas.

A user data bucket (Amazon S3) stores all user data including trained models, evaluation results, and other assets generated during the DeepRacer workflow.

An asset packaging AWS Lambda function packages a model's assets from the user data bucket into the virtual model bucket for export. Packaging jobs that fail go to an Amazon Simple Queue Service dead-letter queue.

A virtual model bucket (Amazon S3) stores exported models. The user's browser downloads an exported model directly from this bucket using the pre-signed URL the API returns.

An Amazon Simple Queue Service FIFO queue receives requests for training and evaluation jobs and stores them in FIFO order. A job that repeatedly fails to dispatch moves to a dead-letter queue rather than blocking the jobs behind it.

An AWS Step Functions training workflow runs each training or evaluation job from start to finish. If no training capacity is available it cleans up and leaves the job waiting for capacity. Otherwise it polls the job every minute while it runs, and finalizes the job whether it succeeds or fails.

AWS Lambda workflow functions perform the steps of each job.

They dispatch each job, set it up, start and monitor the SageMaker job, and record the result.

Amazon SageMaker AI performs the actual training and evaluation of the model using the reward function and hyperparameters provided. Each job runs the DeepRacer training container image from Amazon ECR.

Amazon Kinesis Video Streams carries the simulation video from the SageMaker job to the user's browser.

An Amazon DynamoDB Stream captures item-level changes from the main table and delivers them to the race functions, enabling event-driven orchestration of live race evaluations and real-time broadcast of race state to spectators.

AWS Lambda race functions respond to live and physical race activity.

They start each race evaluation, broadcast race state, recover stalled executions, and rebuild race statistics.

An AWS Step Functions live race workflow runs the queued submissions for a live race one at a time. The stream handler or a facilitator launching the race starts it. For each submission it runs the evaluation on SageMaker through the workflow functions, using four functions of its own:

Amazon EventBridge routes race events.

AWS IoT Core provides a managed WebSocket pub/sub channel for delivering live race state updates to spectator and participant browsers. Each live race uses a dedicated MQTT topic scoped by leaderboard ID, physical race events use a per-event topic tree, and device status and command results go to the device management screens. Browsers subscribe via WebSocket, and the broadcast handler publishes via IAM-authorized HTTPS, so no connections table or custom connect and disconnect handlers are needed. Facilitator and administrator browsers also publish directly to IoT Core, sending race countdown, pause, and resume state and race topic updates without passing through Lambda, which keeps timing jitter low.

An Amazon Simple Queue Service event delete queue receives a cascade-delete request when an event is deleted, so dependent records are removed asynchronously rather than inside the API request. Requests that keep failing go to a dead-letter queue for manual re-drive.

An event delete worker AWS Lambda function consumes the delete queue and removes the laps, runs, rankings, submissions, and tracks belonging to a deleted event, then the event record itself. It takes one message per invocation and is capped at two concurrent executions, so at most two events are torn down at a time.

AWS Systems Manager provides the hybrid activation that enrolls physical cars and timers as managed instances, and RunCommand for running commands on them. Each device is addressed by the managed instance id that hybrid activation assigned to it.

Physical devices (cars and timers) enroll themselves as managed instances using a hybrid activation code, and receive model deployments and control commands through Systems Manager. When a model is deployed, the car downloads it directly from the user data bucket using a pre-signed URL included in the command.

Amazon EventBridge device rules keep device status current.

AWS Lambda device functions track the state of each device.

They track device registration, poll device status, and deregister devices whose records have expired.

Amazon GuardDuty malware protection scans physical models uploaded to the upload bucket and tags each object with the result. The model optimizer polls for that tag for up to a minute and proceeds only when the scan found no threats. A detected threat, an unscannable file, and a scan that failed or never reported all stop the import with a message instead. Malware scanning is on by default, and setting the ENABLE_GUARDDUTY_MALWARE_SCAN=false CDK context value at synthesis time leaves it out, after which the optimizer no longer waits for a tag.

AWS Lambda model transfer functions prepare a model for a physical car and deliver it.

The optimizer converts a model into the format a physical car requires, and the push functions send the transfer command and track its status.

An AWS Step Functions push workflow orchestrates transferring a model to a physical car. It marks the deployment in progress, sends the download and installation command to the car through Systems Manager RunCommand along with a pre-signed URL for the model in the user data bucket, polls until the command finishes, and records the deployment as completed or failed.

An upload bucket (Amazon S3) stores uploaded (but not yet imported) assets from the user.

An Amazon Simple Queue Service import queue receives import jobs from the API functions and holds them until they are accepted by the import dispatcher. Jobs that fail twice move to a dead-letter queue, where a handler marks the import as failed.

An AWS Step Functions import workflow validates an imported virtual model and brings it into the system. It validates the reward function, validates the model, imports the model assets, and records the import as complete, stopping at the first validation that fails.

AWS Lambda import functions perform the steps of each import.

They dispatch each import, validate the reward function and the model, copy the assets, and record the outcome.