Cloud Computing and AWS Global Infrastructure

AWS Cloud & DevOps Engineering · Lesson 01 · AWS Cloud Foundations

Lesson Overview

On the Monday after TechLearningPro's enrollment week, product wanted the lesson player closer to learners in two continents, finance wanted a single invoice they could defend, and security wanted one place to say who was allowed to change production. The team already ran Docker images and a PostgreSQL enrollment store. What they did not have was a shared vocabulary for where those systems would live on AWS, which failures the platform would survive without a hero, and which duties stayed with TechLearningPro even after the bill moved to a cloud account.

That vocabulary is the subject of this lesson, and of the course it opens. Cloud computing is not a synonym for "someone else's servers." It is a model for on-demand access to shared pools of compute, storage, networking, and higher-level services, with elastic capacity, metered cost, and a shared responsibility boundary you must write down before the first production deploy. AWS Global Infrastructure is the physical and logical map of that model: Regions, Availability Zones (AZs), Local Zones, Wavelength Zones, and edge locations that terminate content and accelerate paths to the regional APIs. You will leave able to place TechLearningPro's learning platform on that map without confusing "multi-AZ" with "multi-Region," and without treating an Availability Zone as a free disaster-recovery site.

This lesson is the home for AWS Cloud & DevOps Engineering. The running system for the track is the TechLearningPro Learning Platform on AWS: learner progress APIs, the Monday completion board that leadership reads, enrollment and identity services, and the CI/CD and observability estate that keeps those APIs honest. Later lessons open that estate at the seams that matter: accounts and IAM Identity Center, IAM policies, CLI and SDK access, networking and VPC design, compute and storage, containers, serverless, IaC, and production operations. Module case studies are staff-training designs with stated assumptions. They are not disguised capacity studies or pricing quotes.

Planning assumptions used whenever this lesson quotes a shape or a cost, labeled so they are not mistaken for a live capacity plan:

• About two million active learners in a normal month, with an enrollment-week spike.
• The lesson player and progress APIs need low latency for interactive reads; the Monday board can tolerate data through the previous day.
• Primary Region for the first production landing is chosen for data residency, latency to the largest learner cohort, and service availability—not because a tutorial used us-east-1.
• Illustrative spend figures in this course are ratios for design review. Replace them with the current AWS price card and your Cost Explorer numbers before anyone calls the result a budget.

Six modules, seventy lessons:

Lesson 2 draws the account and identity boundaries this lesson only names. Lesson 3 deepens IAM. Lessons 5 and 6 turn Regions and AZs into concrete VPC designs. This lesson only requires that you can point at a workload and say which Region owns it, how many AZs it needs for its availability goal, what the shared responsibility line is, and which cloud service model you are actually buying.

Learning Objectives

By the end of this lesson you will be able to:

1. Define cloud computing in terms of on-demand self-service, elasticity, metered usage, and shared pools—not as "servers in someone else's building."
2. Separate IaaS, PaaS, and SaaS for TechLearningPro workloads and name what each model leaves on your side of the responsibility line.
3. Explain AWS Regions, Availability Zones, Local Zones, Wavelength Zones, and edge locations, and choose which of them apply to the lesson player versus static course assets.
4. Distinguish multi-AZ high availability from multi-Region disaster recovery, including what data and identity must travel with a Region failover.
5. Apply the AWS Shared Responsibility Model to EC2, managed databases, and serverless, and write down control owners.
6. Map latency, data residency, service availability, and blast radius into a Region selection decision for the learning platform.
7. Sketch an architecture brief for a highly available web application that states AZ placement, edge usage, and failure domains.
8. Reject designs that treat a single AZ as "the cloud," or that confuse CloudFront edge caching with regional API durability.
9. Use durable AWS concepts and current documentation rather than memorized quotas, flags, or prices when reviewing a design.
10. Hand later lessons a Region and availability narrative that AWS Account Setup, IAM Identity Center and Organizations and Amazon VPC Architecture can inherit without re-arguing the map.

Prerequisites

• You can read a basic application architecture: a browser or mobile client, an HTTP API, a database, and object storage for static or media assets. This lesson does not require you to have deployed on AWS yet.
• Familiarity with a command line and with reading JSON or YAML is enough for later labs. The CLI deep dive is AWS CLI, SDKs and Infrastructure Access.
• You understand that production systems fail in partial ways: a disk, a rack, a building, a city, a network path. You do not need formal SRE background; you need willingness to name the failure you are designing against.
• Optional primers: /learn/docker for packing the lesson player, /learn/git for how changes will later enter CI/CD. Neither is required to finish this lesson's architecture brief.

