To understand the global infrastructure AWS, I want to begin with your fundamental business need. You have an application that you have to run for content you need stored or data you need analyzed. Basically, you have stuff that has to live and operate somewhere. Historically, businesses had to run applications in their own data centers, because they didn't have a choice. Once AWS became available, companies like yours, could now run their applications in other data centers they didn't actually own. But the conversation is so much more than that. Because I want you to understand a fundamental problem with any data center, it doesn't matter who built it or who owns it. Events can happen that could cause you to lose connection to that building. If you run your own data center, you have to figure out how to answer the question of what will you do when disaster strikes your building. You could run a second data center, but real estate prices alone could stop you, much less all the duplicate expense of hardware, employees, electricity, heating and cooling, security. Most businesses simply end up just storing backups somewhere, and then hope for the disaster to never come and hope is not a good business plan. AWS answers the question of what happens when disaster strikes by building our data centers in large groups we call regions and here's how it's designed. Throughout the globe, AWS builds regions to be closest to where the business traffic demands. Locations like Paris, Tokyo, San Paulo, Dublin, Ohio. Inside each region, we have multiple data centers that have all the compute storage and other services you need to run your applications. Each region can be connected to each other region through a high speed fiber network controlled by AWS. A truly global operation from corner to corner if you need it to be. Before we get into the architecture of how each region is built, it's important to know that you the business decision maker gets to choose which region you want to run out of. And each region is isolated from every other region. In the sense that absolutely no data goes in or out of your environment in that region, without you explicitly granting permissions for that data to be moved. This is a critical security conversation to have. For example, you might have government compliance requirements that your financial information in Frankfurt cannot leave Germany. Well, this is absolutely the way AWS operates out of the box that any data stored in the Frankfurt region never leaves the Frankfurt region. Or data in the London region never leaves London or Sydney never leaves Sydney, unless you explicitly with the right credentials and permissions request the data be exported. Regional data sovereignty is part of the critical design of AWS regions with data being subject to the local laws and statutes of the country where the region lives. So with that understanding that your data your application, lives and runs in a region, one of the first decisions you get to make is, which region do you pick? There is four business factors that go into choosing a region, number one, compliance. Before any of the other factors you must first look at your compliance requirements. Do you have requirements? Your data must live in UK boundaries. Then you should choose the London region, full stop. I mean, none of the rest of the options matter. Or, let's say you must run inside Chinese borders, well, then you should choose one of our Chinese regions. Most businesses, though, are not governed by such strict regulations. So, if you don't have a compliance or regulatory control that dictates your region, then you can look at the other factors. Number 2, proximity. How close you are to your customer base is a major factor because speed of light, still the law of the universe. If most your customers live in Singapore, consider running out of the Singapore region. You certainly can run out of Virginia. But the time it takes for the information to be sent or latency between the US and Singapore is always going to be a factor. Now we may be developing quantum computing but quantum networking still some ways away. The time it takes light to travel around the world is always a consideration. Locating close to your customer base, usually the right call. Number three, feature availability. Sometimes the closest region may not have all the AWS features you want. Here's one of the cool things about AWS. We are constantly innovating on behalf of our customers. Every year AWS releases thousands of new features and products specifically to answer customer requests and needs. But sometimes those brand new services take a lot of new physical hardware that AWS has to build out to make the service operational. And sometimes that means we have to build the service out one region at a time. So let's say your developers wanted to play with Amazon bracket, our new quantum computing platform. Well, then they have to run in the regions that already have the hardware installed, eventually, can we expect it to be in every region? Yeah, that's a good expectation. But if you want to use it today, then that might be your deciding factor. Number four, pricing. Even when the hardware is equal one region to the next, some locations are just more expensive to operate in. For example, Brazil. Now Brazil's tax structure is such that it costs AWS significantly more to operate the exact same services there than in many other countries. The exact same workload in San Paulo might be, let's say, 50% more expensive to run, then out of Oregon in the United States. Price can be determined by many factors. So AWS has very transparent granular pricing that we will continue to discuss in this class, but know that each region has a different price sheet. So if budget is your primary concern, even if your customers live in Brazil You might still want to operate in a different country again if price is your primary motivation. So four key factors to choose a region, compliance, proximity, feature availability, and pricing. When we come back, we'll look at the moving parts inside a region.
