AWS re:Invent 2025 - Architecting resilient global networks with Amazon Leo (ARC320)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Architecting resilient global networks with Amazon Leo (ARC320)

In this video, Amazon Leo team members Nick and John present their satellite internet service, explaining how they're deploying over 3,200 satellites in low Earth orbit at 590-630 kilometers altitude to deliver sub-50ms latency and up to 1 Gbps speeds. They detail the technical architecture including phased array antennas (Pro, Nano, and Ultra models), satellites moving at 17,800 mph with inter-satellite lasers, ground gateways, and integration with AWS's global network infrastructure. The presentation covers orbital mechanics differences between LEO and GEO, security features including envelope encryption and Macsec, and AWS integrations using IAM temporary delegation, CloudWatch metrics, and EventBridge events. They showcase enterprise use cases spanning backup connectivity, SD-WAN integration, private networking via Direct Connect and Transit Gateway, industrial OT/SCADA applications, and mobility solutions for aviation and maritime. The enterprise preview was announced with 153 satellites currently deployed and service launch planned for 2026.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Amazon Leo's Satellite Internet Service and AWS Integration

Hello everyone. I'm Nick, and I work on the Amazon Leo team. We recently rebranded from Project Kuiper about a week ago, so I may mention that a few more times. We're building satellites, and we're here to talk about what we're building and what we're doing with AWS. John is also going to talk with us.

Hey folks, I'm John. I've been with Amazon for about 11 years now, helping to build the network on the AWS side. I appreciate all of you coming to the farthest flung part of this conference at the latest hour. We really appreciate you all being here.

So what we're talking about today is Amazon Leo. We're building a satellite internet service that will be a global service around the world. We're also here at the AWS conference, and AWS runs a global computing solution. The question we're exploring is what does it look like when you use these things together? What are the benefits? What are the use cases? One of the interesting parts of working for Amazon Leo is that we're a space company. I've been working on the cloud side a lot too, and sometimes you're working on enough things named after planets and other things that you think you're working on space stuff, but not really. You're just working on billing for containers or something. I think we've been teased about space enough, so let's watch an actual rocket launch.

Rocket Launch and Constellation Overview: 3,200 Satellites in Low Earth Orbit

Minus 7 minutes status check to proceed with terminal count. Atlas systems propulsion, hydraulics go. Centaur systems propulsion go, pneumatics go, LO2, LH2 go. Go launch strike. You have permission to launch. Proceeding with 3-2-1. We have ignition. We are now moving at 4000 miles an hour. Software looks nominal. Mechanicals proceeding nominal. All Kuiper satellites have been deployed successfully. Congratulations, Kuiper.

This is a little bit of what our constellation is going to look like. We have plans to launch over 3200 satellites into low Earth orbit. Low Earth orbit is also the name of our brand with LEOs. It's very clever. We're launching at three different shells between 590 to 630 kilometers up in space, which we'll talk about. One of the interesting parts is that everything that goes up must come back down, so you have to build a global ground gateway network. When you add all of those things together, your user experience when you use it will feel a lot like a fiber or cellular network. We're estimated to have less than 50 milliseconds of latency, and our largest terminal can do 1 gigabit down and 400 megabits per second up. So you can get high speeds and low latency, and that's what we're building here.

Usually the first question we get is how ready are you? Where are your satellites? What's the status? So let's cover that now. Over the last six months we have launched roughly every six weeks, putting anywhere between 24 to 27 satellites up at a time. We have 153 satellites up in space. In 2026 that cadence is going to increase. We have facilities down in Cape Canaveral where we're going to be able to work on multiple missions and multiple launches at the same time. We're also working with vehicles that we paid for many years ago and are just now coming online. The Blue Origin New Glenn, the new Ariane 6, as well as the Vulcan Centaur with ULA are all bigger, more powerful rockets that launch more satellites at a time. Our pace is going to increase, and we're all super excited about that. We should have service in 2026.

If you take a look at this image in the center, this is a still shot of one of the many simulations that we run, and this shows you a little bit of the effects of our orbital mechanics. I'm not going to tell you too much about orbital mechanics, but we'll get a little bit into it. Essentially we put the satellites into an angle around Earth, but the way that it actually shows up is it doesn't spend the same amount of time at every latitude. It spends more time at the tops and bottoms. The way that you will see service roll out is the closer you are to these areas that are unfrogged, the sooner you'll get service. For those of you that maybe geography isn't your forte, essentially there's that line that goes to the US-Canada border and that also goes through Central Europe.

On the south, we start down in New Zealand where it's mostly ocean, and the service comes up towards the equator so you'll see us roll out over time.

Connectivity Challenges Across Urban, Suburban, and Remote Locations

What we're going to talk about today is why we go through all this effort. Space is hard, and we want to address the challenges and problems that we're seeing. I'll teach you a little bit about how the satellite network works so you can understand how to use it better. We'll talk about how we're working with AWS and where the overlaps are, and then some of the use cases and what we're seeing from customers and how people actually put this into practice.

Let's talk about some of the challenges here. The problems we see are typically based on how far you are from other options. Let's start close to fiber in the city in urban areas. The challenges we see here are that you've got pretty good fiber, you usually have multiple providers and multiple options, until you don't. If a storm comes through, you have an outage. You might have a hurricane, flood, bushfire, or whatever your location suffers from. Our terminals are meant to be outside and they're hardened, so there's a pretty good chance they'll live through this. Otherwise, you can pop one open from a backpack and now you can connect to the Leo network on demand. So there are some use cases there.

