Skip to content

AWS

Core (cloud infrastructure — AWS breadth across networking, compute, data, delivery, and security) · prereq 01 (DevOps Foundations), 03 (Containers), 04 (Kubernetes & Helm) — the EKS material assumes you already have Kubernetes vocabulary from 04. · ~3–4 days (breadth module — 8 deep-dive submodules spanning networking, edge/DNS, compute, storage/data, IAM/security, resilience/DR, observability, and decoupling/events; wider than the single-topic concept modules). Reality check: this is the 80/20 on-ramp; real fluency runs 100h+ of hands-on practice — Antoine spent ~400h across Kubernetes, Go, and AWS to reach production competence.

Every module before this one taught you infrastructure you can touch and restart yourself — a container, a cluster, a config file. AWS puts a layer between you and the hardware: the network path, the failover, the credential are all now someone else's managed service, and knowing exactly where AWS's responsibility ends and yours begins is what separates a design that survives an AZ outage from one that doesn't. This is the breadth module — AWS across networking, compute, data, delivery, and security: enough of each to design and defend a small production deployment (VPC · EKS · RDS · S3).

TL;DR — in 30 seconds:

  • A subnet is public or private purely by its route table (an IGW route vs none); AWS runs EKS's control plane while you own the data plane, and that split narrows further under Fargate.
  • Storage and databases split by access pattern and resilience need: S3/EBS/EFS by how many things touch the data at once; Multi-AZ (synchronous, automatic failover) vs read replica (asynchronous, read-scaling) vs Multi-Region.
  • Every credential path should end in short-lived, auto-rotating credentials — an IAM role + trust policy
  • STS, or IRSA's OIDC-federated version for an EKS Pod — evaluated under one order: explicit deny wins, else explicit allow, else implicit deny.

Learning objectives

By the end, the junior can:

  • Distinguish public vs private subnets by route-table association (not by "feel"), and explain why a private-subnet resource can still reach the internet outbound (NAT Gateway) but never be reached inbound.
  • Choose between ALB, NLB, and GWLB for a given workload, and state the control-plane/data-plane split AWS owns vs you own in EKS — and how that split shifts under Fargate.
  • Pick the right storage or database primitive for a workload (S3 vs EBS vs EFS; DynamoDB vs RDS; Multi-AZ vs read replica vs Multi-Region) and justify the choice.
  • Explain how IaC (CloudFormation/CDK) and GitOps-based CI/CD change your rollback and environment-promotion story compared to manual changes or a push-based pipeline.
  • Trace how a workload gets AWS credentials without static keys — IAM role, trust policy, sts:AssumeRole (and sts:AssumeRoleWithWebIdentity via OIDC federation for IRSA on EKS Pods specifically) — and evaluate an IAM policy using the explicit-deny-wins order.
  • Frame a resilience or cost conversation using RTO/RPO, the four DR strategies, and the three observability pillars (metrics/logs/traces).
  • Pick the right decoupling primitive (SQS vs SNS vs EventBridge vs Kinesis) for a given event-driven scenario.
Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

1. Learn · acquire the concept

No external course — read this brief, then skim the linked docs.

Mental model (30 minutes) — six clusters, one per pair of Retain themes:

Hold themes 1–6 (networking, compute, data) before moving on; themes 7–12 (delivery, security, operations/ecosystem) are skim-first / reference depth, not required before you continue.

Networking · themes 1–2

A VPC is a regional, logically isolated network you define — its pieces are a CIDR block, subnets, route tables, and gateways.

What makes a subnet "public" or "private" is purely its route table association:

  • Public subnet — a route to an Internet Gateway makes it public.
  • Private subnet — no such route (only a route to a NAT Gateway) makes it private, outbound-only: it can reach the internet outbound but can never be reached inbound.
