AWS Load Balancing and Traffic Management

2. 🌐 Load Balancing at OSI Layers

Layer 3 (Network Layer) - Network Load Balancer (NLB)

graph LR subgraph "Layer 3 Processing" Client_IP[📱 Client
IP: 203.0.113.100] NLB_IP[⚡ NLB
IP: 203.0.113.200
Port: 80] subgraph "5-Tuple Hashing" Hash[🔢 Hash Algorithm
Source IP + Port
Dest IP + Port
Protocol] end Target1[🖥️ Target 1
10.0.1.10:80] Target2[🖥️ Target 2
10.0.1.20:80] Target3[🖥️ Target 3
10.0.1.30:80] end Client_IP --> NLB_IP NLB_IP --> Hash Hash --> Target1 Hash --> Target2 Hash --> Target3 subgraph "NLB Features" F1[⚡ Ultra-low latency
< 100μs] F2[🎯 Static IP per AZ] F3[🔍 Source IP preservation] F4[📊 Millions RPS] F5[🔄 Connection tracking] end

Layer 3 Network Load Balancer: NLB operates at the network layer, making routing decisions based on IP addresses and ports using a 5-tuple hash algorithm. It provides ultra-low latency (sub-100 microseconds), preserves source IP addresses, and can handle millions of requests per second with static IP addresses for each availability zone.

1Create Network Load Balancer

aws elbv2 create-load-balancer \
    --name my-network-load-balancer \
    --scheme internet-facing \
    --type network \
    --subnets subnet-12345678 subnet-87654321 \
    --tags Key=Environment,Value=Production Key=Application,Value=WebApp

NLB Creation Parameters:

--type network: Specifies Network Load Balancer (Layer 3/4)
--scheme internet-facing: Creates public-facing NLB (use 'internal' for private)
--subnets: Must specify subnets in at least 2 AZs for high availability
--tags: Resource tagging for cost allocation and management

Setup Order: This is the first command to create the foundational NLB infrastructure. The load balancer will get automatic static IP addresses in each specified subnet.

Layer 4 (Transport Layer) - Connection Flow

sequenceDiagram participant C as 👤 Client
203.0.113.50 participant NLB as ⚡ Network LB
203.0.113.200 participant T1 as 🖥️ Target 1
10.0.1.10 participant T2 as 🖥️ Target 2
10.0.1.20 Note over C,T2: TCP Connection Establishment C->>NLB: TCP SYN (Port 80)
Seq: 1000 Note over NLB: Flow Hash Calculation
(203.0.113.50:45678 + 203.0.113.200:80 + TCP) NLB->>T1: Forward TCP SYN
Source IP preserved T1->>NLB: TCP SYN-ACK
Seq: 2000, Ack: 1001 NLB->>C: TCP SYN-ACK C->>NLB: TCP ACK + HTTP Request NLB->>T1: Forward to same target
(connection tracking) Note over C,T2: New Connection (Different Flow) C->>NLB: New TCP SYN (Port 443) Note over NLB: New 5-tuple hash
Routes to different target NLB->>T2: Forward to Target 2

Layer 4 Connection Tracking: NLB maintains connection state using flow hash tables. Each unique 5-tuple (source IP, source port, destination IP, destination port, protocol) creates a flow entry that ensures all packets for that connection go to the same target. This provides session persistence while preserving the original client IP address.

2Create Target Group for NLB

aws elbv2 create-target-group \
    --name my-tcp-targets \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-12345678 \
    --target-type instance \
    --health-check-protocol TCP \
    --health-check-port 80 \
    --health-check-interval-seconds 30 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2

TCP Target Group Parameters:

--protocol TCP: Layer 4 protocol (TCP/UDP/TLS available)
--target-type instance: Targets are EC2 instances (vs 'ip' for IP addresses)
--health-check-protocol TCP: Simple TCP connection test
--health-check-interval-seconds 30: Check every 30 seconds
--healthy-threshold-count 2: 2 successful checks = healthy

Purpose: This creates the target group that will contain your backend instances. The TCP health check verifies basic connectivity without HTTP overhead.

