Where the cloud lives

Regions

An AWS Region is a separate geographic area, such as us-east-1 (N. Virginia) or eu-west-1 (Ireland). Each Region is isolated from the others, and your data stays in the Region you choose unless you move it. You pick a Region based on four things: compliance and data sovereignty (laws about where data must live), latency (closeness to your users), which services are available there, and price, which can differ by Region.

Availability Zones

Each Region has multiple Availability Zones (AZs). An AZ is one or more separate data centers with their own redundant power, networking and connectivity. AZs in a Region are physically apart, far enough that a flood or fire in one shouldn't hit another, and linked by fast, private, low-latency network links. Key exam fact: AZs don't share single points of failure.

Dev: A Region is a city. AZs are separate kennels across town, each with its own power and water.

Edge locations, Local Zones and Outposts

Edge locations are sites in many more cities than there are Regions. They serve content and Domain Name System (DNS) answers close to users, for services like Amazon CloudFront and Amazon Route 53. AWS Local Zones put selected AWS services closer to large cities for very low latency. AWS Outposts brings AWS-built hardware into your own building for workloads that must stay on premises.

Exam tip Relationship: a Region contains multiple AZs; each AZ contains one or more data centers; edge locations sit outside Regions, near users.

High availability with multiple AZs

To make the shop highly available, run it in at least two AZs. Put web servers in each, with a load balancer sending customers to the healthy ones, and run the database with a standby copy in another AZ (Amazon Relational Database Service (Amazon RDS) Multi-AZ). If one AZ has a problem, the other keeps taking orders. Remember the closet server from Day 1? This is the fix.

Exam tip Single AZ = a single point of failure. "Highly available" on the exam almost always means "spread across multiple AZs".

When to use multiple Regions

Most workloads are fine in one Region with several AZs. Use more than one Region when you need:

• Disaster recovery: a copy far away in case a whole area is hit (AWS Elastic Disaster Recovery can help)
• Business continuity: keep operating through a major regional event
• Low latency for end users on other continents
• Data sovereignty: a country's data must stay in that country

Why edge locations help

An Amazon CloudFront distribution, a content delivery network (CDN), keeps copies (caches) of product images and pages at edge locations. A shopper in Seattle gets photos from a nearby edge location instead of from Virginia. Benefits: lower latency, less load on the shop's servers, and a layer of distributed denial of service (DDoS) protection at the edge.

Rosa: So the pictures of the squeaky hedgehog load faster for my cousin in Seattle?

Dev: Exactly. The hedgehog is cached.

Console, CLI, SDKs and APIs

Every action in AWS is an application programming interface (API) call. You can make those calls several ways:

• AWS Management Console: the website. Great for learning, exploring and one-time tasks
• AWS Command Line Interface (AWS CLI): typed commands; easy to script and repeat
• AWS software development kits (SDKs): libraries that let apps call AWS in languages like Python, Java or JavaScript
• Calling the APIs directly: what all of the above do underneath

Infrastructure as code

Infrastructure as code (IaC) means describing your resources in a text file (a template) and letting a service build them. AWS CloudFormation reads a template and creates, updates or deletes the whole stack the same way every time. Templates can be reviewed, version-controlled and reused in another Region in minutes.

Exam tip Decision rule: one-time or exploratory task = console. Repeatable, consistent, many environments = IaC (CloudFormation) or scripts with the CLI/SDK.

One-time operations or repeatable processes?

Ask: will we do this again? A one-time look at a bill or a quick test is fine in the console. Anything you repeat (new environments, recovery after a failure, the same setup in another Region) should be a repeatable process: a script or a template. Repeatable means fewer mistakes, faster recovery and a record of exactly what was built.

Dev: If you did it twice by hand, the third time it's a template.

Cloud, hybrid, on-premises

Three deployment models. Cloud (cloud-native, all-in): everything runs in the cloud. Hybrid: some systems stay on premises and connect to cloud resources, like Kibble & Co. keeping Rosa's label server in the warehouse while the shop runs in AWS. On-premises (sometimes called private cloud): everything runs in your own data center, perhaps with cloud-style virtualization and automation tools.

Exam tip Some systems on site + some in AWS, connected = hybrid. AWS Outposts and AWS Storage Gateway are hybrid tools.

Tools for operating what you built

Once things run, a few services help operate them.

