Introduction:

Amazon Web Services is a global public cloud provider, and as such, it has to have a global network
of infrastructure to run and manage its many growing cloud services that support customers around
the world. In this post, we’ll take a look at the components that make up the AWS Global
Infrastructure.
The components are:
• Availability Zones (AZs)
• Regions
• Edge Locations
• Regional Edge Caches
• Local Zones
• Wavelength Zones
• Outposts

1. Availability Zones(AZs):

Availability Zones and Regions are closely related. AZs are essentially the physical data centers of
AWS. This is where the actual compute, storage, network, and database resources are hosted that we
as consumers provision within our Virtual Private Clouds (VPCs). A common misconception is that a
single availability zone is equal to a single data center. This is not the case. In fact, it’s likely that
multiple data centers located close together form a single availability zone.
Each AZ will always have at least one other AZ that is geographically located within the same area,
usually a city, linked by highly resilient and very low latency private fiber-optic connections. However,
each AZ will be isolated from the others using separate power and network connectivity that
minimizes impact to other AZs should a single AZ fail.
These low latency links between AZs are used by many AWS services to replicate data for high
availability and resilience purposes. For example, when RDS (Relational Database Service) is
configured for ‘Multi-AZ’ deployments, AWS will use synchronous replication between its primary and
secondary database and asynchronous replication for any read replicas that have been created.

2. Regions:

A Region is a collection of availability zones that are geographically located close to
one another. This is generally indicated by AZs within the same city. AWS has deployed them across the
globe to allow its worldwide customer base to take advantage of low-latency connections. Every
Region will act independently of the others, and each will contain at least two Availability Zones.
For example, if an organization based in London were serving customers throughout Europe, there
would be no logical sense in deploying services in the Sydney Region simply due to the latency response.
Having global regions also allows for compliance with regulations, laws, and governance relating to
data storage (at rest and in transit). For example, you may be required to keep all data within a
specific location, such as Europe. Having multiple regions within this location allows an organization
to meet this requirement.

Region and Availability Zone Naming Conventions

AWS has a specific naming convention for both Regions and Availability Zones.
Depending on where you are viewing and using the Region name, it can be represented as two
different names for the same Region.
Regions have both a ‘friendly’ name, indicating a location that can be viewed within the Management
Console and a Code Name that is used when referencing regions programmatically, for example
when using the AWS CLI.

Edge Locations

Edge Locations are AWS sites deployed in major cities and highly populated areas across the globe.
They far outnumber the number of availability zones available.
While Edge Locations are not used to deploy your main infrastructures such as EC2 instances, EBS
storage, VPCs, or RDS resources like AZs, they are used by AWS services such as AWS CloudFront
and AWS Lambda@Edge (currently in Preview) to cache data and reduce latency for end-user access
by using the Edge Locations as a global Content Delivery Network (CDN).
As a result, Edge Locations are primarily used by end users who are accessing and using your
services.
For example, you may have your website hosted on EC2 instances and S3 (your origin) within the Ohio
region with a configured CloudFront distribution associated. When a user accesses your website
from Europe, they would be re-directed to their closest Edge Location (in Europe) where cached data
could be read on your website, significantly reducing latency.