Then you get a little bit further out into more suburban areas. This could be two miles or twenty kilometers, and every part of the world is a little bit different. Out here you have fewer options. You may think, for example, that you have two different providers that are fully separated, until our friend the fiber-loving backhoe shows up and cuts a channel or cuts a bridge wherever it is. Now you have maybe zero options, or maybe the options you do have take a couple of months to show up and you need connectivity faster than what people can provide to you. So we see a lot of use cases in this suburban area.

We get a little further out, and now we're in areas where satellite communications are more typical. This is your agriculture, your mining, your far rural areas. When you're out here, everything is harder and more expensive. People's lives can be at risk. The equipment is expensive. The things you're doing are important. Trying to connect those things and make sure they run like they're close to home is difficult.

You get even further out and now we're in airplanes, boats, and islands. These are places we just don't expect to have Internet at all, and so there are a lot of different use cases we can do out in these areas that now it's something we can do. No matter across the board, one of the challenges we see is just the management of these systems. Sometimes these systems were built for a single country or a single niche use case, or you're working with thirty, forty, fifty year old type of equipment and it doesn't have the types of monitoring, management, and ease of use that we expect in the cloud world. So it can just be challenging to manage these things.

What Makes Amazon Leo Different: Performance, Security, and Amazon's Advantages

When you add some of these things up, these are some of the bases that we think Amazon Leo will be different. We're not the first people, we won't be the last, but we think this is what's different about what we're building. One is the performance. We're a connectivity service and that's just what people care about, so performance is paramount. Anything we can do to reduce latency and increase bandwidth, but also the consistency of that, running a high quality network and doing it securely, right? Secure by design is our second area.

Amazon in general has a very high security bar and we meet that. As a connection you want to use and businesses that want to use this, we make sure that we've increased the security of our network. We have advanced encryption across our network and we also have options that keep it completely off the Internet so we can do private networking options. Being ready for business, the way that customers want to be treated, invoicing and management at scale, customer support, and just things you expect from Amazon are things we do.

One of the other interesting parts of working for Amazon Leo over the last few years is all the other things Amazon can bring. If you think about our retail business, the ability to ship antennas around the world quickly and have return logistics for that. The ability to manufacture devices like the millions of Fire TV and Alexa devices, we've got a lot of experience with that manufacturing portion of it. We need to build millions of terminals and thousands of satellites. There are a lot of overlaps there. Both AWS and other parts of Amazon have built custom chips and ASICs. We've built a lot of those into our system to make sure that we get the right price and performance on the satellites.

Looking at the cloud side, one key advantage is that many of the workloads customers want to use in combination with Leo are already running on AWS. This allows you to combine your connectivity and your applications together in ways that provide significant benefits. The process of designing these systems involves challenges we'll discuss, but we can leverage things like control planes, multi-tenancy, and strong APIs that AWS and Amazon have built before. There are many really cool things we can use from Amazon to make Leo better.

Orbital Mechanics 101: Understanding GEO vs LEO Satellite Networks

Let me do a quick audience check. How many of you are networking folks? How many are astronauts or space people? A couple, alright. How many are developers? That's kind of what I expected.

I'm going to teach you some orbital mechanics real quick. GEO, which is short for geosynchronous orbit, represents a simple business model for what we're doing here. An orbit is really just a fancy way of saying you're trying to fall back to Earth using gravity and you're missing, just flying with style. Geosynchronous orbit means you're at a very specific distance. If you're 35,768 kilometers from the Earth, you're falling in a way where you're rotating at the Earth's rotational speed. This means if you're a country and you want to launch one satellite that stays over your country all the time, you put it exactly at this distance. If you've seen TV on your aunt's dish in the country and it takes a second or two for everything to get by, or if you've ever made a satellite phone call and had to make walkie-talkie sounds because the delay is so long, that's because you're going a very far distance into space and coming back. The latency can be 250 to 750 milliseconds depending on how the network is run.

So we decided to build this in Leo. I actually made these fairly accurate for physics, so we'll see if PowerPoint crashes.

With Leo, we're a lot closer to Earth. The latency could be anywhere between 15 to 100 milliseconds depending on things like the angles, if you're using lasers for things that move like airplane flights, or just how you run the network.

We're going around the Earth 16 times a day. You can also see the beam is a lot smaller, so we're not covering very much of the Earth. Now we need more satellites.

Even with about 50 satellites, we're not covering the whole world at any given point in time. However, we've got a lot more control now. The beam is smaller, we're losing less energy and physics to free space, and if we don't want to, we don't need to turn the beams on over the oceans. We have a lot tighter, more granular control. We're also within the Van Allen radiation belt, which means we actually get more built-in protection from being closer to Earth.

For some of you developers, think of it like the difference between running a single Postgres database in your closet versus running a full high-performance scale cluster. As these satellites move around, there are a lot more handovers, a lot more thinking, and a lot more complexity in systems like this. You need to take a cloud-scale design approach to build this network.

How the Network Works: From Antennas to Satellites to Ground Gateways

