Capstone Walkthrough: Building It Session by Session

Session 1 — VPC design: before any compute or data resource exists, the network foundation goes in first — a VPC spanning 3 Availability Zones, with public subnets (for the ALB and NAT Gateways) and private subnets (for EC2 instances and RDS), an Internet Gateway attached to the VPC, and NAT Gateways in each public subnet so private-subnet instances can reach the internet for updates without being directly reachable from it. This has to come first because every other resource in the architecture needs to be placed inside a subnet that already exists.

Session 2 — Shared storage and a golden AMI: an EFS file system is created for any assets multiple EC2 instances need to share (so newly launched instances immediately see the same files as existing ones), and a custom AMI is built and baked with the application's dependencies pre-installed, so new instances launched later by Auto Scaling boot to a ready state quickly rather than running a slow bootstrap script from a bare OS image on every scale-out event.

Session 3 — Auto Scaling and the Application Load Balancer: with the network and a golden AMI ready, a Launch Template references that AMI, an Auto Scaling Group is created spanning the private subnets across all 3 AZs, and an ALB is created in the public subnets with a target group pointing at the Auto Scaling Group — this is the first point where the architecture can actually serve traffic, even before DNS or CDN are wired up, useful for testing directly against the ALB's own DNS name first.

Session 4 — Security groups: only after the actual resources exist does it make sense to lock down security groups precisely — the ALB's security group allows inbound 443 from the internet, the EC2 instances' security group allows inbound traffic only from the ALB's security group (not from the internet directly), and the RDS security group allows inbound only from the EC2 instances' security group, forming a deliberate chain where nothing but the ALB is ever directly internet-facing.

Session 5 — Route 53: with the ALB live and tested, a Route 53 Alias record is pointed at it (and, once CloudFront is added, later repointed at the CloudFront distribution instead), giving the application its real, stable domain name.

Session 6 — Testing and optimization: load testing against the live environment validates the Auto Scaling Group's scaling policy actually responds correctly under real traffic, health check thresholds are tuned so a genuinely unhealthy instance is caught quickly without false-positive flapping on brief blips, and CloudFront is added in front of the ALB at this stage once the origin is confirmed stable and correct.

Session 7 — Documentation and handoff: the final step in a real project (and the most commonly skipped one) — documenting the actual architecture, the reasoning behind key decisions, and an operational runbook for common scenarios (a failed deployment, a database failover, a traffic spike), so the system remains maintainable by people who didn't build it.