Step 2 — Core AWS Services

AWS publishes over 200 services, and the idea of memorizing all of them is exactly the trap the exam wants you to avoid falling into. CLF-C02 tests a much smaller set — the handful of services that show up in almost every conversation about running something in the cloud. Learn what each one is for, not how to configure it, and you’ll be in good shape.

Compute: Where Your Code Actually Runs

Compute services answer the question “where does my application execute?” AWS gives you several answers depending on how much control you want versus how much you’d rather hand off.

MORE CONTROL ──────────────────────────────────────► LESS CONTROL
                                                       LESS OPS WORK

  EC2                Elastic Beanstalk        Containers          Lambda
  (raw virtual        (managed app             (ECS / EKS /       (run code,
  servers, you        deployment, AWS          Fargate — package    no servers
  patch the OS)       handles capacity,        an app once, run     to think
                       load balancing,          it anywhere)         about at all)
                       health checks)

Amazon EC2 (Elastic Compute Cloud) is the foundational building block — resizable virtual servers you configure yourself. You choose the operating system, the instance size, the storage attached to it, and you’re responsible for patching it. Think of EC2 as “renting a computer” rather than renting a finished application platform.

AWS Lambda flips that entirely. You upload a function, AWS runs it in response to a trigger (an API call, a file landing in S3, a scheduled event), and you’re billed only for the milliseconds it actually executes. There’s no server to patch, size, or leave running idle — this is the purest expression of “serverless.”

AWS Elastic Beanstalk sits in between. You give it your application code, and it handles provisioning the EC2 instances, load balancer, auto scaling, and health monitoring behind the scenes. You still know EC2 is involved, you just don’t manage it directly.

Containers package an application with everything it needs to run, so it behaves identically on a laptop, in a test environment, or in production. Amazon ECS and Amazon EKS orchestrate containers at scale, and AWS Fargate removes the need to manage the underlying servers those containers run on — similar in spirit to how Lambda removes servers for functions.

For the exam, the pattern to recognize is: “servers I fully control” → EC2, “deploy my app, don’t make me think about infrastructure” → Elastic Beanstalk, “run this specific piece of code only when triggered” → Lambda, “package once, run consistently anywhere” → containers.

Storage: Where Your Data Lives

Storage questions on CLF-C02 are conceptual — you won’t be asked to calculate IOPS, but you will be asked which storage service fits a described use case.

Service	What it stores	Typical use case
Amazon S3	Objects (files) in buckets, accessed over the internet	Website assets, backups, data lake storage, static files
Amazon EBS	Block storage attached to a single EC2 instance	The “hard drive” for a running virtual server
Amazon EFS	Shared file storage, accessible by many instances at once	Shared home directories, content shared across a fleet of servers

Think of it this way: S3 is a warehouse you access from anywhere — durable, virtually unlimited, and organized as objects rather than files in folders in the traditional sense. EBS is the drive bolted to one specific server — if that EC2 instance disappears, the EBS volume can persist, but it’s fundamentally tied to being attached to one instance at a time. EFS is a shared drive many servers can plug into simultaneously, which matters when you have a fleet of EC2 instances that all need to see the same files.

S3 also comes up constantly in storage class questions at the conceptual level — Standard for frequently accessed data, Infrequent Access for backups you rarely touch, and Glacier-family tiers for long-term archival where retrieval can take longer in exchange for a much lower storage price.

Databases: Structured vs. Flexible

Amazon RDS                              Amazon DynamoDB
─────────────────                       ─────────────────
Relational (tables, rows, columns)      NoSQL (key-value / document)
Fixed schema                            Flexible schema
Good fit: financial records,            Good fit: session data, gaming
  inventory systems, anything            leaderboards, IoT data — anything
  needing SQL joins and                  needing single-digit millisecond
  strict structure                       response at massive scale
Engines: MySQL, PostgreSQL,             Fully managed, serverless-style
  MariaDB, SQL Server, Oracle,           scaling with no engine to choose
  Aurora

Amazon RDS manages relational databases for you — AWS handles patching, backups, and failover, but the underlying data still lives in traditional rows-and-columns tables using an engine you recognize, like MySQL or PostgreSQL. Amazon Aurora is AWS’s own high-performance, MySQL- and PostgreSQL-compatible engine within the RDS family.

Amazon DynamoDB is AWS’s fully managed NoSQL database. There’s no server to size, no engine version to pick — you define a table, a key, and DynamoDB handles the rest, scaling automatically to enormous throughput. It’s the answer whenever a scenario needs extremely fast, simple lookups at scale rather than complex relational queries.

The exam’s favorite trick here: if a question mentions “structured data with complex relationships and requires SQL,” that’s RDS. If it mentions “key-value lookups at massive scale with unpredictable traffic,” that’s DynamoDB.

Networking: Connecting Everything Together

Amazon VPC (Virtual Private Cloud) is your own logically isolated slice of the AWS network — a private space where you launch EC2 instances, databases, and other resources, with control over IP ranges, subnets, and what can talk to what. Think of it as your own private data center carved out of AWS’s infrastructure.

Amazon Route 53 is AWS’s DNS service — it translates human-friendly domain names into IP addresses, and it can also perform health checks and route traffic based on latency or geography.

Amazon CloudFront is AWS’s content delivery network (CDN) — it caches your content at edge locations around the world so users get it from a nearby location instead of round-tripping to your origin server every time.

User request flow with CloudFront + Route 53
─────────────────────────────────────────────
User types domain name
    │
    ▼
Route 53 resolves domain → nearest edge location
    │
    ▼
CloudFront edge location: cached? ──Yes──► Serve immediately
    │
    No
    ▼
Fetch from origin (S3 bucket or EC2/ALB) → cache it → serve

Recognizing “Which Service Fits This Scenario” Questions

CLF-C02 loves describing a business need in plain language and asking you to match it to a service, without ever naming the service in the question. A reliable approach:

Identify the category first — is this compute, storage, database, or networking?
Identify the defining constraint in the scenario — “no server management,” “shared across many servers,” “structured financial records,” “route users to the nearest location.”
Match the constraint to the service built specifically to solve it.

If you find yourself choosing between two services in the same category, re-read the scenario for the one distinguishing detail — the exam almost always includes exactly one clue that rules out the wrong answer.

Exam Focus: What Questions Test From This Step

Matching a scenario to EC2, Lambda, Elastic Beanstalk, or containers based on how much infrastructure control is described
Telling S3, EBS, and EFS apart by access pattern (internet-accessible objects vs. single-instance block storage vs. shared file access)
Choosing RDS for structured/relational needs versus DynamoDB for flexible, high-scale key-value needs
Recognizing VPC as the networking container, Route 53 as DNS, and CloudFront as the CDN
Reading scenario-based questions for the one distinguishing constraint rather than memorizing service names in isolation