Let's take a look at the packet walk in a little more detail. We start with the antenna, which is built to be outside and will talk to a satellite in space.

That satellite comes back down to a ground gateway.

The ground gateway sends it to one of our points of presence. We used to be called Kuiper and these used to be called K-pops, so there were a lot of good Korean jokes. Those are now gone. These are just our points of presence. That point of presence can send it either to the Internet directly to AWS or to a private network interconnect.

If we zoom in on the antenna, let's spend some time there. One of the interesting parts of Leo is that we've spent a lot of time, effort, and engineering, and made a lot of trade-offs to make the antennas really good as opposed to paying lots of money for expensive things. These need to be built in an Amazon style. They need to be rugged and outside, but we need to make sure these are as affordable as possible.

If you think about a lot of the parts of the world that don't have internet, affordability and the entry cost are extremely important for us. These antennas have a radome on top that protects them. Underneath inside is a phased array antenna.

Underneath that is a heat sink, and then there's an ethernet port. That's pretty much it, but there's a lot of really advanced technology in there. These three units we have here are the Pro, the Nano, and the Ultra. The Pro unit is about the size and weight of a laptop, and it does 400 megabits per second on the downlink. The Nano unit is even smaller at 7 inches by 7 inches and does 100 megabits per second. This is really about the size, weight, and power—you want to put it in a backpack or somewhere you're doing SCADA or IoT type monitoring, surveillance, or just serving a small number of users.

Then you have the Ultra, which is the big one. This is what we see for more of our heavy enterprise use cases. It's around 40 pounds and about this big, so it's a little bit bigger. But think of it like data center class—if you want to back up a data center or you have a lot of users, like a camp with 400 people, and you want that full 1 gigabit, this is the unit you're going to want.

Let's talk about the satellites. The satellites get a lot of attention because they're in space and they're pretty cool. They move at 17,800 miles per hour, or 28 kilometers per hour if you prefer other units. This also means they're only over a certain part of Earth for 30, 60, or 90 seconds usually, just based on the speed they're going. One of the interesting things we do from the networking we build is that it's all preprogrammed. The hard part about getting things into space is getting there. The easy part is predicting where it's going to be in the future. These orbits are highly predictable. We know where those are going to be, where the terminals are going to be, and where the ground gateways are going to be, and we can pre-calculate all those topologies.

There are also lasers, which we'll talk about. We can figure out what the network needs to look like, which frequencies are used where, which terminals are going to talk to whom, when they're going to hand off, and we can be extremely accurate with those things. It's a really cool network engineering project. When I say they're predictable, some of the things that are not is that they do sometimes need to use propulsion. We have propulsion on board, which allows us to do a couple of different things. One is we can come in at a lower altitude and raise the orbit once it's been tested and it's clean and good. Also on orbit, if there's any chance of debris or other things we need to do avoidance maneuvers, we can do that. Once the satellite is done, we slow it down and it burns up peacefully in the Earth's atmosphere. We can talk about sustainability in a lot of different ways—essentially we're doing a lot of work there. That's usually the first question we get.

Let's talk about the lasers. Lasers have a couple of different use cases. The first and probably most obvious to folks is when you're out in the middle of the ocean, you're on a boat, you're on an airplane, and there's no ground gateway near you. The lasers allow us to have greater reach. You go up to the satellite and then come back down to a ground gateway. It's about reach, but also if that ground gateway has an issue or if there's a storm there or if there's a fiber cut or if there's antennas having issues, you can use those lasers to get to more options. This gives you optionality in how you build the network as well. They have 4 different lasers that can go north, south, east, and west, and you can build this kind of flexible space backbone. This gives us options on how to route our traffic.

Then we have the ground gateways. This is a picture of those—usually they're going to be 5G gateways just hanging out in a field somewhere. These are super important for us. If you think about it, there might be hundreds or thousands of these terminals on the left and the satellites talking to one or two ground gateways. In networking terms, it's your uplink, and it's very important for the overall network bandwidth. This is also how we'll eventually reduce all the latency. The closer that gateway is to where you want to go, the less time you spend messing around in space. This scales out, so we use the AWS network. We need to put that gateway somewhere near a network to get it to where you want to go.

The gateway basically takes the RF and puts it on the ground network. You think about space a lot, but most of the latency and most of the hard parts of this actually are just typical ground networking. Then we get to the Point of Presence. The Point of Presence then can make a routing decision. If you're running a workload and you don't want to touch the internet, we can take that directly into your AWS environment. If you have a data center or another cloud you want to work with, that's where we would do a private network interconnect. We can do a peering with you and you can take that traffic privately there. Otherwise you can go to the internet. That one's pretty straightforward. So now you're all satellite experts.

Network Design Challenges: Building a Global LEO System at Scale

Which is great news. However, there might be some challenges that are still a little difficult to visualize. One challenge is that building a global network is difficult because we have to do this in many places all at the same time. Earth is a large place, so there's a scale problem. This relates to some of our networking challenges that we're going to get into.

Then there's the matter of performance. You're going to space and back, and you have to do this globally everywhere. But how do you also reduce the latency and increase performance because that's what people care about. You want to design it once. You think about your cloud design, and you don't want 16 different versions of it. However, building in a small country in Africa is much different than building in a large country in Asia versus something in South America. We have to make many different choices about where we're located in the world.