Layer 7 (Application Layer) - Application Load Balancer

graph TD subgraph "Client Requests" Req1[🌐 GET /api/users
Host: api.example.com] Req2[🌐 GET /admin/dashboard
Host: admin.example.com
Cookie: session=premium] Req3[🌐 POST /checkout
Header: X-User-Type: premium] end ALB[🔄 Application Load Balancer
Layer 7 Processing] subgraph "Routing Rules" Rule1{🔍 Path Pattern
/api/*} Rule2{🏠 Host Header
admin.example.com} Rule3{👑 HTTP Header
X-User-Type: premium} Rule4{🍪 Cookie
session=premium} end subgraph "Target Groups" TG_API[🎯 API Microservices
Health: HTTP GET /health] TG_Admin[🎯 Admin Services
Health: HTTP GET /admin/health] TG_Premium[🎯 Premium Services
Health: HTTP GET /status] TG_Standard[🎯 Standard Services
Health: HTTP GET /ping] end Req1 --> ALB Req2 --> ALB Req3 --> ALB ALB --> Rule1 ALB --> Rule2 ALB --> Rule3 ALB --> Rule4 Rule1 -->|Match /api/*| TG_API Rule2 -->|Match Host| TG_Admin Rule3 -->|Premium Header| TG_Premium Rule4 -->|Premium Cookie| TG_Premium ALB -->|Default| TG_Standard TG_API --> API1[🖥️ API-1
10.0.1.10] TG_API --> API2[🖥️ API-2
10.0.1.20] TG_Admin --> Admin1[🖥️ Admin-1
10.0.2.10] TG_Premium --> Prem1[🖥️ Premium-1
10.0.3.10] TG_Standard --> Std1[🖥️ Standard-1
10.0.4.10]

Layer 7 Application Load Balancer: ALB inspects HTTP/HTTPS content to make intelligent routing decisions. It can route based on URL paths, host headers, HTTP headers, query parameters, and cookies. This enables sophisticated architectures like microservices, canary deployments, and user-based routing with detailed HTTP health checks.

1Create Application Load Balancer

aws elbv2 create-load-balancer \
    --name my-application-load-balancer \
    --scheme internet-facing \
    --type application \
    --subnets subnet-12345678 subnet-87654321 \
    --security-groups sg-12345678 \
    --ip-address-type ipv4 \
    --tags Key=Environment,Value=Production

ALB Creation Parameters:

--type application: Specifies Application Load Balancer (Layer 7)
--security-groups: Required for ALB to control inbound/outbound traffic
--ip-address-type ipv4: IPv4 only (can be 'dualstack' for IPv4+IPv6)
--scheme internet-facing: Public ALB (use 'internal' for VPC-only)

Setup Order: This is the first command for ALB setup. Unlike NLB, ALB requires security groups and operates in public subnets for internet-facing deployments.

2Create Target Group with HTTP Health Checks

aws elbv2 create-target-group \
    --name my-web-app-targets \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-12345678 \
    --target-type instance \
    --health-check-protocol HTTP \
    --health-check-path /health \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 10 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3 \
    --matcher HttpCode=200

HTTP Target Group Parameters:

--protocol HTTP: Application layer protocol (HTTP/HTTPS)
--health-check-path /health: Specific endpoint for health checks
--health-check-timeout-seconds 10: Timeout for each health check
--matcher HttpCode=200: Expected HTTP status code(s)
--unhealthy-threshold-count 3: 3 failures before marking unhealthy

Purpose: Creates HTTP-aware target group with application-level health checks. The health check endpoint should return application status, not just connectivity.

3. 🔧 Load Balancer Types and Selection Criteria

graph TD Decision{🤔 Choose Load Balancer Type} Decision -->|Ultra-low latency
Static IP needed
TCP/UDP traffic| NLB[⚡ Network Load Balancer
Layer 3/4] Decision -->|HTTP/HTTPS
Content-based routing
SSL termination| ALB[🔄 Application Load Balancer
Layer 7] Decision -->|Legacy applications
Basic load balancing
Cost-sensitive| CLB[🔄 Classic Load Balancer
Layer 4/7] Decision -->|Global traffic
DNS-based routing
Multi-region| GLB[🌍 Global Load Balancer
Route 53] subgraph "NLB Use Cases" NLB_UC1[📡 Real-time gaming] NLB_UC2[💱 Financial trading] NLB_UC3[🎬 Media streaming] NLB_UC4[🔌 IoT/TCP connections] end subgraph "ALB Use Cases" ALB_UC1[🌐 Web applications] ALB_UC2[🔗 Microservices] ALB_UC3[📱 Mobile APIs] ALB_UC4[🧪 A/B testing] end subgraph "Selection Criteria" SC1[📊 Performance Requirements] SC2[💰 Cost Considerations] SC3[🔧 Feature Requirements] SC4[🏗️ Architecture Complexity] end NLB --> NLB_UC1 NLB --> NLB_UC2 NLB --> NLB_UC3 NLB --> NLB_UC4 ALB --> ALB_UC1 ALB --> ALB_UC2 ALB --> ALB_UC3 ALB --> ALB_UC4

Load Balancer Selection Guide: This decision tree helps choose the appropriate load balancer type based on specific requirements. NLB for maximum performance and static IPs, ALB for HTTP/HTTPS applications with advanced routing, CLB for legacy compatibility, and Global Load Balancer for multi-region deployments.

Feature	Network LB (NLB)	Application LB (ALB)	Classic LB (CLB)
OSI Layer	Layer 3/4	Layer 7	Layer 4/7
Protocols	TCP, UDP, TLS	HTTP, HTTPS	TCP, HTTP, HTTPS
Latency	Ultra-low (~100μs)	Low (~400μs)	Medium
Static IP	✅ Yes	❌ No	❌ No
SSL Termination	✅ Yes	✅ Yes	✅ Yes
Content Routing	❌ No	✅ Yes	❌ No
WebSockets	✅ Yes	✅ Yes	✅ Yes
Source IP Preservation	✅ Always	⚠️ Via headers	⚠️ Via headers

4. ⚙️ Configuration Options

Cross-Zone Load Balancing

graph TB subgraph "Without Cross-Zone LB" Client1[👤 Client 1] --> AZ1_LB[🔄 AZ-1 LB Node
50% traffic] Client2[👤 Client 2] --> AZ2_LB[🔄 AZ-2 LB Node
50% traffic] AZ1_LB --> AZ1_T1[🖥️ Target 1] AZ1_LB --> AZ1_T2[🖥️ Target 2] AZ1_LB --> AZ1_T3[🖥️ Target 3] AZ2_LB --> AZ2_T1[🖥️ Target 4] subgraph "AZ-1: 3 targets" AZ1_T1 AZ1_T2 AZ1_T3 end subgraph "AZ-2: 1 target" AZ2_T1 end end subgraph "With Cross-Zone LB" Client3[👤 Client 3] --> AZ1_LB_CZ[🔄 AZ-1 LB Node
50% traffic] Client4[👤 Client 4] --> AZ2_LB_CZ[🔄 AZ-2 LB Node
50% traffic] AZ1_LB_CZ --> CZ_T1[🖥️ Target 1
25%] AZ1_LB_CZ --> CZ_T2[🖥️ Target 2
25%] AZ1_LB_CZ --> CZ_T3[🖥️ Target 3
25%] AZ1_LB_CZ --> CZ_T4[🖥️ Target 4
25%] AZ2_LB_CZ --> CZ_T1 AZ2_LB_CZ --> CZ_T2 AZ2_LB_CZ --> CZ_T3 AZ2_LB_CZ --> CZ_T4 subgraph "All targets get equal traffic" CZ_T1 CZ_T2 CZ_T3 CZ_T4 end end

Cross-Zone Load Balancing Impact: Without cross-zone LB, traffic is distributed equally among AZ nodes, but unevenly among targets (66.7% to AZ-1 targets, 33.3% to AZ-2). With cross-zone LB enabled, all targets receive equal traffic (25% each) regardless of AZ distribution, but this incurs cross-AZ data transfer charges.

3Enable Cross-Zone Load Balancing

aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/1234567890abcdef \
    --attributes Key=load_balancing.cross_zone.enabled,Value=true

Cross-Zone Configuration:

load_balancing.cross_zone.enabled: Enables even distribution across all targets
ALB: Cross-zone is always enabled (no charge)
NLB: Disabled by default (incurs cross-AZ charges when enabled)
Impact: Better traffic distribution but higher data transfer costs

When to Use: Enable when target distribution is uneven across AZs and consistent load distribution is more important than cost optimization.

Session Affinity (Stickiness)

sequenceDiagram participant C as 👤 Client participant ALB as 🔄 ALB participant T1 as 🖥️ Target 1 participant T2 as 🖥️ Target 2 Note over C,T2: First Request - No Session C->>ALB: GET /login
No session cookie ALB->>T1: Route to Target 1
(Round-robin selection) T1->>ALB: HTTP 200 + Session Data
Set user session ALB->>C: HTTP 200 + Sticky Cookie
AWSALB=target1hash Note over C,T2: Subsequent Requests - Session Affinity C->>ALB: GET /dashboard
Cookie: AWSALB=target1hash Note over ALB: Cookie indicates Target 1
Route to same target ALB->>T1: Route to Target 1
(Session affinity) T1->>ALB: HTTP 200 + User Data
Session maintained ALB->>C: HTTP 200
Session preserved Note over C,T2: Target Failure Scenario C->>ALB: GET /profile
Cookie: AWSALB=target1hash ALB->>T1: Health check failed Note over ALB: Target 1 unhealthy
Route to healthy target ALB->>T2: Route to Target 2
New session required T2->>ALB: HTTP 200
Session reset ALB->>C: HTTP 200 + New Cookie
AWSALB=target2hash

Session Affinity Behavior: When enabled, ALB uses application-controlled cookies or duration-based stickiness to route requests from the same client to the same target. This preserves session state but can create uneven load distribution. If the target becomes unhealthy, the session is redirected to a healthy target.

4Configure Session Stickiness

aws elbv2 modify-target-group-attributes \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/1234567890abcdef \
    --attributes Key=stickiness.enabled,Value=true \
                 Key=stickiness.type,Value=lb_cookie \
                 Key=stickiness.lb_cookie.duration_seconds,Value=86400

Stickiness Parameters:

stickiness.enabled=true: Enables session affinity
stickiness.type=lb_cookie: Load balancer-generated cookie (vs 'app_cookie')
duration_seconds=86400: Cookie expires after 24 hours (1-604800 seconds)
Alternative: Use 'app_cookie' type for application-controlled stickiness

Trade-offs: Improves user experience for stateful applications but can cause uneven load distribution and reduced fault tolerance.

Proxy Protocol Configuration

graph LR subgraph "Without Proxy Protocol" Client1[👤 Client
203.0.113.50] --> NLB1[⚡ NLB
203.0.113.200] NLB1 --> Target1[🖥️ Backend
Sees: 203.0.113.200
❌ Lost original IP] end subgraph "With Proxy Protocol v1" Client2[👤 Client
203.0.113.50] --> NLB2[⚡ NLB
203.0.113.200] NLB2 --> Target2[🖥️ Backend
Receives: PROXY TCP4
203.0.113.50 203.0.113.200
45678 80
✅ Original IP preserved] end subgraph "With Proxy Protocol v2" Client3[👤 Client
203.0.113.50] --> NLB3[⚡ NLB
203.0.113.200] NLB3 --> Target3[🖥️ Backend
Receives: Binary header
+ TLV extensions
✅ Rich metadata] end

Proxy Protocol Functionality: Proxy Protocol preserves original client connection information when load balancers proxy connections. Version 1 uses human-readable text format, while version 2 uses efficient binary format with additional metadata. Backend applications must be configured to parse the proxy protocol header.

5Enable Proxy Protocol

aws elbv2 modify-target-group-attributes \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/1234567890abcdef \
    --attributes Key=proxy_protocol_v2.enabled,Value=true

Proxy Protocol Options:

proxy_protocol_v2.enabled=true: Enables Proxy Protocol v2 (binary format)
NLB Only: ALB doesn't support Proxy Protocol (uses X-Forwarded headers)
Backend Support: Application must parse Proxy Protocol headers
Use Cases: Logging original IPs, security analysis, geographic routing

Important: Ensure your backend applications support Proxy Protocol before enabling, or connections will fail.

Routing Algorithms

graph TD subgraph "Round Robin (Default ALB)" RR_Req1[📨 Request 1] --> RR_T1[🖥️ Target 1] RR_Req2[📨 Request 2] --> RR_T2[🖥️ Target 2] RR_Req3[📨 Request 3] --> RR_T3[🖥️ Target 3] RR_Req4[📨 Request 4] --> RR_T1 end subgraph "Least Outstanding Requests (ALB)" LOR_Req1[📨 Request 1
Target 1: 5 active] --> LOR_T2[🖥️ Target 2
3 active ✅] LOR_Req2[📨 Request 2
Target 2: 4 active] --> LOR_T3[🖥️ Target 3
2 active ✅] LOR_Req3[📨 Request 3
All equal: 3 active] --> LOR_T1[🖥️ Target 1
Round-robin ✅] end subgraph "Flow Hash (NLB Default)" FH_Flow1[📨 Flow 1
203.0.113.50:45678] --> FH_Hash{🔢 5-tuple Hash} FH_Flow2[📨 Flow 2
203.0.113.51:45679] --> FH_Hash FH_Hash --> FH_T1[🖥️ Target 1
Consistent routing] FH_Hash --> FH_T2[🖥️ Target 2
Consistent routing] end

Load Balancing Algorithms: ALB uses Round Robin by default (equal distribution) or Least Outstanding Requests (routes to target with fewest active connections). NLB uses Flow Hash based on 5-tuple (source IP, source port, destination IP, destination port, protocol) ensuring consistent routing for the same connection flow.

6Configure Routing Algorithm

aws elbv2 modify-target-group-attributes \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/1234567890abcdef \
    --attributes Key=load_balancing.algorithm.type,Value=least_outstanding_requests

Algorithm Options:

round_robin: Default for ALB, equal distribution
least_outstanding_requests: ALB only, routes to least busy target
NLB: Always uses flow hash algorithm (not configurable)
Performance: Least outstanding requests better for varying request durations

Best Practice: Use least outstanding requests for applications with variable response times or when targets have different processing capabilities.

5. 🎯 Target Group Configurations

Target Types Comparison

graph TB subgraph "Instance Target Type" TG_Instance[🎯 Target Group
Type: instance] TG_Instance --> EC2_1[🖥️ EC2 Instance
i-1234567890abcdef0
Auto-discovered IP] TG_Instance --> EC2_2[🖥️ EC2 Instance
i-0987654321fedcba0
Auto-discovered IP] TG_Instance --> EC2_3[🖥️ EC2 Instance
i-abcdef1234567890
Auto-discovered IP] end subgraph "IP Target Type" TG_IP[🎯 Target Group
Type: ip] TG_IP --> IP_1[🌐 IP Target
10.0.1.100:80
Manual IP specification] TG_IP --> IP_2[🌐 IP Target
192.168.1.50:8080
On-premises server] TG_IP --> Lambda[⚡ Lambda Function
Auto-assigned IP
Serverless target] end subgraph "ALB Target Type" TG_ALB[🎯 Target Group
Type: alb] TG_ALB --> ALB_Target[🔄 Another ALB
Multi-tier architecture
ALB chaining] end subgraph "Protocol Support" Proto_HTTP[📄 HTTP/HTTPS
Layer 7 protocols] Proto_TCP[🔌 TCP/UDP/TLS
Layer 4 protocols] Proto_GENEVE[🌐 GENEVE
Gateway Load Balancer] end

Target Group Types: Instance targets automatically resolve EC2 instance IPs and integrate with Auto Scaling. IP targets allow manual IP specification for containers, on-premises servers, or Lambda functions. ALB targets enable chaining load balancers for complex architectures. Each type supports different protocols and use cases.

7Create IP-based Target Group

aws elbv2 create-target-group \
    --name my-ip-targets \
    --protocol HTTP \
    --port 8080 \
    --vpc-id vpc-12345678 \
    --target-type ip \
    --ip-address-type ipv4 \
    --health-check-protocol HTTP \
    --health-check-path /api/health \
    --health-check-port 8080 \
    --health-check-interval-seconds 30 \
    --matcher HttpCode=200,201

IP Target Group Parameters:

--target-type ip: Allows IP addresses as targets (not just EC2 instances)
--ip-address-type ipv4: IPv4 addressing (can be 'ipv6' or 'dualstack')
--health-check-port 8080: Custom health check port
--matcher HttpCode=200,201: Multiple acceptable HTTP status codes

Use Cases: Containers with dynamic IPs, microservices on Fargate, Lambda functions, or hybrid architectures with on-premises servers.

8Register IP Targets

aws elbv2 register-targets \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-ip-targets/1234567890abcdef \
    --targets Id=10.0.1.100,Port=8080 \
             Id=10.0.2.150,Port=8080 \
             Id=192.168.1.50,Port=9090,AvailabilityZone=us-east-1a

Target Registration Parameters:

Id=10.0.1.100: IP address of the target
Port=8080: Port for this specific target (can override TG default)
AvailabilityZone: Required for targets outside VPC
Multiple targets: Can register multiple targets in single command

Dynamic Registration: Use this command in deployment scripts or auto-scaling events to dynamically add/remove targets.

GENEVE Protocol for Gateway Load Balancer

graph TB subgraph "GENEVE Encapsulation Flow" Client[👤 Client
Original Packet] --> IGW[🌐 Internet Gateway] IGW --> GWLB[⚖️ Gateway Load Balancer
GENEVE Encapsulation] GWLB --> Appliance1[🛡️ Security Appliance 1
Firewall/IDS] GWLB --> Appliance2[🛡️ Security Appliance 2
DPI/WAF] GWLB --> Appliance3[🛡️ Security Appliance 3
Threat Detection] Appliance1 --> GWLB_Return[⚖️ GWLB Return Path
GENEVE Decapsulation] Appliance2 --> GWLB_Return Appliance3 --> GWLB_Return GWLB_Return --> Target_App[🎯 Target Application
Original packet restored] end subgraph "GENEVE Packet Structure" Outer_IP[📦 Outer IP Header
GWLB ↔ Appliance] UDP_Header[📦 UDP Header
Port 6081] GENEVE_Header[📦 GENEVE Header
VNI + Metadata] Original_Packet[📦 Original Packet
Client ↔ Application] end Outer_IP --> UDP_Header UDP_Header --> GENEVE_Header GENEVE_Header --> Original_Packet

GENEVE Protocol in Gateway Load Balancer: GWLB uses GENEVE encapsulation to send original packets to security appliances while preserving source and destination information. The appliances process the encapsulated packets and return them for decapsulation, enabling transparent security inspection without changing the original traffic flow.

9Create Gateway Load Balancer with GENEVE

aws elbv2 create-load-balancer \
    --name my-gateway-load-balancer \
    --type gateway \
    --subnets subnet-12345678 subnet-87654321 \
    --scheme internal \
    --tags Key=Purpose,Value=SecurityInspection

Gateway Load Balancer Parameters:

--type gateway: Creates Gateway Load Balancer for packet inspection
--scheme internal: GWLB is always internal (no internet-facing option)
Protocol: Automatically uses GENEVE protocol on UDP port 6081
Use Case: Transparent network security appliance integration

Architecture: GWLB sits transparently in the traffic path, sending packets to security appliances for inspection without application awareness.

10Create GENEVE Target Group

aws elbv2 create-target-group \
    --name security-appliances \
    --protocol GENEVE \
    --port 6081 \
    --vpc-id vpc-12345678 \
    --target-type instance \
    --health-check-protocol HTTP \
    --health-check-path /health \
    --health-check-port 80

GENEVE Target Group Parameters:

--protocol GENEVE: Uses GENEVE encapsulation protocol
--port 6081: Standard GENEVE port
--health-check-protocol HTTP: Health checks use HTTP (not GENEVE)
Requirements: Targets must support GENEVE decapsulation

Security Appliances: Targets must be security appliances capable of processing GENEVE-encapsulated traffic and returning processed packets.

6. ☸️ AWS Load Balancer Controller for Kubernetes

graph TB subgraph "Kubernetes Cluster" subgraph "AWS Load Balancer Controller" Controller[🎛️ AWS LB Controller\nWatches K8s resources\nManages AWS resources] end subgraph "Kubernetes Resources" Ingress[📋 Ingress Resource\nalb.ingress.kubernetes.io] Service_NLB[📋 Service - NLB\nservice.beta.kubernetes.io] Service_ALB[📋 Service - ALB\nTargetGroupBinding] end subgraph "Application Pods" Pod1[🐙 Pod 1\n10.0.1.10] Pod2[🐙 Pod 2\n10.0.1.20] Pod3[🐙 Pod 3\n10.0.1.30] end end subgraph "AWS Resources" ALB_AWS[🔄 Application LB\nCreated by Controller] NLB_AWS[⚡ Network LB\nCreated by Controller] TG_AWS[🎯 Target Groups\nAuto-managed] end Controller --> ALB_AWS Controller --> NLB_AWS Controller --> TG_AWS Ingress -.-> Controller Service_NLB -.-> Controller Service_ALB -.-> Controller ALB_AWS --> Pod1 ALB_AWS --> Pod2 NLB_AWS --> Pod3 TG_AWS --> Pod1 TG_AWS --> Pod2 TG_AWS --> Pod3

AWS Load Balancer Controller Architecture: The controller watches Kubernetes Ingress and Service resources, automatically creating and managing AWS load balancers and target groups. It registers Pod IPs as targets and handles lifecycle management, scaling, and health checks, providing seamless integration between Kubernetes and AWS load balancing services.

11Install AWS Load Balancer Controller

helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
    --set clusterName=my-eks-cluster \
    --set serviceAccount.create=false \
    --set serviceAccount.name=aws-load-balancer-controller \
    --set region=us-east-1 \
    --set vpcId=vpc-12345678 \
    -n kube-system

Controller Installation Parameters:

--set clusterName: EKS cluster name for resource tagging
--set serviceAccount.create=false: Use existing service account with IAM role
--set region: AWS region for load balancer creation
--set vpcId: VPC where load balancers will be created

Prerequisites: Service account must exist with appropriate IAM permissions to manage ELB resources.

12Create Ingress for Application Load Balancer

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: my-k8s-alb
    alb.ingress.kubernetes.io/group.name: my-app-group
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: admin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: admin-service
            port:
              number: 80

Ingress Annotations Explained:

scheme: internet-facing: Creates public ALB (use 'internal' for private)
target-type: ip: Registers pod IPs directly (vs 'instance')
group.name: Groups multiple ingresses to share same ALB
ssl-redirect: Automatically redirects HTTP to HTTPS
certificate-arn: ACM certificate for SSL termination

Behavior: Controller creates ALB with listeners on ports 80/443, configures SSL termination, and sets up host-based routing rules.

13Create Service for Network Load Balancer

apiVersion: v1
kind: Service
metadata:
  name: my-nlb-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "HTTP"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/health"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: my-app

NLB Service Annotations:

aws-load-balancer-type: "nlb": Creates Network Load Balancer
cross-zone-load-balancing-enabled: Enables cross-AZ load balancing
backend-protocol: "tcp": Layer 4 TCP protocol
healthcheck-protocol: "HTTP": HTTP health checks (vs TCP)
proxy-protocol: "*": Enables Proxy Protocol v2

Use Case: High-performance TCP/UDP load balancing with ultra-low latency requirements.

🔄 AWS Load Balancing and Traffic Management

📋 Table of Contents

1. 🏗️ Overview