AWS Core Services — The Building Blocks

What you'll learn

• The 4 AWS services that power most apps
• EC2, S3, RDS, Lambda in plain terms
• How they fit together into a real system
• The names that unlock the whole cloud

The four workhorses ⚙️

AWS (Amazon Web Services) is the biggest cloud provider, with 200+ services. Sounds overwhelming — but ~4 services power the vast majority of apps. Learn these and you understand the cloud (Azure and Google have near-identical equivalents under different names).

1. EC2 (Elastic Compute Cloud) = a rented computer. A virtual server in the cloud you can start in a minute, install anything on, and run 24/7. This is IaaS — the raw compute. Need a bigger machine? Resize it. Need ten? Launch ten. When people say "spin up a server," this is usually it.

2. S3 (Simple Storage Service) = an infinite hard drive. Store any file — images, videos, backups, data — with essentially unlimited space, cheaply, accessible from anywhere via a URL. Files live in "buckets." Most websites store their images and user uploads in S3. (Fun fact: misconfigured public S3 buckets are a famous cause of data leaks — remember least privilege from the security track!)

3. RDS (Relational Database Service) = a managed database. It's a SQL database (MySQL/PostgreSQL) that AWS runs for you — handling backups, updates, and scaling. You just connect and query. No installing or maintaining database software yourself.

4. Lambda = run code without a server. This is "serverless": you upload a function, and AWS runs it only when triggered, charging you per execution (often fractions of a cent). No server to manage, no idle cost. Perfect for tasks that run occasionally.

How they combine in a typical app:

User → website → EC2 (or Lambda) runs your code
                    ├── reads/writes data in RDS (database)
                    └── serves images from S3 (storage)

That's a real, production-shaped architecture built from four named boxes. Learn these four and the intimidating AWS console suddenly makes sense.

Regions and Availability Zones 🌍

AWS doesn't run one giant data center — it runs many, grouped into Regions (like us-east-1 in Virginia, or eu-west-1 in Ireland), and each Region contains several Availability Zones (AZs) — physically separate data centers with their own power and cooling, connected by fast private links.

Think of a Region as a city, and its AZs as separate buildings on opposite sides of that city. Why split things up this way?

• Pick a Region close to your users — a user in Japan gets faster load times from ap-northeast-1 (Tokyo) than from Virginia. Lower distance = lower latency.
• Some data must legally stay in-country — data-residency laws (common in finance, healthcare, government) may require EU customer data to stay in an EU Region.
• Spread across AZs for reliability — if you run your EC2 servers in only one AZ and that building loses power, your app goes down. Run copies in two or three AZs in the same Region, and losing one building doesn't take down your app — a load balancer just routes around it.

This is why "multi-AZ" is one of the first things a cloud architect checks: it's cheap insurance against a single data-center failure, and it's entirely different from multi-cloud (which spans providers, not just buildings). Most production AWS systems live in one Region, spread across multiple AZs — global reach and resilience without the complexity of juggling multiple providers.

Real-world case study: The 2017 AWS S3 outage 🔍

On February 28, 2017, an AWS engineer ran a routine command to take a small number of S3 servers offline for debugging in the us-east-1 Region. A typo in the command's input caused it to remove far more capacity than intended, and S3 in that Region went down for about four hours.

Because so many popular websites and apps store files in S3 or depend on services that do, the outage rippled outward: image uploads failed, some smart-home devices stopped responding, and status-check dashboards on other sites couldn't load — because those dashboards themselves stored their icons in the very S3 buckets that were down.

The incident became a textbook lesson in two things covered in this lesson: first, how deeply the modern internet depends on a handful of core services like S3, and second, why spreading critical systems across multiple Regions (not just multiple AZs) matters for anything that truly cannot go down. AWS responded by adding more safeguards around large-scale operational commands — a reminder that even the biggest cloud provider's "four workhorses" are operated by humans who can make a typo.

Summary

• ~4 AWS services power most apps: EC2 (compute), S3 (storage), RDS (database), Lambda (serverless)
• They combine: EC2/Lambda run code, RDS holds data, S3 holds files
• Azure and Google Cloud have equivalents under other names
• Watch S3 permissions — public buckets leak data
• Regions + Availability Zones let you place resources near users and survive a single data-center failure
• The 2017 S3 outage shows how much the internet leans on a few core cloud services

Practice: AWS has a Free Tier — spin up an EC2 instance and an S3 bucket to see them for real. Next: Cloud Networking — connecting these pieces securely.