Exercise 3: Why a Load Balancer Alone Isn't High Availability — Possible Solution
====================================================================

A load balancer distributing traffic across three manually launched
EC2 instances does provide a real, genuine benefit -- if one instance
fails its health checks, the load balancer will stop sending it new
traffic, and the remaining instances continue serving requests. That
much real protection does exist.

The real gap is what happens AFTER that instance fails: with no Auto
Scaling Group managing this fleet, nothing automatically launches a
replacement. The team is now running on two instances instead of
three, permanently, until a person manually notices and launches a
new one. If a second instance then fails before anyone intervenes,
the application is down to a single point of failure -- and if that
one fails too, the whole application goes down, with the load
balancer having nothing healthy left to route traffic to at all.

ANSWER: This setup is not genuine high availability because it can
only ever get WORSE over time with no automatic recovery -- each
instance failure permanently reduces real capacity until a human
manually intervenes. True high availability requires an Auto Scaling
Group specifically because it automatically replaces failed instances,
keeping the fleet at its intended size indefinitely without manual
action -- the load balancer's own health-check-based traffic routing
only mitigates a failure's immediate symptom, it doesn't fix the
underlying reduced capacity.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly distinguishes what a load balancer alone genuinely
provides (routing around an already-failed instance) from what it
does NOT provide (replacing that instance), matching the chapter's own
explicit warn-box point that the two services need each other for the
real high-availability guarantee to actually hold up over time, not
just at a single moment.