Sometimes these choices are based on local laws and regulations, and sometimes they're based on demand. Think about needing to choose whether we use the AWS region, the AWS Local Zone, or AWS Outposts. Then there's making this a global, easily managed network across the world. If I have 1,000 terminals spread across countries, how do I do this using cloud-scale management that we all want?

To give you an idea, if you have to design a LEO network and you want to put the first 8 gateways, you can figure that out. There are some obvious places where we'll have coverage and places where we have demand. If you're building 300 gateways, where are you going to put all those things? This is an example of one of the networking challenges if you decide you want to build a LEO network as well, and that you'll have to solve.

AWS Global Infrastructure: A Massive Network Spanning 9 Million Kilometers

For us, there's a big advantage to using the AWS network. To help you understand that and what it looks like and why we've done this, John is going to come up and talk about networking things. Thanks, John. Yeah, thanks, Nick. Hey folks, my name is Jonathan Philibert. I'm a principal network development engineer in the AWS Global Infrastructure Services space. I work on a team called Internet Edge. It is exactly like it sounds. I work on the parts of the network very close to the internet, way out at the edge, away from the data centers.

One of our favorite things to do is work with the people building services on AWS, hearing about their unique challenges, especially when we get to help solve some of those challenges. That's how we started working with Amazon Leo. They were facing some unique challenges, and by building on AWS, they were able to accomplish some pretty cool things. So I'm here to introduce you to Internet Edge, some of the unique things that we offer, and how Amazon Leo was able to leverage us to build a highly resilient, highly performant, and very secure service.

If you've been to some of the AWS Global Infrastructure Services presentations before, you may know that we run a very large network. It didn't start that way. It actually started very modestly way back in the early 2010s. Back then we were sending traffic out over the open internet between the regions. It didn't really provide the kind of experience that we were looking for. It wasn't very reliable, and it wasn't very performant. So we started on this journey to build a backbone.

As the story goes, it is now massive. It now interconnects our 38 regions globally with over 200 Internet Edge Points of Presence that we use to exchange traffic with the internet. This also includes our 145 Direct Connect POPs that we use to exchange traffic with on-premises networks. This is distributed over 110 metropolitan areas in 58 countries. All said and done, this allows us to exchange traffic with over 5,000 internet peers. When you take redundancy into account, it's a lot of capacity for the internet.

When all this capacity and interconnection is laid out on a map, this is what it looks like. It represents over 9 million kilometers of terrestrial and subsea fiber optic cabling. It's a lot of cable and a lot of fiber. It's actually enough fiber to loop between us and the moon and back more than 11 times. What's even more phenomenal is the growth that we are experiencing. We're adding more fiber to it every day. Just in the past 12 months, we've experienced an 80 percent growth.

This growth has made it vital that we invest in automation. The network is just too big for humans to manage by themselves. So 96 percent of network events are remediated without a human ever being involved.

Security by Design: Macsec Encryption, RPKI, and AWS Shield Protection

Amazon takes security very seriously, and this applies to the network as well. When we were designing it, we wanted to make sure that security came first. It was designed with security in mind. We've done that by utilizing a technology called Macsec, which is a layer of encryption. We use it by encrypting data between regions and between data centers at very close to the physical layer when data leaves secured AWS locations. Since we have this secured internal network, we wanted to make sure that the workloads running within AWS benefit from it. We do that by ensuring that traffic stays on our encrypted paths. When traffic travels between regions, it should stay inside Amazon and never go out to the public internet. All that fiber I was talking about means that we should always have enough internal capacity available to fail over to rather than sending traffic out to the open internet.

Of course, there are workloads within AWS that do need to speak with the internet. We've thought carefully about how we can improve the security and reliability of that type of traffic. One of the ways we've done that is by using a resource called public key infrastructure, or RPKI. It allows the participants of the Internet to cryptographically verify that the routing information they receive is accurate and legitimate. It helps prevent traffic from taking unintended or unreliable paths as it is routed across the Internet. A few years ago, it seemed like every week we were detecting our traffic taking unexpected paths. But more recently, RPKI has done a phenomenal job of preventing these events. It allows networks to detect bad routing information and ignore it, ensuring that traffic only takes reliable paths—the paths that we expect when it goes across the internet.

We've also done some innovative things with traffic engineering. We monitor traffic as it goes through the Internet and collect metrics, reliability information, and statistics around performance. We use that data to make decisions about where we should send our customer traffic. We sometimes ignore the typical routing protocols that run the Internet and instead make data-backed decisions. The people who are building on top of AWS just want to focus on running a great service. They don't want to have to worry about what it means to use public IPs and accept connections from the internet. Unfortunately, the internet doesn't always work like that. There are bad actors out there that will find a service and throw junk packets at it in a bid to disrupt or deny service to your users. We call these distributed denial of service attacks, or DDoS attacks.

That's why we have AWS Shield deployed in each of our more than 200 facilities where we peer with the internet. We've deployed custom homegrown hardware that will detect this traffic, redirect it, drop the bad traffic, and allow the good traffic through, ensuring that your service is uninterrupted. We experience millions of these attacks every year. It is constant, and it really underscores the benefit that AWS Shield provides to not just the infrastructure but all of the software running on top of it as well.

