If a region is where all of the pieces and parts of your application load, some of you might be thinking that we never actually solved the problem that we presented in the last video. Let me restate the problem. You don't want to run your application in a single building because a single building can fail for any number of unavoidable reasons. You may be thinking, if my business needs to be disaster proof, then I can't run in just one location. Well, you're absolutely correct. AWS agrees with that statement and that's why our regions are not one location. To begin with, AWS has data centers, lots of data centers, all around the world, and each region is made up of multiple data centers. AWS calls a single data center or a group of data centers and availability zone, or AZ. Each availability zone is one or more discrete data centers with redundant power, networking, and connectivity. When you launch an Amazon EC2 instance, it launches a virtual machine on a physical hardware that is installed in an availability zone. This means each AWS region consists of multiple, isolated, and physically separate availability zones within a geographic region. But we don't build availability zones right next to each other because if a large-scale incident were to occur like a natural disaster, for example, you could lose connectivity to everything in that availability zone. The question, what happens in case of a disaster, matters. If you are familiar with disaster recovery planning, you might even have an idea of where we're going with this. If you only run one EC2 instance, it only runs in one building or one availability zone and a large-scale disaster occurs, will your application still be able to run and serve your business? The obvious solution to this is to run multiple EC2 instances, just like we showed in the scaling example earlier. But the main thing is, don't run them in the same building, don't even run them in the same street. Push them as far apart as you can before the speed of light tells you to stop if you still want low latency communication. Turns out that the speed of light will let us move these availability zones tens of miles apart from each other and still keep single digit millisecond latency between these availability zones. Now if a disaster strikes, your application continues just fine because this disaster only knocked over some of your capacity, not all and as we saw in the last section, you can rapidly spin up more capacity in the remaining availability zones, thus allowing your business to continue operating without interruption. As a best practice with AWS, we always recommend you run across at least two availability zones in a region. This means redundantly deploying your Infrastructure in two different AZs. But there's more to regions than just places to run EC2. Many of the AWS services run at the region level, meaning they run synchronously across multiple AZs without any additional effort on your part. Take the ELB we talked about previously. This is actually a regional construct. It runs across all availability zones, communicating with the EC2 instances that are running in a specific availability zone. Regional services are by definition, already highly available at no additional cost of effort on your part. So as you plan for high availability, any service that is listed as a regionally scope service, you already have that box checked. When we come back, let's look at going outside the regions for additional solutions.