flowchart LR
    Internet(("Internet"))
    IGW["Internet Gateway (IGW)"]
    NAT["NAT Gateway"]
    subgraph Public["Public subnet"]
      PubRT["Route table:<br/>route to IGW"]
    end
    subgraph Private["Private subnet"]
      Res["Workload (e.g. Pod)"]
      PrivRT["Route table:<br/>no IGW route — only a route to NAT"]
    end
    Internet <-->|"inbound + outbound"| IGW
    IGW <--> PubRT
    Res --> PrivRT
    PrivRT -->|"outbound only"| NAT
    NAT --> IGW

Connecting VPCs:

  • VPC peering is 1-to-1 and not transitive.
  • A Transit Gateway is the hub you reach for once you have more than a couple of VPCs to connect.

Two firewalls — defense in depth, not redundancy:

  • Security groups — stateful, instance-level, allow-only.
  • NACLs — stateless, subnet-level, allow and deny (evaluated in order).

On top of that substrate, three load balancers:

Load balancer Layer What it does
ALB L7 routes HTTP by host/path
NLB L4 pushes raw TCP/UDP at extreme throughput, with a static IP
GWLB L3 threads traffic through inline virtual appliances

Getting traffic to the front door — Route 53 + CloudFront + Global Accelerator round out the traffic-arrival story:

  • Route 53 — Alias records work at the zone apex where CNAME can't; health checks drive automated DNS failover.
  • CloudFront — trades a cache miss for a nearby edge hit.
  • Global Accelerator — skips caching entirely and just routes over the AWS backbone.

Compute — EKS · themes 3–4

AWS runs the control plane; you own the data plane:

flowchart TB
    subgraph CP["AWS-managed — Control plane (HA across 3 AZs)"]
      API["API server"]
      ETCD["etcd"]
      SCHED["Scheduler"]
    end
    subgraph DP["You own — Data plane (worker nodes + everything on them)"]
      MNG["Managed node group"]
      SELF["Self-managed ASG"]
      FAR["Fargate — removes the node<br/>(cost: DaemonSets, privileged Pods, startup speed)"]
    end
    DP -->|"nodes ≤ 1 minor version behind · upgrade order: control plane → add-ons → nodes"| CP
  • Control plane (AWS runs it) — API server, etcd, scheduler, highly available across 3 AZs.
  • Data plane (you own it) — worker nodes and everything running on them, whether a managed node group, a self-managed ASG, or Fargate (which removes the node entirely, at the cost of DaemonSets, privileged Pods, and startup speed).
  • Nodes may trail the control plane by at most one minor version, so upgrades are always control-plane-first, then add-ons, then nodes.

Underneath a node group sit two ordinary knobs:

  • an EC2 purchasing decision — On-Demand / Reserved / Savings Plans / Spot;
  • an ASG scaling policy — target tracking is the default reach-for.

Pod networking and node autoscaling:

  • The VPC CNI gives every Pod a real, routable VPC IP — elegant, but IP-hungry, which is why prefix delegation and secondary CIDRs exist.
  • Karpenter provisions right-sized nodes just-in-time from pending Pods; Cluster Autoscaler just resizes a fixed-shape node group — same job, different philosophy.

Data · themes 5–6

Storage — object vs block vs file:

Storage Type Scope Attachments In Kubernetes
S3 object storage regional — —
EBS block storage single AZ one (fast) EBS CSI driver — StatefulSets, ReadWriteOnce
EFS shared filesystem multi-AZ many EFS CSI driver — ReadWriteMany

S3 is regional object storage at eleven nines of durability (99.999999999%) — AWS's own published figure for the Standard storage class; storage classes and lifecycle rules automate the retrieval-speed-vs-cost trade-off. In Kubernetes that exact EBS-vs-EFS split becomes the EBS CSI driver (StatefulSets, ReadWriteOnce) vs the EFS CSI driver (ReadWriteMany).

Databases — resilience vs read-scaling:

  • Multi-AZ — a synchronous standby for automatic failover, not for scaling reads.
  • Read replicas — asynchronous, and exist for read scaling (and can cross regions).
  • The same AZ-vs-Region distinction reappears one layer up as the DR conversation.

Relational vs key-value:

Database Model Notes
DynamoDB trades joins and schema for effectively unlimited scale at single-digit-millisecond latency
RDS MySQL/PostgreSQL-compatible Aurora is AWS's storage-and-replication upgrade to RDS

