Module 3 — AWS Core
Goal: understand and use the AWS services that carry 80% of real workloads — IAM, EC2, VPC, S3, CloudFront, Route 53, CloudWatch — through the console and the CLI, anchored by a guided tour of the instructor's live production infrastructure.
3.1 The mental model
- Regions = countries' worth of data centres (eu-west-2 = London). AZs = separate exchanges within a region: independent power/cooling/network.
- Everything is an API call. The console, the CLI, and Terraform are three clients of the same API — which is why infrastructure can be code at all.
- Shared responsibility: AWS secures the building and the hypervisor ("security of the cloud"); you secure your OS, apps, data and IAM ("security in the cloud").
- Pay per use — and per mistake. Budgets first.
Lab 3.1 — Guardrails before anything else
Instructor demonstrates in the console, student observes then repeats what's allowed:
- Billing → Budgets → create a $20/month budget with an email alert.
- IAM → create user
studentwith console access + a read-only policy (ReadOnlyAccess), plus full access scoped to the training VPC via tags (instructor prepares; discuss why least-privilege). - Enable MFA on both instructor root/admin and student accounts. Non-negotiable.
3.2 IAM in 45 minutes
Users, groups, roles, policies. The two questions every policy answers: who can do what to which resource. Roles vs users: roles are assumed (by people, services, or EC2 instances) and are how machines get credentials without stored keys.
# On lab-box — it has an instance role attached (look, no keys anywhere):
aws sts get-caller-identity
aws ec2 describe-instances --filters "Name=tag:Project,Values=cloud-course" \
--query 'Reservations[].Instances[].{id:InstanceId,ip:PublicIpAddress,name:Tags[?Key==`Name`]|[0].Value}' --output table
Talking point: where are the credentials? (Instance metadata service — the role.) Why is this better than an access key in a file? (Rotation, revocation, no leaks in git — a top-3 real-world breach cause.)
3.3 EC2 — compute
Instance families (t = burstable general purpose — your lab boxes), AMIs, user-data (the boot script that configured lab-box — show it), EBS volumes, key pairs, security groups.
Lab 3.3 — Launch, use, terminate
Student launches their own instance, console first, then CLI:
- Console: launch t3.micro, Ubuntu 24.04, into the training VPC/subnet, with the
course security group and key pair. SSH in. Run
htop. Terminate it. - Same again, CLI, from lab-box:
aws ec2 run-instances --image-id $(aws ssm get-parameters --names \ /aws/service/canonical/ubuntu/server/24.04/stable/current/amd64/hvm/ebs-gp3/ami-id \ --query 'Parameters[0].Value' --output text) \ --instance-type t3.micro --key-name cloud-course \ --subnet-id <subnet-id> --security-group-ids <sg-id> \ --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=student-test},{Key=Project,Value=cloud-course}]' aws ec2 describe-instances --filters "Name=tag:Name,Values=student-test" \ --query 'Reservations[].Instances[].State.Name' aws ec2 terminate-instances --instance-ids <id> - Reflection: which was faster? Which is repeatable? Which could a pipeline run?
3.4 VPC — the network you already understand
Walk the actual training VPC in the console: VPC → subnets → route tables → IGW → security groups. Trace a packet from the student's laptop to nginx on lab-box: laptop → internet → IGW → route table → subnet → SG check → instance.
Security groups (stateful, instance-level, allow-only) vs NACLs (stateless, subnet-level, allow+deny) — SGs are what you'll touch 99% of the time.
Lab 3.4 — Break glass
- Student removes the SSH rule from the course SG (console) — their own session survives (stateful! established connections persist) but new connections fail. Restore it. Discuss the lock-yourself-out failure mode and why change control matters even without a van.
3.5 S3 + CloudFront — and the big reveal
S3: buckets, keys, versioning, lifecycle, "11 nines" durability, block-public-access. CloudFront: global edge caches, origins, TTLs, invalidations, free TLS via ACM.
Lab 3.5 — Host a site the production way
aws s3 mb s3://cloud-course-<student>-site
echo "<h1>Deployed by CLI</h1>" > index.html
aws s3 cp index.html s3://cloud-course-<student>-site/
aws s3 ls s3://cloud-course-<student>-site/
Then front it with the course's CloudFront distribution (or create one — takes ~10 minutes to deploy; use the wait to teach edge locations and cache behaviour), and verify with the module-2 tools:
curl -sI https://<distribution>.cloudfront.net | grep -i x-cache # Miss → Hit
Instructor show/tell — the production tour (the heart of module 3)
Read-only walk through the instructor's real account:
- Route 53: the
elhindi.nethosted zone; the ALIAS record for the PWA. - ACM: the TLS certificate (us-east-1 — why? CloudFront requirement).
- CloudFront: the distribution — origins, cache behaviours, HTTP→HTTPS redirect, price class, the invalidation history from real deploys.
- S3: the origin bucket — Origin Access Control (bucket is not public; only CloudFront can read it — compare with the student's naive public bucket).
- The publish pipeline: how a build lands in S3 and triggers an invalidation.
- If the course website is deployed: reveal that this very course is served by the same pattern, from the Terraform in this repo.
Student exercise afterwards: draw the whole architecture from memory; annotate each arrow with the OSI layer and protocol.
3.6 CloudWatch (preview) + cost hygiene
- CloudWatch metrics for lab-box: CPU, network, status checks. Set one alarm (CPU > 80% for 5 min → email). Module 7 replaces/deepens this with Prometheus — discuss when native CloudWatch is enough.
- Cost Explorer: find what the course has spent so far. Tag-based filtering on
Project=cloud-course— this is why we tag everything.