- [Alana] For our employee directory application, we'll be using photos of each of our employees. We have to store them somewhere safe. Currently, the only copy of these photos are saved on my laptop right now. But if my laptop breaks, then 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, unbeknownst to me, I'm storing it in a data center somewhere and servers inside that data center. But if a natural disaster happens or a fire or let's say a giant lizard comes out of nowhere, stomps on the data center, then what do we do? Luckily, AWS has planned for this event, and many others, including natural disasters and other unavoidable accidents. The way they planned for it is through redundancy. AWS clusters data centers together around the world. So here, AWS might have a second data center connected to the first data center 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 giant lizards might also extend to impacting an entire AZ, but AWS has planned for that too - - with 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 picking 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 N. Virginia Region. And remember, AWS is not going to name a region in Germany after Northern Virginia. 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 even 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 the 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 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 if all 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 creates slower load times. 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'll talk about. The pricing can vary from region to region, so it may be that some regions like the Sao Paolo 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'll want to consider is the services you want to use. Often when we create new services or new features in AWS, we don't roll out 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'll 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 availability zones and availability zones inside regions. And how do you choose a region? By looking at compliance, latency, pricing, and service availability.