AWS Overview
AWS has 200+ services. This page shows how they fit together, why networking underpins everything, and how the labs in this course are organised.
The Big Picture
┌─────────┐
│ Users │
└────┬────┘
│
v
┌────────────────┐ ┌───────────────┐ ┌────────────────┐
│ Peered VPC │◄─peering│ Internet │ │ Remote workers │
│ (EC2 fleet) │ │ Gateway │ └───────┬────────┘
└────────────────┘ └───────┬───────┘ │
│ v
│ ┌───────────────┐
│ │ Client VPN │
│ └───────┬───────┘
v │ Region: us-east-1
┌────────────────┐ ┌───────┴──────────────────────────┴──────────────────────────────┐
│ On-prem │ │ VPC │
│ data centre │ │ ┌────────────────────────────────────────────────────────────┐ │
└───────▲────────┘ │ │ Availability Zone 1 │ │
│ │ │ ┌─────────────────┐ ┌─────────────────────────────┐ │ │
│ │ │ │ Public subnet │ │ Private subnet │ │ │
│ │ │ │ NAT Gateway │─────►│ EC2 + RDS primary │─┼─┼──► PrivateLink ──► SaaS provider VPC
│ │ │ └─────────────────┘ └──────────────┬──────────────┘ │ │
│ │ └───────────────────────────────────────────┼────────────────┘ │
│ │ replication ◄───────┘ │
│ │ ┌───────────────────────────────────────────┼────────────────┐ │
│ │ │ Availability Zone 2 │ │ │
│ │ │ ┌─────────────────┐ ┌──────────────▼─────────────┐ │ │
└──── Transit ─────┼──┼──►│ Public subnet │ │ Private subnet │ │ │
Gateway │ │ │ NAT Gateway │─────►│ EC2 + RDS replica │ │ │
│ │ └─────────────────┘ └────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Gateway endpoint Interface endpoint │
│ (S3 / DynamoDB) (SNS / SQS / Lambda / CW) │
└───────────────┬────────────────────────────┬────────────────────┘
│ │
v v
┌─────────────┐ ┌──────────────┐
│ S3 / │ │ AWS │
│ DynamoDB │ │ services │
└─────────────┘ └──────────────┘A real AWS environment is never a single service in isolation. It is a VPC (your private network) with compute, databases, and load balancers running inside it, connected to the internet, to other VPCs, to on-premises systems, and to managed AWS services.
The diagram above is a typical production layout. Users reach your app through an Internet Gateway and load balancer. Workloads run in private subnets across multiple Availability Zones for resilience. Outbound traffic leaves through NAT Gateways. AWS services like S3, SQS, and Lambda are reached through VPC endpoints or the public AWS API. Beyond the VPC, peering, Transit Gateway, PrivateLink, and VPN/Direct Connect extend the network to partners, SaaS, and your own data centre.
Mental model
Every service lab in this course (EC2, Lambda, RDS, S3, SQS) assumes you understand this diagram. You don't build all of it on day one, but you need to know where each piece sits and how traffic flows between them.
How AWS Is Organised
AWS services group into categories by what they do. You don't need all 200, this course covers the ones backend engineers use daily:
| Category | What it does | Key services in this course |
|---|---|---|
| Networking | Isolate, connect, and secure resources | VPC, subnets, route tables, security groups, ALB, VPC endpoints |
| Compute | Run applications and containers | EC2, ECS |
| Serverless | Run code without managing servers | Lambda, API Gateway |
| Database & Storage | Persist and retrieve data | RDS, DynamoDB, S3, ElastiCache, OpenSearch |
| Messaging | Decouple services and move events | SQS, SNS, EventBridge, Kinesis |
| Observability | Monitor, log, and alert | CloudWatch (metrics, logs, alarms) |
| Security | Control who can do what | IAM (woven into every lab) |
These categories are not independent silos. A Lambda function (serverless) runs inside a VPC (networking), writes to DynamoDB (database) through a VPC endpoint (networking), publishes events to EventBridge (messaging), and logs to CloudWatch (observability). IAM permissions gate every API call across all of them.
Two cross-cutting concepts appear in every lab:
- Regions and Availability Zones: you choose where resources live. Spread across AZs for resilience; pick a region close to your users for latency
- IAM: controls *who* can call an API. Networking controls *whether the packet can arrive*. Both must allow the action
Why Start With Networking
Networking is listed first in the table above for a reason, not because it is the most exciting service, but because it is the layer everything else sits on. An EC2 instance lives in a subnet. RDS is reachable only through security group rules. Lambda functions that need private database access attach to a VPC. S3 is accessed over the network. Even serverless is not networkless.
Mental model: the house analogy
Learning EC2 or Lambda without networking is like installing appliances before understanding plumbing and wiring. The appliance works in isolation, until you plug it in and nothing happens because the circuit is off or the pipe is blocked.
Most learners want to jump straight to compute or serverless labs. That feels productive, until an error message makes no sense. With networking context, you stop asking "why doesn't my Lambda work?" and start asking "can this ENI reach that security group on port 5432?"
When the service looks broken but networking is the cause
| What you see | What you blame | What's actually wrong |
|---|---|---|
Connection timed out to RDS | Database is broken | Security group doesn't allow inbound from the app's SG on port 5432 |
EC2 can't curl the internet | Instance is broken | No route to 0.0.0.0/0 via NAT Gateway or IGW, or wrong subnet tier |
| Lambda timeout connecting to ElastiCache | Lambda is broken | Lambda not in VPC, or in wrong subnet, or SG mismatch |
| ALB returns 502 Bad Gateway | Application is broken | Target group has no healthy targets, often SG or health check path |
| S3 access denied from private subnet | IAM is broken | No VPC endpoint and no NAT route, traffic never reaches S3 |
Networking Essentials
You don't need to master every networking concept before opening a lab, but you should recognise these terms when they appear. The networking labs (N1–N10) teach each one hands-on.
| Concept | One-line summary |
|---|---|
| VPC / CIDR | Your isolated IP address range in AWS, everything gets an IP from here |
| Subnets | A slice of the VPC in one AZ, public (internet-facing) or private (internal only) |
| Route tables | Decide where packets go, internet via IGW, outbound via NAT, services via endpoints |
| Security groups | Stateful firewalls on each resource, the first thing to check when connections fail |
| DNS | Resolves hostnames inside the VPC, misconfigured DNS breaks apps silently |
| VPC endpoints | Private paths to AWS services (S3, SQS, etc.) without traversing the internet |
| Load balancers | Distribute traffic across targets. ALB for HTTP, NLB for TCP/UDP |
The full sequence is covered in the networking labs: The VPC Itself through Cross-Cutting End-to-End Scenarios. Each lab builds on the previous one, complete them before moving to compute, serverless, or database labs.
Don't skip the networking labs
Learners who jump straight to EC2 or Lambda labs consistently hit walls at session 2 or 3, security group errors, subnet misconfigurations, or "can't reach the database." The networking labs take longer upfront but save multiples of that time across every subsequent lab.
How the Course Fits Together
After this page and the networking foundation, the rest of the course maps directly onto the service categories above. Each category has concept guides (read first) and hands-on labs (build and break things).
- Compute (EC2, ECS): where instances and containers live, how they scale, and what breaks in production
- Serverless (Lambda, API Gateway): event-driven compute, triggers, cold starts, and API design
- Database & Storage (RDS, DynamoDB, S3, ElastiCache): relational vs NoSQL, caching, object storage, and access patterns
- Messaging (SQS, SNS, EventBridge, Kinesis): queues, pub/sub, event buses, and stream processing
- Observability (CloudWatch): metrics, logs, alarms, and the signals that tell you something is wrong
Every lab follows the same format: read the callout before each step, verify at checkpoints, break things intentionally, and clean up when done. IAM, networking, and billing awareness carry through all of them.