Chapter 2
Core AWS Services: Compute, Storage, and Databases
Core AWS Services: Compute, Storage, and Databases
If Chapter 1 was the map of the AWS world, this chapter is the tour of its cities. Compute, storage, and databases are the three pillars every AWS solution stands on — and they make up the largest share of the CLF-C02 exam's "Technology" domain. The exam doesn't ask you to configure these services; it asks you to choose between them. "A company needs X — which service fits?" That decision-making is the skill this chapter builds.
Think of it this way: every application you will ever encounter in your cloud career is a combination of three ingredients. Something to run the code (compute), somewhere to put the files (storage), and somewhere to put the structured data (databases). AWS offers many flavors of each, and each flavor exists because a real customer had a real problem the other flavors couldn't solve. When you understand the problem each service was born to solve, the exam's scenario questions start to feel obvious.

Compute: Machines That Run Your Code
Let's start with the most fundamental question in cloud computing: where does your code actually run? On your laptop, the answer is simple — your laptop's CPU. In AWS, you get to choose from a spectrum of options, ranging from "give me a raw virtual machine and leave me alone" to "I don't even want to think about servers." Understanding where each option sits on that spectrum is the key to the whole compute section.
Amazon EC2: Your Virtual Server in the Cloud
Amazon Elastic Compute Cloud (EC2) is the oldest and most foundational AWS service — launched in 2006, back when "the cloud" was a radical idea. An EC2 instance is a virtual server: it has virtual CPUs, memory, storage, and networking, and you can install whatever operating system and software you want on it. If you've ever used VirtualBox or VMware on your own computer, EC2 is that idea scaled up to a global infrastructure.
Why does EC2 still matter when AWS has launched dozens of fancier compute services since? Because control matters. Some workloads need a specific operating system version. Some need kernel-level customization. Some run legacy software that was written before containers or serverless existed. EC2 gives you the steering wheel, the gas pedal, and the engine bay — full control, with full responsibility.
The exam loves the phrase "full control over the operating system." When a scenario says a company needs to install custom software, modify the OS kernel, or run a specific OS version, the answer is almost always EC2. No other compute service gives you that level of control.
#### EC2 Instance Types: Picking the Right Size
Not all virtual servers are equal. AWS offers hundreds of EC2 instance types, organized into families optimized for different workloads. You don't need to memorize every family for the exam, but you need to understand the categories:
- General purpose (T, M families): Balanced CPU, memory, and networking. The default choice when nothing special is needed — web servers, small databases, development environments.
- Compute optimized (C family): High-performance processors for CPU-hungry work — batch processing, gaming servers, scientific modeling.
- Memory optimized (R, X families): Lots of RAM for memory-hungry work — in-memory databases, big data analytics, real-time processing.
- Storage optimized (I, D families): Fast local SSD storage for I/O-intensive work — data warehousing, distributed file systems.
- Accelerated computing (P, G families): GPUs for machine learning, graphics rendering, high-performance computing.
The exam won't ask "which instance family for a GPU workload?" at a deep level, but it does test the concept: different instance types exist for different workload characteristics (compute, memory, storage, GPU). A question might describe a memory-intensive analytics workload and ask what matters most in instance selection — the answer is memory-optimized instances.
#### EC2 Pricing Options: How You Pay Changes Everything
This is one of the most heavily tested topics on the entire CLF-C02 exam. EC2 offers several pricing models, and choosing the wrong one can cost a company ten times what it should pay — or cause its servers to vanish without warning. Let's walk through each.
On-Demand Instances are the default: you pay by the second (with a 60-second minimum) for as long as the instance runs, with no commitment. It's like renting a car by the day — maximum flexibility, highest per-unit price. Use On-Demand for short-term, unpredictable workloads: development, testing, or a new application whose traffic patterns you don't know yet.
Reserved Instances (RIs) are a commitment play: you commit to 1 or 3 years of usage in exchange for a discount of up to 72% compared to On-Demand. It's like signing a year-long apartment lease instead of staying in hotels — much cheaper per night, but you're locked in. There are two flavors: Standard RIs (biggest discount, can't change instance type) and Convertible RIs (smaller discount, can change instance attributes). Use RIs for steady-state workloads you know will run for years — production databases, company web applications.
Savings Plans are the modern, more flexible cousin of Reserved Instances. Instead of committing to a specific instance type, you commit to a dollar amount of compute usage per hour for 1 or 3 years, and the discount (also up to 72%) applies across EC2, Fargate, and Lambda. If your workload shifts from one instance family to another, Savings Plans follow you. AWS now recommends Savings Plans over Standard RIs for most customers.
Spot Instances are the bargain bin — and the most misunderstood option. AWS has spare compute capacity sitting idle in its data centers. Rather than let it go to waste, AWS sells it at discounts of up to 90% off On-Demand pricing. The catch? AWS can reclaim Spot Instances with a 2-minute warning whenever it needs the capacity back. Your server can simply disappear mid-task.
This is a classic exam trap. Spot Instances are for fault-tolerant, interruptible workloads: batch processing, big data analytics jobs that can checkpoint and resume, CI/CD build servers, image rendering. They are NOT for production databases, critical web servers, or anything stateful that can't survive sudden termination. When a scenario mentions "cost optimization" AND "the workload can tolerate interruptions," the answer is Spot Instances. When it mentions "steady state" or "production," think Reserved Instances or Savings Plans.
Dedicated Hosts and Dedicated Instances exist for compliance. A Dedicated Host is a physical server reserved entirely for your use — nobody else's virtual machines run on that hardware. This matters for companies with licensing or regulatory requirements (like certain Microsoft or Oracle licenses) that demand physical isolation. The exam tests this at a conceptual level: "a company needs physical server isolation for compliance" → Dedicated Hosts.
#### AMIs: The Blueprints for Your Instances
Every EC2 instance launches from an Amazon Machine Image (AMI) — a template containing the operating system, pre-installed software, and configuration. Think of an AMI as a cookie cutter: you define the shape once, then stamp out identical instances whenever you need them. AWS provides AMIs for Amazon Linux, Ubuntu, Windows Server, and more, and companies create custom AMIs with their application stack baked in so new instances launch ready to serve traffic in minutes.
AMIs appear on the exam in scenarios about launching consistent, repeatable environments quickly — "the company needs to deploy 50 identical web servers" points to a custom AMI. Don't confuse AMIs (templates for instances) with snapshots (backups of EBS volumes).
Here's a quick decision framework:
| Workload characteristic | Best pricing option |
|---|---|
| Short-term, unpredictable | On-Demand |
| Steady, predictable, 1–3 years | Reserved Instances or Savings Plans |
| Can be interrupted, fault-tolerant | Spot Instances |
| Needs physical hardware isolation | Dedicated Hosts |

AWS Lambda: Code Without Servers
Now let's jump to the opposite end of the spectrum. With EC2, you manage the server. With Lambda, there is no server — at least, none that you ever see or manage.
AWS Lambda lets you run code in response to events without provisioning or managing any infrastructure. You upload your function (a small piece of code), tell Lambda what should trigger it (an HTTP request, a file uploaded to S3, a database change, a schedule), and AWS handles everything else: it runs your code when triggered, scales automatically from zero to thousands of parallel executions, and you pay only for the compute time your code actually consumes — measured in milliseconds.
Consider a real example. A photo-sharing app needs to create thumbnails every time a user uploads a photo. The old way: run a server 24/7 waiting for uploads, paying for idle time between uploads. The Lambda way: a function triggers automatically when a photo lands in S3, creates the thumbnail in a few hundred milliseconds, and you pay fractions of a cent. No servers to patch, no capacity to plan, no idle costs.
The exam tests Lambda with trigger words: "serverless," "event-driven," "no infrastructure to manage," "pay only for compute time used," "automatic scaling." If a scenario describes code that runs in response to events (file uploads, database changes, HTTP requests) and the company doesn't want to manage servers, the answer is Lambda. Also know: Lambda functions have a maximum execution time of 15 minutes — they're for short tasks, not long-running processes.
The "serverless" label confuses people. There are servers — they're just AWS's problem, not yours. Serverless means you don't provision, patch, scale, or pay for idle server capacity. It's a shift from "renting computers" to "renting code execution."
Lambda's event sources are worth understanding because the exam describes them in scenarios. A Lambda function can be triggered by: an S3 event (file uploaded), a DynamoDB stream (database item changed), an API Gateway HTTP request (someone hits your API), a CloudWatch scheduled event (run every night at midnight), or an SQS message (work queued up). The pattern is always the same — something happens, code runs in response.
Lambda also has limits the exam occasionally probes. Functions time out after a maximum of 15 minutes, so Lambda is wrong for long-running jobs like training machine learning models or processing multi-hour video renders — those belong on EC2. Memory is configurable (which proportionally scales CPU), and concurrency limits control how many simultaneous executions can run. For the CLF-C02 level, just remember: short, event-driven tasks = Lambda; long-running processes = EC2.
Elastic Beanstalk: The Easy Button for Applications
Between EC2's full control and Lambda's zero management sits Elastic Beanstalk — and it's exactly what it sounds like: the easy button for deploying applications.
With Elastic Beanstalk, you upload your application code (in Java, Python, Node.js, PHP, Ruby, Go, .NET, or Docker), and Beanstalk automatically provisions the EC2 instances, load balancer, database, and networking needed to run it. It handles deployment, capacity provisioning, load balancing, and health monitoring. You keep full control of the underlying resources — you can SSH into the EC2 instances Beanstalk creates — but you don't have to assemble the infrastructure yourself.
Think of the spectrum this way: EC2 is buying ingredients and cooking from scratch. Beanstalk is a meal kit — the ingredients are pre-measured and the recipe is included, but you're still cooking. Lambda is ordering delivery — food just arrives.
Beanstalk appears on the exam in scenarios where developers want to deploy applications quickly without managing infrastructure details, but still want control over the underlying resources. Key differentiator from Lambda: Beanstalk is for traditional long-running applications (web apps, APIs); Lambda is for short event-driven functions.
It's worth pausing on how Beanstalk differs from just using EC2 directly, because the exam probes this boundary. With plain EC2, you decide how many instances to run, you set up the load balancer, you configure auto-scaling rules, you wire up the database. With Beanstalk, you describe the application and Beanstalk assembles all of that for you — but the EC2 instances it creates are still yours: you can log into them, install monitoring agents, and customize them. Companies choose Beanstalk when they want EC2's control without EC2's assembly work. Startups love it because a two-person team can deploy like a twenty-person ops team.
Amazon Lightsail: Simplicity for Small Projects
Lightsail is AWS's simplest compute offering — virtual private servers with predictable, flat-rate monthly pricing starting at just a few dollars. It bundles compute, storage, and networking into one easy package with a simplified console. It's designed for people who find the full AWS console overwhelming: small business websites, blogs, development sandboxes, student projects.
Lightsail is a minor exam topic. Know it as the "simple, predictable pricing, small projects" option — AWS's answer to basic VPS hosting. If a scenario mentions a small business wanting simple monthly pricing for a basic website, Lightsail fits.
Compute Decision Guide
When the exam gives you a scenario, run through this mental checklist:
- Need full OS control or custom software? → EC2
- Short code triggered by events, no server management? → Lambda
- Deploy a web app fast, keep infrastructure control? → Elastic Beanstalk
- Simple website, predictable low cost? → Lightsail
- Containers? → That's ECS/EKS territory (beyond CLF-C02's depth, but know the names: Elastic Container Service and Elastic Kubernetes Service run containerized applications)
And a final exam-day reminder on compute pricing, since it's the single most tested sub-topic in this chapter: On-Demand = flexibility at full price; Reserved/Savings Plans = commitment for up to 72% off; Spot = up to 90% off but interruptible; Dedicated Hosts = physical isolation for compliance. If you can recite that mapping cold, you've banked several exam questions before you even sit down.
Storage: Where Your Data Lives
Every application needs somewhere to put its data, and "data" isn't one thing — it's files, disk volumes, shared folders, archives, and backups, each with different access patterns. AWS's storage services each solve a different piece of the puzzle. The exam tests whether you can match the data's characteristics to the right service.

