How Much of a Restaurant Serving Robot Can AWS Rebuild?
A breakdown of a restaurant serving robot's stack against AWS services, and why AWS no longer has a dedicated robotics fleet or sim service.
Serving robots that carry plates across a restaurant floor are common now. Their behavior breaks down into a handful of distinct technical pieces: localization and path planning, obstacle avoidance, fleet management and task assignment, and the edge-to-cloud link that handles monitoring and updates.
This article maps those pieces onto AWS services to see how far a rebuild would get, and where it runs into a gap that AWS itself used to fill and no longer does.
The Robot's Stack, Broken Down
- Localization and path planning: the robot places itself on a map of the restaurant and computes a route to a table
- Obstacle avoidance: the robot detects people and furniture and slows down or stops
- Fleet management and task assignment: when several robots are working the floor, something decides which robot takes which delivery
- Edge-to-cloud connectivity: remote monitoring and over-the-air (OTA) software updates
Localization and obstacle avoidance run entirely on the robot's onboard sensors and edge inference. The section below covers why they can't move to the cloud; the rest of the article focuses on the two pieces that do map onto AWS services: fleet management and task assignment, and edge-to-cloud connectivity.
What Maps Cleanly Onto AWS
Edge-to-cloud connectivity: AWS IoT Core and AWS IoT Greengrass
Monitoring and OTA updates map directly onto AWS IoT Core and AWS IoT Greengrass.
- AWS IoT Core registers each robot as a Thing, handles MQTT status messages, and keeps current state in a device shadow
- AWS IoT Greengrass runs on the robot's edge hardware, executing local inference and receiving OTA jobs
Both are current, general-purpose IoT services used well beyond robotics, so there's nothing robot-specific standing in the way of using them here.
Location data: Amazon Location Service
Storing table coordinates and floor-plan positions maps onto Amazon Location Service, using its map and geofencing features.
The robot's own SLAM (simultaneous localization and mapping), which relies on onboard cameras or LiDAR, still runs on the robot. Amazon Location Service only takes over once that estimate needs to be stored and queried as a coordinate in the cloud.
Fleet management and task assignment: no dedicated service, so it's Step Functions, DynamoDB, and Lambda
Deciding which robot takes which delivery has no dedicated managed service on AWS today. Building it means combining general-purpose services instead:
- AWS Step Functions manages a delivery task's state, from request to completion
- Amazon DynamoDB holds each robot's current position, status, and availability
- AWS Lambda runs the assignment logic that matches an available robot to a task
None of this is robotics-specific; it's a standard async processing pattern. The trade-off is that the assignment logic itself has to be designed from scratch, since there's no managed service that already understands "robot fleet."
What Has to Stay on the Robot
Localization and obstacle avoidance stay on the robot because of how fast their control loops have to run, not because AWS lacks a matching service.
Localization: scan matching runs on a tens-of-milliseconds cycle
LiDAR-based localization is largely a matter of scan matching: comparing the robot's current sensor reading against the map it built a moment ago to work out its position and heading. This comparison isn't a one-time calculation. It has to run continuously, on a cycle measured in tens of milliseconds. Any gap between cycles lets the robot's actual position drift away from its estimated one.
Path planning splits into a slow global layer and a fast local one
Path planning has two layers, and they run on different clocks:
- Global path planning (algorithms like A*) computes the overall route across the restaurant's map. The map itself doesn't change often, so this layer can tolerate hundreds of milliseconds to a few seconds of latency.
- Local path planning (algorithms like the Dynamic Window Approach, or DWA) recalculates a short-range route around whatever obstacle just appeared, using the most recent sensor data. A person stepping into the robot's path has to be handled within tens of milliseconds.
Latency in global planning is an inconvenience. Latency in local planning turns directly into a collision risk.
Motor control runs on an even tighter loop
The speed commands sent to a differential-drive robot's two independently driven wheels go through a PID feedback loop, running on a cycle even tighter than local path planning: single digits to a few tens of milliseconds.
The line comes from comparing round-trip time to loop period
None of these three loops can move to the cloud, and the reason comes down to comparing two numbers. A round trip to the cloud, even over in-store Wi-Fi or 4G/5G, can take tens to hundreds of milliseconds. Localization, local path planning, and motor control all run on cycles in that same range or tighter.
Send one of these calculations to the cloud and wait for a response, and the next control cycle arrives before the answer does. The rule that falls out of this: anything where the round trip is longer than the loop period has to run on the robot. Fleet task assignment can tolerate seconds of latency; wheel control cannot. That difference decides whether a workload can move to the cloud at all, independent of whether AWS happens to offer a service for it.
Hardware not included
None of this is something a rebuild can verify without the physical robot. There's no substitute for LiDAR, motors, wheels, or a chassis when the thing being tested is actual movement.
The realistic way to test the software layer alone is a ROS 2 setup paired with Gazebo or Isaac Sim. AWS used to offer a managed version of this kind of simulation environment through AWS RoboMaker, which the next section covers in more detail; running one now means building and maintaining it independently.
AWS No Longer Has a Dedicated Robotics Service
The reason fleet management above has to be assembled from general-purpose services is that AWS used to offer a dedicated one, and it's gone.
- AWS IoT RoboRunner was a managed service for fleet management and task assignment across multiple robots. AWS announced its end of life in 2023 and shut it down in the first half of 2024.
- AWS RoboMaker, a service for robotics software development and simulation, reached end of support on September 10, 2025. AWS pointed customers toward AWS Batch for the simulation workloads it used to handle.
Both services covered exactly the parts of this stack that are hardest to replicate: coordinating a fleet, and simulating robot behavior before deploying it. As of September 2026, neither has a replacement. Combining general-purpose services is the only option left for fleet management, and there's no managed path for simulation at all.
Mapping a serving robot's stack onto AWS splits into three parts. The edge-to-cloud link and location data reproduce well on current services. Fleet management and task assignment have no dedicated service, so they have to be assembled from general-purpose ones. And localization, path planning, and motor control stay on the robot regardless of what AWS offers, because their control loops run faster than a round trip to the cloud ever could.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article