mateusz@systems ~/book/cloud-architecture $ cat section.md

Cloud Provider Architecture

Cloud providers abstract datacenter infrastructure into logical constructs like regions, availability zones, and VPCs. Understanding how these map to physical infrastructure helps you design for resilience, predict failure modes, and optimize costs. This section focuses on AWS with cross-references to GCP and Azure equivalents.

# AWS Regions and Availability Zones

AWS organizes infrastructure hierarchically into regions and availability zones (AZs).

Regions

A region is a provider-defined geographic and fault-isolation boundary (for example, us-east-1 in Northern Virginia or eu-west-1 in Ireland). AWS designs most Regional services to operate with substantial autonomy, but a Region is not a promise of complete independence.

Isolation: Regional stacks and services are designed to limit failure propagation. Review each service and workload for global components and shared dependencies such as identity, DNS, deployment, observability, and deliberately configured cross-Region calls.

Data residency: Location behavior is service- and configuration-specific. Verify primary data, replicas, backups and snapshots, logs and telemetry, failover copies, administrative or support access, and key management. Selecting a Region alone does not establish GDPR or other compliance; legal and compliance review must determine the applicable residency, access, and transfer rules.

Availability Zones (AZs)

An availability zone is one or more discrete datacenters within a region, with redundant power, networking, and connectivity. Each region has multiple AZs (typically 3-6).

us-east-1 Region · N. Virginia us-east-1a us-east-1b us-east-1c us-east-1d/e/f Facility 1 Facility 2 Facility 3 + 1d, 1e, 1f power/net/cooling separate bldg/grid distant from 1a/1b extra redundancy AZs connected by high-bandwidth links (<2ms)
Region us-east-1 contains multiple isolated availability zones (AZs) — each an independently powered, cooled, and networked facility — linked by low-latency (<2ms) connections.

Physical mapping: AZ letter mappings are not universally randomized. Regions introduced after November 2012 use consistent mappings across accounts; in older Regions, accounts created starting in November 2025 also receive consistent mappings, while earlier accounts retain account-specific mappings. Use AZ IDs (for example, use1-az1) when coordinating the same physical AZ across accounts.

Failure domain: AZ is the fundamental failure domain in AWS. Power outage, network partition, or cooling failure affects one AZ, not others.

Designing for AZ Failures

Deploy resources across multiple AZs for high availability:

Single AZ (not resilient) us-east-1a Web Server Database Primary us-east-1b (empty) us-east-1c (empty) Problem: AZ failure = total outage Multi-AZ (resilient) us-east-1a Web Server Database Primary us-east-1b Web Server Database Standby us-east-1c Web Server AZ failure: traffic shifts to remaining AZs, DB fails over to standby
Single-AZ deployments concentrate the web server and database primary in one zone, so an AZ failure is a total outage. Spreading web servers across all three AZs and adding a database standby in us-east-1b lets traffic shift and the database fail over when a zone goes down.

# VPCs: Virtual Private Clouds

A VPC is a logically isolated network within an AWS region. You define IP ranges (CIDR blocks), subnets, routing tables, and gateways.

10.0.0.0/16 VPC · us-east-1 10.0.1.0/24 10.0.2.0/24 10.0.10.0/24 10.0.11.0/24 us-east-1a · public us-east-1b · public us-east-1a · private us-east-1b · private EC2, public IP to IGW DB, no internet access
VPC 10.0.0.0/16 partitions into subnets pinned to specific AZs: public subnets host EC2 instances reachable via an internet gateway, while private subnets (e.g., databases) have no direct internet access.

Subnets: Each subnet lives in a single AZ. Spread subnets across AZs for redundancy.

Routing: Route tables control traffic. Public subnets route 0.0.0.0/0 to internet gateway (IGW). Private subnets route via NAT gateway (for outbound) or stay isolated.

Under the hood: VPCs use encapsulation (similar to VXLAN) to isolate customer traffic on shared physical infrastructure. Your 10.0.1.5 is distinct from another customer's 10.0.1.5—even though they might be on the same physical server.

# AWS Storage Services Architecture

Understanding how AWS storage services work internally helps you choose the right service and predict performance/availability.

S3: Object Storage

Architecture: S3 stores objects (files) across multiple AZs by default. Each object is replicated to at least 3 AZs. Metadata and data are separated (control plane vs data plane).

