If you are interested in AWS, you may have heard many praises for its global infrastructure. But sometimes, it can be confusing to understand the global AWS infrastructure concepts and how to apply them in your own operations. In this post, I will discuss AWS’s global infrastructure and how it may benefit you.
First, let’s imagine a situation without AWS or another cloud provider. Then, you need to build and run your own data center physically. You would rent a building for this and keep its ongoing maintenance. The whole process is tiresome, let alone its vulnerability to any disaster or risk. For example, if a natural disaster like an earthquake or a hurricane hits, you could lose all connections to your servers, making them inaccessible to your users. You can build a second data center as a solution, but this time, your expenses skyrocket with more maintenance effort to run it. Instead, you should focus on your own work that earns you money, right?
But you don’t have to do this. Instead, you can utilize AWS’s global network infrastructure. So, let’s discuss the primary components of AWS’s global infrastructure and how they work one by one.
AWS Regions & Which to Choose
AWS has various geographical regions around the world where it runs multiple data centers for you. Each AWS region is geographically separate, often in different countries, working discreetly. Besides, no data can move without your permission in the region you choose. For example, if you select the US-North Virginia region, your data stays there and can only leave that location if you grant permission.
While configuring AWS resources, you often start with selecting an AWS region to work with. However, some AWS services like AWS IAM, Amazon Route 53, and Amazon CloudFront span multiple AWS regions, and their resources are not bound to a single AWS region. But you can be in any region to configure their resources. Technically, they work from the US North Virgina (us-east-1) region, the first AWS region established historically.
About the AWS Region Codes
Each AWS region has a unique code, which you may need in AWS CLI commands or other usages related to AWS resources. This region code follows a convention. It starts with the geographical region or country code. For example, AWS regions in the US start with 'us', regions in Europe begin with 'eu', and so on.
Then comes the AWS region’s sub-division according to the region’s cardinal direction. Again, the US regions on the east coast start with 'us-east', whereas the ones on the west coast begin with 'us-west'. But there are also 'central', 'south', and 'north' regions, too. For example, 'eu-north' for northern European regions like Sweden, or 'ap-south' for ‘Asia-Pacific South’ like the AWS regions in India. It even goes more, like 'ap-southeast' for regions in Australia, Indonesia, etc.
The only number following the geographical region is given according to the order of creation, making the region code unique. For example, 'eu-west-1', the Ireland region, is the first region in the 'eu-west' (even in Europe, by the way). When AWS opened a region in London, UK, it received the region code 'eu-west-2'.
But don’t count on this region code convention. AWS assigns them themselves. Some geographical regions may not make sense to you. You can learn the region codes from this EC2 documentation for regions and zones.
Choosing the Right AWS Region
Today, there are over 30 AWS regions globally. I remember the time when there were only six or eight. (Yes, I am getting old. 😊 ) However, which one is ideal for you? I recommend asking these questions when choosing the right AWS region for your needs.
Are there any compliance reasons?
Some government regulations or specific laws may require you to run your application in a particular AWS region. For example, suppose you are in Europe, and there is a requirement binding you to keep your data there. In that case, you should deploy your applications and data to European regions such as Europe-Ireland, Europe-Frankfurt, etc.
Where are your users?
If you have no boundaries regarding compliance, you should select your AWS region according to the proximity. For example, if your traffic mainly comes from the UK, consider using the Europe-London region as the first option to provide the best user experience with the lowest latency possible.
Do you need a specific AWS service?
Sometimes, the AWS service you seek may not be in the closest AWS region to you. New AWS regions, for instance, may lack some services you need. In this case, you can choose an AWS region with the service you are looking for. But even in that case, selecting the closest AWS region offering that AWS service would be wiser for performance.
Are lower prices more crucial for you than performance?
Even if you use the same AWS services, prices may vary from region to region. So, some AWS regions may cost more than others. Therefore, you should also consider this factor when selecting your ideal AWS region. You can visit the pricing page of your AWS service to see which region provides the lowest price.
Availability Zones for Reliability, Scalability, and High Availability
Having discussed regions, let’s examine the availability zones (AZs) forming an AWS region. AZs are specific locations in the AWS regions. Each AWS region has more than two availability zones consisting of clusters of isolated data centers. For instance, the US-North Virginia region has six AZs now, whereas the Europe-Ireland region has three AZs. All these availability zones are interconnected through a physical network connection outside the Internet in the same AWS region, yet each runs independently.
The data center buildings in the AZs are secure and designed to resist natural disasters or outages. They are located separately and far from each other. So, in case of a disaster in an availability zone, the others will not be affected. If you launch your EC2 instances in at least two availability zones and one of the AZs fails, the ones in the other AZ will do fine, and your application will continue to run smoothly. Otherwise, none of your EC2 instances would be available.
Besides, running your apps in multiple AZs enables you to utilize multiple data centers, increasing your ability to scale when needed. Availability zones are physical data centers. So, they have limited capacity. By using multiple AZs, you can claim more capacity when needed, increasing your flexibility and scalability.
But please keep the latency in mind if you run a mission-critical application. If you place your EC2 instances in the same availability zone, you get the minimum latency possible because they will be in the same data center. But then, you will lose the availability benefits a multi-AZ architecture provides. So, you should consider this wisely in deciding which outcome is crucial for you: latency or availability.
About the Availability Zone Codes
Like an AWS region, each availability zone also has a unique zone code. It is constructed by appending lowercase letters to the region code beginning with 'a'. For example, six AZs in the US North Virginia, 'us-east-1' region, are named 'us-east-1a', 'us-east-1b', 'us-east-1c', 'us-east-1d', 'us-east-1e', and 'us-east-1f' respectively. Similarly, an AWS region with three AZs has availability zone codes constructed by appending letters from 'a' to 'c' to its region code.
However, the mapping of these zone codes to physical AZs may change in each AWS account. In other words, your account’s 'eu-west-1a' zone may correspond to another physical AZ in the 'eu-west-1' region than mine. But they stay the same within the AWS account.
Edge Locations for Faster Content Delivery
Your users may be located far from the AWS region you use and may be complaining about latency. In that case, AWS edge locations may help you with faster content delivery.
AWS edge locations are a network of data centers where data files are cached by a content delivery network (CDN) service called AWS CloudFront. They are separate from regions, spread worldwide, and are high in number. So, they are physically much closer to users. That way, you can ensure faster communication and quick content delivery for your users no matter where they are. But please keep in mind that the first user closer to an edge location doesn’t benefit from caching. Subsequent users get the same cached content from that edge location.
Edge locations are specifically used with AWS CloudFront. So, let’s also briefly discuss CloudFront, too.
Speed Up Your Content Delivery with AWS CloudFront
AWS CloudFront is a service that caches copies of the static and dynamic content in the edge locations. It is primarily helpful for massive static data files like videos, images, etc. When you use CloudFront, user requests are directly routed to the nearest edge location. If the content is already cached in the edge location, it is directly delivered to the end user from there by CloudFront. Otherwise, CloudFront retrieves it from the origin server, working as the source of the content, and caches it in the edge location for subsequent requests. Then, as subsequent users come with the same request, the content is served from the cache automatically.
For example, let’s assume you are in the Europe-Ireland region, but a significant portion of requests to your website come from the US. Without CloudFront, a user request to view an image or see a page must pass from one network to another on the Internet until it arrives at the origin server. This can cause latency problems and impact the performance.
However, if you use CloudFront for the same case, the request will be routed to the nearest edge location to the user. The edge location would utilize the inner AWS network to access the origin server, avoiding unnecessary travel on the Internet in between. Besides, whenever you get requests closer to that edge location, the data will be served automatically from the cache without traveling to the origin server each time.
Edge locations can also run the DNS probing requests to Route 53, AWS’s domain name service (DNS). So users get the DNS responses more quickly. However, there is much more to say about Route 53, as it is a vast topic outside the subjects of this post.
AWS Outposts: Get AWS On-Premises
Some situations require you to stay in your building and use your own data center. But you can still use AWS services even in that case. AWS Outposts allows you to install AWS operational infrastructure on your site. This solves the potential latency problems and provides supported AWS services you may need on-premises.
Use Multiple AWS Regions Easily with AWS CloudFormation or AWS CDK
Provisioning your AWS resources as code not only avoids human errors but also allows you to easily replicate your AWS architecture in another AWS region. Using AWS CloudFormation or AWS CDK, whichever tool you choose, you can define your AWS resources as code to automate the creation of your AWS resources in an AWS region.
Do you want to test an AWS region before selecting one for production? Or do you want to replicate your AWS architecture in another region to serve new users? Whatever reason you may have, in minutes, you can create the same architecture in another AWS region by creating the same stacks from your CloudFormation templates or deploying your CDK app there.
Do you want to discard the resources in an AWS region afterward? Deleting the stacks you created in that AWS region will be sufficient to remove all AWS resources managed by them. Because AWS regions are discreet structures, a stack creation, update, or deletion in a region doesn’t affect others. Of course, this is only valid for regional resources, not global ones, such as IAM roles or users.
Would you like to learn infrastructure as code on AWS?
AWS CloudFormation allows you to write your infrastructure code in YAML or JSON. Whereas AWS CDK enables you to use common programming languages, such as Python, while still deploying CloudFormation stacks. I discussed the differences and similarities between AWS CDK and AWS CloudFormation in a previous post.
You can also learn AWS CloudFormation and AWS CDK via our highly-rated online courses on Udemy. Please check our Courses page to join them with discounts special to this blog.
Conclusion
AWS global infrastructure is an ecosystem with logically distributed locations and data centers around the world. It helps you improve your applications’ performance and speed and ensures fault isolation for your users regardless of their location. In this post, I tried to give an overview of AWS’s global infrastructure components so that you can grasp them more easily and benefit from them more.
Thanks for reading & see you in my next post!
References
