Following on from our post on the AWS Cloud Practitioner Essentials Compute topic, in this post we’ll look at module 3 which concerns itself with the global infrastructure AWS has in place to deliver cloud services and the reliability built in using the various regions and availability zones to provide both redundancy and lower latency.
AWS Regions
The problem facing any business running a data center is how do you keep access to the data and applications you have running highly available. Building a second data center can be a solution, however if it’s located in the same geographic area as the first one, if disaster hits, like a flood, hurricane or earthquake that takes out the power to the town, city or even state that your data centers are located, your users end up losing access to your data and applications.
AWS solves this problem by building clusters of data centers in entirely different geographic locations referred to as regions.
Each region is close to population centers where the demand for cloud services exists and each region contains multiple data centers each containing the compute and storage resources to service AWS customers. Each data center in each region is connected to other regions via high speed fiber optic connections.
You get to choose the region you want to build solutions in, and unless you specifically request otherwise, all your data will remain within the data centers in a single region. This can be critical from a compliance and security perspective in some industries where the laws and regulations dictate that certain data should not move out of a specific jurisdiction.
The first decision when selecting a region is compliance. Are you subject to compliance frameworks that limit you to specific geographic regions. If you are UK based and need to keep your data onshore for compliance purposes, then you need to select eu-west-2 (London), no other AWS region meets compliance requirements.
If you are Europe based and have to keep data within European boundaries, the you can select from eu-west-1 (Ireland), eu-south-1 (Milan), eu-west-3 (Paris), eu-north-1 (Stockholm), eu-central-1 (Frankfurt).
If you are not bound by geographic compliance, there are over 27 regions and 87 availability zones to select from around the world, with each region having at least 3 separate data centers (availability zones) to leverage for redundancy and availability.
The next consideration if you are not bound by compliance is proximity. If the bulk of your users are in Australia, then using the Sydney region will provide the best latency and user experience purely down to the laws of physics and the distance data needs to travel between the servers and the users.
Then you need to consider whether the resources or features you require are available in the region you want to use. Not all regions have every resource or instance type. Newly launched regions for instance may have significantly less available AWS features than more mature regions.
For instance Amazon Braket the quantum computing platform relies on specific highly specialised hardware that only exists in a handful of regions.
Pricing is another factor when choosing a region. Due to localised cost variations like power, communications and tax laws, some regions cost more than others to run the same hardware in data centers. So some regions will cost you more to run the same instances and services.
AWS Availability Zones
AWS regions are made up of multiple availability zones. These are separate data centers or groups of data centers with high security, redundant and backup power supplies as well as redundant networking and private connectivity.
So the ideal use case for multiple AZs is to run multiple EC2 instances in separate AZs with user traffic load balanced between them. That way if one data center is taken out by a natural disaster then your application will persist due to EC2 instances being run in separate AZs. And should you have had the foresight to set up autoscaling, new EC2 instances would be spun up automatically in the working AZs to compensate for the data center that went offline.
Some AWS services are already regionally scoped, meaning they automatically run across multiple AZs without input from you. Elastic Load Balancers for instance will automatically run across multiple AZs
AWS Edge Locations
In addition to regions and AZs, AWS operates a vast network of edge locations that have the ability to cache and replicate data closer to the users accessing it. AWS’s content delivery platform is Amazon Cloudfront. Using cloudfront as an access point to your data means users will be accessing your data that has been replicated to an edge location closest to them, thus providing lower latency and higher availability.
Amazon Route53 also operates across the edge network, allowing your application and web property DNS to take users to the closest edge location to retrieve data
Provisioning AWS Resources
When you first start out you will probably start to create AWS resource instances like EC2 compute instances in a VPC using the AWS management console.
Here you can navigate to the desired resource console and provision resources using the web interface that steps you through the options and settings for each resource.
Once you reach the production stage of your AWS journey, creating resources manually will become tedious and potentially error prone as you try to accurately duplicate resources. The same API that is used by the AWS management console is also available for you to use.
You can script resource creation and use the AWS CLI to create resources in an accurate and predictable manner.
You can also use various software platforms with the AWS SDK to programmatically deploy and manipulate AWS resources as well as AWS Cloudformation which allows you to create JSON or YAML templates to deploy resources in a repeatable fashion.
AWS Elastic Beanstalk is another service to automate the process of deploying EC2 instances and associated services for your application. Using Elastic Beanstalk, you supply the service your application code and desired configurations and Elastic Beanstalk will create all the required resources, scalers, load balancers required by the application automatically. Elastic beanstalk configurations can then be saved and reused to replicate or regenerate virtual networks when needed.
Diagramming AWS Regions and Availability Zones
When you connect your AWS account(s) to hava.io, diagrams will be generated for every VPC discovered in the account.
The diagram will be laid out in columns, with each column representing an availability zone.
Detailed on the above VPC diagram you can see the Region where the VPC was built in the attribute pane to the right hand side of the diagram, in this case it was us-east-1.
On the diagram itself, there are 2 columns highlighted in light green and light blue which are the availability zones. The left hand side green column is the us-east-1d AZ and the right hand blue column is us-east-1c.
Immediately we can see what AZs are in use and what regions they reside in and we can also see that our database only exists in us-west-2c, so if that AZ goes offline, so does our application. Visually presenting virtual networks like this allows you to understand exactly what is running where and also the implications of what would happen if an individual AWS AZ should go offline due to a natural disaster. You can see at a glance whether your network has been engineered to survive a zone outage.
Outliers are also easier to spot on a diagram than in the AWS management console. There could be individual resources showing up that make no sense, or you might see an entire environment show up in your Hava environment console that shouldn't be there. Maybe an old dev environment or a staging environment that should have been shutdown a long time ago, but is still running.
Using Hava you will be able to see exactly where you have resources running within the AWS global infrastructure without having to draw a single icon. Your diagrams will also remain up to date automatically, so they are ready for you to view whenever you like.
So that's a run down of the AWS Cloud Practitioner Essentials Global Infrastructure and Reliability topic.
In the next post in the series, we will take a look at AWS networking.
If you are using AWS, GCP or Azure to build cloud solutions but are not leveraging Hava to generate and auto update your network documentation, you can take a free 14 day trial of the fully featured teams plan using the button below.
At the end of the trial, you can select the plan that best suits your needs, or you can continue using Hava for free with a single cloud account.
