Amazon Web Services has introduced the open-source Physical AI Toolchain — a set of reference architectures, Terraform modules, and deployment automation covering the full cycle of AI development for robots: synthetic data generation, model training, simulation validation, edge hardware deployment, and continuous improvement based on data sent back from robots to the cloud. The project connects AWS managed services with the NVIDIA Physical AI stack and is published on GitHub under the Apache-2.0 license.

image
image
image

What happened

The repository aws-samples/sample-the-physical-ai-toolchain-on-aws on GitHub, under the Apache-2.0 license, contains reference architectures and independent Terraform modules, each accompanied by a working example. The modules connect Amazon S3, SageMaker, AWS Batch, EKS, EC2, ECR, and IoT Greengrass services with NVIDIA Physical AI components: Isaac Sim handles physical simulation, Isaac Lab handles reinforcement learning in thousands of parallel environments, GR00T handles fine-tuning of vision-language-action models, Cosmos handles synthetic data generation, and OSMO handles stage orchestration. Data and models are transferred in open formats such as Zarr, LeRobot, URDF, ONNX, and ROS 2. As a verifiable example, the repository includes fine-tuning a GR00T policy on 27 teleoperation episodes of a UR3 pick-and-place task.

Context

The individual components are not new: Isaac Sim, Isaac Lab, GR00T, Cosmos, and OSMO are already known parts of NVIDIA Physical AI, and AWS cloud services have long been used for model training. What is new is their connection as infrastructure-as-code: after the closure of Amazon RoboMaker in 2025, robotics engineers did not have a comparable cloud pipeline; the path from teleoperation data to a trained policy had to be assembled manually, and teams lost months at the junctions between stages. The sector is large and growing: according to Capgemini Research Institute, 79% of companies are already working with physical AI. Amazon also has its own experience operating over 1 million robots, as well as the AWS Physical AI fellowship with MassRobotics and NVIDIA.

Why this matters for the industry

For companies and independent developers, the entry model into physical AI is changing: a pipeline that was previously assembled from custom scripts on top of disparate services can now be deployed declaratively using individual Terraform modules, which significantly reduces the cost and time to launch for startups. Open dataset and policy formats reduce dependence on a specific vendor at the data level and allow any stage of the pipeline to be replaced with a custom component. Since the modules are not interdependent and the formats are open, this architecture is highly likely to become the de facto reference for the sector, and community forks for scenarios outside AWS and NVIDIA should be expected. If the framework takes hold, the comparability of research results will increase over the next couple of years due to common data formats and a common training and validation pipeline, although there remains a risk of fragmentation between cloud stacks and research dependence on a single vendor.

Why this matters for users

The barrier to entry is reduced to a minimum: to get started, you only need an AWS account with a GPU quota, an NVIDIA NGC key, and a Hugging Face token. Terraform modules are deployed one by one, and each stage is accompanied by instructions and a working example, so the first narrow scenario based on a ready-made example from the repository can be set up in days, even without prior expertise in physical AI. A reasonable strategy for the first product is not the entire pipeline immediately, but a narrow vertical PoC, for example, fine-tuning a policy on your own teleoperation data for a specific task.

What is currently unknown / limitations

The primary sources contain no numerical metrics: neither the success rate of trained policies, nor simulation-to-reality transfer indicators, nor figures on training and inference costs or edge deployment latency. The example with 27 teleoperation episodes is a smoke-test scale: it proves the pipeline's functionality, not generalization or policy quality, and extrapolating the conclusion of "dozens, not thousands of episodes" from a single narrow UR3 pick-and-place scenario is methodologically incorrect, as data volume requirements depend on the task. Claims of vendor neutrality "to the robot manufacturer and type of tasks" and continuous improvement based on cloud data remain marketing statements without numerical confirmation, and the mentioned cases of Telexistence (over 300 humanoids in Japanese stores), Bedrock Robotics, and RLWRLD are cited without methodology or results.

Sources

Author

Look at AI, editorial team