If your team already runs workloads in a single Region without documenting AZ placement or shared responsibility, stay here. The Monday incident this course keeps returning to often starts as "we thought the cloud was one place."

Detailed Core Concepts

What cloud computing is for

Cloud computing exists so that capacity, placement, and operational toil can change with demand without a capital project for every enrollment spike. For TechLearningPro the decision is concrete. Enrollment week multiplies progress writes. A quiet Wednesday does not. Buying hardware for the spike and leaving it idle is a cost design. Refusing to scale for the spike is a reliability design. The cloud model lets you choose those designs separately from owning a data center, but it does not choose them for you.

Useful characteristics, stated as obligations rather than marketing:

1. On-demand self-service. An authorized identity can provision and release resources through APIs without a ticket to a hardware desk. The authority model is the hard part; lesson 2 and lesson 3 own it.
2. Broad network access. Clients reach services over the internet or private links. "Reachable" is not "exposed." Networking lessons make that distinction operational.
3. Resource pooling. Many customers share underlying physical capacity. Isolation is logical: accounts, VPCs, IAM, encryption, and tenancy choices. Shared pools do not excuse weak tenancy design.
4. Elasticity. You can add and remove capacity. Elasticity without autoscaling policy, budget alarms, and cleanup is how labs become invoices.
5. Measured service. Meters exist: hours, bytes, requests, data transfer. The bill is a design artifact. AWS Well-Architected Framework and Cost Basics and later FinOps lessons deepen the meters; this lesson only insists you name them when you choose a Region and a topology.

Cloud is also a contract about responsibility. If you cannot say who patches the guest OS, who rotates the database password, who owns the Region failover runbook, and who pays for idle NAT gateways, you do not yet have a cloud architecture. You have a purchase order.

Service models: IaaS, PaaS, SaaS

The same learning platform will buy more than one model. Mixing them without naming the boundary produces tickets that bounce between "platform" and "application."

Serverless functions and managed container platforms sit toward the PaaS end of the spectrum for compute, but you still own code defects, IAM, VPC placement when used, and cost of invocations or task hours. Do not call a design "serverless" as a way to skip shared responsibility. Call out what you still operate.

Capex versus opex is a finance conversation; for engineers the sharper distinction is fixed capacity you forget versus variable capacity you must observe. An always-on EC2 fleet and a Lambda function both can surprise you. One surprises you with idle hours. The other surprises you with request storms and concurrency limits. Name the surprise you are accepting.

Deployment models and why "the cloud" is still a choice

Public cloud, private cloud, and hybrid connectivity are deployment models, not maturity levels. TechLearningPro's default in this course is public AWS with intentional private networking for data planes. Hybrid appears when an enterprise constraint forces it—corporate identity, on-premises data that cannot move yet, or Direct Connect for steady private throughput. Hybrid Connectivity: VPN and Direct Connect owns those mechanics. This lesson only forbids pretending that "lifted into one AZ" is a hybrid strategy.

Multi-cloud as a default availability strategy is usually a political statement wearing an architecture badge. Two clouds double the identity, networking, observability, and skill surface. A second cloud can be a deliberate vendor or regulatory hedge. It is not free resilience. For this course, deep competence on AWS with clear Region and AZ design beats shallow presence in three providers.

AWS Global Infrastructure map

Region. A Region is a geographic area with a set of Availability Zones, independent of other Regions for most failure domains, with its own service endpoints and data residency implications. Resources you create in eu-west-1 do not automatically exist in ap-south-1. APIs are regional unless the service is explicitly global (for example, IAM, Organizations, and some edge configurations—verify current documentation for the service you use). Choosing a Region chooses latency to users, legal and contractual residency expectations, which services and instance families are available, and the blast radius of a regional event.

Availability Zone. An AZ is one or more discrete data centers with redundant power, networking, and connectivity within a Region. AZs in a Region are connected with high-bandwidth, low-latency links, and are engineered so that a failure in one AZ is unlikely to cascade to another. Multi-AZ for a database or load-balanced API tier means you are designing so that loss of one AZ does not take the service offline, provided your application can tolerate the failover behavior of each component. An AZ is not a backup Region. It does not protect you from a Region-wide control-plane or connectivity event, from a bad deploy you pushed to every AZ, or from data corruption you replicated everywhere.