Delivery · themes 7–8

Themes 7–12 (Delivery · Security · Operations) are skim-first / reference depth — not required before you continue.

Infrastructure as Code (IaC) replaces console-clicking with version-controlled templates:

  • In CloudFormation, a stack is the live, deployed instance of a template, and a change set previews exactly what an update will add/modify/delete before you commit.
  • CDK is the same engine, just synthesized from a real language instead of hand-written YAML.
  • You meet IaC here first as CloudFormation/CDK; its hands-on, state-centric treatment lands in module 07 (Terraform).

CI/CD:

  • CI means "build and test on every merge."
  • CD splits into delivery (auto-prepared, human-gated release) and deployment (fully automatic, no gate).

Push vs GitOps — the split matters more than it looks:

  • Push — your CI pipeline needs live cluster credentials.
  • GitOps — an in-cluster agent (ArgoCD/Flux) pulls from Git and continuously reconciles the cluster to match it. So a rollback is git revert, and promoting to the next environment is an auditable pull request, not a pipeline re-run with different flags.

Security · themes 9–10

Every IAM decision reduces to one evaluation order:

explicit deny wins, else explicit allow, else implicit deny.

Least privilege means starting from nothing and adding narrowly-scoped allows — not starting from * and subtracting.

Roles beat users for anything automated, because there's no static credential to leak — an EC2 instance profile, or in Kubernetes, IRSA:

flowchart LR
    Pod["Pod"] --> SA["ServiceAccount<br/>(annotated with role ARN)"]
    SA --> OIDC["OIDC federation"]
    OIDC --> STS["sts:AssumeRoleWithWebIdentity"]
    STS --> Trust["IAM role trust policy"]
    Trust --> Creds["short-lived, auto-rotating<br/>credentials → Pod"]
    Creds --> S3[("reads the S3 bucket")]

IRSA is a ServiceAccount annotated with a role ARN, which under the hood is just an automated sts:AssumeRoleWithWebIdentity (OIDC federation) against that role's trust policy, handing the Pod short-lived, auto-rotating credentials.

Guardrails and secrets:

  • Permission boundaries cap what a single role's own policies can ever grant; SCPs do the identical job one level up, across whole accounts/OUs.
  • Secrets Manager buys automatic rotation and audit at a price; Parameter Store is the cheaper, config-shaped sibling; KMS underlies both via envelope encryption — a data key encrypts your data, and KMS encrypts that data key.
  • Shield/WAF stop bad traffic at the edge; GuardDuty/Macie/Inspector detect what already got through (threats, exposed PII, vulnerable images).

Operations & ecosystem · themes 11–12

Observability — three pillars, and their AWS split:

  • Metrics (trend/alert), logs (discrete debugging), and traces (cross-service latency) are the three pillars of observability.
  • CloudWatch/CloudTrail/Config split the same way operationally: performance, "who changed what," and "did config drift from policy."

Resilience and cost:

  • RTO (how long to recover) and RPO (how much data you can afford to lose) frame every DR conversation.
  • The four DR strategies are a straight cost/speed dial, not a ranked best-practice list: backup & restore → pilot light → warm standby → multi-site.
  • Cost tracking is the same instinct pointed at money instead of downtime.

Decoupling primitives — pick by the pattern:

Primitive Pattern Note
SQS decouples producer from consumer queue depth is a genuinely good autoscaling signal
SNS fans one event out to many subscribers —
EventBridge the general event bus and scheduler —

Serverless and analytics:

  • Lambda / API Gateway / Step Functions form the serverless compute-and-orchestration layer.
  • Athena / Redshift / Glue / EMR are the analytics stack, roughly ordered by how much infrastructure you're willing to manage yourself.

Read next: the AWS Well-Architected Framework overview (focus on the Reliability, Security, and Cost Optimization pillars) and the EKS Best Practices Guides (focus on Cluster Autoscaling and Security). Retain deck (beat 5): SE Onboarding::05 AWS.