Amazon S3: The Infinite Hard Drive
Amazon Simple Storage Service (S3) is AWS's object storage — and arguably the most important storage service to understand for the exam. Here's the mental model: S3 is an effectively infinite hard drive in the cloud where you store objects (files) inside buckets (folders, roughly).
Key concepts the exam tests:
Objects and buckets. You store files (objects) in buckets. Bucket names are globally unique across all of AWS — there's only one bucket named "my-company-backup" in the entire world. Objects can be up to 5 TB each, and a bucket can hold unlimited objects.
Durability and availability. S3 is designed for 99.999999999% (eleven 9s) durability — meaning if you store 10 million objects, you'd statistically lose one every 10,000 years. It achieves this by automatically replicating your data across multiple facilities. Standard S3 also offers 99.99% availability.
S3 storage classes are where the exam really digs in. Not all data needs instant access, so why pay instant-access prices for all of it? S3 offers tiers:
- S3 Standard: For frequently accessed data. Highest cost, millisecond access. Your active website assets, daily-used files.
- S3 Intelligent-Tiering: Automatically moves data between access tiers based on usage patterns. For data with unknown or changing access patterns — set it and forget it.
- S3 Standard-IA (Infrequent Access): For data accessed less than once a month but needing instant retrieval when accessed. Lower storage cost, but you pay a retrieval fee. Backups, disaster recovery files.
- S3 Glacier Instant Retrieval / Flexible Retrieval / Deep Archive: Archive tiers for data rarely or almost never accessed. Deep Archive is the cheapest storage in AWS — pennies per GB per month — but retrieval takes up to 12 hours. Think: regulatory archives, medical records retention, old financial data you legally must keep but will probably never read.
Storage class questions are extremely common. The pattern: the scenario describes how often data is accessed, and you match it to the class. "Accessed daily" → Standard. "Accessed once a month" → Standard-IA. "Archived for compliance, rarely retrieved" → Glacier Deep Archive. "Access patterns unpredictable" → Intelligent-Tiering. Also know that moving data to cheaper classes is a core cost-optimization strategy.
Versioning keeps multiple versions of an object in the same bucket — every time you overwrite a file, the old version is preserved. This protects against accidental deletion and overwrites. Once enabled, it's a powerful safety net.
Lifecycle policies automate the storage-class transitions. You write rules like: "move objects to Standard-IA after 30 days, to Glacier after 90 days, delete after 7 years." The exam loves lifecycle policies in cost-optimization scenarios — they're how companies automatically push aging data to cheaper tiers without manual effort.
S3 use cases to remember: static website hosting, data backup, data lakes for analytics, storing application assets (images, videos). S3 is object storage — it's not a file system you mount, and it's not a database.
A word on S3 security. By default, S3 buckets are private — nobody can access your objects unless you explicitly grant permission. Companies control access with bucket policies (JSON documents stating who can do what) and can enable encryption so stored data is unreadable without the keys. The exam tests this at a conceptual level: S3's default is private, and public access must be deliberately configured. When a scenario mentions accidentally exposed data, the root cause is misconfigured permissions, not an S3 default — S3 never makes buckets public on its own.
Cross-Region Replication (CRR) automatically copies objects from a bucket in one AWS Region to a bucket in another. Companies use it for disaster recovery (a backup copy on the other side of the world), for lower-latency access (users in Europe read from a European copy), and for compliance (data must exist in specific geographic locations). The exam tests CRR at a conceptual level: "the company needs its S3 data automatically copied to another Region" → Cross-Region Replication. Note that versioning must be enabled on both buckets for replication to work.
Watch for the distinction between replication and versioning. Versioning keeps history of an object in the same bucket (protection against overwrites). Cross-Region Replication copies objects to a different bucket in a different Region (disaster recovery, latency, compliance). The scenario's goal tells you which one fits.
EBS vs. Instance Store: Disks for Your EC2 Instances
When you launch an EC2 instance, it needs a hard drive. AWS gives you two kinds, and confusing them is a classic exam mistake.
Amazon Elastic Block Store (EBS) provides persistent block storage volumes that you attach to EC2 instances — like plugging an external hard drive into a server. "Persistent" is the key word: EBS volumes survive independently of the instance. If you stop or terminate the EC2 instance, the EBS volume (and its data) still exists. EBS volumes can be snapshotted (backed up to S3), resized, and moved between instances in the same Availability Zone. There are different volume types: gp3/gp2 (general purpose SSD — the default), io2/io1 (provisioned IOPS SSD for demanding databases), st1/sc1 (hard disk drives for throughput-heavy or cold data).
Instance store is the opposite: temporary storage physically attached to the host computer running your EC2 instance. It's fast, but ephemeral — when the instance stops or terminates, the data is gone forever. Think of it as RAM's bigger cousin: great for caches, buffers, and temporary processing files; terrible for anything you can't afford to lose.
One practical detail: some EC2 instance types only come with instance store volumes (no EBS by default), particularly storage-optimized families. This surprises people who assume every instance has persistent disk. The exam doesn't go this deep, but the principle is worth internalizing — always check what kind of storage your instance type provides before trusting it with important data.
The exam tests this distinction directly: "Which storage persists independently of the EC2 instance?" → EBS. "A company needs temporary high-speed storage for a cache that can be rebuilt" → instance store. Remember: EBS = persistent, instance store = ephemeral. If the scenario mentions data that must survive a reboot, it's EBS every time.
Amazon EFS: Shared File Storage
Amazon Elastic File System (EFS) provides shared file storage that multiple EC2 instances can access simultaneously — like a network drive for the cloud. While EBS attaches to one instance, EFS can be mounted by hundreds of instances at once. It's elastic (grows and shrinks automatically), and it's a natural fit for content management systems, shared web server content, or any workload where multiple servers need the same files.
The differentiator the exam tests: EBS = one instance; EFS = many instances sharing the same files. "Multiple EC2 instances need shared access to the same files" → EFS.
AWS Storage Gateway: Bridging On-Premises and Cloud
Not every company is ready to move everything to the cloud at once. AWS Storage Gateway is a hybrid service — a virtual or physical appliance that sits in a company's on-premises data center and connects it to AWS cloud storage. It lets companies keep using their existing applications while their data is seamlessly backed up to, cached from, or tiered into S3, Glacier, or EBS.
Storage Gateway is a minor topic. Know it as the hybrid storage bridge: connects on-premises environments to AWS cloud storage. The trigger phrase is "hybrid" or "on-premises data center needs to use cloud storage."
Storage Gateway comes in three flavors, though the exam only expects you to recognize the concept: File Gateway (presents S3 as a network file share your existing servers can use), Volume Gateway (presents cloud-backed iSCSI volumes to on-premises servers), and Tape Gateway (replaces physical tape backup libraries with virtual tapes stored in S3 and Glacier). The common thread: your on-premises applications keep working exactly as before, while AWS quietly becomes the storage behind them. It's the "migrate without rewriting" story that convinces cautious enterprises to start their cloud journey.
Storage Decision Guide
| Data characteristic | Best service |
|---|---|
| Files/objects, accessed over the internet | S3 |
| Rarely accessed archive data | S3 Glacier Deep Archive |
| Disk volume for one EC2 instance, must persist | EBS |
| Temporary fast scratch space | Instance store |
| Shared files across many EC2 instances | EFS |
| Connect on-premises storage to AWS | Storage Gateway |

