Setup a Load Balancer on AWS Lightsail with SSL

One instance goes down and your entire world goes dark. Sound familiar? Not just websites... life works that way too. Single points of failure will wreck you every time. Daniel Otto walks us through building redundancy into your AWS Lightsail setup with a load balancer, and honestly... the principles here go way beyond cloud infrastructure.

The Single Point of Failure Problem

Picture this. You've got one WordPress instance running your site. One. All your traffic, all your visitors, all your work... funneled through a single machine. It's like the Death Star having one thermal exhaust port. We know how that ended.

Daniel Otto lays it out clean in this tutorial. Two instances without a load balancer means you're manually directing people to specific addresses. No failover. No safety net. No resilience. One goes down... everybody feels it.

A load balancer changes the game. It sits between the internet and your instances, routing traffic to whichever one is healthy and available. Think of it as mission control... quietly working behind the scenes so your visitors never know anything happened.

Setting It Up (The Receipts)

Here's the practical breakdown:

Step 1: Create the load balancer. Navigate to your AWS Lightsail Networking tab. Click create. The default HTTP configuration works for now... you'll layer on SSL/TLS shortly. Cost: $18 USD/month. Know that going in.

Step 2: Attach your instances. Select the instances you want behind the load balancer. Otto uses two WordPress instances. Could be more. The load balancer distributes traffic evenly across whatever you attach.

Step 3: Update your DNS records. This is critical. Your domain's A record needs to point to the load balancer now... not individual instances. The load balancer becomes the single gateway. Everything flows through it.

Step 4: Enable SSL/TLS. Create a certificate from the load balancer's inbound traffic settings. Validate domain ownership by adding a CNAME record to your DNS zone. Trim your domain name from the validation string before pasting... Otto catches this detail that'll save you headaches. Once validated, select the certificate and HTTPS is live.

Step 5: Fix health checks. This is where it gets interesting.

The Redirect Loop Problem

Otto hits a wall. Health checks fail. The load balancer can't confirm his instances are alive.

Why? Because WordPress instances with existing HTTP-to-HTTPS redirect rules create an infinite loop. The load balancer communicates with instances on port 80 (HTTP). Instance says "nope, go to HTTPS." Load balancer sends it back on HTTP. Instance says "nope" again. Loop. Browser crashes with a "too many redirects" error.

The workaround is elegant. Customize the health check path to point to a simple file... `health.html`. Then SSH into each instance and create it:

```bash cd /opt/bitnami/apps/wordpress/htdocs touch health.html ```

Do this on every attached instance. Wait five minutes. Health checks pass. BAM... you're back in business.

That's the kind of quiet, unglamorous fix that keeps systems alive. No fireworks. Just a blank HTML file doing its job in the background.

The Failover Test

Here's where the rubber meets the road. Otto stops one instance. Loads the domain. Site still works... traffic routed to the surviving instance. Starts it back up, stops the other one. Domain still resolves. Both directions covered.

This is the test most people skip. Don't skip it. Verify the thing actually works before you need it to work. Because when that instance goes down at 2 AM on a Saturday... you want to sleep through it, not scramble.

Why This Matters Beyond Servers

Redundancy isn't just an infrastructure principle. It's a life principle.

The WHELHO Wheel has eight sections for a reason. If your entire identity lives in one section... Work, say... and that section crashes, everything crashes. Build load balancing into your life. Relationships that catch you when work fails. Recreation that sustains you when relationships strain. Spirit that holds when the body breaks.

Three months without food. Three days without water. Three minutes without hope. Your systems need backup plans... digital and human.

Otto's tutorial is clean, practical, and honest about the gotchas. He hits walls and shows you how he got past them. That's the kind of teaching that actually sticks... not polished perfection, but real problem-solving in real time.

Quick Reference

| Step | Action | Watch For | |------|--------|-----------| | Create load balancer | Networking tab → Create | $18/month cost | | Attach instances | Select from dropdown | All instances need identical content | | Update DNS | A record → load balancer | Replace instance IP, not add | | Enable SSL | Create + validate certificate | Trim domain from CNAME name field | | Fix health checks | Custom path → `health.html` | Create file on EVERY instance | | Test failover | Stop instances one at a time | Verify domain resolves each time |

Your website visitors don't care about your infrastructure. They care that the page loads. A load balancer lets you quietly work behind the scenes... absorbing failures, routing around problems, keeping the lights on while nobody notices. That's the whole point. Build the safety net before you need it. Test it before it matters. And remember... redundancy isn't paranoia. It's love for the people depending on what you built. 💙

--- Source: https://www.youtube.com/watch?v=qxP0S5sLTr0