Local Zones and Wavelength. Local Zones place select AWS services closer to large metro areas for latency-sensitive workloads. Wavelength Zones embed AWS compute and storage at telecom edges for ultra-low latency to mobile devices. Most of TechLearningPro's lesson APIs will not start here. Mention them so you do not invent "we need a Local Zone" when CloudFront plus a well-chosen Region would meet the latency budget. Use them when measured latency to a metro or mobile cohort fails the product SLO and the service you need exists in that Local or Wavelength Zone.

Edge locations and regional edge caches. Edge locations are where Amazon CloudFront, Route 53, AWS WAF (when associated at the edge), and related edge services terminate client connections close to users. They improve delivery of cacheable content and DNS resolution paths; they do not replace a multi-AZ origin design. Caching a course video at the edge is appropriate. Caching personalized progress API responses aggressively without a cache key design is how learners see someone else's completion state—or stale state after a checkpoint. Amazon CloudFront and Edge Delivery owns edge behavior. This lesson only places the edge on the map.

Points of presence versus Regions. Learners in many countries can hit an edge POP quickly while the authoritative progress write still lands in one primary Region. That is normal. It is also why "we are global because CloudFront is global" is an incomplete sentence. Global edges with a single-Region origin give global read acceleration for cacheable assets, not global write durability.

Shared Responsibility Model

AWS publishes the Shared Responsibility Model: AWS is responsible for security of the cloud; you are responsible for security in the cloud. The line moves with the service abstraction.

For EC2-style IaaS, you own guest OS patching, application secrets, security group rules, and data classification. For RDS, AWS owns more of the database engine host lifecycle; you still own schema design, auth to the database, parameter choices, encryption settings you configure, and network exposure. For Lambda, you own function code, IAM roles the function assumes, what the code sends to logs, and dependency vulnerabilities. For S3, you own bucket policies, public access blocks, encryption settings, and lifecycle; AWS owns the underlying durable storage infrastructure.

Write responsibility as a table in the architecture brief, not as a slide title. Columns that work in design review: control, AWS-owned portion, TechLearningPro-owned portion, evidence (Config rule, CloudTrail, runbook owner). Lesson 37 and lesson 44 deepen audit and compliance automation. Here, refuse any design that says "AWS handles security" without a row for IAM, data, and network exposure.

Failure domains you must name

Design reviews go wrong when people mix these domains:

1. Instance or task failure. One host or task dies. Load balancing and health checks absorb it if capacity remains.
2. AZ impairment. Power, cooling, or network in one AZ. Multi-AZ data stores and multi-AZ compute capacity absorb it if you actually ran capacity in more than one AZ and tested failover.
3. Region impairment. Rare, large. Requires a DR plan: backups, replica Region, DNS or traffic shift, identity and secrets available in the recovery Region, and a rehearsed RTO/RPO. Backup, Disaster Recovery and Resilience owns the rehearsal. This lesson forbids calling "we use three AZs" a DR plan.
4. Human and pipeline failure. A bad IAM policy, a deleted VPC route, a deploy that empties a table. Multi-AZ replicates the mistake at high speed if your pipeline targets all AZs equally. Change management and least privilege are part of infrastructure design.
5. Dependency failure. Upstream IdP, payment provider, or a single NAT gateway. Draw dependencies. A multi-AZ API behind one NAT in one AZ is a single-AZ product with decorative subnets.

Region selection for TechLearningPro

Choose a primary Region with explicit criteria:

• Latency to the largest interactive learner cohort and to operators who must use the console and APIs under incident pressure.
• Data residency and contractual constraints for learner PII and payment-adjacent data. If legal requires residency in a geography, that constraint outranks a slightly cheaper instance family elsewhere.
• Service and feature availability for the components you need in the next twelve months, not only what a quickstart used.
• Cost structure as a secondary factor after residency and latency. Transfer and cross-Region replication are easy to underestimate. Use illustrative arithmetic only with labels, then check the live price card.
• Operational familiarity. A Region your on-call has never used is a hidden reliability risk.

Secondary Region, if any, is a DR or expansion decision with a written RTO/RPO. It is not a place you casually create "a few test resources" with production data copies. Account strategy in lesson 2 will keep sandbox and production data from meeting in that secondary Region by accident.

Elasticity, quotas, and honesty about limits