Databases: Where Your Structured Data Lives
Here's a truth that surprises beginners: there's no single "best" database. Relational databases, key-value stores, data warehouses, and in-memory caches each exist because they solve fundamentally different problems. AWS offers a managed version of each — "managed" meaning AWS handles patching, backups, and maintenance while you focus on your data. The exam tests whether you can match the workload to the database type.
Amazon RDS: Managed Relational Databases
Amazon Relational Database Service (RDS) is AWS's managed relational database offering. "Relational" means data organized in tables with rows and columns, queried with SQL — the model behind MySQL, PostgreSQL, Oracle, and SQL Server for decades. RDS supports all of these engines (plus Amazon Aurora, AWS's own high-performance MySQL/PostgreSQL-compatible engine), and AWS handles the undifferentiated heavy lifting: provisioning, patching, backups, and failover.
The killer feature for the exam is Multi-AZ deployments. With one click, RDS maintains a standby copy of your database in a different Availability Zone. If the primary fails, RDS automatically fails over to the standby. Your application keeps running; your users never notice. This is the textbook answer for "high availability for a relational database."
Read Replicas are the companion feature: read-only copies of your database that offload read traffic. If your application does 90% reads and 10% writes, replicas let you scale reads horizontally without overloading the primary.
RDS appears in scenarios involving traditional applications that need SQL, transactions, and complex queries — e-commerce sites, business applications, anything with structured data and relationships. "Managed relational database with automatic failover" → RDS Multi-AZ. "Need to scale database reads" → Read Replicas. Aurora is worth knowing by name as AWS's high-performance proprietary engine compatible with MySQL and PostgreSQL.
A note on backups. RDS automates backups with a configurable retention period (up to 35 days), and you can restore to any point in time within that window. Manual snapshots are kept until you delete them. The exam occasionally tests this: automated backups handle the "oops, we need yesterday's data" case; snapshots handle the "keep this copy forever" case.
Amazon DynamoDB: Serverless NoSQL
DynamoDB is AWS's managed NoSQL database — specifically a key-value and document store. Forget tables with fixed schemas; DynamoDB stores items identified by keys, and it delivers single-digit millisecond response times at any scale. It's serverless: no servers to provision, automatic scaling, pay-per-request pricing.
When does NoSQL beat relational? When your data doesn't fit neat tables, when you need massive scale with predictable low latency, or when your access patterns are simple key lookups rather than complex joins. Real examples: user session storage, shopping carts, mobile app backends, gaming leaderboards, IoT sensor data.
The exam contrasts DynamoDB with RDS constantly. "Needs single-digit millisecond latency at massive scale" → DynamoDB. "Key-value data model" → DynamoDB. "Serverless database, no infrastructure to manage" → DynamoDB. If the scenario mentions SQL, joins, or complex queries, it's RDS; if it mentions key-value, extreme scale, or millisecond latency, it's DynamoDB.
DynamoDB's pricing is also worth a passing understanding. It offers on-demand mode (pay per read/write request — great for unpredictable traffic) and provisioned mode (you declare capacity in advance — cheaper for steady, predictable workloads). This mirrors the EC2 pricing logic from earlier in the chapter: pay-as-you-go flexibility versus committed-use discounts. The exam rarely goes deeper than the concept, but recognizing the pattern — AWS consistently offers both models — helps you reason through unfamiliar questions.
Amazon Redshift: The Data Warehouse
Redshift is AWS's data warehouse service — built for analytics, not transactions. Here's the distinction that matters: RDS handles your operational database (processing orders right now), while Redshift handles your analytical workload (analyzing ten years of order history to find trends). Data warehouses use columnar storage and massively parallel processing to crunch petabytes of historical data for business intelligence.
Redshift = analytics and business intelligence over large historical datasets. "The company needs to run complex analytical queries over petabytes of historical data" → Redshift. Don't confuse it with RDS (transactions) or DynamoDB (key-value speed).
Amazon ElastiCache: Speed Through Memory
ElastiCache provides managed in-memory caching using Redis or Memcached. The concept is simple: RAM is roughly a million times faster than disk. By caching frequently accessed data in memory, applications avoid hitting the database for every request. A news website caches its homepage; an e-commerce site caches product listings; a gaming platform caches leaderboards.
ElastiCache = caching to improve read performance and reduce database load. "Application needs sub-millisecond data access" or "reduce load on the database from repeated reads" → ElastiCache. It's a performance layer in front of your database, not a database replacement.
Database Decision Guide
| Workload characteristic | Best service |
|---|---|
| Traditional app, SQL, transactions | RDS |
| High availability for relational DB | RDS Multi-AZ |
| Scale database reads | RDS Read Replicas |
| Key-value, massive scale, millisecond latency | DynamoDB |
| Analytics over huge historical datasets | Redshift |
| Cache frequently read data for speed | ElastiCache |

