Amazon Leo for Enterprise: What a LEO Satellite Network Changes for Cloud Architecture
Amazon Leo Ultra delivers 1 Gbps via satellite with private networking to AWS. Here is what it concretely changes for enterprise connectivity, how it integrates with Cloud WAN and Direct Connect, and when it beats MPLS, SD-WAN, or Starlink.
I wrote a post in February comparing MPLS vs SD-WAN vs Cloud WAN. The conclusion was that Cloud WAN is the control plane, not the pipe. You still needed a physical underlay: fiber, MPLS, or broadband.
That premise just changed.
Amazon Leo (formerly Project Kuiper) is now in enterprise preview with over 300 satellites deployed. The Leo Ultra terminal delivers 1 Gbps download and 400 Mbps upload via phased-array antenna. And the part that matters for architects: it connects directly to AWS Transit Gateway or Direct Connect Gateway through a point-and-click interface. No public internet in the path.
For years, the advice for remote sites was “bond two cellular links, accept the jitter, and pray.” Or worse: sign a 3-year VSAT contract at 10 Mbps for $3,000/month with 600ms latency. Both options constrained what you could run at the edge. Real-time dashboards? Forget it. Video-based quality inspection? Not with 10 Mbps upstream. Cloud-native MES? Only if you cache aggressively and tolerate staleness.
This is not consumer satellite internet. This is a new WAN underlay for enterprises that operate where fiber does not reach.
The Three Terminal Tiers
Amazon Leo offers three hardware tiers, each targeting a different use case:
| Terminal | Size | Download | Upload | Target |
|---|---|---|---|---|
| Leo Nano | 7” x 7” | up to 100 Mbps | TBD | IoT, edge sensors, remote monitoring |
| Leo Pro | 11” x 11” | up to 400 Mbps | TBD | Branch offices, maritime, aviation |
| Leo Ultra | 20” x 30” | up to 1 Gbps | up to 400 Mbps | Industrial sites, primary WAN |
Leo Ultra is the one that shifts the enterprise connectivity conversation. Full-duplex phased array, custom Amazon silicon, no moving parts, weatherproof. Pole-mounted outdoor installation. This is built for factories, mines, offshore platforms, and construction sites where running fiber costs six figures per kilometer.
The “no moving parts” detail matters more than it sounds. Traditional VSAT dishes use mechanical gimbals to track geostationary satellites. Those gimbals fail in harsh environments: cement dust, salt spray, extreme cold. A phased-array antenna is solid-state. It electronically steers its beam across multiple LEO satellites as they pass overhead. Nothing to jam, nothing to corrode, nothing to recalibrate after a storm.
The 20x30 inch form factor is roughly the size of a large pizza box. Compare that to a 1.2-meter VSAT dish. You can mount Leo Ultra on a container roof, a telecom mast, or the side of a factory building without structural engineering approval.
Private Networking: The Architectural Game-Changer
Consumer satellite internet routes through the public internet. That is a non-starter for enterprises with compliance requirements, real-time operational data, or hybrid cloud architectures.
Amazon Leo offers two private networking paths:
Direct to AWS (D2A): connect directly to your VPCs via AWS Transit Gateway or AWS Direct Connect Gateway. Point-and-click setup through the Leo web console. Traffic never touches the public internet. This is the path for workloads running on AWS: IoT data ingestion, SCADA telemetry, edge-to-cloud ML inference, backup replication.
Private Network Interconnect (PNI): establish peering at major colocation facilities to connect remote locations directly to your data center or core network. This is the path for enterprises running hybrid or multi-cloud: your Leo-connected sites route into your existing MPLS backbone via colo, not via AWS. Setup in days, not the weeks or months typical for traditional private circuits.
The D2A path is the more interesting one for AWS-native architectures. Think of it as a Direct Connect connection where the “last mile” is a satellite link instead of a fiber cross-connect. Same Transit Gateway attachment model, same routing, same security groups and NACLs on the VPC side. The underlay changed; the overlay did not.
Where Leo Fits in the WAN Decision
In my previous post on WAN options, I framed the decision around three axes: cost, latency, and manageability. Adding satellite as a fourth underlay option expands the matrix:
MPLS: still the gold standard for deterministic latency and SLAs between established sites. But it requires physical infrastructure at both ends. Lead time is weeks to months. Cost scales linearly with distance.
SD-WAN over broadband: cheaper than MPLS, software-defined path selection, but depends on broadband availability. No broadband at the site? No SD-WAN.
Starlink: available now with 11,000+ satellites in orbit. Consumer-first, but Starlink Business exists. No native AWS private networking integration. Traffic routes through the public internet. Latency around 25-50ms. Good as a backup or for temporary sites.
Amazon Leo: enterprise-first private networking. Native AWS integration (D2A). 1 Gbps throughput on Ultra. Latency in the 25-50ms range (LEO orbit at 590-630 km altitude). Still in preview with limited coverage expanding through 2026.
The decision framework:
| Scenario | Best Option |
|---|---|
| Established site with fiber available | MPLS or DX |
| Branch office with broadband | SD-WAN + Cloud WAN overlay |
| Remote industrial site, no fiber, AWS-heavy | Amazon Leo Ultra (D2A) |
| Remote site, multi-cloud or on-prem heavy | Amazon Leo Ultra (PNI) |
| Temporary site (construction, events) | Starlink or Leo Pro |
| Maritime / aviation | Leo Pro or Leo Ultra |
| IoT sensors, low bandwidth | Leo Nano |
| Redundancy for existing WAN | Leo as secondary path |
The Cloud WAN Integration Story
Here is where it gets architecturally clean. If you are already running AWS Cloud WAN (as I recommended in the February post for multi-region enterprises), adding Leo-connected sites is straightforward:
- Leo terminal connects via D2A to your Transit Gateway or Direct Connect Gateway
- That TGW/DXGW is already an attachment in your Cloud WAN core network
- Cloud WAN segment policies route traffic between Leo-connected sites and your VPCs
No new routing plane. No additional VPN tunnels. The satellite site becomes another spoke in your existing hub-and-spoke or mesh topology. Cloud WAN handles the segmentation, routing propagation, and policy enforcement the same way it handles your fiber-connected sites.
This is the “Cloud WAN is the control plane, not the pipe” thesis validated. The pipe changed from fiber to satellite. The control plane does not care.
The SD-WAN Overlay Question
A common question: “Do I still need SD-WAN if I have Leo with D2A?”
Short answer: probably not for the satellite-connected sites.
SD-WAN’s core value is intelligent path selection across multiple underlays (MPLS + broadband + LTE). If your remote site has exactly one underlay (Leo), there is no path selection to optimize. You get the satellite link or nothing.
Where SD-WAN still adds value: if you run Leo as primary and LTE/cellular as backup, an SD-WAN appliance at the site can failover between them transparently. But at that point you are running SD-WAN for resilience, not for optimization. And AWS Cloud WAN with its built-in failover policies might handle that routing decision centrally without requiring a box at the edge.
My take: for greenfield remote sites on Leo, skip the SD-WAN appliance. Use Cloud WAN for policy routing and rely on Leo’s built-in link monitoring. For existing sites where you are adding Leo alongside MPLS or broadband, keep your SD-WAN stack and add Leo as another transport.
Latency Reality Check
LEO satellites orbit at 590-630 km altitude. Round-trip to the satellite and back: approximately 4-8ms of propagation delay. Add ground station processing and backhaul to the nearest AWS region: total end-to-end latency lands in the 25-50ms range for most paths.
For context:
- MPLS between Paris and Frankfurt: ~10-15ms
- Broadband between Paris and Frankfurt: ~15-25ms
- Geostationary satellite (VSAT): 600-700ms
- LEO satellite (Leo/Starlink): 25-50ms
The jump from GEO to LEO is the difference between “video conferencing is impossible” and “video conferencing works fine.” Real-time SCADA monitoring, VoIP, remote desktop sessions: all viable over LEO. They were not viable over traditional VSAT.
50ms is not competitive with fiber for latency-sensitive financial workloads or real-time gaming. But for industrial operations, edge IoT, and general enterprise connectivity at remote sites, it is more than adequate.
Put it differently: at 50ms, you can run a Grafana dashboard refreshing every 5 seconds, push OPC-UA telemetry to AWS IoT Core, execute Bedrock inference calls for quality inspection, and hold a Teams video call with the factory floor. All simultaneously over a single Leo Ultra link. Try that on traditional VSAT.
The 400 Mbps symmetric upload is equally important. Edge AI workloads that need to ship camera frames or sensor batches to the cloud were bottlenecked by asymmetric links. Leo Ultra’s upload bandwidth makes real-time visual inspection pipelines viable from remote sites for the first time over satellite.
Enterprise Use Cases Already in Motion
Aviation: Delta Air Lines announced a multi-year partnership (March 2026) to install Amazon Leo on 500 aircraft starting 2028. Free high-speed Wi-Fi for SkyMiles members, powered by satellite-to-AWS infrastructure. JetBlue is also in the enterprise preview.
Maritime: Amazon signed agreements with maritime partners in February 2026. Ships equipped with Leo Pro or Leo Ultra get persistent connectivity for fleet management, crew welfare, and real-time logistics tracking. No more switching between coastal cellular and expensive VSAT.
Energy: Hunt Energy is in the enterprise preview. Their use case: connecting distributed energy assets (wells, solar farms, substations) across remote geography. The combination of bandwidth and private networking eliminates the connectivity gap for operational technology (OT) networks.
Manufacturing: this is where I see the largest enterprise opportunity. A global industrial group with 40+ manufacturing sites across 3 continents will have sites where fiber simply does not exist or costs more than the building. Leo Ultra as primary WAN for those sites, with D2A routing into their AWS data lake, means real-time quality telemetry, MES integration, and edge ML inference become possible where they were not before.
What Is Not Ready Yet
Honesty time. Amazon Leo is still in enterprise preview. Here is what is not yet resolved:
Coverage: 300+ satellites deployed out of a planned 3,236 constellation. Coverage is expanding but not global yet. You need to verify coverage at your specific site locations.
GA timeline: commercial launch targeted for mid-2026. Enterprise preview is limited to select customers.
Pricing: not publicly disclosed for enterprise tiers. Expect it to follow a bandwidth-commitment model similar to Direct Connect, not a flat monthly fee like Starlink consumer.
Redundancy: for critical sites, you will want Leo as one path and something else (cellular, MPLS, broadband) as failover. Do not design Leo as your sole WAN path until the constellation is fully deployed and you have months of uptime data.
Weather sensitivity: Ka-band (which Leo uses for high-throughput) is susceptible to rain fade. Amazon’s signal processing algorithms mitigate this, but heavy tropical rain will degrade throughput temporarily. Plan for it in your link budget.
Honest Recommendation
If you operate remote industrial sites without reliable connectivity and your workloads run on AWS, Amazon Leo with D2A is the most architecturally elegant option on the roadmap. It eliminates the “last mile” problem without adding routing complexity: same Transit Gateway model, same Cloud WAN overlay, same security posture.
But do not rip out your MPLS contracts today. Leo is in preview, coverage is incomplete, and you need production uptime data before making it a primary WAN path. The smart play: sign up for the enterprise preview, test at 2-3 representative sites, measure actual throughput and latency under your workload profile, and plan for a phased rollout in 2027 once the constellation is fully deployed.
For sites where fiber exists and MPLS works: keep it. Leo is not competing with fiber on latency or cost-per-bit at established locations.
For the sites where you have been limping along on expensive VSAT, unreliable cellular bonding, or simply no connectivity at all: Leo Ultra changes the game. 1 Gbps from a pole-mounted antenna, private path into your VPCs, no public internet in the middle. That is the connectivity pattern those sites have been waiting for.
ONE LETTER A MONTH · NO TRACKER · UNSUBSCRIBE ANYTIME
Comments
Sign in to leave a comment
