“Start small. Make it boring. Let the graph tell you when to add the next piece.”
Notes from last night’s pager session
Elastic Load Balancing is the first AWS service I reach for when a single server starts to sweat. Think of it as a smart doorman that spreads incoming requests across a pool of instances. It sounds simple. It is simple once you know the edges. Today I want to share the first steps that have worked for me and the traps I keep seeing in real projects.
A short story about traffic spikes and quiet fixes
We wrapped up the holidays with one of those traffic bursts that make you respect the basics. A site went from comfy to packed in minutes after a surprise link. The app servers were fine. The bottleneck was sessions sticking to one box and a single public endpoint. We placed an ELB in front, switched DNS with Route 53, and watched the error rate fall. No heroics. No all nighter. Just a boring change made on purpose.
This is the part I keep coming back to. Elastic Load Balancing buys you time. It gives you a cushion to scale out with more instances, to deploy without dropping connections, and to roll back when your new build misbehaves. It is not magic. It will not fix a slow database or a chatty app. It will give your servers a fair queue and a shared front door.
What ELB does well and what you still own
ELB shines at distribution for HTTP, HTTPS, and TCP. You get health checks, basic sticky sessions, and metrics in CloudWatch. You can place it in multiple Availability Zones and it will create nodes in each zone you enable. Your job is to keep your app stateless when you can, keep sessions small when you cannot, and keep instance counts even across zones. You also own SSL cert care, security group rules, and sane timeouts on both sides of the load balancer.
Deep dive one: Listeners, timeouts, and SSL that does not bite
Start with listeners. For web apps, set up HTTP on 80 and HTTPS on 443. Offload SSL at the ELB with a cert you upload to AWS IAM. This keeps your app servers lighter and lets you run plain HTTP behind the load balancer. A couple of tips that save pain:
- Idle timeout on ELB is 60 seconds by default. If your app streams or holds long polls, bump it. Match it with keep alive settings on Nginx or Apache so ELB and your app agree on how long to wait.
- Certificate chain matters. Include the full chain when you upload the cert or some clients will fail the handshake and you will chase ghosts in access logs.
- If you must pass through SSL, use a TCP listener and end SSL on the instance. You lose sticky sessions based on the ELB cookie in that case, so plan your session story.
Do not forget redirects. If you offload SSL and the app still redirects to plain HTTP, users will bounce between protocols and cookies will act weird. Make the app respect the X Forwarded Proto header and serve secure links when needed.
Deep dive two: Health checks and stickiness that plays nice
Health checks are the heartbeat of Elastic Load Balancing. Keep them simple and fast. I like a cheap endpoint that does a quick dependency check and returns plain 200. No heavy database joins. No external calls. A few notes that help:
- Path and success codes: For HTTP checks, choose a path like /health and allow 200 only. If you return 302 you might pass a broken app.
- Thresholds: Keep healthy and unhealthy thresholds tight at first. You want the ELB to react quickly but not flap. Start with 2 to 3 checks each and a short interval, then adjust if you see churn.
- Warm up: When you deploy a new instance, register it only after it is truly ready. Bake app start checks into your user data or init scripts so it passes health fast and clean.
- Sticky sessions: If you need them, start with the ELB generated cookie. It is simple and good enough for many apps. Keep the stickiness window short so load can rebalance when traffic shifts.
Watch HealthyHostCount, UnHealthyHostCount, and Latency in CloudWatch. Latency spikes with a flat HealthyHostCount often means your app is slow or your database is busy. A drop in HealthyHostCount means ELB sees failures and is pulling instances out of rotation.
Deep dive three: Zones, subnets, and security groups that line up
In a VPC, you attach the ELB to subnets in the zones you want. In EC2 Classic you just enable zones. Either way, keep your instance count even per zone. ELB nodes in each zone route to instances in the same zone. If you put five boxes in one zone and one box in another, the lonely one will get hammered. Balance the pool first, then scale out.
- Security groups: Give the ELB its own group. Allow inbound 80 and 443 there. On your app instances, allow inbound only from the ELB security group. This keeps the public away from your app ports.
- Private instances: You can keep app instances in private subnets. The ELB stays public, the app stays private, and you sleep better at night.
- DNS: Point your domain to the ELB DNS name with a Route 53 alias. Do not CNAME the root of your zone. Use the alias feature so you get the right behavior and no extra bill for DNS queries.
Reflective close
New year, same basics. Keep your Elastic Load Balancing setup boring and clear. Clean listeners. Fast health checks. Even spread across zones. Tight security groups. Watch the few CloudWatch metrics that matter and let the graphs nudge your next move. When traffic shows up, you will already have the first steps in place, and that is usually all you need to turn a tense spike into a quiet evening.