Compute vs. Storage vs. Database: Keeping Them Straight
Before the practice questions, it's worth pausing on a confusion the exam deliberately creates. Beginners mix up these categories because AWS names don't always help. Here's the mental sort:
- Compute answers "where does code run?" — EC2, Lambda, Beanstalk, Lightsail. If the scenario is about running an application, processing files, or executing logic, you're in compute territory.
- Storage answers "where do files live?" — S3, EBS, EFS, instance store, Storage Gateway. If the scenario is about keeping objects, disk volumes, shared files, or archives, you're in storage territory.
- Databases answer "where does structured data live?" — RDS, DynamoDB, Redshift, ElastiCache. If the scenario mentions SQL, key-value lookups, analytics, or caching, you're in database territory.
A question might say: "A company needs to store user profile photos durably and serve them to a mobile app." Photos are files → S3 (storage), not a database. Another might say: "A company needs to store user preferences as key-value pairs with millisecond access." That's structured data with key lookups → DynamoDB (database), not S3. The exam rewards this categorical thinking.
Putting It All Together: A Real Architecture
Let's tie everything together with a scenario — the kind of thinking the exam rewards.
Imagine you're advising a startup building a photo-sharing app. Users upload photos from their phones, browse feeds, and the company wants analytics on usage trends. Here's how the services combine:
- Uploads land in S3 Standard (durable, internet-accessible object storage). A lifecycle policy moves photos older than 90 days to Glacier for cheap long-term retention.
- A Lambda function triggers on each upload to generate thumbnails — no servers to manage, pay per execution.
- User accounts and photo metadata (who uploaded what, when) live in DynamoDB — key-value lookups at millisecond speed as the user base grows.
- The marketing team runs monthly trend reports against years of usage data in Redshift.
- The main web application runs on EC2 (they need custom software installed), using Reserved Instances for the steady production workload and Spot Instances for the nightly batch thumbnail reprocessing.
- Frequently viewed profile data is cached in ElastiCache so the database isn't hammered on every page load.
- Database backups go to S3 Standard-IA — accessed rarely, but instantly available if disaster strikes.
Notice how every choice follows from the workload's characteristics. That's the exam's game: read the scenario, identify the characteristics, match the service. There are no trick questions here — only pattern recognition, and now you have the patterns.
One more scenario to sharpen the skill — a question-style drill. A healthcare company must store patient scan images for 10 years (legal requirement), access them roughly twice a year, and keep costs minimal. Walk through it: images are files → storage category. Retained 10 years, rarely accessed, cost-sensitive → S3 Glacier Deep Archive. If instead the scans were accessed weekly by doctors, the answer shifts to S3 Standard-IA (instant retrieval matters). Same data, different access pattern, different service. The exam changes one variable at a time exactly like this — train yourself to spot which variable changed.
End-of-Chapter Test
1. A company runs a production e-commerce website on EC2 instances with steady traffic 24/7. They want to reduce compute costs for this predictable workload over the next 3 years. Which pricing option should they choose?
- A. Spot Instances
- B. On-Demand Instances
- C. Reserved Instances
- D. Dedicated Hosts
2. A media company needs to process video files uploaded by users. The processing job takes 5 minutes per file, can be interrupted and resumed, and runs mostly overnight. Which EC2 pricing option provides the greatest cost savings?
- A. On-Demand Instances
- B. Reserved Instances
- C. Spot Instances
- D. Dedicated Instances
3. A developer wants to run a small piece of code automatically every time a file is uploaded to an S3 bucket. They do not want to provision or manage any servers. Which service should they use?
- A. Amazon EC2
- B. AWS Lambda
- C. Amazon Elastic Beanstalk
- D. Amazon Lightsail
4. A company stores 500 TB of financial records that must be retained for 7 years for regulatory compliance. The records are almost never accessed. Which S3 storage class is MOST cost-effective?
- A. S3 Standard
- B. S3 Standard-IA
- C. S3 Intelligent-Tiering
- D. S3 Glacier Deep Archive
5. A startup's application data has unpredictable access patterns — some months files are accessed daily, other months barely at all. They want S3 to automatically optimize storage costs without manual intervention. Which storage class should they use?
- A. S3 Standard
- B. S3 Intelligent-Tiering
- C. S3 Glacier Flexible Retrieval
- D. S3 Standard-IA
6. An EC2 instance is terminated accidentally. The company needs the data from its attached disk volume to still be available. Which storage type provides this persistence?
- A. Instance store
- B. Amazon EBS
- C. Amazon S3
- D. Amazon EFS
7. Three web servers need simultaneous read-write access to the same shared configuration files. Which storage service should they use?
- A. Amazon EBS
- B. Instance store
- C. Amazon EFS
- D. S3 Glacier Deep Archive
8. A company needs a managed SQL database with automatic failover to a standby instance in another Availability Zone. Which RDS feature provides this?
- A. Read Replicas
- B. Multi-AZ deployment
- C. Amazon Aurora
- D. ElastiCache
9. A mobile gaming company needs a database that delivers single-digit millisecond response times for millions of player score lookups per second. The data model is simple key-value pairs. Which database service is the BEST fit?
- A. Amazon RDS
- B. Amazon DynamoDB
- C. Amazon Redshift
- D. Amazon ElastiCache
10. A retail company wants to analyze 5 years of sales history (several petabytes) to identify purchasing trends for a business intelligence dashboard. Which service is designed for this workload?
- A. Amazon RDS
- B. Amazon DynamoDB
- C. Amazon Redshift
- D. AWS Lambda
11. An application's database is experiencing high read traffic that is slowing down response times. Most queries request the same product catalog data repeatedly. Which service would BEST reduce the load on the database?
- A. Amazon Redshift
- B. Amazon ElastiCache
- C. Amazon S3
- D. AWS Storage Gateway
12. A company with an on-premises data center wants to back up its local file server data to AWS cloud storage without changing its existing backup software. Which service enables this hybrid approach?
- A. AWS Lambda
- B. Amazon EFS
- C. AWS Storage Gateway
- D. Amazon Lightsail
Answer Key
1. C — Reserved Instances. A steady, predictable 24/7 production workload running for years is the textbook case for Reserved Instances (or Savings Plans), offering up to 72% savings over On-Demand in exchange for a 1- or 3-year commitment.
2. C — Spot Instances. The job can be interrupted and resumed (fault-tolerant), runs during off-hours, and cost savings are the priority — Spot Instances offer up to 90% off for exactly this kind of interruptible batch workload.
3. B — AWS Lambda. Code triggered by events (S3 uploads) with no server management is the defining Lambda use case. EC2 requires server management, Beanstalk is for full applications, and Lightsail is for simple virtual servers.
4. D — S3 Glacier Deep Archive. Data retained for compliance and almost never accessed belongs in the cheapest archive tier. Retrieval takes hours, but for regulatory records that's acceptable — and the storage cost is a fraction of the other classes.
5. B — S3 Intelligent-Tiering. When access patterns are unpredictable or changing, Intelligent-Tiering automatically moves objects between tiers based on actual usage, optimizing cost without manual lifecycle rules.
6. B — Amazon EBS. EBS volumes persist independently of the EC2 instance lifecycle. Instance store data is lost forever when the instance stops or terminates — that's the critical distinction.
7. C — Amazon EFS. EFS is shared file storage mountable by multiple EC2 instances simultaneously. EBS attaches to only one instance at a time, and S3 Glacier is for archival, not shared live file access.
8. B — Multi-AZ deployment. Multi-AZ maintains a synchronous standby in another Availability Zone with automatic failover. Read Replicas scale reads but don't provide automatic failover; Aurora is a database engine, not a failover feature.
9. B — Amazon DynamoDB. Key-value data, massive scale, single-digit millisecond latency — DynamoDB was built for exactly this. RDS is relational (wrong data model), Redshift is for analytics, and ElastiCache is a cache layer, not the primary store.
10. C — Amazon Redshift. Complex analytical queries over petabytes of historical data is the data warehouse use case. RDS handles transactions, DynamoDB handles key-value speed, and Lambda runs code — none are built for large-scale analytics.
11. B — Amazon ElastiCache. Repeated reads of the same data are the classic caching scenario — ElastiCache stores the catalog in memory, serving it in microseconds and sparing the database. Redshift is for analytics, not caching.
12. C — AWS Storage Gateway. The hybrid bridge: it connects on-premises environments to AWS cloud storage while letting companies keep their existing software and workflows. It's the answer whenever "on-premises" and "cloud storage" appear together.