Skip to content

Pillar 3 — Simulation

Last updated: 2026-09 · owner: Youngjin · volatility: high (versions/instances change often) Unless separately noted, each item inherits the page metadata (owner/updated/volatility). When an item has its own owner, add an item footer. ← back to index

L0 TL;DR: Robot policies are trained thousands of times faster and more safely in simulation than on real hardware. The right stack on AWS is EC2 G6e/G7e (RTX GPU) + NVIDIA Isaac Sim AMI (GUI) + AWS Batch (headless3 large-scale RL1). ⚠️ AWS RoboMaker was discontinued 2025-09-10 — never propose it. The latest Isaac Sim GA is 5.1.0, and 6.0 is still Preview.

Top 3 questions customers ask most in this pillar

  1. "How do I run Isaac Sim/Lab on AWS? On which instances?" → Isaac on AWS
  2. "How do I scale thousands~tens of thousands of parallel RL environments in the cloud?" → Large-scale parallel RL
  3. "Do I have to bet everything on NVIDIA? What about open-source alternatives?" → Open-source alternatives, decisions

Stable principle (rarely changes): the value of simulation is (1) parallelism (thousands~8,000 environments at once on a single GPU)2, (2) safety (exploring risky policies without breaking real hardware), and (3) automatic labeling (perfect ground truth)5 — and the economics of physical robots that converts these into money (one robot's price = tens of thousands of GPU hours) is item 6 below. Rendering requires an RTX (RT Core)4 GPU, so A100/H100 (compute GPUs) cannot be used for Isaac Sim rendering — an invariant constraint that governs instance selection.

1. Isaac Sim & Isaac Lab on AWS 🟢 GA

L0 TL;DR: The canonical path to running NVIDIA Isaac Sim (simulator) + Isaac Lab (RL framework) on AWS EC2 GPUs. A free AMI in the Marketplace makes entry easy.

Customer need/problem: "A local workstation GPU isn't enough. I want to use Isaac Sim in the cloud with a GUI, and run training headless at large scale."

Solution overview [1]:

  • Versions: latest Isaac Sim GA = 5.1.0 (2025-10-30). 6.0 is Preview ("Early Developer Release," GTC'26) — even if the GitHub patch tag is mislabeled "GA," do not call 6.0 GA. Isaac Lab stable is 2.3.x; 3.0 is beta (introduces the Newton physics engine).
  • License: Isaac Sim source is Apache 2.0 (free for commercial). But redistributing/offering-as-SaaS/turnkey-installing the Omniverse Kit runtime to third parties requires an NVIDIA AI Enterprise license. Not needed for internal R&D or selling only the output. Isaac Lab is BSD-3.
  • GPU requirement: RTX (RT Core) required. Minimum RTX 4080 (16GB), ideal RTX PRO 6000 Blackwell (48GB). A100/H100 not supported (no RT Core).

What each stack component actually does [1] (docs verified 2026-07):

Component Technical summary For simulation
Isaac Sim High-fidelity simulator built on RTX ray tracing — USD scenes, camera/LiDAR sensor simulation, Replicator SDG The axis for perception and synthetic data that needs realistic rendering
Isaac Lab The RL/imitation-learning framework on top of Isaac Sim — thousands of parallel environments on one GPU, integrations with skrl, rsl_rl, etc. The standard entry point for locomotion/manipulation policy training
Marketplace AMI A pre-configured Isaac Sim image (free) — boots ready to use, no driver/dependency installs Removes the entry barrier that makes the "30-minute hands-on" possible
NICE DCV AWS's remote display protocol — high-quality, low-latency streaming with no extra license cost on EC2 Operate the cloud GPU's Isaac Sim GUI as if local
AWS Batch MNP Multi-node parallel10 batch jobs — queues and schedules container jobs across nodes Parallelizes large headless RL jobs without a GUI (item 2)
G6e / G7e Render-capable GPU instances with RT Cores The only families satisfying the invariant constraint (no A100/H100)

AWS mapping [1]:

  • Instances: G6e (L40S 48GB) / G7e (RTX PRO 6000 Blackwell 96GB, GA 2026-01). The official Isaac Sim Development Workstation AMI (build 2026.1.1, Ubuntu 24.04, free) supports G6e/G7e, with g6e.4xlarge recommended.
  • Access: remote GUI streaming via NICE DCV (= Amazon DCV) client/web.
  • Reference architecture: the AWS Solutions Guidance "Physical AI for Robotics on AWS" (Isaac Sim on GPU EC2 + Isaac Lab + SageMaker + IoT Greengrass edge). AWS has a dedicated Physical AI blog channel (aws.amazon.com/blogs/physical-ai/).
graph LR
    U[SA / developer] -- NICE DCV remote GUI --> WS["EC2 G6e/G7e<br>Isaac Sim AMI (GUI)"]
    WS -- scene editing · SDG --> D[(USD assets · data)]
    U -- job submission --> B["AWS Batch MNP<br>headless Isaac Lab"]
    D --> B
    B --> P[(trained policy)]

Decision criteria:

  • GUI scene editing · SDG7 → G6e (cost) or G7e (performance, large scenes).
  • Large-scale headless RL → item 2 (AWS Batch).
  • Whether open source suffices → item 3 / decisions.

Customer case: case pending (for Unitree H1 training, see the AWS blog in pillar-2).

➡️ Next action: use "a 30-minute hands-on launching the Marketplace Isaac Sim AMI on g6e.4xlarge and connecting via NICE DCV" as the first proposal, then connect to headless training with pai-sim-isaaclab end-to-end hands-on (Terraform provisions g6e → Isaac Lab quadruped PPO8 headless training → policy export, ~2h/$12). If license questions arise, precisely explain "source is Apache, but redistribution/SaaS requires AI Enterprise."

🔗 Related assets:

🔄 Volatile data (versions — checked 2026-07, some years to be re-confirmed on GitHub)
Component Status Note
Isaac Sim 5.1.0 🟢 GA (2025-10-30) latest GA
Isaac Sim 6.0 🟡 Preview Early Dev Release, PhysX+Newton multi-backend
Isaac Lab 2.3.x 🟢 GA compatible with Isaac Sim 5.1
Isaac Lab 3.0 🟡 beta Newton physics engine
Isaac Sim AMI 🟢 GA build 2026.1.1, G6e/G7e

2. Large-scale parallel RL simulation 🟢 GA

L0 TL;DR: Isaac Lab simulates thousands~8,192 environments at once on a single GPU. On AWS, the official path for headless large-scale RL is AWS Batch (Multi-Node Parallel).

Customer need/problem: "Training a single policy takes days. I want to mass-parallelize environments and scale across multiple nodes."

Solution overview [1]/[3]:

  • Isaac Lab simulates thousands~8,000 environments at once on a single GPU and scales near-linearly across multiple nodes (concrete numbers in the collapsed block below — always cite with measurement conditions).
  • The anchor evidence for convergence time [1]: ETH Zurich trained ANYmal locomotion policies on a single workstation GPU with 4,096 parallel environments (PPO) in under 4 minutes on flat terrain and about 20 minutes on rough terrain (Rudin et al., CoRL 2021, arXiv:2109.11978) — the origin point that publicly proved massively parallel RL converges within practical time, and the research lineage behind ANYmal's deployed locomotion. Cite it as the basis for "make a robot walk in minutes" demos.
  • AWS Batch Multi-Node Parallel Jobs is the AWS-recommended orchestrator (also the RoboMaker migration path). The AWS HPC/Physical AI blog has an Isaac Lab on G6e + Batch MNP + EFS + ECR reference.
graph TD
    S[policy training] --> Q{observation type · scale?}
    Q -- state observation · mostly locomotion --> ONE["single EC2 GPU<br>thousands~8,192 environments at once"]
    Q -- pixel observation · ultra-large --> MNP[AWS Batch Multi-Node Parallel]
    MNP --- EFS[(EFS shared storage)]
    MNP --- ECR[(ECR containers)]
🔄 Volatile data (benchmarks — NVIDIA official performance benches, "with training" basis, checked 2026-07)
Task Envs GPU Throughput
Cartpole-Direct 4,096 1×RTX 4090 510,000 FPS
Humanoid (Velocity-Rough-G1) 4,096 1×RTX 4090 82,000 FPS
Cartpole-Direct 4,096 16×L40 (4 nodes) 3,500,000 FPS
Precise manipulation (Repose-Cube-Shadow) 8,192 1×RTX 4090 170,000 FPS

Source: isaac-sim.github.io/IsaacLab performance benchmarks [1]

AWS mapping [1]: AWS Batch (MNP) + EFS (shared storage) + ECR (containers) + G6e/G5. On the NVIDIA side, OSMO handles multi-node orchestration. ⚠️ There is no official Isaac reference architecture for EKS · ParallelCluster — Batch is the documented path.

Decision criteria:

  • Single GPU with thousands of environments is enough (most locomotion) → single EC2 instance.
  • Multi-node needed (ultra-large, pixel observations) → AWS Batch MNP.
  • Want to integrate the training loop with SageMaker → the Isaac Lab on SageMaker blog in pillar-2.

Customer case: Unitree H1 RL (Isaac Lab on SageMaker) — see pillar-2.

➡️ Next action: draw the "scale Isaac Lab parallel RL with AWS Batch MNP" architecture, and judge scaling by whether the customer's task is pixel-observation (→ multi-node needed) or state-observation (→ single GPU is enough). When citing benchmarks, always include measurement conditions (env count · GPU).

🔗 Related assets: pillar-2 HyperPod · decisions: securing GPUs

3. Open-source simulator alternatives 🟢 GA / ⚪ partly Hype

L0 TL;DR: If you dislike the NVIDIA full stack, or for certain workloads open source is better. MuJoCo (+MJX) is the most reliable alternative (Unitree actually uses it), Gazebo is the ROS-native standard, and Genesis is under-validated relative to its hype (the famous "430,000×" claim was refuted).

Customer need/problem: "NVIDIA lock-in is a burden" / "ROS integration comes first" / "I need differentiable physics."

Solution overview [1]:

  • MuJoCo / MJX — the C engine is GA (v3.10), MJX-JAX is a mature RL workhorse (differentiable, cross-vendor), and MuJoCo Warp is Alpha (not production). Unitree maintains its own MuJoCo repo for Go2/G1/H1 RL = real vendor adoption. MuJoCo Playground is RSS 2025 validated, sim-to-real on 6 platforms.
  • Gazebo — latest LTS Jetty (2025-09), Harmonic is the most widely deployed. ROS 2 native. ⚠️ Gazebo Classic 11 is EOL as of 2025-01 — no Classic for new projects. CPU-based, so unsuited for GPU parallel RL (an Isaac complement).
  • Genesis — Apache 2.0, active, but the "43M FPS / 430,000×" claim is refuted on realistic workloads (actually 3~10× slower than ManiSkill on contact-rich manipulation). Not validated as an Isaac replacement → ⚪ hype caution.

AWS mapping: all runnable on EC2. MuJoCo/MJX (JAX) can also use A100/H100 (P4/P5) (no RTX rendering needed) — unlike Isaac, being able to use compute GPUs is an advantage. Large scale via AWS Batch.

Decision criteria (details → decisions):

  • Photoreal rendering · SDG · full stack → Isaac Sim.
  • Differentiable · lightweight · cross-vendor GPU · fast RL iteration → MuJoCo/MJX.
  • ROS 2 integration · CPU · traditional robotics → Gazebo.
  • Genesis → PoC/experiment only, no production dependence.
graph TD
    Q{What is the priority?} -- photoreal rendering · SDG · full stack --> I["Isaac Sim 🟢<br>(needs G6e/G7e)"]
    Q -- differentiable · cross-vendor GPU · fast RL iteration --> M["MuJoCo / MJX 🟢<br>(P4/P5 also work)"]
    Q -- ROS 2 integration · CPU · traditional robotics --> G[Gazebo 🟢]
    Q -- latest hype validation --> X["Genesis ⚪<br>PoC only · no production"]

Customer case: Unitree (MuJoCo, training on production HW).

➡️ Next action: for customers worried about "NVIDIA lock-in," present the neutral position "AWS runs Isaac, MuJoCo, and Gazebo all well — just choose by workload." With MuJoCo, emphasize the cost benefit of being able to reuse compute GPUs (P5).

🔗 Related assets: decisions: NVIDIA vs open source

4. NVIDIA Cosmos 3 (world foundation model) 🟢 GA · ⚠️ not hosted on AWS

L0 TL;DR: A foundation model that generates, reasons about, and simulates the physical world. Commercially usable (OpenMDW-1.1). ⚠️ But AWS did not make the list as an official Cosmos 3 cloud host (Azure/CoreWeave/Baseten and others host it) — a competitive reality an SA should know.

Customer need/problem: "We want to generate diverse real-world scenarios for training/evaluation." (For the data-generation angle, see pillar-1.)

Solution overview [1]: Cosmos 3 (GA at GTC Taipei 2026-05-31) is the current flagship — Reasoner (VLM) + Generator (diffusion), MoT architecture. Super 64B (data center), Nano 16B (RTX PRO 6000, real-time robotics, includes Nano-Policy-DROID), Edge (Jetson, planned — parameters undisclosed). License OpenMDW-1.1 (commercial OK). Distributed on HF/GitHub/NGC. ⚠️ The old Predict/Transfer/Reason lineup is in maintenance mode (advised to migrate to Cosmos 3).

  • Drawing the line — the physics sim is the "body," the WFM is the "eyes" [1]: a WFM is not a replacement for a physics simulator but a generative data-amplification layer. Where a physics sim like Isaac numerically computes rigid bodies, contact, and friction to drive the robot's "body," a WFM converts the sim's gray scenes into photoreal ones or diversifies lighting/textures/viewpoints to multiply data (Cosmos-Transfer1, arXiv:2503.14492). The one-line answer to the customer question "does Cosmos replace Isaac?"

AWS mapping: weak direct mapping — Cosmos 3 does not have AWS as a named host. But because the weights are open (HF/GitHub), it can be self-hosted on EC2 G7e (Nano 16B, RTX PRO 6000). That's AWS's angle: "not a managed host, but you can run it directly on the optimal GPU."

Decision criteria: need managed Cosmos NIM → another cloud. Open-weight self-hosting · data sovereignty · integration with an existing AWS stack → EC2 G7e.

Customer case (⚠️ announced only, not production-validated): many Korean companies announced as Cosmos 3 adopters, including Doosan Robotics, LG Electronics, Samsung Electronics — high Korean relevance, but "announced adoption," not validated production.

➡️ Next action: when a Korean customer is interested in Cosmos 3 → respond with a "self-host Cosmos 3 Nano on AWS G7e" PoC (turning the absence of managed hosting into a self-hosting + data-sovereignty strength).

🔗 Related assets: pillar-1 Cosmos data generation · pillar-4 sim-to-real

5. Digital twin — IoT TwinMaker & Omniverse on AWS 🟢 GA (low velocity)

L0 TL;DR: AWS IoT TwinMaker was not discontinued (the third-party "discontinued" claim is misinformation, confused with SiteWise maintenance). It is GA and open to new customers, but new features are slow (low velocity). Omniverse is also GA via an AWS Marketplace AMI.

Customer need/problem: "We want to build a digital twin9 of our equipment/factory and connect it to robot simulation and monitoring."

Solution overview [1]:

  • AWS IoT TwinMaker — GA, official product page active, no discontinuation banner (confirmed 2026-07-11). ⚠️ The "discontinued" claim from innfactory.de/oneuptime.com etc. is an unverified rumor; do not repeat. But with no major new features in 2025~26, it is low velocity.
  • NVIDIA Omniverse on AWS — Marketplace AMI (Developer/Production, Linux/Windows). Runs on EC2 G6e/G7e. The Production AMI is a paid subscription bundling an AI Enterprise license + support. ⚠️ There is no dedicated "OVX" instance family — Omniverse on AWS = G6e/G7e + AMI. There is no clear basis for a managed "Omniverse Enterprise on AWS."
  • The reality→sim pipeline in 3 steps [2]: ① Reality Capture — as-is scan of the actual line/cell (NavVis etc.) → ② OpenUSD conversion — layer composition combining a static background layer with separate robot/sensor layers → ③ validate in sim, then train. On AWS, run this editing environment remotely with the Omniverse AMI (G6e/G7e) + Amazon DCV.
🔄 Volatile data (AMI versions/pricing — checked 2026-07)
Item Value
Latest AMI 2026.1.0 (Ubuntu 24.04, 2026 Q1 Refresh)
Production AMI subscription ~$1.00/hr (Marketplace listed price, includes AI Enterprise + support)

AWS mapping: IoT TwinMaker + IoT SiteWise + Omniverse AMI (G6e/G7e).

Decision criteria: equipment data integration · lightweight twin → TwinMaker (given the low velocity). Photoreal simulation · USD6 collaboration → Omniverse AMI.

Customer case: case pending.

➡️ Next action: if the customer asks "isn't TwinMaker dead?", correct it immediately ("GA, open to new customers, just low velocity"). If they want twin + simulation integration, connect to the Omniverse AMI. If they ask "is there OVX?", answer precisely "no, G6e/G7e + AMI."

🔗 Related assets:

6. Why simulation — the economics of physical robots (price · BOM · regulation) 🟢 GA (stable principle)

L0 TL;DR: "Sim is cheap" in numbers. Physical robots span ~100× from an entry quadruped at ~$1,600 to an unsold humanoid at an estimated ~$130K+, about half of a humanoid's cost is joints (actuators + hands), and in Korea the legally required guarding setup (→ pillar-4 safety regulation) is added on top. The same money buys tens of thousands of GPU hours — one 4,096-environment parallel training run costs $11~12 on Spot. This economics underwrites the ROI of this whole pillar (items 1 · 2).

Customer need/problem: "How do we justify simulation infrastructure investment to executives?" — knowing the cost structure of physical trial and error is itself the ROI argument for sim.

Solution overview [1]/[3]:

  • Price per robot (public prices, rough, time-varying): Unitree Go2 (entry quadruped) ~$1,600 → Unitree G1 (entry humanoid) $13,500 → Franka Research 3 (cobot arm) ~$20–30K → Boston Dynamics Spot from ~$74.5K (fully configured with arm/LiDAR $150–300K+) → Unitree H1 ~$90K → Fourier GR-1 ~$150K. ⚠️ Do not read the price list as a budget — Tesla Optimus "$20–30K" is a mass-production target, not a sale price (current build cost estimated $50–100K); BD Atlas is not sold (analyst estimates ~$130–145K); Figure·Apollo·Digit have no public unit price (pilot/RaaS). Of the ten public rows, four cannot be bought at any listed number.
  • Half the cost is joints, not "intelligence" [3]: in a humanoid BOM12, actuators (motor + precision reducer) + precision hands account for ~48–57% (Morgan Stanley 'The Humanoid 100', 2025-02 — on Tesla Optimus Gen2, actuators ~56%, and the 14 planetary roller screws alone ~19% of the total; ex-software BOM $50–60K). Precision-reducer oligopoly (Harmonic Drive cited at ~85% share), concentrated rare-earth magnet supply, and the absence of scale (~13K humanoid shipments estimated for 2025) stack up, so unit costs don't come down easily. Inside sim, that half is free — zero joint wear, breakage, or replacement cost.
  • GPU-hour equivalence [2]: Seoul Region g6e.xlarge (L40S 48GB) On-Demand $2.288/hr, Spot measured ~$0.98/hr (2026-08, AWS Price List API — varies by time/AZ). On the ETH recipe (4,096 environments, locomotion in <4~20 minutes, → item 2), one training run is $11~12. The price of one Spot quadruped (~$75K) buys tens of thousands of g6e GPU hours — physical trial and error also adds wear, accidents, and labor, while sim's hourly rate is the entire bill.
  • Zero regulatory setup: the legally required guarding of a physical cell (1.8 m fence, KCs-certified light curtains, etc. → pillar-4 safety regulation) and the risk-assessment/certification lead time do not exist in sim. Risky scenarios — high-speed collisions, drops, hardware failures — can be repeated safely without limit; AWS and NVIDIA official docs make the same argument ("training robots in the real world is slow, expensive, and potentially dangerous").

AWS mapping: this economics is itself the investment justification for items 1 (Isaac on EC2) and 2 (Batch parallel RL). Prices are measured via the AWS Price List API (ap-northeast-2) — always cite with a date.

Decision criteria: up-front physical cell investment vs sim-first → sim-first is almost always the answer. But say in the same breath that manipulation does not get solved by sim alone (→ pillar-4 manipulation) to stay honest.

Customer case: (the framing itself is a combination of public vendor/research figures — sources are cited inline)

➡️ Next action: when asked to justify sim investment to executives, start with two numbers — "joints are half the cost, and free in sim" + "$12 per training run." Detailed prices swing, so always attach the date, and connect the safety/regulation axis to pillar-4.

🔗 Related assets: pillar-4 safety regulation · decisions · exec executive brief

The honest reality of this pillar (SA must-read)

  • AWS RoboMaker is dead (support ended 2025-09-10). Never present it as an option. The successor stack = EC2 G6e/G7e + Isaac Sim AMI + AWS Batch MNP.
  • Isaac Sim 6.0 is not GA (Preview). The latest GA is 5.1.0. Don't be fooled by the GitHub patch-tag label.
  • AWS is not a named Cosmos 3 host (Azure/CoreWeave host it). Responding with self-hosting (G7e) is the honest angle.
  • A100/H100 cannot render in Isaac Sim (no RT Core). Rendering is G6e/G7e; compute RL can also use P5 (MuJoCo).
  • The TwinMaker discontinuation story is a rumor — correct it, but honestly acknowledge "low velocity."
  • Genesis "430,000×" is refuted, MuJoCo Warp is Alpha, Unity Robotics Hub is effectively abandoned (since 2022), Habitat has been unmaintained since v0.3.4 — do not exaggerate open-source maturity.

owner: Youngjin · updated: 2026-09 · volatility: high (versions · instances are managed in the collapsed block) · sources: [1] official/paper, [3] vendor, [4] unverified. Some GitHub release years advised to re-confirm.

  1. Reinforcement learning (RL) — training a policy through trial and error to maximize a reward signal. In simulation, thousands of parallel environments let robots learn control policies such as locomotion quickly. ↩

  2. Parallel environments — replicating the same simulation environment thousands of times on a single GPU and running them simultaneously. Speeds up RL experience collection by thousands of times — the core value of simulation. ↩

  3. Headless — running the simulator without a GUI. No rendering overhead, so large-scale parallel training jobs run headless. ↩

  4. RT Core / RTX GPU — the NVIDIA GPU family with dedicated ray-tracing hardware (RT Cores). Required for Isaac Sim's photoreal rendering, so A100/H100 (no RT Cores) cannot be used for rendering. ↩

  5. Ground truth — the exact answer data that serves as the reference for training and evaluation. In simulation the engine already knows every object's position and segmentation mask, so perfect labels are generated automatically. ↩

  6. USD (Universal Scene Description) — the standard 3D scene description format created by Pixar. Isaac Sim scenes, robots, and assets are all described in USD; it is the common language of the Omniverse ecosystem. ↩

  7. Synthetic Data Generation (SDG) — a technique that uses a simulator to auto-generate training images and annotations (labels). Its biggest advantage: labeling cost converges to zero. 🎥 Isaac Sim Replicator SDG tutorial ↩

  8. PPO (Proximal Policy Optimization) — the most widely used reinforcement learning algorithm. Converges stably and is the de facto default for robot locomotion training. ↩

  9. Digital twin — A physically faithful virtual replica of a real factory, warehouse, or robot. Enables policy training, validation, and scenario experiments without touching the real environment. ↩

  10. MNP (Multi-Node Parallel) — the AWS Batch mode that runs a single job across multiple EC2 nodes. It lets large training/simulation jobs that need inter-node communication be managed through a batch queue. ↩

  11. OSMO — NVIDIA's workflow orchestration platform for robotics workloads. It schedules multi-stage jobs such as synthetic data generation, simulation, and model training across on-premises and cloud clusters (e.g., Kubernetes). ↩

  12. BOM (Bill of Materials) — the list of parts and materials that go into building one unit of a product, and its cost composition. "Half of a humanoid's BOM is joints" refers to the share of hardware cost taken by actuators (motors + reducers) and hands. ↩