What are Regions, Availability Zones and Local Zones ?

Hey everyone, so far we have discussed about some AWS concepts with real time use cases. If anyone visiting my profile for the first time, I am suggesting you to go through my previous articles to get clear understanding about AWS topics which I have covered so far.

Now, I think most of you have clear idea about, how an application runs in AWS and how it will utilizes the AWS services like their servers, databases, storage etc. But in reality you might not be aware of where EC2 instances or any other services are deployed or how the traffic to our application is maintaining or how it is halting our application from failover. So like that there are so many queries that comes up into our mind. To understand about all of this doubts, let’s discuss about regions, availability zones and local zones.

About Regions, Availability Zones and Local Zones ?

To serve any web application over the internet, we need to host our EC2 instance in a single location or in multiple locations depends on the requirement that we have. Here the location is nothing but a Region.

Each region is a separate geographical area and each region has multiple isolated locations known as Availability Zones.

Local Zones provide you the ability to place resources, such as compute and storage, in multiple locations closer to your end users. But we can’t replicate these resources across regions unless we specifically choose to do so.

Each region is independent of each other but the Availability Zones in each region are isolated and are connected through low-latency links.

A Local zone is an AWS infrastructure deployment where we can place services close to our end users. A Local Zone is an extension of a Region that is in a different location from your Region. It provides a high-bandwidth backbone to the AWS infrastructure and is ideal for latency-sensitive applications, for example machine learning.

Image source: AWS docs

About Regions

Regions have the greatest possible fault tolerance and stability because they are isolated from each other regions. Because they are isolated they have their own resources and we can’t replicate their resources in other regions automatically.

NOTE: If we want to transfer data over regions then definitely the charges will be applicable.

If you want to run your application in a single country then we should have to host our EC2 instance in a single region and if we want to run that application globally then we should have to host our EC2 instance across multiple regions.

We know that AWS is fully managed service so once we deployed our application in any region then we need to be worry about our application security or anything because it is fully AWS managed service.

According to the information from amazon, we have 23 regions around the world.

In regions, we cluster data centers.

To know more about regions, click here.

About Availability Zones

As I said that in each region we cluster data centers, where each group of logical data centers is an Availability Zone.

If we distribute instances across multiple Availability Zone’s and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests.

Elastic IP address which is an alternative concept of instance failure handling. If the instance in one Availability Zone fails then automatically it will remap the address to an instance in another Availability Zone.

An Availability Zone is represented by a Region code followed by a letter identifier. For eg: us-east-1a.

To ensure that resources are distributed across the Availability Zones for a Region, we independently map Availability Zones to names for each AWS account. For example, the Availability Zone us-east-1a for your AWS account might not be the same location as us-east-1a for another AWS account.

Each AZ has it’s own unique and consistent identifier ID, which will be used to coordinate Availability Zones across accounts. For eg: use1-az1 is an unique id of us-east-1a AZ.

Viewing AZ IDs enables you to determine the location of resources in one account relative to the resources in another account. For example, if you share a subnet in the Availability Zone with the AZ ID use-az2 with another account, this subnet is available to that account in the Availability Zone whose AZ ID is also use-az2. The AZ ID for each VPC and subnet is displayed in the Amazon VPC console.

There might be a restriction from AWS that, from launching an instance in a constrained Availability Zone unless you already have an instance in that Availability Zone. Eventually, we might also remove the constrained Availability Zone from the list of Availability Zones for new accounts. Therefore, your account might have a different number of available Availability Zones in a Region than another account.

According to the AWS information, the number of Availability Zones are 73.

To know more about AZ, click here.

About Local Zones

While launching an EC2 instance, when you select a subnet in local zone then local zones have their own connections to the internet and support AWS Direct Connect. So the benefit is whatever resources created in a Local Zone can serve local users with very low-latency communications.

A Local Zone is represented by a Region code followed by an identifier that indicates the location, For eg: us-west2-lax-la.

NOTE1: To use a local zone we must enable it. Next, create a subnet in the Local Zone. Finally, launch any of the following resources in the Local Zone subnet, so that your applications are closer to your end users:

• Amazon EC2 instances
• Amazon EBS volumes
• Amazon FSx file servers
• Application Load Balancer
• Dedicated Hosts

NOTE2: Local zones are not available in every region. For information about the Regions that support Local Zones, click here.

We also have a new concept called Regions and endpoints. When we work with an instance using the command line interface and API then we use this regions and endpoints. For more information, click here.

NOTE: Some AWS resources might not be available in all Regions, Availability Zones, and Local Zones. Ensure that you can create the resources that you need in the desired Regions or Availability Zones before launching an instance in a specific Availability Zone.

We have a new concept called Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations.

Is it possible to migrate an instance to another Availability Zone ?

Yes, it is possible. We can migrate an instance from one Availability Zone to another Availability Zone. For example, let’s say you are trying to modify the instance type of your instance and we can’t launch an instance of the new instance type in the current Availability Zone. In this case, you can migrate the instance to an Availability Zone where we are able to launch an instance of that instance type.

The migration process involves:

• Creating an AMI from the original instance
• Launching an instance in the new Availability Zone
• Updating the configuration of the new instance, as shown in the following procedure

Some important points on Regions, Availability Zones and Local Zones

1. When you launch an instance, select a Region that puts your instances closer to your customers.
2. Launch your instances across multiple Availability Zones to protect your applications from the failure of a single location.
3. The benefit of launching an instance in a Local Zone is that you can run latency-sensitive applications close to your end users.
4. While launching an instance in a region and if we did not specify any Availability Zone or Local Zone then by default then select an Availability Zone.
5. Based on the system health and available capacity, we can determine the best Availability Zone.(While launching an instance, if you select default Availability Zone then AWS provides best Availability Zone)
6. If you are deploying an application in US then select near by region only, don’t select the region which is located in the UK like that.

Choosing AWS Regions and Availability Zones based on:

1. Latency and Proximity
2. Cost
3. Service catalog
4. Regulatory Compliance and Security
5. Service Level Agreements
6. The Green Factor

To understand deeply about these points, click here.

“I have covered everything about Regions, Availability Zones and Local Zones. If you clearly understand this article then you can deploy your instance using some best practices, because as we know that knowledge on something will work better than without knowledge on anything. Now you got a piece of knowledge on this topic so you can deploy an instance in an efficient way. If you are excited to know more about this or if you want to run your application on AWS then feel free to reach us at any point of time or do comment here. We are always ready to help you out”.

Excited to read about more AWS topics ?, then do follow me for more upcoming articles. If you like this article and if you think that this article will be helpful for you then do claps for this article.

Thank you !!!