There's a lot of security that's built into the way that AWS runs their network, but we really care about the security of the Leo network as well. What we've done is add additional security and encryption on top of what's built into the AWS parts that we're using. When our antenna receives traffic, we put envelope encryption on it and send it all the way through to our point of presence. This means that if someone were to break into the ground gateway site and try to sniff the wire, all they're getting is ciphertext. There's nothing there. If someone were to be more ambitious and go into space and steal a satellite, they're also just going to get ciphertext. The idea is that across our network we're using advanced encryption to make sure we have encryption throughout. We also have a handful of ISO specs, including ISO 27001 and ISO 22301.

How AWS Edge Sites Enable Low Latency and High Resiliency for Amazon Leo

These ISO specs provide organizations with proof that they're doing things the right way and have controls in place, so security is built in from the ground up. This is something we take really seriously. So what are some of the unique challenges that Amazon Leo faced and how did building on AWS help them solve it? Well, Amazon Leo is building a giant constellation in space and sending all this traffic up to it, but at the end of the day, the contents still live down here on Earth. The AWS edge sites are advantageous in this way because they already exist in the places where Amazon Leo wants to send their traffic. By building on top of AWS, Amazon Leo can benefit from a terrestrial network that already exists. It also happens to be the cloud network with the highest throughput and the lowest latency.

AWS helps Leo provide its service in more locations faster. It allows them to focus on their core business challenges, like building out that giant satellite constellation and operating their lasers in space. Our edge sites are also advantageous because of their proximity to other networks. These facilities are where internet exchange occurs, where networks meet to exchange traffic with one another. It's also where AWS deploys services like CloudFront, Route 53, and AWS Global Accelerator. These are services that need to be right at the edge of the network with very close access to these other networks so that they can be close to the users requesting content from these services.

Now that Amazon Leo is built on AWS, they will also benefit from having this close proximity to these services and external networks. Having this close proximity to the networks and to the services is vital for a great customer experience. It drives down latency, and Amazon Leo is designing their service to be as low latency as possible. We know that the path from the antenna up to the satellite and back down to the ground gateway is already about 10 milliseconds. The path from the ground gateway into the AWS network can add another 12 milliseconds. We expect this to come down over time as additional ground gateways are deployed, but at launch it will be about 12 milliseconds.

We are bound by the laws of physics here. The data is being transmitted at the speed of light and we cannot make light travel any faster. So the only way we can optimize latency is by limiting the distance that the data has to travel. That is exactly what Amazon Leo is doing. By deploying globally into the locations where internet exchange occurs, they are positioning themselves to be physically close to the content that is important to their customers, whether it's the latest applications running in EC2, an on-premises network via Direct Connect, or the latest cat memes coming from the internet.

The other impressive thing that Amazon Leo gains by building on top of AWS is the amount of resiliency that is built into the service. We've already established that the AWS edge sites are present in the locations where Amazon Leo wants to send their traffic. That means they can deploy the ground gateways they'll need and never be too far away from AWS. Since the AWS network is global, any of the ground gateways can be used to reach any of the Amazon Leo points of presence. If the ground gateways experience any problems for whatever reason, the satellite constellation can choose to send the traffic to a different ground gateway, and that ground gateway will be able to reach any of the Amazon Leo points of presence.

We also see here that the ground gateways have the option of having redundant connections into the AWS network. This can be especially handy if we run into one of the fiber-seeking backhoes. Even Amazon is not immune to the fiber-seeking backhoe. So if one of the paths gets dug up, the ground gateway can simply use the redundant path to land the traffic into the AWS network.

Finally, by building on top of AWS, Amazon Leo has the ability to make their points of presence entirely redundant. By building on top of AWS, Leo has been able to build an impressive amount of resiliency into their service that should allow you, if you choose to build on Amazon Leo, to build a very resilient service as well. I'll now hand back to Nick for the enterprise preview.

Enterprise Preview: Setting Up and Managing Amazon Leo with AWS Integration

Thanks, John. So one of the questions we usually get from folks is, you know, we're both Amazon companies between AWS and Amazon Leo. What does it look like? What are the integrations and what does that entail? Last week, if you missed it, we announced our enterprise preview. We're taking interest from customers that want to start testing, and we're starting all that testing very shortly.

Let's walk through what it actually is going to look like to use Amazon Leo and I can show you what the integrations look like along that journey. To start off, you can go to our website now. We're out on Leo.amazon.com. You can click on business and learn a little about use cases and other things. When we go available, you'll be able to go from there and click into the Leo Enterprise console.

The way that you log into that console is by using your AWS credentials. You can use IAM or SSO or your favorite way to log into AWS. From there you'll log in and you'll get into our console. You'll see it looks a lot like the AWS console because we're using the same Cloudscape open-sourced UI components, but it is a separate URL and it's different. Once you log in and as you're doing the account creation process, we're going to use a new feature that launched last week. It's called IAM temporary delegation. This allows the Leo network to ask for permissions into your account.

In this example, what we're doing is we're asking for requests to put CloudWatch metrics in as well as EventBridge events and some support functions for our customer support. You do this one time. If, for example, you don't have access to create IAM roles, you can also delegate that to your IAM administrator, so it's a cool feature we're using that to essentially increase the amount of metrics and EventBridge that you'll get. From there, you can go through the ordering process. There are a few different components to this. You'll choose an antenna, which is a one-time cost. You can then choose what we call the service plan, which is a lot like your cell phone bill and happens every month.

