Load-Balancing

Right, let’s talk about visibility. You’ve deployed your ALB, traffic is flowing, and everything seems fine. But you’re not flying blind here. You’ve got two phenomenal tools to figure out exactly what your load balancer is doing: Access Logs, which are the raw, unfiltered truth of every single request, and CloudWatch Metrics, which are the digested, high-level summary. One is the detailed transaction history; the other is your monthly bank statement. You need both to get the full picture.

Right, let’s talk about what happens when you decide to fire a server. It’s not as simple as just yanking the plug. If you do that, you’re a monster, and you’ll have a trail of confused users and failed requests behind you. This is where Connection Draining (for Classic and Network Load Balancers) and its slightly more nuanced sibling, Deregistration Delay (for Application Load Balancers), come in. Think of it as the polite way to tell your instances, “Hey, you’re fired, but finish what you’re doing first.”

Right, let’s talk about sticky sessions. You’ve probably built an app where a user adds something to their cart, and on the next click, it’s gone. Poof. Annoying, right? The culprit is often that their request got routed to a different backend instance that doesn’t know about their session. Sticky sessions, or session affinity if you’re feeling fancy, are ELB’s answer to this. It’s the feature that lets you say, “For the love of all that is holy, send this user’s requests to the same target until further notice.”

Right, let’s talk about listener rules. This is where ELB stops being a simple traffic cop and starts acting like a concierge with a very specific, slightly obsessive set of instructions. You’ve already told your Application Load Balancer (ALB) to listen on port 443. Great. But when a request comes in, how does it know which target group to send it to? That’s the listener rule’s job. It’s a series of if statements that you get to define, and they are evaluated in a priority order until one matches. The two most powerful conditions you’ll use are based on the host (the Host header, like api.example.com) and the path (like /images/*). This is how you can host a dozen different microservices on a single load balancer, which is both elegant and a fantastic way to save money.

Right, so you’ve decided you need raw, unfiltered performance for your TCP or UDP traffic. You’re not messing around with HTTP headers or cookie-based stickiness. You need packets to fly from your users to your instances with as little fuss and overhead as possible. Enter the Network Load Balancer (NLB). This is the tool you call when every millisecond counts and you need to handle a tidal wave of traffic without breaking a sweat.

Right, let’s talk about target groups. This is where the ELB rubber meets the road. You’ve told your load balancer to distribute traffic, but you haven’t told it where to send it. That’s the target group’s job. It’s a logical grouping of your backend endpoints—your poor, overworked servers (or functions) that will actually do the heavy lifting. Think of it like a bouncer at an exclusive club. The ELB is the door, checking IDs (health checks). The target group is the bouncer’s list: “Okay, you’re on the list, you can come in. You? Not on the list. Get lost.” You need to define what “the list” looks like.

Right, so you’ve got an Application Load Balancer (ALB). It’s not just a dumb traffic cop; it’s a reasonably sophisticated reverse proxy that can make decisions based on what’s inside the HTTP request. This is where you go from “please send this to a server” to “please send this specific kind of request to this specific group of servers.” The magic that makes this happen is a combination of Listeners, Rules, Conditions, and Actions. Let’s break it down without the marketing fluff.

Right, so you need to get traffic into your AWS architecture. You could just point a DNS name at a single EC2 instance and pray, but we both know how that ends: with you getting paged at 3 AM when it decides to go on a spiritual retreat. Enter Elastic Load Balancing, your digital bouncer, traffic cop, and concierge all rolled into one. It’s not just about distribution; it’s about making your system resilient and intelligent. But AWS, in its infinite wisdom, offers you not one, but four main choices. Picking the right one isn’t just a technicality—it’s the difference between a smooth ride and a constant headache.