A self-healing, auto-scaling
web tier with path-based routing

One entry point, many backends, rules deciding who gets what

Most beginner AWS projects stop at "spin up a server, install a web server, done." That doesn't show anything about how real systems handle traffic — multiple backends, health checks, failure isolation, routing logic. I wanted something small enough to build in an afternoon that actually exercises a pattern used in production everywhere: one load balancer in front, many backends behind, and Layer-7 rules routing requests purely on the URL path.

Hit /about-me and you land on one backend. Hit /what-am-i-doing and you land on a completely different one. Then I took it further: each backend sits behind its own Auto Scaling Group, so they scale and self-heal independently, and the whole thing is fronted by HTTPS on a custom domain via ACM and Route 53.

Three backends that fail and heal independently

Each backend runs behind its own Auto Scaling Group, across three Availability Zones. If the ASG behind /about-me loses an instance, it replaces the instance automatically and the ALB simply stops routing to the unhealthy one in the meantime — without touching the other two paths at all. That isolation is the whole point.

Port 80 on the ALB does nothing but 301-redirect to 443, so clients are never served over plain HTTP. TLS terminates at the load balancer; the hop from ALB to each instance travels over port 80 inside the private network, and the instances aren't reachable from the internet directly at all — their security group only accepts traffic from the ALB's security group.

Step by step

HTTPS on my own domain, and where TLS actually stops

Once routing worked over plain HTTP on the ALB's default DNS name, I layered on a real domain and a certificate: a wildcard *.shinn.life cert in ACM, DNS-validated through Route 53, attached to the HTTPS:443 listener; the HTTP:80 listener switched to a 301 redirect; and a Route 53 alias record pointing routingalb.shinn.life at the ALB.

Why TLS terminates at the load balancer

Worth being precise, because it's a common point of confusion. TLS is terminated at the ALB — the browser-to-ALB hop is encrypted, but the ALB then forwards to the instances over plain HTTP:80 inside the VPC. That last hop isn't encrypted, and that's a deliberate, standard choice — not an oversight:

Three paths, three backends, one domain

Same load balancer, same certificate — the URL path alone decides which backend answers.

The bugs I actually hit (and how I found them)

More useful to write down than the happy path — these are the mistakes that actually cost time, and the reasoning that got me out of each one.

<Directory "/var/www/html">
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ /index.html [L]
</Directory>

$ curl -v https://routingalb.shinn.life
* connect to 52.220.x.x port 443 failed: Connection refused

# check what listeners actually exist
$ aws elbv2 describe-listeners --load-balancer-arn ...
  Port: 80   # ...only HTTP:80 existed — I never created the HTTPS:443 listener

What I ended up with

What I'd highlight to someone reviewing this

• ✓Path-based routing is a Layer-7 capability. It's one of the things that separates an Application Load Balancer (L7) from a Network Load Balancer (L4).
• ✓Each backend fails and heals independently — one ASG per target group, deliberately, not a shared one.
• ✓Routing logic lives in infrastructure, not app code. No backend needed to know or care what path routed to it.
• ✓TLS terminates at the ALB, on my own domain, with a cert ACM renews automatically — and the ALB is the sole public entry point.
• ✓Debugging means distinguishing failure modes. A fast "connection refused" versus a slow timeout point at completely different root causes — and telling them apart saved real time.

What I'd improve next

This build is deliberately console-driven and static — a focused way to learn the routing and scaling primitives before adding complexity on top of them. If I took it further, here's where it would go:

• ✓Manage it all with Terraform — capture every resource as code instead of clicking through the console, so the whole stack is reproducible, reviewable, and safe to tear down and rebuild without guessing what I clicked last time.
• ✓Move from static pages to containers — run real containerised apps behind the same ALB, keeping the routing and scaling model intact while the workload itself becomes something closer to production.
• ✓Deploy through a CI/CD pipeline — ship changes automatically on every push instead of manually baking static pages into User Data, closing the loop between writing code and seeing it live.