That service plan is going to be based upon multiple things. You can get some options in certain industries and verticals. You can also choose whether you want that networking to go to the Internet or do private networking. That's one of the forks you can choose as well. From there we can tell you what it costs and what that looks like. It's a fairly standard ordering process. You do start with your location so we can make sure that we have capacity there and that we're offering service in that way.

Then, while that antenna is getting shipped out and you're getting ready for the installation, if you chose one of the private networking options, you can go set up your own IPv4 addressing details. So if you're cloud people, this is kind of like the VPC for your satellite antenna things. From here you can set up IPv4 subnets, CIDR ranges, and you can associate it with a gateway. You can associate it with a gateway for Direct Connect or Transit Gateway. Those will allow you to connect directly to AWS or to that private network interconnect that we talked about.

Once the antenna shows up, the install is meant to be very simple. You might put it on a pole mount or a non-penetrating roof mount, however you want to install the device or the temporary stand, just put it in your parking lot and make sure it works. It will need to see the top 110 degrees of the sky or 35 degrees above the horizon. From there it's a single Ethernet cable back into an indoor power injector. It does need to be an Amazon Leo power injector just because there's some proprietary technology going on there. Then you connect that to the rest of your network, so you connect it to your switch, connect to a firewall, router, private 5G. It's Ethernet, so you can do what you want.

That's all very simple to do. The larger Ultra, despite being a little bit larger, this one you might want like two people who are getting onto a pole, but otherwise it's very similar. It's 110 degrees. No one's invented 300 watts of POE yet, so we do have a standard power brick, and then that has just a standard Ethernet coupler designed to be ingress-rated for outdoor use.

You'll wire up the power, plug in the Ethernet cable to your existing network, and you're ready to go.

Day 2 happens, and this is where we start doing management of these devices. Your network operations teams, security teams, and other stakeholders want to make sure these things are being managed correctly. I have a list of some of the metrics and events we're starting off with, including how much data you've used, signal strength, and the angle of the antennas to make sure someone hasn't knocked it over or anything like that. These are available in the Leo console, but since these are also being shared through AWS temporary delegation, you can also view these metrics inside your AWS account.

If you want to build dashboards or automations, or your network operations team wants to get a page that alerts you every time something happens, you can use all the existing CloudWatch and EventBridge integrations into the rest of your environment. All of our logs are going into AWS CloudTrail, so if you need to figure out who made a change or why something broke, that information is there as well.

From a billing perspective, this is pretty standard. This is not in the Leo console, so you won't see it in the same billing area. You will build a profile per country that you want to operate in. You have to enter your billing address and some other things that are country-specific. The pricing is not released yet, so stay tuned. We'll have more information as we get into general availability.

Customer Use Cases: From Basic Internet Access to SD-WAN and Private Networking

I love all the folks out of AWS. There are a bunch of builders, and you want to build things and see how to use it. Now that you understand all the background, let's talk about what we're learning from customers. This is my favorite part of the job. I've been out here three years talking with folks about their use cases and what they can do. For starters, it's pretty wide and broad.

Leo as a company is working directly to sell to consumers. We also have direct sales to enterprises, and we also have a part of our business selling to governments, so that covers a ton of use cases. You can think about almost every vertical you can imagine: financial services, mining, rescue and disaster relief, manufacturing. There are interesting use cases across the board.

What's underneath these use cases and what's creating the new capabilities really comes down to three things. One is performance. You get a lot more bandwidth and a lot lower cost than you could do before. What does that enable? What does that change? There are some areas where if you're already using some bandwidth and you just have a lot more, it's straightforward. But there are also areas where you have so much more bandwidth that you can change the applications, the way you work, and how close that site feels to you.

One of the pieces of feedback we get from folks is that they would love to put this type of workload or application on the network, but they don't trust the other options right now. If you have critical infrastructure or other things that need to go through security reviews and auditing, that's a lot of what we're building for. Then there's location. If you're in a hard-to-reach place, that limits what you can do. If you add up these three factors, let's walk through how you can use it.

Let's start off with the easy stuff. I've worked with enterprises long enough that no one does the hard stuff first. We're going to walk through easy things and things that make sense to a lot of people. Providing Internet connectivity to folks is really powerful. If we take an industrial use case, we hear things like the workers don't want to go out on that oil rig unless they have full confidence that they can call someone when they need to. They need to make sure they can talk to their families and do basic things like that. There's not a lot of complex architecture going on.

We get a lot of use cases like giving folks Internet access. If someone's doing maintenance, they want to be able to call someone who's good at maintenance. Or they want to use Salesforce, CRMs, or whatever applications they use every day. It gets pretty far. Whether you're a telco building cell towers and trying to get connectivity there for the first time, or you're someone like our own internal Amazon folks building distribution centers, getting day-one connectivity there is difficult. It can take weeks or months. Amazon can ship devices much faster than that, so you get an antenna, you stand it up, and you have day-one connectivity. Then on day two, you can choose what to do with it. You keep it there for backup or you move it to the next place that you need it.

Then you think about education and the underserved parts of the world. We're working with folks that say they're going to put an antenna there for maybe some industrial or business purposes.

