Application Load Balancer: Listener Rules, Target Groups, and Health Check Configuration

How ALB routes traffic

ALB is a Layer 7 (HTTP/HTTPS) load balancer. It terminates TLS, reads the HTTP request, evaluates listener rules, and forwards to a target group. The key distinction from NLB (Layer 4) is that ALB can make routing decisions based on request content.

Traffic flow:

1. Client connects to ALB DNS name (or custom domain via Route 53 alias)
2. Listener on port 80 or 443 receives the connection
3. ALB terminates TLS (if HTTPS), decrypts the request
4. Listener rules evaluate in priority order — first match wins
5. Matched rule forwards to a target group
6. Target group selects a healthy target using the load balancing algorithm
7. ALB forwards the request to the selected target

Content-based routing rules

ALB rules can match on: host header, path, HTTP headers, query strings, HTTP method, and source IP. Rules are evaluated in priority order:

resource "aws_lb_listener_rule" "api_v2" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  condition {
    path_pattern {
      values = ["/api/v2/*"]
    }
  }

  condition {
    http_header {
      http_header_name = "X-API-Version"
      values           = ["2.0", "2.1"]
    }
  }

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_v2.arn
  }
}

resource "aws_lb_listener_rule" "api_v1" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 200

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_v1.arn
  }
}

# Redirect HTTP to HTTPS (on the HTTP listener)
resource "aws_lb_listener_rule" "redirect_https" {
  listener_arn = aws_lb_listener.http.arn
  priority     = 100

  condition {
    path_pattern {
      values = ["/*"]
    }
  }

  action {
    type = "redirect"
    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }
}

Target groups and health checks

A target group defines the targets and how to check their health. A target is unhealthy if health checks fail unhealthy_threshold_count consecutive times:

resource "aws_lb_target_group" "api" {
  name        = "api-targets"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"  # "instance" for EC2, "ip" for ECS awsvpc, "lambda" for Lambda

  health_check {
    enabled             = true
    path                = "/health"
    port                = "traffic-port"   # same port as target
    protocol            = "HTTP"
    healthy_threshold   = 2   # 2 consecutive successes = healthy
    unhealthy_threshold = 3   # 3 consecutive failures = unhealthy
    timeout             = 5   # seconds to wait for response
    interval            = 30  # seconds between checks
    matcher             = "200-299"  # 2xx = healthy
  }

  deregistration_delay = 30  # seconds to drain connections before target removal
}

Health check path: should return 200 quickly (under timeout seconds) with minimal resource usage. Don't health-check a path that queries the database — a slow DB causes health check failures, causing ALB to take the target out of rotation, potentially cascading.

Deregistration delay: when a target is deregistered (removed from the group or marked unhealthy), ALB waits this many seconds to drain in-flight connections before stopping traffic to it. Default 300s. Reduce it for faster deployments in ECS rolling updates.

resource "aws_lb_listener_rule" "weighted" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }

  action {
    type = "forward"
    forward {
      target_group {
        arn    = aws_lb_target_group.api_v1.arn
        weight = 90  # 90% to v1
      }
      target_group {
        arn    = aws_lb_target_group.api_v2.arn
        weight = 10  # 10% to v2 (canary)
      }
      stickiness {
        enabled  = true
        duration = 600  # once a client hits v2, stick to v2 for 10 min
      }
    }
  }
}

Internet-facing vs internal ALB

Internet-facing: ALB is assigned public IPs. Must be deployed in public subnets (subnets with route to internet gateway). DNS resolves to public IPs. Clients from the internet can reach it.

Internal: ALB is assigned private IPs only. Deployed in private subnets. DNS resolves to private IPs. Only accessible within the VPC or from peered/connected networks.

resource "aws_lb" "public_api" {
  name               = "public-api"
  internal           = false           # internet-facing
  load_balancer_type = "application"
  subnets            = aws_subnet.public[*].id       # public subnets required
  security_groups    = [aws_security_group.alb_public.id]
}

resource "aws_lb" "internal_services" {
  name               = "internal-services"
  internal           = true            # internal only
  load_balancer_type = "application"
  subnets            = aws_subnet.private[*].id      # private subnets
  security_groups    = [aws_security_group.alb_internal.id]
}

The scheme (internal attribute) cannot be changed after creation — it requires destroying and recreating the ALB.