Read time: 10 minutes.

ALB’s - the new hotness that are 2.5 years old.

Amazon’s Application Load Balancers (ALB) are leaps and bounds above their previous generation of Elastic Load Balancers (ELB) that you are already familiar with.

If your first experience was like mine though, you realized you now needed to configure and track a new thing (Target Groups), said forget that, and went back to your classic ELB to get the job done.

Once you overcome this slight cognitive burden though, ALB’s + Target Groups will likely become your new best friend. The aim of this blog post is to break down ALB’s basic features set in order to replace your ELB’s core functionality without adding too much cognitive plaque.

External Face/Internal Face

ELB’s used to be an all-in-one object where external facing ports + security rules mapped directly to internal ports and your service. Done. In order to provide a much richer feature set, ALB’s split all the internal specifications into an object called “Target Groups”. I like to think of this split like this:

1
2
3
4
5
6
7
8
9
10
Target Group Configuration = everything INTERNAL about the service i'm providing.
  - which ec2 is my service on?
  - which port does my service expose?
  - how can I check if it's healthy?

ALB Configuration = Everything CLIENT facing + the Target Group
  - SSL Certs
  - exposed ports
  - security groups
  - and a plethora of new rules for directing your clients traffic

Think Target Groups First

A bit ani-intuitive, I like to create my target groups first and then later attach them to an ALB. This allows me to focus on one side of the request at a time, starting with everything I already know about my service. Since health checks are a part of the Target Group, it also allows time for my service to register as Healthy while I setup the external facing ALB.

Target Groups are service facing and everything about their configuration is related to the internal service. When you are configuring a target group, think about your infrastructure internals.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
1) Target Group Name (unique string)
   I personally like the naming convention <internal port>-<service name>
   e.g. 30602-users-api
   This will visually sort the list when I'm looking at them in the console.

2) Target Type [Instance, IP, Lambda function]
   Since we are staying in par with ELB's, "Instance" is the usual choice here.
   "IP" is useful for DB's and other very important ip's..or VIP's..yuk.yuk.yuk.

3) Protocol (HTTPS/HTTP/TCP)
   This is the one setting you want to consider what will be client facing.
   HTTPS if exposing port 443 and using an SSL certificate.
   HTTP if exposing a non-ssl port, like 80.
   TCP option is useful if launching a TCP Load Balancer, *NOT* an ALB.

4) Port (your internal service port)
   This port should align to the port your service is exposed on the server.  
   For example, port 3000 for a default rails application.  
   30602 for some kubernetes services exposed on 30602. etc.

5) VPC
   Not too much special here, just make sure you select the correct one your
   instances reside in.

6) Health Check Settings
  - Protocol (can be http if https selected above, TCP is no longer an option)
  - Path
  - Port (again, your internal service port)
  - Timing Interval
  - Response codes. *NEW* You can use a range like 200-299 if desired.

TG Rules for the Road

  • If you plan to use an SSL on your ALB, the protocol on configuration 3 above must be HTTPS.

  • HTTPS/HTTP Protocols must have HTTPS/HTTP HealthCheck.
    If you have been tempted in the past to simply apply an TCP port open check in order to ensure a healthy perspective from the load balancer perspective, you can unfortunately no longer do this. It’s slightly disappointing since this now increases your troubleshooting surface area after a service that was down is brought back up, but on the upside, it’s the safer option from a high traffic perspective.

  • A Target Group can only belong to 1 Application Load Balancer at a time.
    If you were considering some sort of “universal target group”, perhaps used for forwarding request on port 80 to 443, and applying it to several ALB’s, toss that from your mind immediately. Target groups can only