But there's also a school there, or we think it's in our best interest to add financial literacy or training to the corporate uses that we're using as well. So there's a lot of things around Internet to schools and countries that need it. This is all just kind of easy things, low risk. As we get a little bit further down, we can look at the architecture.

So this goes to the gateway. We taught you those things. And maybe you're using CloudFront for your gaming update or you're using a corporate application, a data center, or maybe your learning application happens to be on AWS. One of the interesting things that we talked about was that AWS doesn't take those things off the backbone. It's basically like cold potato routing where it stays on that network the whole way. So if you're using applications that are on AWS and you're just doing the Internet, it doesn't leave the network. And so you get benefits of this even without doing anything fancy.

If we get a little bit fancier, the next thing we see is backup and resilience. We've talked a lot about the backhoe, and again cell towers are also not immune from these things. So if those go down, you want another option maybe, or to support microwave networks and industrial use cases. We see things like, you know, we're out in the middle of nowhere and we're trying to get everything. We tried every cell carrier, we tried every satellite provider, we tried every fiber provider, and you just can't keep this site up enough. So we go to space. We have a different network, we have a lot of different ways that we work. So this non-terrestrial network is a great way to add resiliency to applications that need to stay up all the time.

In typical enterprise use cases, we see a ton of work with SD-WAN. You have multiple options, and Amazon Leo can just be another one of those that plugs into that. Then also the use cases around disaster response. We're working with folks who say they need to bring in a whole team of folks. They need to access medical records or they need to do maybe voice over LTE and communications when they stand up after some sort of event happens. So they bring maybe some sort of case that's pre-built in and it's got multiple options, and now Amazon Leo is part of your go bag that you take out to these types of events.

From here this architecture is also fairly simple. So you can take your SD-WAN router, which already takes multiple forms of connectivity into it, and just add Amazon Leo to it so that you can run the SD-WAN either in AWS, which a lot of folks do, or you can also run it at your data center. So it works pretty simply.

Some folks we're working with want to add private networking into this. So essentially you can add your Leo path to be fully private so that it can connect directly back to your data center via that PNI, or you can take it directly into your VPC and connect your SD-WAN there. So in this case, some of the benefits are that you may not actually need an SD-WAN router if all you need is that encryption and you need privacy. The antenna can do that. Alternatively, some people want to further secure their SD-WAN, so now you can run SD-WAN over private addressing, and that's one less thing that's exposed to the Internet.

Industrial and Critical Operations: OT Networks, SCADA Systems, and Direct Connect

Then we get a little bit higher up. Let's do some harder things. So this is in the industrial cases, which comes down to a lot of things like OT and critical operations. These things you don't want usually connected to the Internet. So what does that look like? We actually have a couple of slides on this. I'll walk through here in a little bit. One of the cases we see with telcos is they want to get rid of older 2G and 3G networks. So you can take those control planes, you can put them on AWS, you can run that network there. And now your transmission from your cell site and then back into your virtualized 2G and 3G core is all running on one network again.

So that's kind of an interesting use case. We see a lot of use cases, particularly since we work with AWS a lot, about data center resiliency. Those things need to be up all the time. How do we add Leo to this to make sure that we add more nines to your reliability story? And then also if you think about remote healthcare, one of the examples we heard was, look, in this country there's not enough radiologists. Radiologists are not distributed equally across the world. So they want to find out, can we do this virtually? Can we use radiologists from other countries, put an antenna at this hard to reach place, and now they have good enough connectivity? They can talk to doctors and healthcare experts in other places, so you can change medical outcomes through connectivity.

So if we take a look at a couple of these examples, these start to get a little bit more meaty. So this is an example of what we call the turbofan demo that we're running on our briefing center, and this is a sort of a physical manifestation of the full Purdue model.

We've got full IT OT separation that's going into a Cloud WAN network. The idea is that most of the time for these types of workloads, you run those locally and you try to do that as best as you can. In some cases, that local site may go down, and you've got a site resiliency quantity of one. So if you start to change this SCADA network and you start putting some of the components in the cloud, first, now you can start using that SCADA data in the cloud for interesting data lakes and analysis and other things. Second, you can start distributing that across the world.

This model is to have a backup for all your SCADA traffic, keep it separated, and move it to the cloud if you need to. But now that you've got resources that are running your local site remotely, you need to make sure you get to the cloud extremely reliably. So here you use whatever connections you can and you add Leo as your resilient backup. We can connect directly into your private network, and it all again has some integration there.

If we take a look at another example, this is the gold standard for Direct Connect. So if you want four nines of SLA offered from Direct Connect, this is what you've got to do: two ports at two locations each. When I see customers do this, usually large mature customers get there and they can do this, but you're looking at a couple hundred thousand dollars usually, depending upon routers, project managers, and cross-connect costs and everything else. So not everyone gets there. This is the three nines version of that. It's a little bit easier to get to but still can be challenging for folks, particularly as you're just getting started.

One of the things we're working with customers on is this: if you're trying to do a migration and you're trying to get into AWS, and your end goal is getting to the right inside that VPC, we can do this faster. Again, we can ship an antenna faster than project managers can figure out where a cable goes. So you can use this for day one connectivity. Your application team and your developers are happy because they can get to that VPC where they need to send their traffic.