Check yourself — why can a private subnet's resource reach the internet outbound but never be reached inbound?

Its route table has a route to a NAT Gateway, not an Internet Gateway — NAT Gateways are outbound-only by design, so there's no path back in. Only an IGW route (which lives on public subnets) accepts inbound traffic.

Check yourself — what exactly changes about the EKS control-plane/data-plane split when you move from a managed node group to Fargate?

The line between "AWS manages" and "you manage" shifts further onto AWS's side. With a managed node group you still own the node — an AWS-provided AMI you trigger updates on, running inside your own ASG. Fargate removes the node from your ownership entirely, at the cost of no DaemonSets, no privileged Pods, and a slower cold start.

2. Pair · passive → active

Drive the onboarding-tutor:

  • "Quiz me: for five random services from this deck, make me say exactly what AWS manages vs what I manage."
  • "Explain why GitOps's git revert rollback is safer than re-running a push-based pipeline with old parameters."
  • "Walk me through the exact hop-by-hop credential path for a Pod reading an S3 bucket via IRSA — don't let me skip a step."
  • "Give me a workload and make me pick between ALB/NLB/GWLB, and separately between DynamoDB/RDS/Aurora — and defend both picks."
  • "Quiz me on RTO vs RPO with a concrete scenario, then make me pick the cheapest DR strategy that still hits the targets."

Common gotchas

  • Treating "Level: Core" and 8 submodules as separable topics to skim independently. Fix: the Prove gate deliberately cuts across networking, compute, IAM, and delivery in single questions (the networking-path question alone needs IGW/NAT and ALB target types and the VPC CNI) — the breadth is the point, not a menu to pick from.
  • Assuming a service you can name is a service you can defend. Fix: the Pair prompts and the gate both push past naming ("IRSA handles it") to the mechanism — rehearse the exact hop-by-hop path, not just which service is involved.
  • Skipping the provenance habit while using the tutor. Fix: the gate's last question specifically asks which claim you took from the tutor and how you checked it — get in the habit of verifying a tutor-supplied hop against the trust-policy/STS mechanism or the docs as you go, not only when the gate asks.
Check yourself — you're asked to pick between DynamoDB and RDS/Aurora for a workload, in one sentence. What single question about the access pattern decides it?

