When we discuss AWS services, we need to start at the top with regions and availability zones. They have big implications for all of our services. At the time of writing this book, AWS listed 18 Regions, 55 Availability Zones (AZ), and one local region around the world. In the words of AWS Global Infrastructure, (https://aws.amazon.com/about-aws/global-infrastructure/): 

Some of the services AWS offer are global, but most of the services are region-based. What this means for us is that we should build our infrastructure in a region that is closest to our intended users. This will reduce the latency of the service to our customer. If our users are in the United States east coast, we should pick us-east-1 (N. Virginia) or us-east-2 (Ohio) as our region if the service is regional-based:

 

Not all regions are available to all users, for example, GovCloud and the China region are not available to users in the United States by default. You can list the regions available to you via aws ec2 describe-regions:

$ aws ec2 describe-regions
{
    "Regions": [
        {
            "RegionName": "ap-south-1",
            "Endpoint": "ec2.ap-south-1.amazonaws.com"
        },
        {
            "RegionName": "eu-west-3",
            "Endpoint": "ec2.eu-west-3.amazonaws.com"
        },
...

All the regions are completely independent of one another. Most resources are not replicated across regions. If we have multiple regions, say US-East and US-West, and need redundancy between them, we will need to replicate the necessary resources ourselves. The way you choose a region is on the top right corner of the console: 

The number behind the regions in the preceding AWS regions screenshot represents the number of AZ in each region. Each region has multiple availability zones. Each availability zone is isolated, but the AZs in a region are connected through low-latency fiber connections: 

Many of the resources we built are copied across availability zones. The concept of AZ is very important, and its constraints are important to us for the network services we will build. 

We can check the AZs in a region in AWS CLI: 

$ aws ec2 describe-availability-zones --region us-east-1
{
    "AvailabilityZones": [
        {
            "Messages": [],
            "RegionName": "us-east-1",
            "State": "available",
            "ZoneName": "us-east-1a"
        },
        {
            "Messages": [],
            "RegionName": "us-east-1",
            "State": "available",
            "ZoneName": "us-east-1b"
        },
...

Why do we care about regions and availability zones so much? As we will see in the coming few sections, the networking services are usually bound by the region and availability zones. Virtual Private Cloud (VPC), for example, needs to reside entirely in one region, and each subnet needs to reside entirely in one availability zone. On the other hand, NAT Gateway is AZ-bound, so we will need to create one per AZ if we needed redundancy. We will go over both services in more detail, but their use cases are offered here as examples of how regions and availability zones are the basis of the AWS network services offering. 

AWS Edge locations are part of the AWS CloudFront content delivery network in 59 cities across 26 countries. These edge locations are used to distribute content with low latency with a smaller footprint than the full data center Amazon builds for the region and availability zones. Sometimes, people mistook the edge locations' point-of-presence for full AWS regions. If the footprint is listed as an edge location only, the AWS services such as EC2 or S3 will not be offered. We will revisit the edge location in the AWS CloudFront section. 

AWS Transit Centers is one of the least documented aspects of AWS networks. It was mentioned in James Hamilton's 2014 AWS re:Invent keynote (https://www.youtube.com/watch?v=JIQETrFC_SQ) as the aggregation points for different AZs in the region. To be fair, we do not know if the transit center still exists and functions the same way after all these years. However, it is fair to make an educated guess about the placement of the transit center and its correlation about the AWS Direct Connect service that we will look at later in this chapter.

It is impossible to cover all of the services related to AWS in one chapter. There are some relevant services not directly related to networking that we do not have the space to cover, but we should be familiar with: 

• The Identify and Access Management (IAM) service, https://aws.amazon.com/iam/, is the service that enables us to manage access to AWS services and resources securely.
• Amazon Resource Names (ARNs), https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html, uniquely identify AWS resources across all of AWS. This resource name is important when we need to identify a service, such as DynamoDB and API Gateway, that needs access to our VPC resources. 
• Amazon Elastic Compute Cloud (EC2), https://aws.amazon.com/ec2/, is the service that enables us to obtain and provision compute capacities, such as Linux and Windows instances, via AWS interfaces. We will use EC2 instances throughout this chapter in our examples. 

This was a relatively long introduction to the AWS network overview, but an important one. These concepts and terms will be referred to in the rest of the chapters in this book. In the upcoming section, we will take a look at the most import concept (in my opinion) for AWS networking: the virtual private cloud.