AWS Elb

Elastic Load Balancing (ELB)

Distribute traffic across EC2 instances with health checks, SSL/TLS termination, and automatic failover for high availability and scalability.

TL;DR Checklist

• Use Application Load Balancer (ALB) for HTTP/HTTPS (most common)
• Use Network Load Balancer (NLB) for extreme performance (millions of RPS)
• Distribute targets across multiple AZs for high availability
• Configure health checks with appropriate thresholds
• Use sticky sessions only for stateful applications
• Terminate SSL/TLS at load balancer (not instances)
• Enable connection draining for graceful shutdown
• Monitor target health and latency metrics
• Use security groups to restrict ingress to LB only
• Configure appropriate idle timeout

When to Use

Use ELB when:

• Distributing traffic across EC2 instances
• Requiring SSL/TLS termination
• Building highly available applications
• Needing automatic failover
• Distributing traffic based on hostname or path
• Requiring extreme throughput (NLB)

When NOT to Use

Avoid ELB when:

• Running containers (use service mesh instead)
• No traffic distribution needed
• Very low traffic (cost not justified)

Purpose and Use Cases

Primary Purpose: Distribute incoming application traffic across multiple targets with SSL termination, health checks, and automatic failover.

Common Use Cases:

1. Web Application LB — Distribute HTTP/HTTPS across web servers
2. API Gateway — Load balance API servers across instances
3. High Performance LB — Extreme throughput with NLB
4. Multi-tier Application — Separate LBs for web and app tiers
5. Global Load Distribution — AWS Global Accelerator with regional ALBs

Architecture Design Patterns

