Chapter 30 AWS II: VPC, EC2, ELB & EKS
VPCs from CIDR plan to route tables, security groups against network ACLs, NAT gateways and VPC endpoints, EC2 with launch templates, user data, IMDSv2 and Session Manager instead of SSH, EBS resizes, Application and Network Load Balancers with health checks and their 502s, Auto Scaling groups and instance refresh, Route 53, and EKS: the managed control plane, node groups, access entries, IRSA and Pod Identity, and the AWS Load Balancer Controller - against the same simulated account, CLI and Terraform.
In plain words
Picture a private office park you rent from AWS. You draw its streets (the VPC and its subnets), decide which gates open to the public road (internet gateways), and put guards at every door (security groups) and at every street corner (network ACLs). Inside you park rented machines (EC2 instances), put a receptionist at the entrance who spreads visitors over the offices (a load balancer), and hire a manager who keeps exactly the right number of offices staffed (an Auto Scaling group).
The last part puts a Kubernetes cluster in the park: AWS runs its brain, you run its hands.
Why it matters on call
When a page says "the site is down" on AWS, the answer is almost always in this chapter's layers: a route that points nowhere, a security group or ACL that drops packets, a load balancer whose targets are unhealthy, an instance that never finished its user data, a pod with the wrong AWS identity. Knowing the layers in order turns a guessing session into a checklist.
The skills transfer one to one to a real account: the same CLI calls, the same error messages, the same Terraform resources.
Lessons
- VPC design: CIDRs, subnets per AZ, route tables
- Security groups vs network ACLs
- The way out: NAT gateways and VPC endpoints
- AWS with Terraform: the aws provider and state in S3
- EC2: images, instance types, user data, EBS
- Inside the instance: IMDSv2, instance roles, Session Manager
- Load balancers: ALB, NLB, health checks and their status codes
- Auto Scaling groups: desired capacity, health, instance refresh
- EKS: what AWS runs and what you run
- EKS identity: access entries, IRSA, Pod Identity
- The AWS Load Balancer Controller: Ingress and Service to ALB and NLB
- Reviewing an AWS workload: the network and compute checklist
23 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Do the labs need a real AWS account?
No. Everything runs against the simulated account from AWS I (111122223333, eu-central-1): VPCs, instances with shells you reach through Session Manager, load balancers that really health-check, Auto Scaling groups that replace instances, and EKS clusters you use with kubectl. The commands are the real AWS CLI v2 commands, so the labs can be repeated in a sandbox account later.
Why does the chapter avoid SSH everywhere?
Because modern AWS setups do: Session Manager gives a shell through the SSM agent with no open port, no key to distribute or rotate, IAM deciding who may connect and every session logged. Instances in the labs have no key pair at all. SSH and EC2 Instance Connect are explained, but only as the older option.
How does this relate to the Kubernetes chapters?
The Kubernetes you learned with kubeadm is the same inside EKS: kubectl, Deployments, Services, Ingresses. What changes is the outside: AWS runs the control plane, nodes are EC2 instances in an Auto Scaling group, pods get VPC addresses, kubectl authenticates with IAM, pods get AWS credentials through Pod Identity or IRSA, and Ingresses become AWS load balancers through a controller.
Is Terraform covered or only the CLI?
Both. The network is built once with the CLI to see every object and once with Terraform's aws provider, with the state in an S3 bucket and S3-native locking (use_lockfile, Terraform 1.10+). The Terraform lesson also covers the habits that differ from azurerm, such as the security group egress rule the provider removes.
What does the chapter leave for later?
Monitoring and cost: CloudWatch metrics and alarms, Logs Insights, CloudTrail investigations, budgets and tagging come in AWS III. This chapter ends with a review lesson that points at what costs money while idle (NAT gateways, load balancers, endpoints, EKS control planes) so the bill does not surprise you in the next one.