Client S3 API control plane 3+ AZs data plane Writes metadata (name, size, etag); returns success once 2+ replicas confirm. Client S3 API Nearest Replica Reads from nearest replica, returns object to client. 11 nines durability (99.999999999%) via replication + erasure coding.
S3 PUT writes metadata via the control plane, then replicates the object's data across 3+ availability zones before returning success once at least 2 replicas confirm. GET reads from the nearest replica. Both paths, combined with erasure coding, deliver S3's 11 nines (99.999999999%) of durability.

Consistency: S3 provides strong read-after-write consistency (as of Dec 2020). After successful PUT, immediate GET returns new data.

Failure mode: AZ failure doesn't affect S3 availability (data in other AZs). Rare control plane issues (like Oct 2025 DynamoDB incident) can impact API availability.

EBS: Elastic Block Store

Architecture: EBS volumes are block devices (like virtual disks) attached to EC2 instances. Each EBS volume exists in a single AZ and is replicated within that AZ.

EC2 Instance us-east-1a EBS Volume Replicated within AZ (multiple physical drives) Not visible across AZs AZ failure = EBS volumes in that AZ unavailable
An EC2 instance in us-east-1a talks directly to its attached EBS volume. The volume is replicated across multiple physical drives within that AZ only — it isn't visible from other AZs, so an AZ failure takes its EBS volumes down with it.

Limitation: EBS volumes can't be attached to instances in different AZs. To move data across AZs, create snapshot (stored in S3, multi-AZ) and restore in target AZ.

Use case: Low-latency block storage for databases, boot volumes. Not suitable for multi-AZ shared access (use EFS or S3 instead).

EFS: Elastic File System

Architecture: EFS is a managed NFS-compatible file system that spans multiple AZs. Data is automatically replicated across AZs in a region.

EC2 EC2 EC2 us-east-1a us-east-1b us-east-1c All instances see the same data EFS replicated across AZs AZ failure: instances in other AZs continue accessing EFS
EFS is a shared NFS-compatible file system: every mounting instance, regardless of AZ, sees the same replicated data. If one AZ fails, instances in the surviving AZs keep accessing EFS without interruption.

Use case: Shared file storage across instances/AZs. Home directories, application data, content management. Higher latency than EBS (network filesystem).

# Fault Domains in Cloud Environments

Cloud providers define fault domains at multiple levels:

  • Server/instance: Single VM or bare-metal instance. Smallest unit.
  • Rack: Not exposed to customers, but AWS internally tracks rack-level failures.
  • Availability Zone: Exposed to customers. Primary failure domain for design.
  • Region: Provider-defined geographic boundary designed for substantial autonomy; global and shared dependencies may remain.

AWS guidance: Distribute workloads across AZs for HA within a region. Use multiple regions for disaster recovery (DR) against region-level failures.

# Cross-Cloud Comparison

GCP and Azure have similar concepts with different terminology.

Concept AWS GCP Azure
Geographic Area Region Region Region
Fault Domain
(within region)		 Availability Zone (AZ) Zone Availability Zone
Private Network VPC VPC Virtual Network (VNet)
Object Storage S3 Cloud Storage (GCS) Blob Storage
Block Storage EBS Persistent Disk Managed Disks
File Storage EFS Filestore Azure Files
Compute (VMs) EC2 Compute Engine Virtual Machines

Note: While names differ, core concepts are similar. All major clouds provide multi-AZ/zone architectures, private networks, and tiered storage (object/block/file).

# Key Takeaways

  • Regions are geographic fault-isolation boundaries designed for substantial autonomy, but service and shared dependencies must be reviewed
  • Data residency is service- and configuration-specific; Region selection alone is not a compliance guarantee
  • AZ letter mappings can differ for older accounts; use AZ IDs to coordinate the same physical AZ across accounts
  • Design for AZ failures by spreading resources across multiple AZs
  • VPCs use encapsulation to isolate customer networks on shared infrastructure
  • S3 replicates across AZs (multi-AZ resilient); EBS is single-AZ (snapshot to move data)
  • EFS spans AZs for shared file access across instances
  • Fault domains: instance < rack < AZ < region; design for AZ-level failures at minimum
  • GCP/Azure have equivalent concepts (zones, VNets, object/block/file storage)