• AWS Systems Manager: see and manage your servers at scale (patching, running commands, inventory)
• AWS Service Catalog: a menu of approved, preconfigured products teams can launch themselves
• Service Quotas: view and request increases to limits on resources per account and Region
• AWS Elastic Beanstalk: upload code and let AWS provision the servers, load balancing and scaling (more next chapter)

Service models

How much of the stack you manage depends on the model:

• IaaS (infrastructure as a service): you get virtual servers, storage and networks and manage the OS up (Amazon EC2)
• PaaS (platform as a service): you deploy code; the platform runs it (AWS Elastic Beanstalk)
• SaaS (software as a service): a finished application you just use, such as web email or an online office suite
• Serverless: no servers to manage at all, pay per request (AWS Lambda)

Deployment models

Cloud (all in AWS), hybrid (some on-premises, connected to AWS), on-premises / private cloud (in your own data center, possibly with AWS hardware like AWS Outposts).

The ways to use AWS

Everything in AWS is an API; the tools are different front ends to it.

• AWS Management Console: web interface. Best for learning, one-off tasks and looking around
• AWS CLI: commands in a terminal. Best for scripts and repeatable admin tasks
• AWS SDKs: libraries for Python, Java, JavaScript and more. Best when your application calls AWS
• Infrastructure as code (IaC): AWS CloudFormation templates (or the AWS CDK) describe whole environments. Best for repeatable, version-controlled deployments
• AWS CloudShell: a browser terminal with the CLI already set up

Choosing

Repeatable and consistent across many environments = IaC. Automating from an app = SDK. Quick scripted task = CLI. Exploring or a single change = Console.

Three models

Where the workloads physically run:

• Cloud (cloud-native / all-in): everything runs in AWS
• Hybrid: on-premises systems connected to AWS (for example over AWS Site-to-Site VPN or AWS Direct Connect), common during migrations or when some systems must stay
• On-premises (private cloud): your own data center; AWS can extend into it with AWS Outposts (AWS racks in your building)

Exam clues

'Keep some workloads on-premises for latency or regulation, but use AWS for the rest' = hybrid. 'Run AWS services inside our own data center' = AWS Outposts.

Reasons

A Region is a separate geographic area with multiple Availability Zones. Most workloads run in one Region, but several Regions help with:

• Disaster recovery: survive the loss of a whole Region
• Latency: serve users from a Region close to them
• Data residency/compliance: keep each country's data in its own Region
• Global applications: for example DynamoDB global tables, S3 Cross-Region Replication, Route 53 routing users to the nearest Region

Things to remember

Regions are isolated: resources don't automatically copy between them, prices can differ by Region, and not every service exists in every Region.

Exam tip Choosing a Region: compliance first, then latency to users, service availability and price.

What they are

Edge locations are hundreds of small sites in cities around the world, separate from Regions. They cache and serve content close to users.

• Amazon CloudFront: content delivery network (CDN) that caches websites, images and video at the edge
• Amazon Route 53: DNS answered from edge locations
• AWS Global Accelerator: routes traffic onto the AWS network at the nearest edge for better performance
• AWS Shield / AWS WAF protection at the edge

Benefits

Lower latency for users far from your Region, less load on your origin servers, and DDoS protection at the edge.

Exam tip Global users complain the site is slow: CloudFront. Edge location ≠ Availability Zone.

The pieces

AWS's infrastructure is built in layers:

• Region: a geographic area (for example us-east-1, N. Virginia) with at least three Availability Zones
• Availability Zone (AZ): one or more data centers with independent power, cooling and networking, close enough for low latency but far enough apart to avoid shared disasters
• Edge locations: CDN and DNS points of presence in many cities
• Local Zones: AWS compute in large metro areas for single-digit-millisecond latency
• Wavelength Zones: AWS inside 5G carrier networks
• AWS Outposts: AWS racks in your own data center

High availability

Run copies of your app in at least two AZs behind a load balancer so one data center failing doesn't take you down. Use multiple Regions for disaster recovery.

Exam tip Survive a data center failure = multiple AZs. Survive a regional disaster = multiple Regions.

What they are

AWS SDKs are code libraries (Python Boto3, JavaScript, Java, .NET, Go, PHP, Ruby, C++ and more) that let your application call AWS services, for example upload a file to S3 or write an item to DynamoDB. They handle authentication (signing requests), retries and errors.

Exam tip Your app needs to call AWS = SDK. A person running commands = CLI. Building environments from templates = CloudFormation.