AWS Global Infrastructure

-: For our employee directory application, we will be using photos of each of our employees. If we have only one copy of those photos and don't want to lose them, we have to store them somewhere safe. Currently, the only copy of these photos are saved on my laptop. But if my laptop breaks, what happens? No more photos. I want to make sure this doesn't happen, so I'm going to upload the photos to AWS to ensure that the copies exist even if my laptop is destroyed. This also allows me to access my photos from anywhere, my home, my phone, a plane, on a train, everywhere. When I store these photos in an AWS service, I'm storing it in a data center somewhere, on servers inside that data center. But if a natural disaster happens, such as an alien coming down from space and destroying a data center, then what do we do? Luckily, AWS has planned for this event and many others, including natural disasters and other unavoidable alien accidents. The way they plan for it is through redundancy. AWS has clusters of data centers around the world. So here AWS would have a second data center connected to the first through redundant high speed and low latency links. That way, if the first data center goes down, the second data center is still up and running. This cluster of data centers is called an Availability Zone, or AZ. An AZ consists of one or more data centers with redundant power, networking, and connectivity. Unfortunately, sometimes natural disasters like hurricanes or other disasters might also extend to impacting an entire AZ, but AWS has planned for that, too, again, using redundancy. Like data centers, AWS also clusters AZs together and also connects them with redundant high speed and low latency links. A cluster of AZs is simply called a Region. In AWS, you get to choose the location of your resources by not only picking an AZ, but also choosing a Region. Regions are generally named by location so you can easily tell where they are. For example, I could put our employee photos in a Region in Northern Virginia called the Northern Virginia Region. So knowing there are many AWS Regions around the world, how do you choose an AWS Region? As a basic rule, there are four aspects you need to consider when deciding which AWS Region to use, compliance, latency, price, and service availability. Let's start with compliance. Before any other factors, you must first look at your compliance requirements. You might find that your application, company, or country that you live in requires you to handle your data and IT resources in a certain way. Do you have a requirement that your data must live in the UK boundaries? Then you should choose the London Region, full stop. None of the rest of the factors matter. Or if you operate in Canada, then you may be required to run inside the Canada Central Region. But if you don't have a compliance or regulatory control dictating your Region, then you can look at other factors. For example, our employee photos are not restricted by regulations, so I can continue looking at the next factor, which is latency. Latency is all about how close your IT resources are to your user base. If I want every employee around the world to be able to view the employee photos quickly, then I should place the infrastructure that hosts those photos close to my employees. We are all bound by the speed of light. Applied to your business, that means that if your users live in Oregon, then it makes sense to run your application in the Oregon Region. You could run it in the Brazil Region, but the latency from Oregon to Brazil might impact your users and create a slower load time. But maybe I really want to run my application or store my employee photos in Brazil. One problem I might run into is the pricing, which is the next factor we will talk about. The pricing can vary from Region to Region, so it may be that some Regions, like the São Paulo Region, are more expensive than others due to different tax structures. So even if I wanted to store my employee photos in Brazil, it might not make sense from the latency perspective or the pricing perspective. And then finally, the fourth factor you will want to consider is the services you want to use. Often when we create new services or features in AWS, we don't roll those services to every Region we have right away. Meaning, if you want to begin using a new service on day one after it launches, then you will want to make sure it operates in the Region that you're looking at running your infrastructure in. To recap, Regions, Availability Zones, and data centers exist in a redundant, nested sort of way. There are data centers inside of Availability Zones and Availability Zones inside of Regions. And how do you choose a Region? By looking at compliance, latency, pricing, and service availability. Those are the basics, but it isn't the end of the story when it comes to AWS Global Infrastructure. We also have the global edge network, which consists of edge locations and regional edge caches. Edge locations and regional edge caches are used to cache content closer to end users, thus reducing latency. Consider this scenario. You are a company hosting a website to your users all over the world. Even though your website is being downloaded from all over, it's hosted out of an AWS Region in North America, say Ohio. Without caching, every user would need to send a request to the Ohio Region where the data is downloaded, and then the data would be returned to the user and rendered in their browser. If the user is located in the USA or nearby country, there may not be much latency in this process. However, if a user is coming from a place that is located far from the Ohio Region, then latency will be greater. Latency is a big hurdle for many use cases, including web applications. So to reduce this latency, you could use the edge locations to cache frequently accessed content. When you cache content at an edge location, a copy is hosted across the edge locations around the world. That way, when a user goes to retrieve that information, it will come from the closest edge location, which will greatly reduce the latency for that user. You can use services like Amazon CloudFront to cache content using the edge locations.