Hack University - Architecture 2: the classic web app

The three-tier workhorse

This is the architecture behind an enormous share of production software, and it is nothing but this course assembled:

An ALB (lesson 5-2) in the public subnets of two AZs owns the public address and the TLS certificate.
Two or more EC2 instances (unit 3) run your app, in private subnets, one per AZ. They wear sg-app, which admits port traffic only from the ALB's security group.
RDS Multi-AZ (unit 6) holds the data, in private subnets, wearing sg-db, which admits 5432 only from sg-app (lesson 6-2's chaining).
Each instance carries an IAM role (lesson 2-3) for whatever AWS access the app needs, such as presigning S3 URLs (lesson 4-3) for user uploads.

Trace a request: browser → ALB (public) → app instance (private) → database (private), and each arrow is permitted by exactly one security-group rule. Everything else is default-deny (lessons 2-2, 3-3, 5-1).

The classic web app: public ALB, app servers hidden in private subnets across two AZs, Multi-AZ database behind chained security groups. Only the gold path is reachable from outside.

What the classic architecture costs per month

These are rough list prices in cents for a minimal version: two small app instances, the smallest Multi-AZ-ready database, their disks, and the ALB's fixed hourly charge.

ec2=850    # two small app instances
rds=1550   # smallest Multi-AZ-ready db instance
ebs=160    # disks
alb=1640   # the load balancer's fixed hourly charge
total=$((ec2 + rds + ebs + alb))
printf 'classic web app: $%d.%02d/month\n' $((total / 100)) $((total % 100))

Output

classic web app: $42.00/month

The largest line is the one that runs no application code. The ALB costs about $16.40 a month before a single request arrives, more than both app servers combined at $8.50.

That is not a pricing quirk, it is what the component is for. The ALB and the RDS standby are availability infrastructure, and availability is a subscription rather than a usage charge. You pay to have somewhere to fail over to, whether or not you ever need it.

The honest takeaway from that cost sum

High availability has a fixed price of admission.

The ALB and the RDS standby buy survival of an availability zone failure, and they cost real money whether or not anyone visits. A business pays that gladly, because an hour of downtime costs more than a year of the ALB.

A portfolio project is in a different position. Below a certain scale, one public instance or the serverless architecture in lesson 9-3 is the pragmatic choice, and accepting the risk of a rare AZ failure is a legitimate engineering decision rather than a corner cut.

The version of that decision worth aiming for is the serverless one, where idle genuinely means $0 as lessons 7-1 and 8-2 showed. It sidesteps the fixed fee instead of gambling against it.

What survives an availability zone going dark

The ALB is the reason the app survives it.

Health checks are its built-in feature, as lesson 5-2 covered. The checks fail for the instance in the dead AZ within seconds, the ALB stops sending it traffic, and everything routes to the surviving instance. No human is involved and no configuration changes.

RDS covers the data layer the same way with standby promotion from lesson 6-1. The two mechanisms are independent, which is exactly what you want: a compute failure and a database failure are handled by different machinery.

Together they make the two-AZ promise from lesson 1-2 real. The physical separation was always there in the region's design, and these two components are what turn it into uptime.