AWS accounts and services have quotas (limits). Some are soft and adjustable; some are hard. Do not invent numbers in design docs. When a quota matters—API rate, concurrent Lambda executions, Elastic IPs, VPCs per Region—look up the current quota in Service Quotas for the account and Region, and record the value you observed. Enrollment week is when silent quotas become outages. Design for backoff and for quota increase lead time; do not assume infinite elasticity on day one of a launch campaign.

Cost as an infrastructure property

Every architecture choice in this lesson has a meter nearby: data transfer out to the internet, inter-AZ traffic for chatty tiers, idle load balancers, NAT gateway hours and processing, unused Elastic IPs, orphaned EBS volumes, multi-Region replication. You do not need FinOps fluency yet. You need the habit of asking "what runs when nobody is learning?" and "what crosses an AZ or Region boundary on the hottest path?" Illustrative example for ratios only: if inter-AZ chatter on a progress write path is chatty by design, the reliability win of multi-AZ can arrive with a transfer line item; fix chattiness in the application before blaming the cloud. Replace any dollar figure with current pricing before budgeting.

Architecture and Design Diagrams

The first diagram places TechLearningPro on the AWS map without pretending the edge is the database.

mermaidCopy
flowchart TB
  subgraph users [Learners and instructors]
    Browser[Browser and mobile clients]
  end

  subgraph edge [Edge]
    DNS[Route 53]
    CDN[CloudFront edge locations]
  end

  subgraph region [Primary AWS Region]
    subgraph azA [Availability Zone A]
      ALBA[Load balancer node]
      APPA[Lesson API tasks]
    end
    subgraph azB [Availability Zone B]
      ALBB[Load balancer node]
      APPB[Lesson API tasks]
    end
    DB[(Multi-AZ managed database)]
    S3[(S3 course assets)]
  end

  Browser --> DNS
  DNS --> CDN
  CDN --> ALBA
  CDN --> ALBB
  ALBA --> APPA
  ALBB --> APPB
  APPA --> DB
  APPB --> DB
  CDN --> S3
  APPA --> S3
  APPB --> S3

The second diagram separates high availability from disaster recovery so design review cannot flatten them.

mermaidCopy
flowchart LR
  subgraph ha [Multi-AZ HA in Region R1]
    AZ1[AZ 1]
    AZ2[AZ 2]
    AZ3[AZ 3]
  end

  subgraph dr [Multi-Region DR]
    R1[Region R1 primary]
    R2[Region R2 recovery]
  end

  AZ1 --> ha
  AZ2 --> ha
  AZ3 --> ha
  R1 -->|"replicated data + runbook"| R2
  ha -->|"not the same as"| dr

Technical Explanation

How a request finds a Region and an AZ

A learner resolves a hostname through DNS (often Amazon Route 53). The record may point at CloudFront or at a regional load balancer. CloudFront selects an edge location near the client for TLS termination and cache lookup. On a cache miss for an origin-facing API path, or for a non-cacheable progress POST, traffic continues to the Region you configured as origin. Inside the Region, the load balancer distributes to healthy targets across the AZs you registered. The AZ of the client is irrelevant; the AZ of the target and of the data store is what your multi-AZ story depends on.

If the database is single-AZ, the API tier can be multi-AZ and still be down for writes when that AZ fails. If the database is multi-AZ but the application hard-codes a cache or a filesystem on an instance in one AZ, you have moved the single point of failure, not removed it. Read the failover behavior of each managed service you use: whether DNS endpoints flip, whether the client must refresh configuration, and how long the manufacturer documents for failover. Do not invent seconds.

Control plane versus data plane

AWS APIs that create and modify resources are control-plane style operations. Serving learner progress reads and writes is data-plane work. During rare control-plane impairment, you may still serve traffic from existing capacity while being unable to scale or heal via API. Designs that require continuous control-plane churn to stay healthy are fragile. Prefer warm capacity buffers for known spikes, tested autoscaling, and runbooks that include "API slow" as a condition. This distinction also matters for IAM: who can call control-plane APIs in production is a tighter set than who can invoke a read-only data API.

Global services and regional services

Some services present global endpoints and globally scoped resources (IAM users and roles are account-global constructs managed via global endpoints; CloudFront distributions are global configurations with edge behavior). Most application resources are regional: VPCs, EC2 instances, RDS instances, ALBs, and many others. A common incident pattern is creating a VPC in Region A and an RDS instance in Region B, then wondering why the security group reference fails. Console "recent Region" sticky state makes this worse. Train operators to read the Region in the console header and in CLI profiles. Lesson 4 will make profiles and AWS_REGION explicit.

