Introduction to AWS IaaS Solutions

Chapter 1. Introduction to AWS

Today’s systems administrators need to acquire and strengthen their skills on public cloud platforms. Amazon Web Services (AWS) began as an infrastructure to run the Amazon.com website and, as of this writing, has since grown to be the largest public cloud provider.

AWS provides a wide variety of service offerings from Infrastructure as a Service (IaaS) through to the application and Platform as a Service (PaaS) and nearly everything in between, which offers alternatives to running infrastructure on-premises.

AWS services are available on demand throughout the world, which makes it a compelling place to run infrastructure and applications. You might already have some familiarity with AWS, which is fine; this guide is geared toward folks who are early in their AWS journey or those looking to solidify their understanding of AWS IaaS solutions for compute, block storage, and networking.

AWS Command-Line Interface Installation

You will be using the AWS command-line interface (CLI) along with the AWS console for the examples in this guide. You can find CLI installation instructions online.

In this chapter, we begin our journey by exploring the AWS public cloud platform with a focus on the IaaS features. We cover general architectural features of the AWS cloud including geographic regions and availability zones. This will give you a comprehensive understanding of the basics needed to deploy your IaaS workloads on AWS.

A full glossary of AWS terms is available in the additional resources online.

Regions

AWS infrastructure is comprised of many services available in many areas of the world known as Regions. These Regions provide geographic availability with close proximity for low-latency access. AWS also provides the GovCloud region, which is a specialty region for government agencies and provides additional compliance and security requirements.

Each Region is located within a country’s boundary to ensure protection by any regulatory requirement for geo-locality of workloads, data, and services. Some Regions might also require special access such as Asia Pacific (Osaka) due to country-specific regulations.

Edge connectivity is provided globally, which also gives service-focused access to features like the Content Delivery Network (CDN), Domain Name System (DNS) using Route 53, Identity and Access Management (IAM), and others. This ensures that you and your customers have rapid access to the resources as well as geographic availability in the case of loss of access to a particular Region.

Regions are names identified by a two-letter country code (e.g., US, EU, CA, CN), a general location (e.g., East, West, Central), and a numeric marker; for example:

• US-East (North Virginia) Region: us-east-1

• US West (Oregon) Region: us-west-2

• EU (Ireland) Region: eu -west 1

• AWS GovCloud (US): us-gov-west-1

It is helpful to know the Region names and their programmatic short name when using the AWS CLI or other systems that deploy and manage AWS infrastructure. You will see references throughout this guide for the AWS CLI and links to more resources for other configuration management and Infrastructure as Code (IaC) tools (e.g., Terraform, RackN, Chef, Puppet, Ansible).

Availability Zones

Within each of the AWS Regions are physically separated and isolated datacenters known as Availability Zones (AZs) which you can see illustrated in Figure 1-1. Each AZ has high-speed and low-latency networking within a Region and is described as being within a metropolitan distance (approximately 100 km) to provide low enough latency for replication of services and data while also providing protection against a significant business disruption such as power grid failure or some other localized outage.

Figure 1-1. Logical view of AZs within Regions

AWS does not publish the physical locations or proximity between datacenters or any technical specifications on the hardware environments. It can be possible to have a single AZ span more than one datacenter; however, there will not be two AZs sharing the same datacenter infrastructure.

Network Access for AWS Infrastructure

Administrative access to AWS is available anywhere using either the AWS console in a web browser or using the AWS CLI, which can each be used on a variety of devices. Network access for the applications and specific resources within your AWS environment is what you must design for to use the services that you create.

There are three methods that you can use to access your AWS infrastructure and services:

Internet

Open connectivity via direct network across the internet using an Internet Gateway within your AWS environment

Virtual Private Network (VPN)

Software or hardware VPN with an endpoint on-premises and continuous or on-demand tunnel access to your AWS environment using your own VPN devices

Direct Connect

Dedicated hardwire access to the AWS network which is available through networking and cloud service providers for high-speed, low-latency, and routed access directly to your AWS Region

These options are not mutually exclusive. Your requirements for access will vary from application to application and service to service. Lots of AWS services are used directly over the internet with public/private key, AWS credentials, and other access-level controls. This reduces the need for dedicated networks for many customers.

Design decisions around internet access, workload placement, and data locality are important because you might require subnet accessibility, internet gateways, IP routing, and other infrastructure configuration from Region to Region.

Direct Connect is ideal for organizations that want bidirectional direct access to network resources. You can use this for database replication services, disaster recovery, replication between on-premises datacenters and the AWS cloud, data warehouse accessibility, and much more.

Just imagine that you want to have your data on-premises but have applications running on AWS to access that data. Using direct network access, caching services, and other options now opens the door to exciting hybrid deployments for real-time applications.

Design Patterns for Availability with AWS

The best way to ensure availability is to take advantage of existing AWS services and its resilient infrastructure. Certain trade-offs must occur when you design for resiliency because of cost and performance. As we get further into this guide, we explore more of the service-specific deployment patterns.

Here are some key tips for designing for availability for core services:

Think globally, act locally

Just like the earth-friendly phrase goes, you should utilize services with global availability but be mindful of where your customers and users access the environment. Make use of CDNs, caching, and cross-Region services where possible for the best consumer experience.

Use multiple AZs

They are called “Availability Zones” for a reason. Utilize more than one AZ within your Regions for safety. Designing your network strategy must include this or else you might bump into network addressing challenges as you try to expand later.

Cross-region deployments

For broad availability, use services that can span Regions as well as the AZs within them. Treat a Region like you would a Metropolitan Area Network and build applications to be able to be run and recovered across Regions.

Back up your data and configuration

Cloud services can be distributed and have high availability, but that does not ensure the backup of resources. Backups are needed for either point-in-time recovery or complete loss recovery after a significant disruption. Even replication will replicate errors and data loss, leaving your team with only backups and snapshots as recovery options.

You will find there are fewer limitations on architecture than there are on your budget. Resiliency is available at nearly every layer of the stack provided that you can budget for it. The value of on-demand infrastructure is that you can scale as needed and design for these burst patterns.

You must design your networking strategy in advance of these bursts and expansions. Early decisions about network addressing within and across your AZs and Regions can affect growth and expansion.

AWS services have quotas and some upper-bound technical limits. For example, you can have no more than five Virtual Private Clouds (VPCs) per Region by default. You can order increases, which also increases dependencies, such as an increase to the number of internet gateways per Region. Hard limit examples include 500 security groups per VPC, and 16 security groups per network interface. All service limits and quotas are available in the AWS documentation.

Conclusion

Now that you have a good understanding of the general AWS infrastructure, we now move on to the AWS VPC environment. This is the basis of access control, networking, and network security for the AWS IaaS platform where you will be launching your compute and storage resources.