What is cloud computing and why use it
To understand the global AWS infrastructure, let’s begin with your fundamental business need:
You have an application that you have to run, or 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.
Let’s analyze a fundamental problem with any data center, regardless of 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 data centers in large groups called Regions.
Throughout the globe, AWS builds Regions to be closest to where the business traffic demands. Locations like New York,, Paris, Tokyo, Sao Paulo, Dublin, Ohio. Inside each Region, there are 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. Now 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 permission 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. 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 are four business factors that go into choosing a Region.
Compliance.
Before any of the other factors, you must first look at your compliance requirements. Do you have a requirement your data must live in UK boundaries? Then you should choose the London Region, full stop. None of the rest of the options matter. Or let’s say you must run inside Chinese borders. Then you should choose on 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.
Proximity.
How close you are to your customer base is a major factor because of network latency. If most of your customers live in Singapore, consider running out of the Singapore Region. Now you certainly can run out of Virginia, but the time it takes for the information to be sent between the US and Singapore is always going to be a factor. Even though we may be developing quantum computing, quantum networking is still some ways away. The time it takes light to travel around the world is always a consideration. Locating close to your customer base is usually the right call.
Feature availability.
Sometimes the closest Region may not have all the AWS features you want. AWS constantly innovates. 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 AWS has to build the service out one Region at a time. So let’s say your developers wanted to play with Amazon Braket, the 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? Well, yes, that’s a good expectation, but if you wanna use it today, then that might be your deciding factor.
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 Sao Paulo might be, let’s say, 50% more expensive to run than out of Oregon in the United States. Price can be determined by many factors, so AWS has very transparent granular pricing, 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.
