You don't need to memorize 200 services to start your AWS journey. But you do need to understand the foundations. Here's everything I wish someone had explained to me before I started studying for my AWS certification.
1. What Even Is Cloud Computing?
Let's start from the very beginning. Cloud computing sounds fancy, but the core idea is simple: there's a physical server somewhere, and you're renting it over the internet.
Instead of buying your own hardware, setting up a server room, and hiring people to maintain it — you use someone else's infrastructure (like AWS) and pay only for what you use.
Here's the official NIST definition:
"A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of **configurable computing resources* that can be rapidly provisioned and released with minimal management effort or service provider interaction."*
Let's break that down into human language:
- On-demand → You get resources whenever you want them
- Shared pool → Multiple customers share the same physical infrastructure
- Configurable → You choose how much CPU, RAM, storage you need
- Rapidly provisioned and released → Spin up a server in minutes, shut it down when you're done
- Minimal management effort → No need to physically touch any hardware
2. What's Actually Behind the "Cloud"?
Behind the cloud, there are real, physical server racks sitting in massive data centers around the world. AWS has these data centers spread across the globe, and the infrastructure is organized in a clear hierarchy:
Region
A large geographic area (e.g., eu-west-1 for Ireland, us-east-1 for N. Virginia). You choose a region based on where your users are, compliance requirements, or pricing.
Availability Zone (AZ)
Each Region contains multiple AZs (e.g., eu-west-1a, eu-west-1b, eu-west-1c). An AZ is one or more data centers with independent power, networking, and connectivity. Multiple AZs exist for redundancy — if one goes down, the others keep running.
Edge Locations / Points of Presence (PoP)
These are smaller, lightweight locations spread even more widely than Regions. They're used primarily for caching content closer to end users.
3. Edge Networks and CDN — Speed Matters
Imagine your origin server is in the US, but a user in Southeast Asia wants to load your website. Without any optimization, every single request travels across the Pacific Ocean and back. That's slow.
This is where Edge Networks and CDN (Content Delivery Network) come in.
How it works:
- Your original content lives on the Origin Server (e.g., in
us-east-1) - AWS caches copies of your static content (images, CSS, JS, videos) at PoP / Edge Locations around the world
- When a user in Singapore requests your site, they get the cached version from the nearest PoP — not from the US
- Result: dramatically lower latency
CDN vs Edge Network — are they the same thing?
Not exactly. The Edge Network is the infrastructure — the distributed network of servers worldwide. CDN is the most well-known use case of that infrastructure. In practice, people use the terms interchangeably, and that's mostly fine.
AWS's CDN service is called CloudFront, and it leverages these Edge Locations.
4. Virtualization and the Hypervisor
Here's where it gets interesting. When you launch an EC2 instance, you're not getting a dedicated physical server. Here's what's actually happening:
- Host Computer → The physical AWS server rack in a data center
- Host OS → The operating system running on that physical machine
- Hypervisor → Software that sits on top of the Host OS and splits the physical machine into multiple virtual machines
- Your EC2 Instance → One of those virtual machines
So if a physical server has 64 CPUs and 256 GB RAM, the hypervisor might split it into four isolated instances of 16 CPUs / 64 GB RAM each. Different customers can be using the same physical hardware without ever knowing about each other — completely isolated.
AWS built their own hypervisor called Nitro, which operates at the hardware level for minimal performance overhead.
Key takeaway: EC2 instances are virtual slices of physical servers, managed by a hypervisor. Multiple instances from different customers can live on the same physical machine, fully isolated from each other.
5. The Shared Responsibility Model — Who's Responsible for What?
This is probably the most important concept for your certification exam. AWS and the customer share security responsibilities, but the line between them is very clear.
Security OF the Cloud → AWS's Job
AWS is responsible for protecting the infrastructure that runs all the services:
- Physical security — data center access, cameras, biometric entry
- Hardware — servers, storage, networking equipment
- Software — compute, storage, database, networking services
- Global infrastructure — Regions, Availability Zones, Edge Locations
- Host OS & Hypervisor — you can't even access these
Security IN the Cloud → Your Job
You are responsible for everything you put in and configure on the cloud:
- Customer data — whatever you upload, store, or process
- Platform, applications & IAM — who has access to what, roles, permissions, secret keys
- OS & firewall configuration — if you launched an EC2 with Ubuntu, patching it is on you
- Encryption — client-side, server-side, in-transit, at-rest decisions
- Network traffic protection — security groups, NACLs, VPN configurations
The Three Control Categories
| Category | Who? | Examples |
|---|---|---|
| Inherited | AWS only | Physical & environmental security, host OS, physical servers |
| Shared | Both | Patch management, configuration management, awareness & training |
| Customer-Specific | Customer only | Guest OS, custom applications, data encryption strategies |
Quick Quiz — Test Yourself
| Question | Answer |
|---|---|
| Patching your EC2 instance's operating system? | You |
| Guest OS security patches? | You |
| Running the host OS and virtualization layer? | AWS |
| Managing IAM user access and secret keys? | You |
| Maintaining the server under your Lambda functions? | AWS |
| Physical security of data centers? | AWS |
| Encryption-at-rest strategy for your RDS database? | You |
Simple rule of thumb: If you can configure it in the AWS Console or CLI → it's your responsibility. If you can't even touch it → it's AWS's responsibility. If both sides need to do their part → it's shared.
Think of it like renting an apartment: AWS gives you a secure building (locked doors, fire alarms, security guards). But whether you lock your own door, put your valuables in a safe, or leave your windows open — that's entirely on you.
6. AWS Support Plans — Developer vs Business
When you create an AWS account, you'll need to choose a support plan. Here's the practical difference between the two most common ones:
| Feature | Developer (~$29/mo) | Business (~$100/mo or % of usage) |
|---|---|---|
| Who can open tickets | 1 person (primary contact) | Unlimited team members |
| Response time (critical) | 12 hours | 1 hour |
| Support channels | Email only | Email + Phone + Chat |
| Trusted Advisor | Limited checks | Full access |
| Third-party software support | No | Yes |
Which one should you pick?
- Developer → Great for learning, experimenting, and building prototypes. Start here if you're just getting started.
- Business → Essential when you're running production workloads with real users. The 1-hour critical response time alone is worth it when something goes down.
Good news: You can start with Developer and upgrade to Business anytime from the AWS Console (Support Center > Change Plan). Billing is prorated, so you only pay for what you use. You can also downgrade later if needed.
Wrapping Up
Before diving into specific services like S3, Lambda, or DynamoDB, make sure these foundational concepts are solid:
- Cloud = renting virtual resources from physical infrastructure over the internet
- Regions → AZs → Edge Locations form the backbone of AWS's global presence
- CDN / Edge Networks cache content close to users for speed
- Hypervisors split physical servers into isolated virtual machines (EC2 instances)
- Shared Responsibility Model — know what's yours vs what's AWS's (this will be on the exam)
- Support Plans can be upgraded/downgraded as your needs evolve
These aren't glamorous topics, but they're the bedrock everything else is built on. Nail these, and the rest of your certification journey will make a lot more sense.
Happy cloud learning! If you found this helpful, drop a reaction or follow for more AWS certification notes.
Top comments (0)