Consistency, replication, and what "durable" means

S3 is designed for very high durability of objects across multiple devices and facilities within a Region (see current AWS documentation for the precise durability design statement). That does not mean every storage service you attach to an EC2 instance has the same properties. An EBS volume lives in a single AZ. EFS and multi-AZ databases have their own replication models. When someone says "the data is in AWS, so it is safe," ask which service, which Region, which AZ configuration, which backup plan, and which restore test date.

Cross-Region replication is a deliberate feature you turn on and pay for; it is not ambient. Replication also copies bad writes. DR is not only bytes in another Region; it is the ability to make those bytes serve the product under time pressure.

Latency budgets for two products

TechLearningPro has at least two latency products sharing infrastructure language:

1. Lesson player progress. Interactive. Learners feel single-digit or low tens of milliseconds difference when the Region is far, and they feel cache mistakes as wrong state. Keep the authoritative write path short: edge for static assets, Region close to the cohort for APIs and DB.
2. Monday board. Analytical. Freshness is a morning contract, not a millisecond contract. Do not force the board's warehouse path to dictate the player's Region, and do not force the player's multi-AZ OLTP design to dictate the board's batch window. Data engineering lessons on this platform already separated those products; cloud placement should respect the same boundary.

Security at the infrastructure layer

Even before dedicated security lessons, global infrastructure choices encode security:

• Public exposure. Edge and public subnets are not where databases live.
• Account isolation. One compromised sandbox should not hold production learner PII. Lesson 2.
• Encryption and key residency. KMS keys are regional. Multi-Region key strategies are explicit. Lesson 41.
• Audit. CloudTrail organization trails and regional data events are how you prove who changed the map. Lesson 37.

Shared responsibility means AWS will not stop you from opening 0.0.0.0/0 to SSH on a public instance. The infrastructure map must include the controls you accept.

Practical Implementation or Design Walkthrough

You will not create billable multi-Region infrastructure in this walkthrough. You will produce an architecture brief that a staff engineer could implement in later lessons without re-litigating placement. Use the AWS Management Console (or documentation) only to verify that the services you name are available in the candidate Region—not to leave resources running.

Step 0: Budget alert and account hygiene

1. Use a sandbox AWS account, never production learner data.
2. Before any lab in this module creates resources, create an AWS Budgets alert (or equivalent billing alarm) at a threshold your team agrees—illustrative starter threshold many training teams use is a low double-digit USD monthly forecast, but set a number that matches your sandbox policy and verify current Budgets behavior in docs.
3. Tag every later resource with project=techlearningpro-lab, owner=<you>, ttl=<date>.
4. Record cleanup owners. Idle load balancers and NAT gateways are the usual orphan bills after "just looking."

Step 1: Write the workload statements

In a markdown ADR (architecture decision record), write:

• Players: learners, instructors, Monday board readers, CI systems, on-call engineers.
• Data classes: public course media, authenticated progress events, enrollment PII, secrets.
• Availability intent: e.g., "lesson progress API survives single-AZ impairment without manual failover; Monday board may be unavailable during AZ events if batch can rerun before 06:00."
• RPO/RTO sketch for Region loss: even if the answer is "not yet in scope," write that sentence so nobody invents it during an incident.

Step 2: Shortlist Regions

Pick two candidate Regions. For each, document:

• Latency note from your major cohort (measured with a simple HTTPS probe to a public endpoint in-Region, or from published latency guidance—do not invent numbers).
• Data residency constraint: pass/fail.
• Services required in the next module wave: VPC, EC2 or ECS/Fargate, RDS or Aurora, S3, CloudFront, IAM Identity Center usage pattern.
• Operator timezone and staffing.

Select one primary. Put the second on a "DR candidate" list without provisioning.

Step 3: AZ count and service modes

For the progress API:

• Require at least two AZs for load balancer targets and for the managed database multi-AZ mode.
• State whether three AZs are needed for capacity headroom or for services that recommend odd counts for quorum-style components (when you introduce such components later).
• Explicitly forbid single-AZ "temporary" production.

For static assets:

• S3 in the primary Region plus CloudFront.
• Document cache behavior for public media versus private signed content at a high level; details wait for the CloudFront lesson.

