Skip to content

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:

  1. Billing → Budgets → create a $20/month budget with an email alert.
  2. IAM → create user student with console access + a read-only policy (ReadOnlyAccess), plus full access scoped to the training VPC via tags (instructor prepares; discuss why least-privilege).
  3. 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:

  1. 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.
  2. 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>
    
  3. 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:

  1. Route 53: the elhindi.net hosted zone; the ALIAS record for the PWA.
  2. ACM: the TLS certificate (us-east-1 — why? CloudFront requirement).
  3. CloudFront: the distribution — origins, cache behaviours, HTTP→HTTPS redirect, price class, the invalidation history from real deploys.
  4. S3: the origin bucket — Origin Access Control (bucket is not public; only CloudFront can read it — compare with the student's naive public bucket).
  5. The publish pipeline: how a build lands in S3 and triggers an invalidation.
  6. 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.

Quiz

1. Console, CLI, Terraform — what do they have in common? All three are clients of the same AWS APIs; anything you click can be scripted.
2. Why does lab-box need no AWS keys to run aws commands? It has an IAM role; credentials are delivered (and rotated) via the instance metadata service.
3. Why is the production S3 origin not public, and how does CloudFront read it? Public buckets are a classic data-leak vector; Origin Access Control gives the distribution—and only it—signed access to the bucket.
4. An AZ fails. What happens to a well-designed 3-tier app? A badly designed one? Well-designed: LB health checks drop the dead AZ; capacity in the surviving AZs serves traffic; the DB fails over to its standby. Badly designed (single-AZ): outage until the AZ recovers — the cloud version of a single unprotected fibre path.