Capstone: Deploying a Simple Web Application on AWS

Nine chapters, one piece at a time. This closing chapter combines every one of them into a single, realistic architecture — a small web application handling user photo uploads, with a database, background image processing, and real monitoring — built the way a genuine, small production deployment actually would be.

The Target Architecture

Users upload a photo through a web app; the app stores metadata in a database, saves the original image to object storage, and a background job automatically generates a thumbnail. Every piece of this deliberately gives every prior chapter's own technique a real, concrete place to apply.

Step 1 — Region & Multi-AZ Planning

Chapter 1: the whole deployment lands in one Region, with the web and database tiers deliberately spread across two Availability Zones from the very start — not retrofitted later once something has already failed.

Step 2 — An IAM Role, Not Embedded Keys

Chapter 2: a dedicated IAM role is created for the web servers, scoped to exactly what they need — s3:PutObject/s3:GetObject on the one specific application bucket, and permission to write to CloudWatch Logs. Nothing broader, and no long-term access key ever touches the application's own code.

Step 3 — VPC, Subnets & the Two Gateways

Chapter 5: one VPC, public subnets (route to an Internet Gateway) for the web tier, and private subnets (route to a NAT Gateway) for the database — outbound-only internet access for the database tier, never inbound, exactly as Chapter 5's own asymmetry described.

Step 4 — EC2 Web Servers

Chapter 3: web servers launch from a custom AMI (the application pre-installed), sized as t3.small — general-purpose, matching the workload's own modest, steady traffic. The step 2 IAM role is attached at launch; a security group allows inbound HTTP only from the load balancer (Step 8), never directly from the internet.

Step 5 — S3 for the Photos

Chapter 4: the application bucket stores original uploads in S3 Standard, with versioning enabled (protecting against an accidental overwrite) and Block Public Access left firmly on — exactly the real, account-level safeguard the chapter's own Deep Root Analytics case study made the case for. Nothing in this bucket is ever meant to be directly public.

Step 6 — RDS for Application Data

Chapter 6: a Multi-AZ RDS PostgreSQL instance sits in the private subnets from Step 3, storing photo metadata (uploader, timestamp, S3 key). Its own security group allows inbound traffic only from the web tier's security group — never a public IP, never 0.0.0.0/0.

Step 7 — A Lambda Function for Thumbnails

Chapter 7: an S3 event trigger fires a Lambda function the moment a new photo lands in the bucket, generating a real thumbnail and saving it back to S3 under a separate key prefix — a genuinely well-suited serverless job (short, event-driven, bursty) that would be wasteful to run on a permanently-provisioned EC2 instance instead. Its own IAM role is scoped identically narrowly to Step 2's — read the original, write the thumbnail, nothing more.

Step 8 — Load Balancer & Auto Scaling

Chapter 8: an Application Load Balancer (real content-based routing isn't needed here, but ALB's own container/microservice-friendly health checks are still the right default) sits in front of the web tier, distributing traffic across an Auto Scaling Group spanning both AZs from Step 1. A target tracking policy holds average CPU at 60% — the same worked example from Chapter 8 itself.

Step 9 — Monitoring & a Budget

Chapter 9: a CloudWatch alarm watches RDS free storage space (a metric collected automatically, unlike the memory/disk-space gotcha for EC2) and notifies the team before it runs low; the ASG's own target tracking policy from Step 8 is fed directly by CloudWatch's CPU metric. An AWS Budget is set at a real, planned monthly threshold — understood, per Chapter 9's own warning, as an alert mechanism, not an automatic spending cutoff.

The Full Picture

What's Still Out of Scope, Honestly

This capstone deliberately stops short of several real, genuine next steps: no CI/CD deployment pipeline for the application code itself, no CloudFront CDN or WAF in front of the ALB, no Route 53 DNS configuration, no multi-Region disaster recovery, and no containerization (ECS/EKS) as an EC2 alternative. Each is a real, legitimate next step for a production system — named honestly as still outstanding rather than treated as solved here, the same discipline this site applies to every other course's own capstone.

Closing the Course

From Chapter 1's real global infrastructure and shared responsibility model to this chapter's own working, multi-service architecture — every chapter in between covered one specific, genuine piece of what it actually takes to run something real on AWS. Compute, storage, networking, databases, serverless, scaling, and monitoring together are what make a deployment resilient and secure — not any single service used in isolation.

Hands-On Exercises