Step 4: Shared responsibility table

Add at least eight rows covering: physical facilities, hypervisor, guest OS (if any), container runtime, application code, IAM policies, security groups, data encryption configuration, backup restores, and edge WAF association ownership (even if WAF arrives later). Assign each row to AWS, TechLearningPro, or shared with a note.

Step 5: Failure mode table

Step 6: Diagram and review questions

Attach the Mermaid (or equivalent) diagrams from this lesson, customized with your Region code and service names. In review, answer:

1. Where does a progress POST become durable?
2. What happens if AZ a is unavailable at peak?
3. What still works if CloudFront is unavailable but the Region is healthy (and vice versa)?
4. Which meters did we accept (inter-AZ, egress, idle)?
5. What is explicitly out of scope until the DR lesson?

Console / CLI verification examples (non-billable)

List Regions your account can see (safe read-only):

bashCopy
aws ec2 describe-regions --query 'Regions[].RegionName' --output text

Confirm you are looking at the intended Region before any create call:

bashCopy
aws configure get region
echo "$AWS_REGION"

Do not run create calls for VPCs, NAT gateways, or load balancers until lessons 5–8 and your budget alert exist. Read-only exploration is enough for this lesson's deliverable.

Enterprise Real-World Scenarios

Scenario A: Enrollment week, single-AZ database

A team launched the lesson API across two AZs but left RDS Single-AZ to save money during a pilot. An AZ networking impairment took the database offline. The load balancer showed healthy app instances that could not write progress. Learners saw intermittent failures; support blamed "the cloud."

What good looks like. Multi-AZ for the stateful dependency that defines the product's write path, with a tested client reconnect. The pilot discount was a hidden single point of failure. Cost discussion belongs on the bill with the availability sentence attached, not as a silent engine toggle.

Scenario B: "Multi-Region" without identity or DNS

A platform team replicated S3 assets to a second Region and declared DR done. During a game day, IAM roles, secrets, container images, and Route 53 failover were never exercised. Data existed; the product did not.

What good looks like. DR is an application cutover story: identities, images, configuration, data, traffic shift, and ownership. Bytes without a runbook are a backup science project.

Scenario C: Edge-first personalization bug

CloudFront cached an API response that included learner-specific progress because the cache key ignored the auth identity and the origin set cache headers poorly. Learners saw mixed progress states.

What good looks like. Edge for static and deliberately cacheable public content; authenticated APIs default to careful cache control. Global infrastructure includes the edge, but product correctness still owns the cache key.

Scenario D: Region choice by tutorial inertia

All production resources landed in a Region because the first workshop used it, while most learners and the legal residency requirement sat elsewhere. Latency and compliance both failed in slow motion.

What good looks like. Region ADR with residency and latency first, tutorial defaults last. Moving Regions later is far more expensive than writing the ADR now.

Scenario E: Shared responsibility gaps on a managed service

An RDS minor version issue and an application connection storm landed at once. The team opened tickets to AWS for application pool sizing and blamed themselves for host patching they did not own. Both sides wasted time.

What good looks like. A responsibility table consulted during incidents. AWS-owned and customer-owned actions proceed in parallel with clear owners.

Best Practices

1. Write Region and AZ intent in an ADR before the first production Terraform apply. Include residency, latency, and DR scope.
2. Treat multi-AZ as the default for production stateful dependencies that gate learner progress writes.
3. Keep edge and origin responsibilities separate in diagrams and in cache policy.
4. Name failure domains explicitly in every design review: instance, AZ, Region, human, dependency.
5. Use sandbox accounts and budget alerts before experiments; tag with TTL.
6. Prefer durable concepts and live documentation over memorized prices, quotas, and CLI flags.
7. Align cloud placement with product latency classes—player versus Monday board—so one SLO does not vandalize the other.
8. Record shared responsibility owners for the services you actually use, not for an abstract pyramid.
9. Assume quotas exist; check Service Quotas before launch campaigns.
10. Do not confuse account isolation, AZ isolation, and Region isolation; lesson 2 builds the account story on this map.

Common Mistakes and Anti-Patterns