Pattern 1: Application Load Balancer for Web Applications

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  # Application Load Balancer
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: web-alb
      Type: application
      Scheme: internet-facing
      IpAddressType: ipv4
      Subnets:
        - subnet-0123456789abcdef0  # Public subnet AZ1
        - subnet-0123456789abcdef1  # Public subnet AZ2
        - subnet-0123456789abcdef2  # Public subnet AZ3
      SecurityGroups:
        - sg-0123456789abcdef0  # ALB security group
      Tags:
        - Key: Name
          Value: web-alb

  # Target Group
  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: web-tg
      Port: 8080
      Protocol: HTTP
      VpcId: vpc-0123456789abcdef0
      HealthCheckEnabled: true
      HealthCheckProtocol: HTTP
      HealthCheckPath: /health
      HealthCheckIntervalSeconds: 30
      HealthCheckTimeoutSeconds: 5
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 3
      Matcher:
        HttpCode: 200-299
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: 30
        - Key: stickiness.enabled
          Value: 'false'
        - Key: load_balancing.algorithm.type
          Value: least_outstanding_requests
      Tags:
        - Key: Name
          Value: web-tg

  # HTTP Listener (redirect to HTTPS)
  HTTPListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
        - Type: redirect
          RedirectConfig:
            Protocol: HTTPS
            Port: '443'
            StatusCode: HTTP_301
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 80
      Protocol: HTTP

  # HTTPS Listener
  HTTPSListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      Certificates:
        - CertificateArn: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref WebTargetGroup
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 443
      Protocol: HTTPS
      SslPolicy: ELBSecurityPolicy-TLS-1-2-2017-01

  # Host-Based Routing
  HostBasedListenerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      Actions:
        - Type: forward
          TargetGroupArn: !Ref WebTargetGroup
      Conditions:
        - Field: host-header
          Values:
            - example.com
            - www.example.com
      ListenerArn: !Ref HTTPSListener
      Priority: 1

  # Path-Based Routing
  PathBasedListenerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      Actions:
        - Type: forward
          TargetGroupArn: !Ref APITargetGroup
      Conditions:
        - Field: path-pattern
          Values:
            - /api/*
      ListenerArn: !Ref HTTPSListener
      Priority: 2

  # API Target Group
  APITargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: api-tg
      Port: 8000
      Protocol: HTTP
      VpcId: vpc-0123456789abcdef0
      HealthCheckPath: /api/health
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: 60
        - Key: load_balancing.algorithm.type
          Value: least_outstanding_requests

  # Register EC2 Instances (Alternative: Auto Scaling Group)
  # Typically done via Auto Scaling Group with TargetGroupArNs property

  # CloudWatch Alarms
  ALBUnHealthyHostsAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: ALB-Unhealthy-Hosts
      MetricName: UnHealthyHostCount
      Namespace: AWS/ApplicationELB
      Statistic: Average
      Period: 300
      EvaluationPeriods: 2
      Threshold: 1
      ComparisonOperator: GreaterThanOrEqualToThreshold
      Dimensions:
        - Name: TargetGroup
          Value: !GetAtt WebTargetGroup.TargetGroupFullName
        - Name: LoadBalancer
          Value: !GetAtt ApplicationLoadBalancer.LoadBalancerFullName

  ALBHighLatencyAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: ALB-High-Latency
      MetricName: TargetResponseTime
      Namespace: AWS/ApplicationELB
      Statistic: Average
      Period: 300
      EvaluationPeriods: 2
      Threshold: 1.0  # 1 second
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: LoadBalancer
          Value: !GetAtt ApplicationLoadBalancer.LoadBalancerFullName

  ALBHTTPErrorsAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: ALB-HTTP-5xx-Errors
      MetricName: HTTPCode_Target_5XX_Count
      Namespace: AWS/ApplicationELB
      Statistic: Sum
      Period: 300
      EvaluationPeriods: 2
      Threshold: 10
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: LoadBalancer
          Value: !GetAtt ApplicationLoadBalancer.LoadBalancerFullName

Outputs:
  LoadBalancerDNS:
    Value: !GetAtt ApplicationLoadBalancer.DNSName
    Description: ALB DNS name
  LoadBalancerArn:
    Value: !Ref ApplicationLoadBalancer
    Description: ALB ARN
  TargetGroupArn:
    Value: !Ref WebTargetGroup
    Description: Target group ARN (for ASG)

Key Elements:

• Application Load Balancer for Layer 7 (application) routing
• HTTP to HTTPS redirect
• SSL/TLS termination at ALB
• Health checks with thresholds
• Host and path-based routing rules
• Deregistration delay for graceful shutdown
• Least outstanding requests algorithm
• CloudWatch alarms for health and performance

Pattern 2: Network Load Balancer for High Performance

Resources:
  # Network Load Balancer
  HighPerformanceLB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: high-perf-nlb
      Type: network
      Scheme: internet-facing
      IpAddressType: ipv4
      Subnets:
        - subnet-0123456789abcdef0
        - subnet-0123456789abcdef1
        - subnet-0123456789abcdef2
      LoadBalancerAttributes:
        - Key: load_balancing.cross_zone.enabled
          Value: 'true'
      Tags:
        - Key: Name
          Value: high-perf-nlb

  # TCP Target Group
  TCPTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: tcp-tg
      Port: 9000
      Protocol: TCP
      VpcId: vpc-0123456789abcdef0
      HealthCheckEnabled: true
      HealthCheckProtocol: TCP
      HealthCheckIntervalSeconds: 10
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: 30
        - Key: preserve_client_ip.enabled
          Value: 'true'

  # TCP Listener
  TCPListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref TCPTargetGroup
      LoadBalancerArn: !Ref HighPerformanceLB
      Port: 9000
      Protocol: TCP

Key Elements:

• Network Load Balancer for extreme performance
• TCP/UDP for low-latency protocols
• Ultra-high throughput (millions of RPS)
• Ultra-low latency (< 100 microseconds)
• Cross-zone load balancing

Pattern 3: Load Balancer with Security Group Integration

Resources:
  # Security group for ALB
  ALBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: alb-sg
      GroupDescription: Security group for ALB
      VpcId: vpc-0123456789abcdef0
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
          Description: HTTP from anywhere
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
          Description: HTTPS from anywhere
      SecurityGroupEgress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0

  # Security group for targets (restrict to ALB)
  TargetSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: target-sg
      GroupDescription: Security group for ALB targets
      VpcId: vpc-0123456789abcdef0
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 8080
          ToPort: 8080
          SourceSecurityGroupId: !Ref ALBSecurityGroup
          Description: App traffic from ALB
      SecurityGroupEgress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0

Key Elements:

• ALB in public subnets with public SG
• Target instances in private subnets
• Target SG restricts ingress to ALB only
• Egress allows outbound for database, external APIs

Integration Approaches

1. Integration with Auto Scaling Groups

ASG + ALB enables:

• Dynamic registration of targets
• Automatic scaling based on metrics
• Health check integration

2. Integration with CloudWatch

ALB + CloudWatch provides:

• Request count and latency metrics
• Target health metrics
• HTTP error rate tracking

3. Integration with WAF

WAF + ALB provides:

• Web application firewall rules
• DDoS protection
• SQL injection and XSS prevention

4. Integration with Route 53

Route 53 + ALB enables:

• DNS failover to secondary ALB
• Weighted routing policies
• Geolocation routing

Common Pitfalls

❌ Pitfall 1: Unhealthy Targets Not Deregistered

Problem: Failed instances still receive traffic; user-facing errors.

Solution:

• Set appropriate health check thresholds (2 failures = unhealthy)
• Monitor target health in CloudWatch
• Set UnhealthyThresholdCount appropriately

❌ Pitfall 2: No Connection Draining

Problem: In-flight requests dropped during instance termination.

Solution:

• Enable deregistration delay (connection draining)
• Set timeout appropriate for longest request (30-300s)
• Allows graceful shutdown

❌ Pitfall 3: Sticky Sessions Overused

Problem: Session stickiness can cause uneven load; if target fails, session lost.

Solution:

• Enable only for stateful applications
• Prefer stateless design
• Use session store (ElastiCache, RDS)

❌ Pitfall 4: Single AZ Deployment

Problem: AZ failure causes complete outage; no automatic failover.

Solution:

• Always register targets in multiple AZs (minimum 2)
• ALB automatically fails over to healthy targets
• Cross-zone load balancing distributes traffic

❌ Pitfall 5: SSL Policy Too Permissive

Problem: Weak SSL ciphers expose traffic to interception.

Solution:

• Use ELBSecurityPolicy-TLS-1-2-2017-01 or newer
• Disable older protocols (TLS 1.0, 1.1)
• Regular updates to AWS-managed policies

❌ Pitfall 6: Not Monitoring Target Health

Problem: Silent failures; no alerts when targets become unhealthy.

Solution:

• Enable CloudWatch alarms for unhealthy host count
• Monitor HTTP 5xx error rate
• Test health check endpoint regularly

Best Practices Summary

Related Skills

Core Workflow

1. Assess Requirements — Understand the use case, scale, integration needs, and existing infrastructure. Checkpoint: Document requirements, constraints, and success criteria.

2. Design Architecture — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. Checkpoint: Verify the architecture addresses all requirements and follows CNCF conventions.

3. Implement & Configure — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. Checkpoint: Validate all YAML against schema and test in a staging environment.

4. Deploy & Monitor — Apply manifests to the cluster, verify component health, and confirm observability is working. Checkpoint: Confirm all pods/services are running, probes passing, and metrics/alerts configured.

Constraints

MUST DO

• Include at least one complete working YAML manifest example
• Note when content is auto-generated vs. manually verified
• Reference relevant CNCF project documentation

MUST NOT DO

• Deploy manifests without testing in a staging environment first
• Use deprecated API versions (e.g., apps/v1beta1)
• Omit resource limits and requests in Kubernetes manifests

Live References

Authoritative documentation links for this skill's domain. The model follows markdown links at load time to resolve external references and inline content.

• Primary Documentation
• API Reference or Getting Started
• Configuration Guide
• Best Practices
• Common Patterns or Tutorials