Software Development Engineer, Leo Data Science Platform

Amazon Leo is Amazon's low Earth orbit satellite network. Our mission is to deliver fast, reliable internet connectivity to customers beyond the reach of existing networks. From individual households to schools, hospitals, businesses, and government agencies, Amazon Leo will serve people and organizations operating in locations without reliable connectivity. We are looking for a Software Development Engineer to build and scale the services/cloud layer of VirtSat, Leo's virtual satellite simulation platform. VirtSat lets developers and automated pipelines across Leo create, provision, and test virtual satellites, ground gateways, customer terminals, and TT&C antennas on demand — replacing scarce physical hardware benches with cloud infrastructure that scales with the constellation. You will own the simulation control plane: the APIs, orchestration workflows, and health systems that turn a single request into a fully provisioned, flight-software-running virtual satellite. Every Leo satellite software release is validated on this platform before launch, which means the availability and latency of the services you own directly set the pace at which the constellation ships software. This is a distributed systems role on a platform with an unusual property: your dependencies are physical. You will build APIs whose correctness depends on certificate provisioning, hardware emulation, radio link simulation, and the flight software itself — and you will make that stack behave like a reliable, self-service service. Export Control Requirement: Due to applicable export control laws and regulations, candidates must be a U.S. citizen or national, U.S. permanent resident (i.e., current Green Card holder), or lawfully admitted into the U.S. as a refugee or granted asylum. Key job responsibilities * Own the entity lifecycle APIs — create, provision, power-on, and tear down virtual satellites, gateways, customer terminals, and antennas — and drive them to and past a 99.9% availability bar * Design and evolve the orchestration layer: long-running state machines that coordinate provisioning across distributed dependencies where any step can fail on physics rather than code, and where partial failure must be recoverable rather than restart-from-scratch * Own the service-side plugin framework — the published contract, registration, delegation, and result aggregation that lets subsystem owner teams define their own initialization, health validation, and provisioning logic without our team in the loop * Build the health check aggregation API: a single call that returns per-subsystem health with every failure attributed to the team that owns it, so customers self-diagnose instead of paging an on-call * Build and own continuous canaries that validate the full stack against a pre-production constellation on a fixed schedule, wired so that a failure cuts a ticket and pages automatically with no human in the detection path * Integrate with certificate, identity, and entity-registry services — device identity generation at constellation scale, certificate lifecycle, namespace registration, and the calibration data that makes a virtual entity behave like its physical twin * Drive down provisioning latency, currently measured in minutes at p90, through parallelization, image pre-baking, and eliminating serialized dependencies * Own observability end to end — structured logging, embedded metrics, distributed tracing, and log centralization — with the specific goal that a customer can root-cause a failed run from logs alone without recreating it * Scale the platform for concurrent multi-tenant use: capacity management across bare-metal pools, fleet-wide provisioning throughput, and cost per simulated entity * Partner closely with the virtualization and emulation team that owns the host layer, with subsystem owner teams who build against your plugin contract, and with the test frameworks and release pipelines that are your highest-volume