1. Single-AZ production "for now." Symptom: total outage when one AZ fails. Cause: pilot cost cutting left in place. Fix: multi-AZ for critical stateful services; schedule the change before the next enrollment week.
2. Calling three AZs a DR plan. Symptom: Region event still ends the product. Cause: no recovery Region, no DNS plan, no data practice. Fix: write RTO/RPO and a game day, or explicitly defer DR with leadership signature.
3. Global CloudFront as proof of multi-Region durability. Symptom: origin Region outage takes writes offline everywhere. Cause: edge mistaken for origin HA. Fix: diagram edge versus origin; design origin multi-AZ first.
4. Ignoring inter-AZ and egress meters. Symptom: surprise transfer costs after "we only added HA." Cause: chatty cross-AZ app design. Fix: measure; keep chatty tiers co-located when safe; accept necessary HA transfer as a named cost.
5. Sticky console Region creating resources in the wrong place. Symptom: "resource not found," cross-Region confusion. Cause: operator error amplified by console state. Fix: CLI profiles with explicit Regions; checklist in the runbook.
6. Invented quotas and prices in design docs. Symptom: false confidence, failed launches. Cause: blogging from memory. Fix: cite Service Quotas and current price cards; label any classroom arithmetic as illustrative.
7. Skipping shared responsibility on PaaS. Symptom: unpatched assumptions, open security groups, no backup restore test. Cause: "managed" heard as "done." Fix: responsibility table and restore drill dates.
8. Secondary Region used as unmanaged playground with prod data. Symptom: sprawl and leakage. Cause: no account or OU strategy. Fix: lesson 2 account boundaries; never copy prod PII to playground Regions.

Troubleshooting and Design Review

Learners far from the Region report slow APIs; static content is fine. Check origin Region latency and whether the API is incorrectly forced through far edges or extra hops. Static content on CloudFront can look healthy while POST/GET to the API origin is not. Measure the API hostname separately from the media hostname.

One AZ shows unhealthy targets; others are fine. Check capacity in the failing AZ, subnet routing, and whether the database or a dependency lived only there. Confirm the load balancer is truly multi-AZ and that autoscaling can place replacements in healthy AZs.

Failover tested on paper but not in practice. Run a game day: stop an AZ's capacity (in sandbox) or simulate dependency loss. Measure recovery against the statement in the ADR. Document actual minutes; replace marketing numbers.

Bill spikes after "just architecture work." Look for NAT gateways, load balancers, running EC2, unattached EBS, and cross-Region data movement. Confirm budget alerts fire. Cleanup is part of troubleshooting.

Design review checklist

• Is the primary Region justified by residency and latency, not habit?
• Which components are multi-AZ, and which single-AZ exceptions have owners?
• Is DR in scope, deferred, or undefined? Undefined is not allowed.
• Are edge cache behaviors safe for authenticated progress?
• Is the shared responsibility table filled for the services in the diagram?
• Are budget alerts and sandbox boundaries in place before labs continue?
• What will lesson 2 need as account boundaries to protect this map?

Interview Questions and Answers

Q1. What is the difference between a Region and an Availability Zone?

A Region is a geographic area with multiple AZs and regional APIs. An AZ is an isolated location within a Region engineered with independent failure characteristics and connected to other AZs in that Region with high-bandwidth, low-latency links. Multi-AZ protects against AZ-level impairment inside one Region. Multi-Region protects against broader geographic or regional events and requires an explicit DR design.

Q2. Why is multi-AZ not the same as disaster recovery?

Because many Region-scoped failures and human errors are not AZ-scoped. DR needs data recovery objectives, a place to run, identity and configuration, traffic shifting, and rehearsal. Three healthy AZs with a corrupted schema or a bad deploy can still be fully down.

Q3. How does the Shared Responsibility Model change between EC2 and Lambda?

On EC2 you own much more of the guest OS and runtime patching surface. On Lambda AWS operates the underlying execution environment to a greater degree, but you still own function code, IAM permissions, sensitive data handling, dependency vulnerabilities, and how the function is exposed. "Serverless" does not mean "no security duty."

Q4. When would you consider a Local Zone for TechLearningPro?

When measured latency requirements for a specific metro cohort cannot be met from the parent Region and the needed services exist in that Local Zone. Teaching content delivery alone rarely justifies it if CloudFront plus a sensible Region meet the SLO. Do not choose Local Zones for fashion.

Q5. What goes into selecting a primary Region?

Data residency and legal constraints, latency to interactive users and operators, service availability for your architecture, cost as a secondary factor, and operational readiness. Tutorial default Regions are not a criterion.

Q6. How do edge locations change a highly available design?

