Let's start by reminding ourselves of the ten AWS components that can enable highly available solutions when they're used together, and how we use each of these AWS components to increase fault tolerance and durability. These AWS services really help us as architects. So it's only fair we give them the star treatment they deserve. So to help you remember, let's count down to naming our number one high availability component. Starting at number ten with AWS Regions. AWS has 15 geographical regions including AWS GovCloud and the China region. Each region is a separate geographical area designed to be completely isolated from the the other Amazon regions. This achieves the greatest possible fault tolerance and stability. Essentially, everything you need to run a service is available in any AWS region. So chose the one closest or best network to your location. You only see the resources tied to the region that you specified. When you store data in a specific region it is not replicated outside that region unless you explicitly request AWS to do so. Which brings us nicely to candidate number nine on the high availability top ten, Availability Zones. Each region has multiple, isolated locations known as Availability Zones or AZs as we call them. AZs allow you to place instances and data in multiple locations. AZs are distinct geographical locations that are engineered to be insulated from failures in other AZs. In short, availability zones are designed for fault isolation. They are connected to multiple internet service providers and different power grids. They are interconnected using high-speed links so applications can rely on local area network connectivity for communication between availability zones within the same region. You may be responsible for selecting the availability zones where your system will reside. Systems can span multiple availability zones and you need to design your systems to survive temporary or prolonged failure of an availability zone in the case of a disaster. By placing Amazon EC2 instances in more than one AZ, an application can be protected from failure at a single location. As an architect, ideally, you want to run independent application stacks in more than one AZ so that if one zone fails, the application in the other zone can continue to run. A few design points to keep in mind when considering global versus regional in the design stage. AWS accounts are global. You can use the same AWS account in all regions. AMIs or Amazon Machine Images are regional so an AMI is tied to the region where its files are located within Amazon S3. You can copy an AMI from one region to another. Elastic IP Addresses are regional. By default, you can have five elastic IP addresses per region. Security Groups are regional. So you can have a maximum of 500 security groups per region. EBS snapshots are stored regionally. It's tied to the region and can only be used to create volumes in that region. You can, however, copy a snapshot from one region to another. EBS Volumes are tied to its Availability Zone and can be attached only to instances in that same Availability Zone. An instance is tied to the Availability Zone in which you launched it. However, do note that the instance ID is tied to the region.