Global Infrastructure & Compute

An AWS Region is a distinct geographic location made up of multiple (two or more) isolated Availability Zones. Regions are fully independent, so data stored in one never leaves it unless you explicitly transfer it, making Region selection the primary lever for data residency and compliance. Region choice also affects latency, service availability (not every service launches in every Region at once), and pricing. Do not confuse Regions with Availability Zones: a Region (e.g., us-east-1) is the broad geographic boundary, while AZs are isolated data centers inside it. Multi-AZ gives high availability within one Region; multi-Region supports disaster recovery across geographies.

An Availability Zone (AZ) is one or more discrete data centers within an AWS Region, each with independent power, cooling, and networking. AZs in a Region are connected by high-bandwidth, low-latency private fiber, enabling replication and failover without cross-Region traffic costs. The key exam distinction: a Region is a geographic area containing multiple AZs (new Regions launch with at least three), while an AZ is the fault-isolation boundary inside it. Services like Amazon EC2 and RDS deploy at the AZ level, so spreading instances across multiple AZs is the standard high-availability pattern.

An edge location is a data center in AWS’s global network that sits outside of Regions and Availability Zones. Amazon CloudFront uses edge locations to cache copies of static and dynamic content—images, videos, API responses—so requests from nearby users are served with minimal latency instead of traveling to the origin server. The key exam distinction is that edge locations are separate from Regions: AWS operates hundreds of them worldwide versus a much smaller number of Regions, letting CloudFront deliver low-latency content even where no full Region exists. AWS Global Accelerator also routes traffic through this edge network.

Amazon EC2 (Elastic Compute Cloud) is AWS’s core Infrastructure-as-a-Service compute offering. It provisions virtual machines — called instances — letting you choose the CPU, memory, storage, and networking profile for your workload. Because EC2 exposes the full operating system, you are responsible for patching, configuring, and securing the OS and everything running on it, the defining IaaS trait under the shared-responsibility model. For the CLF-C02 exam, contrast EC2 with managed services: AWS Lambda abstracts the server entirely (no OS access, billed per invocation), and Amazon RDS manages the database engine. EC2 means maximum control with maximum management responsibility.

AWS Lambda is a serverless compute service that runs code in response to triggers such as an API Gateway request, an S3 object upload, a DynamoDB stream, or an SNS notification. AWS manages the underlying infrastructure — provisioning, patching, and scaling — so you only write and deploy function code. Billing is based on the number of invocations and execution duration measured in milliseconds, so there is no charge while the function is idle. The key exam distinction is between Lambda and EC2: EC2 provides persistent virtual machines where you control the OS and pay for uptime regardless of load, while Lambda is stateless and ephemeral, suited for short bursts of work rather than long-running processes or persistent connections.

AWS Auto Scaling monitors demand and automatically adjusts the number of EC2 instances — or units of other scalable resources — to maintain steady performance without over-provisioning. It works through scaling policies: target tracking keeps a chosen metric (such as average CPU utilization) at a set target, while step scaling responds to CloudWatch alarms in incremental steps. A common exam confusion is treating Auto Scaling and Elastic Load Balancing as interchangeable. They are complementary, not equivalent: Auto Scaling controls the fleet size, while ELB distributes incoming requests across the running instances. Both are needed for an elastic, highly available architecture.

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets — EC2 instances, containers, IP addresses, or Lambda functions — within one or more Availability Zones, improving fault tolerance by routing around unhealthy targets. The main types are Application Load Balancer (ALB) for HTTP/HTTPS at layer 7, Network Load Balancer (NLB) for ultra-low-latency TCP/UDP at layer 4, and Gateway Load Balancer for third-party virtual appliances. For CLF-C02, remember ELB does not add capacity by itself: it distributes traffic across whatever instances exist, while Auto Scaling adds or removes those instances during demand spikes.

AWS Elastic Beanstalk is a Platform as a Service (PaaS) offering: you upload your code and it automatically handles capacity provisioning, load balancing, auto scaling, and application health monitoring. It supports runtimes such as Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker, deploying onto standard resources like EC2 instances, Elastic Load Balancers, and Auto Scaling groups. The exam nuance: those resources stay visible and billable in your account (unlike Lambda, where infrastructure is hidden), and Beanstalk itself is free.

AWS CloudFormation is an infrastructure-as-code service that lets you define AWS resources in a JSON or YAML template, then provision and manage them together as a single unit called a stack. When you update the template, CloudFormation applies only the needed changes in the correct dependency order, keeping environments consistent and repeatable. A key CLF-C02 distinction is that CloudFormation manages the provisioning layer, while AWS Elastic Beanstalk is a higher-level service that also handles deployment and runtime configuration. CloudFormation gives you finer control but requires defining each resource explicitly; Beanstalk trades that control for simplicity.