Whether the access pattern is known key lookups that need to scale near-infinitely (DynamoDB) or requires arbitrary joins/full SQL on an existing or moderate-scale relational workload (RDS, or Aurora once a single RDS instance's storage/replication story is outgrown) — the schema/query-model trade, not just "which is faster."

Check yourself — why is a GitOps rollback (git revert) considered safer than re-running a push-based pipeline with old parameters?

A push-based rerun re-executes against whatever the cluster's current state happens to be, using parameters you're trusting are still correct. A GitOps agent continuously reconciles the cluster to match Git, so a git revert is a plain, auditable pull request the agent applies the same reconciliation logic to — there's no separate "did the rerun actually undo everything" question, because the agent is always just converging toward what Git says now.

Done when: you can pick the right primitive under a two-line scenario (which load balancer, which storage, which DR tier) without hedging, and defend the IRSA credential path hop-by-hop.

3. Do · produce an artifact

Exercise — design a small production deployment (on paper or as a diagram):

  1. Sketch a VPC spanning 3 AZs with public and private subnets, an EKS cluster in the private subnets fronted by an ALB, a Multi-AZ RDS database, and an S3 bucket for static assets.
  2. Annotate two ownership boundaries on your diagram: (a) the EKS control-plane/data-plane split (what AWS manages vs you), and (b) the credential path that lets a Pod read the S3 bucket without static keys (IRSA → trust policy → STS).
  3. Add the delivery path onto the same diagram: which tool provisions this infrastructure once (IaC), and which mechanism keeps the running app in sync with Git afterward (GitOps agent) — and mark why that second arrow points from the cluster, not into it.
  4. Name one thing you'd track for cost and one for resilience (an explicit RTO/RPO pair) for this design.
  5. Optional (deeper): pick one component and write the CloudFormation (or CDK) snippet that would actually provision it.

Done when: your diagram correctly places control-plane vs data-plane ownership, shows the IRSA credential path with no missing hop, and names both a concrete delivery mechanism and a concrete DR target.

4. Prove · understanding gate

Mandatory. Pass bar in the Socratic gate.

  1. Networking path: A request from the internet needs to reach a Pod running in a private subnet behind an ALB in your EKS cluster. Trace the path — IGW vs NAT, ALB target type, VPC CNI — and explain why the Pod itself never needs a public IP.
  2. Ownership split: What exactly does AWS manage vs what do you manage in EKS, and how does that split change between a managed node group and Fargate?
  3. Credentials: Walk through how a Pod gets temporary AWS credentials to read an S3 bucket with zero static keys baked in — name every hop from the IAM role's trust policy to the credentials landing in the Pod.
  4. Delivery & resilience: You need to roll back a bad deploy in a GitOps-managed EKS cluster that's backed by a Multi-AZ RDS database. What's your first move for the app, and how is that different from your DR plan if an entire AZ goes down?
  5. Provenance: You almost certainly leaned on the tutor for at least one boundary on your diagram — the IRSA hop chain, or the control-plane/data-plane split. Which specific claim did it give you, and how did you check it — against the trust-policy/STS mechanism or the AWS docs — rather than trusting the diagram it drew for you?

Pass bar: you can defend each answer with the underlying mechanism (route tables, trust policies, reconciliation loops) — not just name the service — and point to how you verified any tutor-supplied hop. "IRSA handles it", "GitOps rolls it back", or "the agent drew it" without the how = back to Pair.

5. Retain · fight forgetting

Study the module deck SE Onboarding::05 AWS — its theme subdecks let you drill one area at a time:

  • 1 VPC & Network Foundations · 2 Load Balancing & Global Traffic · 3 EKS Cluster & Node Lifecycle · 4 EKS Networking & Scaling · 5 Storage · 6 Databases & Caching · 7 Infrastructure as Code · 8 CI/CD & GitOps · 9 IAM & Access Control · 10 Secrets, Encryption & Threat Detection · 11 Observability, Cost & Resilience · 12 Serverless, Messaging & Analytics

The deck syncs to your Anki automatically on pull (anki-sync). Done when you can recall, from the deck: the public/private subnet mechanism, the EKS ownership split, storage and database selection criteria, the IaC/GitOps delivery model, the IAM policy-evaluation order and IRSA credential path, and the RTO/RPO-driven DR ladder.

Key takeaways

  • A subnet is public or private purely by its route table — a route to an Internet Gateway makes it public; a route to only a NAT Gateway makes it private and outbound-only, with no path back in.
  • EKS splits ownership at the control plane. AWS runs the API server, etcd, and scheduler across 3 AZs; you own the data plane (nodes and everything on them) — Fargate shifts that line further onto AWS at the cost of DaemonSets, privileged Pods, and cold-start speed.
  • Storage and database choice follows the access pattern, not preference. S3/EBS/EFS split by how many things touch the data at once; Multi-AZ (synchronous, automatic failover) is for resilience, read replicas (asynchronous) are for read scaling — they solve different problems.
  • Every IAM decision reduces to one evaluation order: explicit deny wins, else explicit allow, else implicit deny — and IRSA is just an automated sts:AssumeRoleWithWebIdentity against a role's trust policy, handing a Pod short-lived, auto-rotating credentials with no static keys.
  • GitOps rolls back with git revert, not a pipeline rerun — an in-cluster agent continuously reconciles the cluster to match Git, so a revert is a plain, auditable pull request instead of re-executing against whatever state the cluster happens to be in now.
  • RTO/RPO frame every DR conversation, and the four DR strategies are a cost/speed dial, not a best-practice ranking — backup & restore → pilot light → warm standby → multi-site, each trading cost for faster recovery and less data loss.

Go deeper — curated resources

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

Gate log (mentor fills on pass)

  • Date passed:
  • Passed by: / checked by:
  • Weak spots noticed (feeds system improvement):