And then you continue to do the work and you add the Direct Connect location so that port shows up great. And so now if that router has maintenance and goes down, you've got a backup path through Leo. And this continues to work even as you add more resiliency. So if you get to the three nines or the four nines architecture, then you're still adding more resiliency through Leo.

Transformation and Future Applications: Machine Learning, Mobility, and Enterprise Preview Signup

So then we get into what I call transformation because typically, if you think about people processing things, this is where you start changing the people and the processes. We're still on enterprise preview, so it's still early days, but these are some of the use cases we're hearing from customers where they think there's a big change to start changing what they're doing. If you take a look at some of these industries—manufacturing, energy, agriculture—they've been doing this for sometimes centuries out in the middle of nowhere with no connectivity. The amount of people running around with pencils and doing it in a very reliable way exists. And you go, okay, well what if we give you gigabit? What would you do with that? And they're like, well, it would take us a long time to figure that out, but it seems like we can do a lot of things.

If you take a look at automation, so if you take maybe manufacturing, if there's a certain part of the manufacturing floor that's dedicated to running a local data center, and if you have good enough connectivity, and if you can move that data center outside of that facility or you just take the non-real-time stuff out, you get floor space back. But now you can start running more interesting applications that maybe require more computing or are tied into central systems. This can be things like process automation or there's a lot of very interesting things like what Amazon does in our manufacturing and the way that we do logistics. But it takes time to get there, and it takes connectivity.

There's also then this question of where do you put the computing. So if you have strong connectivity to the outside world, do you need a local data center? We've talked with customers that go, we have a data center here just because the fiber to this area isn't very reliable, maybe it's an island or something else, so we had to put a local data center there. If now you have strong connectivity, you can go, okay, well I can use that connectivity maybe to put an Outpost there. I can put an Outpost there, I can run the local computing, and it has enough link back to the cloud it can work. But you might go, if I have good enough connectivity, let's just run that stuff on the cloud. I don't want to run the computing there. So we're having conversations like that with customers.

We also see some very interesting machine learning cases where the data and operations in remote locations are valuable. We'll talk about that in more detail, but we also see opportunities with in-flight entertainment and things that move. What can we do now, especially if we add cloud applications to it?

This example is interesting. I've had a chance to go out on site with a handful of customers to really deeply learn about their use cases. One of the consistent things we see is that there's always someone there who deeply understands how everything works. There's a guy who can put his hand on the motor and tell if the bearings are going bad. There's a guy who knows how the fish swim and can tell if they're hungry or going to breed based on their behavior. There's a guy who can tell you that when the valve pump makes a certain sound, it's because someone's abusing the system.

Sometimes all these experts want is a camera, a microphone, or an infrared heat sensor. If they just want the microphone and can send all that data to the cloud, we could do this stuff. The idea is that you're not taking this person away, but if you can send this data, you can get this data off of just being maybe not even monitored at all. You can start sending that through machine learning systems and start to do this stuff at scale. You're not talking about huge amounts of bandwidth sometimes, but you are talking about changing the way that we're operating at that site, which they may have been doing for a while.

Then you get into the mobility use cases. We have an announcement we made with JetBlue, for example. How do we change their passenger experience? What's important is that no one likes to pay a lot of money for flights. So how do you increase the efficiency of these things? How do you track the internals of the airplanes? If you look at land mobility, like mining, you would really like for these big expensive trucks that can cause safety issues to be automated so you don't have folks driving those things.

But then how do you get there? You need monitoring, you need video, you need multiple layers of connectivity to make sure this is going to be safe. Once you get there, it's a lot more productive. I also found out that people run data centers on boats. I personally wouldn't want to run a data center on top of salt water, but there are people who need computing and things out in the ocean. There's also a lot of things that can happen there. So how do you get your IoT data and your logistics data and all of that out? There are a lot of interesting things that we're going to be working on here.

We're also working with Hunt Energy. A lot of the people we work with right now are utility providers. You're talking about a business that's been around for a long time and has a low appetite for risk. They're a good use case because we're working on use cases like this. How would we change the way that we're doing power distribution locally and even across the world? It's something that's extremely regulated. If we want to do all this cool stuff on the right with AWS, we want to make sure we can do that reliably and simply.

This looks sort of like the turbofan demo that we looked at where we can do HMI, we can do separation, we can put the firewalls in, we can pipe that in over into AWS. We have separate VPCs for operations and analytics. That's going into SageMaker and S3 for analysis, and then all your third parties that need to operate these things can operate in different accounts through Transit Gateway and we get that scale here. There are folks who really want to change, and that change is really hard to do. We're working with them.

To wrap this up, first, thanks for coming out. Second, if I have anything to share with you, it's that there are a lot of ways to use this. Hopefully we've shown you some examples. You're all now satellite experts, so you can tell your friends. There are a lot of use cases that you can do. You can start simply. You don't have to go into the hard stuff first, but we can also talk about that if you want to. There's a continuum you can go through.

We're in enterprise preview, so you can go and sign up for the interest list. We also have a booth downstairs if you go down to the Venetian by the bus. You can come talk to our teams, sign up for the interest list, and those kinds of things. Thank you for coming out, and I'll be up here for questions. I also provide feedback. I read all that stuff, so if you want to see some more interesting stuff in the next presentation, just let me know.

---

; This article is entirely auto-generated using Amazon Bedrock.