I’m going to cover the AWS global infrastructure, which is the name that AWS assigns to the various infrastructure, including the data centers, availability zones, and other equipment they have worldwide. Let’s take a closer look at how it’s composed. Firstly, we have regions, which are separate physical locations around the world. There are numerous regions globally, and the list continues to expand. Within each region, we have multiple availability zones, typically at least three, and sometimes more.
For example, use one, there are six availability zones at the time of this recording. All of those numbers can always change. Now, an availability zone is one or more physical data centers. So just consider it to be a separate data center. That means that you can spread your resources across availability zones and there’s less correlation in terms of failure. So if one data center fails for some reason, then the other ones shouldn’t. You can spread your resources and make sure that you always have your applications running when you need them. Now, all of the regions are connected around the world by the AWS global network. That’s a network that’s managed by AWS. They make sure that there’s plenty of bandwidth and they manage the latency. So you get great performance when you’re moving data between AWS regions.
Now, within each region, there is plenty of networking capability that is always redundant. What else is there besides regions? We also have availability zones within the availability zones, where we create subnets that can be public or private, and that’s where we launch our resources. There are also other ways to leverage AWS services. For example, if you have a corporate data center, you can actually get a piece of hardware that comes into your data center called AWS Outposts. An AWS Outpost supports a subset of services available from AWS, so not everything, but things like EC2 can be run on-premises and have connectivity back to an AWS region. Next, we have something called a local zone, which is similar to availability zones and is usually in metropolitan areas. The idea is to get your resources a bit closer to where you are. If there is a local zone closer to your office or data center than the actual region data centers themselves, that can be a good place to launch your resources, even if you have to pay a bit more for it.
But if you want lower latency, then we have wavelength zones. These are for 5G. So if you, for example, have mobile applications and you want to make those available over the 5G network, you can deploy your applications in a wavelength zone. And again, it’s about lowering the latency, reducing the delay between the server or the mobile application in this case, and the actual service that’s being delivered from the data center. Wavelength zones have connectivity back to the AWS region, so they are about enhancing performance for your applications and connecting them to your end users or to the servers in your data center. Now let’s break down a region to provide more detail about the level of redundancy here. Here I’m just showing two availability zones, but usually there are more. Each availability zone can be used to create subnets. A subnet is simply an IP networking space. You can create public subnets with public accessibility, meaning your applications like your web servers can be available on the internet. Alternatively, you can create private subnets that have no direct connectivity from the outside world. Each availability zone has redundant power sources, so you are not relying on just one power source. If one fails, the other one should take over the load.
We also have redundant networking both within the availability zone and between availability zones. Now availability zones have low latency between them. So the network performance between availability zones and within them is very good. And that’s because the availability zones are relatively close together. AWS doesn’t specify exactly how close, but they’re relatively close within a metropolitan area. On the other hand, the actual regions are fairly distant from each other. So it makes sense to keep your applications highly available within a region so that you’ve got great performance and you can fail over very quickly between one availability zone and another. However, if for disaster recovery purposes, you need to have a copy of your applications more geographically distant, then that’s where you would put them into a separate region. So now we can deploy our resources across our different subnets within different availability zones. And that’s how we get high availability and we’ll see how we can then connect to them a bit later on. Another component of the AWS global infrastructure is Amazon CloudFront. CloudFront is a content delivery network. What that simply means is that content, for example, videos or images, can be cached at different places around the world. And that means that users in those different places in the world are able to access those resources with lower latency. Again, it’s about network performance. It’s about the performance of the application.
If you want to watch a video from Australia, you don’t want that video to be physically located in the US because that’s a long way away and the performance won’t be good. So CloudFront ensures that it’s cached in different parts of the world so that there should be a copy of that video closer to you. Now with AWS, we can easily deploy services globally, which is an absolute game-changer with the cloud. In the past, when I had to deploy resources into different data centers in different parts of the world, it was extremely difficult and expensive. Now with the management console, the CLI, or the API, you can deploy resources all over the world. For example, here we’re launching virtual servers and databases in different parts of the world. In some cases, you might set them up to be redundant and automatically copy data between them, synchronizing that data very easily to set up in the cloud, very difficult to do it outside of the cloud when you’re managing all that infrastructure yourself.