They reduce latency for cacheable content and change TLS termination points, but the origin's AZ design still determines write availability. Edge is complementary to multi-AZ, not a substitute.

Q7. What is a control plane versus data plane concern in an outage?

If you can still serve from existing capacity but cannot call APIs to scale or heal, you are seeing control-plane trouble relative to data-plane success. Designs that require constant control-plane changes to stay healthy are fragile under exactly those conditions.

Q8. Why tag lab resources and set budget alerts in a foundations course?

Because foundational learning often creates the most orphaned billable resources. Budgets and tags make cost visible and cleanup assignable. Least privilege and hygiene start before production.

Q9. How would you explain IaaS versus PaaS using the enrollment database?

Self-managed PostgreSQL on EC2 is IaaS-heavy: you patch and operate the engine host. Amazon RDS for PostgreSQL is a managed platform service: AWS takes more of the host lifecycle, while you still own schema, access, and configuration choices. Same data product, different responsibility split.

Q10. What interview signal shows someone understands blast radius?

They separate instance, AZ, Region, identity, and deploy blast radii, and they can name one control for each. They do not claim that "being on AWS" collapses those distinctions.

Q11. How should prices appear in architecture documents?

As labeled illustrative ratios or as figures pulled from the current price card and Cost Explorer with a date. Invented precision is worse than a variable. Interview answers should say how they would verify cost, not recite a blog's numbers.

Hands-On Exercises

Lab cost warning. Prefer read-only verification in this exercise. If you create any billable resource, set a budget alert first, use a sandbox account, tag with TTL, and delete before you leave the session. NAT gateways, load balancers, and running EC2 instances are common accidental charges.

Exercise 1: Architecture brief for a highly available web application

Problem. Produce a design package for TechLearningPro's lesson progress API and static course media that survives single-AZ impairment in the primary Region. DR to a second Region may be deferred but must be explicitly scoped.

Tasks.

1. Create a budget alert in the sandbox account (or document why your organization applies a central alert) before any create API calls.
2. Write an ADR selecting a primary Region with residency, latency, and service-availability arguments.
3. Draw a diagram with at least two AZs for the API tier, a multi-AZ data store choice, S3 for media, and CloudFront at the edge.
4. Fill a shared responsibility table (≥8 rows) and a failure-mode table (≥5 rows).
5. List meters you expect to matter (egress, inter-AZ, idle LB, etc.) without inventing prices; note where you will read the live price card.
6. Verify with read-only CLI or console that required services exist in the chosen Region; paste evidence (Region list, service availability notes).
7. Cleanup: confirm no orphaned billable resources from exploration; delete any you created; record screenshots or CLI proof of deletion.

Deliverables. ADR, diagram source, tables, evidence of Region verification, cleanup notes.

Challenge. Add a production constraint: leadership wants RPO under one hour for progress data for a Regional loss. Extend the brief with what must be true (replication, identity, DNS, game day) without implementing it yet. Write what you would refuse to claim until rehearsed.

Lesson Summary

Cloud computing for TechLearningPro is a model for elastic, metered capacity with a written shared responsibility line—not a synonym for outsourcing thinking. AWS Global Infrastructure gives you Regions for placement and residency, Availability Zones for isolating failure inside a Region, and edge locations for bringing cacheable content closer to learners. Multi-AZ high availability and multi-Region disaster recovery are different designs; conflating them produces brittle Monday mornings. Service models shift what you still own; they never shift ownership of IAM mistakes, open data, or untested restores to zero.

You now have a map and a vocabulary the rest of the course can inherit. AWS Account Setup, IAM Identity Center and Organizations turns that map into account boundaries and human access paths. AWS Identity and Access Management deepens authorization. Networking Fundamentals for AWS and Amazon VPC Architecture place subnets onto the AZs you chose. Keep the architecture brief nearby; every later lab should still answer which Region, which AZ story, and which duties remain yours.

Further Reading

• AWS Global Infrastructure for the current map of Regions, AZs, and edge presence.
• Regions and Availability Zones in AWS documentation for definitions and how resources bind to Regions.
• Shared Responsibility Model for how responsibility shifts by service category.
• Amazon CloudFront documentation for edge behavior versus regional origins.
• AWS Budgets for sandbox alerts before labs create resources.
• Service Quotas for verifying limits in the account and Region you actually use.
• Current AWS pricing pages and Cost Explorer for any figure you promote from "illustrative" to "budget."