AWS Elastic Load Balancing

Understanding Load Balancing, Scalability, and High Availability

What is Elastic Load Balancing?

AWS Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of registered targets and routes traffic only to healthy targets.

Key Functions

  • Traffic distribution
  • Health checking
  • SSL/TLS termination
  • Session persistence
  • Cross-zone balancing
  • Path-based routing
  • Host-based routing
  • HTTP header-based routing
  • Query string parameter-based routing

Key Terminology

Listeners

A process that checks for connection requests using the protocol and port you configure. Each load balancer needs at least one listener.

Target Groups

A collection of targets (EC2 instances, IP addresses, Lambda functions, etc.) that receive traffic from the load balancer.

Rules

Define how requests are routed to targets. Each rule consists of a priority, one or more actions, and one or more conditions.

Health Checks

Periodic tests to verify that targets are functioning as expected.

Load Balancer Flow Diagram

┌───────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                                   │
│                                         Internet                                                  │
│                                            │                                                      │
└────────────────────────────────────────────┼──────────────────────────────────────────────────────┘
                                             │
                                             ▼
┌───────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                                   │
│                                      Security Group                                               │
│                                            │                                                      │
└────────────────────────────────────────────┼──────────────────────────────────────────────────────┘
                                             │
                                             ▼
┌───────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                                   │
│                                     Elastic Load Balancer                                         │
│                                            │                                                      │
│                                            │                                                      │
│                ┌───────────────────────────┼───────────────────────────┐                          │
│                │                           │                           │                          │
│                ▼                           ▼                           ▼                          │
│         ┌─────────────┐            ┌─────────────┐            ┌─────────────┐                    │
│         │  Listener 1 │            │  Listener 2 │            │  Listener 3 │                    │
│         │ (HTTP:80)   │            │ (HTTPS:443) │            │ (TCP:3306)  │                    │
│         └──────┬──────┘            └──────┬──────┘            └──────┬──────┘                    │
│                │                           │                           │                          │
│                ▼                           ▼                           ▼                          │
│         ┌─────────────┐            ┌─────────────┐            ┌─────────────┐                    │
│         │    Rules    │            │    Rules    │            │    Rules    │                    │
│         └──────┬──────┘            └──────┬──────┘            └──────┬──────┘                    │
│                │                           │                           │                          │
│                ▼                           ▼                           ▼                          │
│         ┌─────────────┐            ┌─────────────┐            ┌─────────────┐                    │
│         │Target Group1│            │Target Group2│            │Target Group3│                    │
│         └──────┬──────┘            └──────┬──────┘            └──────┬──────┘                    │
│                │                           │                           │                          │
└────────────────┼───────────────────────────┼───────────────────────────┼──────────────────────────┘
                 │                           │                           │
                 ▼                           ▼                           ▼
┌────────────────────────────┐  ┌────────────────────────────┐  ┌────────────────────────────┐
│                            │  │                            │  │                            │
│     EC2 Instances          │  │     Containers             │  │     Lambda Functions       │
│     IP Addresses           │  │     IP Addresses           │  │                            │
│                            │  │                            │  │                            │
└────────────────────────────┘  └────────────────────────────┘  └────────────────────────────┘

Key Differences: Scalability vs Availability

Aspect Scalability Availability
Primary Focus Performance and capacity Uptime and reliability
Measures Throughput, response time Uptime percentage, MTBF
Challenges Resource limits, costs Single points of failure
Solutions Auto Scaling, larger instances Redundancy, failover
ELB Features Connection draining, auto scaling integration Multi-AZ deployment, health checks

Application Load Balancer (ALB)

Layer 7 Features

  • HTTP/HTTPS traffic routing
  • Path-based routing
  • Host-based routing
  • Query string routing
  • HTTP header routing
  • WebSocket support
  • HTTP/2 support
  • gRPC support
  • Fixed response actions
  • Redirect actions

Use Cases

  • Microservices architecture
  • Container-based applications
  • Web applications
  • API endpoints
  • Single-page applications
  • Mobile backends

Pricing

$0.0225 per ALB-hour (or partial hour) + $0.008 per LCU-hour (or partial hour)

LCU = Load Balancer Capacity Unit, based on new connections, active connections, bandwidth, and rule evaluations

Network Load Balancer (NLB)

Layer 4 Features

  • TCP/UDP/TLS traffic
  • Ultra-low latency (~100μs)
  • Static IP support
  • Elastic IP support
  • Connection preservation
  • Source IP preservation
  • Millions of requests per second
  • Private Link integration
  • Zonal isolation
  • TLS termination

Use Cases

  • TCP/UDP applications
  • Gaming applications
  • IoT services
  • Media streaming
  • VoIP applications
  • Financial trading platforms

Pricing

$0.0225 per NLB-hour (or partial hour) + $0.006 per LCU-hour (or partial hour)

NLB LCU based on new connections, active connections, and bandwidth

Gateway Load Balancer (GWLB)

Layer 3/4 Features

  • GENEVE protocol support (port 6081)
  • Transparent network gateway
  • Virtual appliance scaling
  • High availability
  • Health monitoring
  • Flow symmetry
  • Appliance fleet management

Use Cases

  • Firewall deployments
  • Intrusion detection/prevention systems
  • Deep packet inspection
  • Security appliances
  • Network analytics
  • Web application firewalls

Pricing

$0.0225 per GWLB-hour (or partial hour) + $0.008 per LCU-hour (or partial hour)

GWLB LCU based on new connections, active connections, and bandwidth

Classic Load Balancer (CLB)

Legacy Features

  • Basic Layer 4/7 routing
  • EC2-Classic support
  • Simple routing
  • Basic health checks
  • SSL termination
  • Sticky sessions (only cookie-based)
  • Connection draining

Note: Not recommended for new applications. Use ALB or NLB instead.

Limitations

  • No advanced routing capabilities
  • No HTTP/2 or WebSocket support
  • No path-based routing
  • No host-based routing
  • No support for containers
  • Limited monitoring metrics

Pricing

$0.025 per CLB-hour (or partial hour) + $0.008 per GB of data processed

Load Balancer Type Comparison

Feature Application LB Network LB Gateway LB Classic LB
OSI Layer Layer 7 Layer 4 Layer 3/4 Layer 4/7
Protocol Support HTTP, HTTPS TCP, UDP, TLS IP (GENEVE) TCP, SSL/TLS, HTTP, HTTPS
Static IP No Yes Yes No
Connection Draining Yes (Deregistration Delay) Yes (Deregistration Delay) Yes (Deregistration Delay) Yes
Path-based Routing Yes No No No
WebSocket Yes Yes No No
HTTP/2 Yes No No No
Sticky Sessions Yes (Application or Duration-based) Yes (Source IP) Yes (Flow Hash) Yes (Duration-based)

Security Groups for Load Balancers

Overview

Security groups act as virtual firewalls for your load balancers and instances, controlling inbound and outbound traffic.

  • Stateful - return traffic is automatically allowed
  • Allow rules only (no explicit deny)
  • Applied at the instance level
  • Evaluated before traffic reaches the load balancer

Load Balancer Security Group

# Inbound Rules
HTTP (80): 0.0.0.0/0
HTTPS (443): 0.0.0.0/0

# Outbound Rules
All traffic: Target Security Group

Target Security Group

# Inbound Rules
HTTP (80): Load Balancer Security Group
HTTPS (443): Load Balancer Security Group

# Outbound Rules
All traffic: 0.0.0.0/0

SSL/TLS Security

SSL Termination

Load balancers can decrypt HTTPS traffic before sending it to targets, reducing the computational load on backend servers.

  • Centralized SSL certificate management
  • Reduced backend processing
  • Simplified certificate renewal
  • Support for multiple certificates

Security Policies

Predefined security policies that specify SSL protocols, ciphers, and server order preference.

  • ELBSecurityPolicy-TLS13-1-2-2021-06
  • ELBSecurityPolicy-TLS13-1-2-Res-2021-06
  • ELBSecurityPolicy-TLS13-1-1-2021-06
  • ELBSecurityPolicy-FS-1-2-Res-2020-10
  • ELBSecurityPolicy-FS-1-2-Res-2019-08

Network ACLs

Overview

Network Access Control Lists (NACLs) provide an additional layer of security at the subnet level.

  • Stateless - return traffic must be explicitly allowed
  • Both allow and deny rules
  • Applied at the subnet level
  • Processed in order (lowest rule number first)

NACL Configuration for Load Balancers

# Inbound Rules
100: Allow HTTP (80) from 0.0.0.0/0
110: Allow HTTPS (443) from 0.0.0.0/0
120: Allow ephemeral ports (1024-65535) from 0.0.0.0/0
* Deny all other traffic

# Outbound Rules
100: Allow HTTP (80) to 0.0.0.0/0
110: Allow HTTPS (443) to 0.0.0.0/0
120: Allow ephemeral ports (1024-65535) to 0.0.0.0/0
* Deny all other traffic

Security Best Practices

General Recommendations

  • Use HTTPS instead of HTTP
  • Implement the latest security policies
  • Restrict access to load balancers using security groups
  • Enable access logs for auditing
  • Use AWS WAF with ALB for additional protection
  • Implement least privilege access for management
  • Regularly rotate SSL/TLS certificates

Common Vulnerabilities

  • Overly permissive security groups
  • Outdated SSL/TLS protocols
  • Lack of logging and monitoring
  • Insecure cipher suites
  • Missing health checks
  • Unencrypted backend connections

Understanding Sticky Sessions

Overview

Sticky sessions, also known as session affinity, ensure that all requests from a client during a session are sent to the same target.

  • Maintains session state
  • Improves caching efficiency
  • Reduces database load
  • Supports stateful applications

Implementation

# Enable sticky sessions on target group
aws elbv2 modify-target-group-attributes \
  --target-group-arn $TARGET_GROUP_ARN \
  --attributes Key=stickiness.enabled,Value=true \
              Key=stickiness.type,Value=lb_cookie \
              Key=stickiness.lb_cookie.duration_seconds,Value=86400

Types of Sticky Sessions

Load Balancer Generated (Duration-Based)

  • Cookie generated by load balancer
  • Configurable duration (1 second to 7 days)
  • AWSALB/AWSELB cookies
  • Simpler implementation
  • No application changes required

Application-Based

  • Custom cookie names
  • Application-controlled expiry
  • More flexible control
  • Better for complex scenarios
  • Requires application code changes

Cookie Types in AWS ELB

Application Load Balancer Cookies

  • AWSALB: Used for duration-based stickiness
  • AWSALBCORS: Used for cross-origin requests
  • AWSALBAPP: Used when application-based stickiness is enabled
  • AWSALBTG: Contains routing information

Classic Load Balancer Cookies

  • AWSELB: Used for duration-based stickiness

Custom Application Cookies

Any cookie name can be used for application-based stickiness, but common names include:

  • JSESSIONID (Java applications)
  • PHPSESSID (PHP applications)
  • ASP.NET_SessionId (.NET applications)

Sticky Session Flow

┌─────────────┐                 ┌─────────────┐                 ┌─────────────┐
│             │                 │             │                 │             │
│   Client    │                 │    ALB      │                 │   Target    │
│             │                 │             │                 │             │
└──────┬──────┘                 └──────┬──────┘                 └──────┬──────┘
       │                               │                               │
       │  1. Initial Request           │                               │
       │ ─────────────────────────────>│                               │
       │                               │                               │
       │                               │  2. Forward to Target         │
       │                               │ ─────────────────────────────>│
       │                               │                               │
       │                               │  3. Response                  │
       │                               │ <─────────────────────────────│
       │                               │                               │
       │  4. Response with Cookie      │                               │
       │ <─────────────────────────────│                               │
       │                               │                               │
       │  5. Subsequent Request        │                               │
       │     with Cookie               │                               │
       │ ─────────────────────────────>│                               │
       │                               │                               │
       │                               │  6. Forward to Same Target    │
       │                               │ ─────────────────────────────>│
       │                               │                               │
       │                               │  7. Response                  │
       │                               │ <─────────────────────────────│
       │                               │                               │
       │  8. Response                  │                               │
       │ <─────────────────────────────│                               │
       │                               │                               │

Sticky Sessions Best Practices

Configuration

  • Set appropriate cookie duration
  • Enable health checks
  • Configure connection draining
  • Monitor session distribution
  • Test failover scenarios

Considerations

  • Impact on scaling
  • Session timeout handling
  • Failover scenarios
  • Load distribution
  • Increased memory usage

Alternatives

  • Distributed caching (ElastiCache)
  • Session replication
  • Database session storage (DynamoDB)
  • Stateless design
  • JWT tokens

Vertical Scaling (Scale Up)

Characteristics

  • Increasing instance size
  • Adding more resources to existing instances
  • Limited by hardware capacity
  • Usually requires downtime

Implementation

# Example: Upgrading instance type
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --instance-type t3.large

Horizontal Scaling (Scale Out)

Characteristics

  • Adding more instances
  • Distributing load across instances
  • No theoretical limit
  • No downtime required
  • Better fault tolerance

Implementation

# Example: Registering targets with ALB
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:... \
  --targets Id=i-1234567890abcdef0 Id=i-0987654321fedcba0

Auto Scaling Integration

Auto Scaling Groups

Auto Scaling Groups (ASG) automatically adjust the number of EC2 instances based on demand.

  • Maintains minimum and maximum instance counts
  • Automatically registers new instances with the load balancer
  • Deregisters terminated instances
  • Respects health check grace periods
  • Supports multiple scaling policies

Implementation

# Create Auto Scaling Group with Load Balancer
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateId=lt-1234567890abcdef0,Version='$Latest' \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 2 \
  --target-group-arns arn:aws:elasticloadbalancing:... \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --vpc-zone-identifier "subnet-1234567890abcdef0,subnet-0987654321fedcba0"

Scalability Patterns

Proactive Scaling

  • Scheduled scaling
  • Predictive scaling
  • Based on known patterns
  • Planned capacity
  • Example: Scaling up before business hours

Reactive Scaling

  • Dynamic scaling
  • Based on metrics
  • Auto Scaling policies
  • Real-time adjustment
  • Example: Scaling based on CPU utilization

Mixed Scaling

  • Combines both approaches
  • Base on predictions
  • Adjusts for variations
  • Optimal efficiency
  • Example: Scheduled scaling with dynamic adjustments

High Availability

Key Components

  • Multiple Availability Zones
  • Redundant instances
  • Automatic failover
  • Health monitoring
  • Cross-zone load balancing
  • Connection draining

Implementation

# Create ALB with multiple AZs
aws elbv2 create-load-balancer \
  --name my-load-balancer \
  --subnets subnet-12345678 subnet-87654321 \
  --security-groups sg-12345678 \
  --scheme internet-facing

Fault Tolerance

Features

  • Health checks
  • Connection draining (deregistration delay)
  • Sticky sessions
  • SSL termination
  • Request routing
  • Automatic recovery

Health Checks

# Configure health checks
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:... \
  --health-check-protocol HTTP \
  --health-check-port 80 \
  --health-check-path /health \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --health-check-timeout-seconds 5 \
  --health-check-interval-seconds 30

Cross-Zone Load Balancing

Without Cross-Zone Balancing

Each load balancer node distributes traffic only among the registered targets in its Availability Zone.

Zone A: LB Node → 5 targets (20% traffic per target)
Zone B: LB Node → 2 targets (50% traffic per target)
Zone C: LB Node → 3 targets (33% traffic per target)

Result: Uneven distribution across targets in different AZs

With Cross-Zone Balancing

Each load balancer node distributes traffic evenly across all registered targets in all enabled Availability Zones.

Zone A: LB Node → All 10 targets (10% traffic per target)
Zone B: LB Node → All 10 targets (10% traffic per target)
Zone C: LB Node → All 10 targets (10% traffic per target)

Result: Even distribution across all targets regardless of AZ

Configuration by Load Balancer Type

  • Application Load Balancer: Always enabled (cannot be disabled)
  • Network Load Balancer: Disabled by default (can be enabled)
  • Gateway Load Balancer: Disabled by default (can be enabled)
  • Classic Load Balancer: Disabled by default (can be enabled)

Availability Patterns

Active-Active

  • All nodes active
  • Load distributed
  • Maximum resource usage
  • Higher cost
  • Maximum availability

Active-Passive

  • Standby nodes
  • Failover capability
  • Lower resource usage
  • Lower cost
  • Reduced complexity

N+1 Redundancy

  • Extra capacity
  • Failure tolerance
  • Balanced approach
  • Moderate cost
  • Efficient resource usage

CloudWatch Metrics

Key Metrics

  • RequestCount: Number of requests processed
  • HealthyHostCount: Number of healthy targets
  • UnHealthyHostCount: Number of unhealthy targets
  • TargetResponseTime: Time taken for target to respond
  • HTTPCode_ELB_4XX: Client-side error count
  • HTTPCode_ELB_5XX: Server-side error count
  • ActiveConnectionCount: Current active connections
  • NewConnectionCount: New connections established
  • ProcessedBytes: Total bytes processed

Alarms and Notifications

# Create CloudWatch alarm for high latency
aws cloudwatch put-metric-alarm \
  --alarm-name HighLatencyAlarm \
  --alarm-description "Alarm when latency exceeds threshold" \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --statistic Average \
  --period 60 \
  --threshold 1 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=LoadBalancer,Value=app/my-load-balancer/50dc6c495c0c9188 \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:region:account-id:my-topic

Access Logs

Overview

Access logs capture detailed information about requests sent to your load balancer, stored in an S3 bucket.

  • Client IP address
  • Request time
  • Request path
  • Response status
  • Latency information
  • Bytes processed
  • User agent

Enabling Access Logs

# Enable access logs for ALB
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --attributes Key=access_logs.s3.enabled,Value=true \
              Key=access_logs.s3.bucket,Value=my-access-logs-bucket \
              Key=access_logs.s3.prefix,Value=my-app-logs

Request Tracing

X-Ray Integration

AWS X-Ray helps trace requests through your application, providing insights into performance bottlenecks.

  • End-to-end request tracing
  • Latency visualization
  • Error identification
  • Service dependency mapping
  • Root cause analysis

Implementation

To enable X-Ray tracing with ALB:

  1. Install X-Ray daemon on your application servers
  2. Instrument your application code with X-Ray SDK
  3. Configure sampling rules
  4. Analyze traces in X-Ray console

Monitoring Dashboard

CloudWatch Dashboard

Create custom dashboards to monitor your load balancers and targets in one place.

# Create CloudWatch dashboard
aws cloudwatch put-dashboard \
  --dashboard-name "ELB-Monitoring" \
  --dashboard-body file://elb-dashboard.json

Key Visualizations

  • Request count by status code
  • Target response time distribution
  • Healthy vs. unhealthy hosts
  • Connection count trends
  • Error rate percentage
  • Surge queue length (CLB)
  • Spillover count (CLB)

Netflix

Architecture Overview

Netflix uses AWS ELB extensively to handle millions of streaming requests globally.

  • Application Load Balancers for API traffic
  • Network Load Balancers for video streaming
  • Multi-region deployment
  • Auto Scaling integration
  • Custom health checks

Key Benefits

  • Handles traffic spikes during new releases
  • Provides low-latency streaming experience
  • Enables regional failover
  • Supports millions of concurrent streams
  • Optimizes content delivery costs

Amazon.com

Architecture Overview

Amazon's e-commerce platform uses sophisticated load balancing to handle peak shopping events like Prime Day.

  • Multiple load balancer tiers
  • Path-based routing for microservices
  • Sticky sessions for shopping carts
  • Predictive scaling
  • Global traffic distribution

Key Benefits

  • Handles extreme traffic spikes (Prime Day)
  • Maintains consistent shopping experience
  • Enables A/B testing through routing
  • Provides regional resilience
  • Optimizes resource utilization

OpenAI (ChatGPT)

Implementation

  • ALBs for API endpoints
  • Auto-scaling for handling viral demand
  • Request prioritization
  • Multi-region deployment
  • Advanced health checks for AI services

Alexa Voice Service

Implementation

  • NLBs for voice traffic
  • Ultra-low latency requirements
  • WebSocket connections
  • Global distribution
  • High availability architecture

Prime Video

Implementation

  • Content delivery optimization
  • Regional traffic management
  • Adaptive bitrate streaming
  • Cross-zone load balancing
  • Integration with CloudFront

Audible

Implementation

  • Audio streaming optimization
  • Download management
  • Personalized content delivery
  • Multi-device synchronization
  • Global content distribution

Goodreads

Implementation

  • Social network traffic patterns
  • Content recommendation systems
  • User-generated content handling
  • Database connection management
  • API traffic distribution

Kindle Services

Implementation

  • E-book delivery optimization
  • Whispersync technology
  • Global device synchronization
  • Content library management
  • Reading progress tracking

Advantages of AWS Elastic Load Balancing

Performance Benefits

  • Distributes traffic evenly across targets
  • Automatically scales to handle varying loads
  • Reduces latency with cross-zone balancing
  • Offloads SSL/TLS processing
  • Optimizes connection management

Availability Benefits

  • Continuous health checks of targets
  • Automatic failover to healthy targets
  • Multi-AZ deployment for high availability
  • Fault isolation
  • Graceful target deregistration

Management Benefits

  • Fully managed service (no maintenance)
  • Integrated with AWS services
  • Detailed monitoring and logging
  • Centralized certificate management
  • Simplified security implementation

Limitations of AWS Elastic Load Balancing

Technical Limitations

  • No static IP for ALB (only NLB)
  • Limited customization of load balancing algorithms
  • Cannot span multiple regions (regional service)
  • Limited protocol support per load balancer type
  • Fixed connection idle timeout (350 seconds for ALB)

Cost Considerations

  • Hourly charges regardless of traffic volume
  • Additional charges for data processing
  • Cross-AZ data transfer costs
  • S3 storage costs for access logs
  • Potential over-provisioning costs

Operational Challenges

  • DNS propagation delays during failover
  • Complex troubleshooting across distributed system
  • Limited visibility into internal load balancer operations
  • Potential for session loss during scaling events
  • Requires careful security group configuration

When to Use Each Load Balancer Type

Application Load Balancer

Best for:

  • HTTP/HTTPS applications
  • Microservices architecture
  • Container-based applications
  • When path-based routing is needed
  • When host-based routing is needed

Network Load Balancer

Best for:

  • TCP/UDP traffic
  • Ultra-low latency requirements
  • Static IP address needs
  • Millions of requests per second
  • PrivateLink integration

Gateway Load Balancer

Best for:

  • Deploying virtual appliances
  • Firewall implementations
  • Intrusion detection systems
  • Deep packet inspection
  • Traffic inspection requirements

Classic Load Balancer

Best for:

  • Legacy EC2-Classic applications
  • Simple round-robin balancing
  • When both TCP and HTTP are needed on the same port
  • Not recommended for new applications

Test Your Knowledge

1. Which AWS load balancer operates at Layer 7 of the OSI model?

A) Application Load Balancer
B) Network Load Balancer
C) Gateway Load Balancer
D) Elastic Load Balancer

2. Which load balancer type provides static IP addresses for each Availability Zone?

A) Application Load Balancer
B) Network Load Balancer
C) Classic Load Balancer
D) All load balancer types

3. Which cookie is used by Application Load Balancers for duration-based sticky sessions?

A) AWSALB
B) AWSELB
C) JSESSIONID
D) PHPSESSID

4. Which of the following is NOT a feature of AWS Gateway Load Balancer?

A) Transparent network gateway
B) GENEVE protocol support
C) Path-based routing
D) Flow symmetry

5. Which feature allows session persistence in Application Load Balancers?

A) Cross-zone balancing
B) Health checks
C) Sticky sessions
D) Path routing

6. Which load balancer is best suited for applications requiring ultra-low latency?

A) Application Load Balancer
B) Network Load Balancer
C) Gateway Load Balancer
D) Classic Load Balancer

7. Which of the following is true about cross-zone load balancing?

A) It's disabled by default for all load balancer types
B) It's enabled by default for all load balancer types
C) It's always enabled for Application Load Balancers
D) It incurs no additional data transfer charges

8. What is the purpose of a security group for a load balancer?

A) To encrypt traffic between clients and the load balancer
B) To control which traffic can reach the load balancer
C) To authenticate users accessing the load balancer
D) To monitor the health of the load balancer

9. Which AWS service is commonly used to monitor load balancer metrics?

A) AWS Config
B) AWS Inspector
C) Amazon CloudWatch
D) AWS Trusted Advisor

10. Which load balancer is designed specifically for deploying and scaling third-party virtual appliances?

A) Application Load Balancer
B) Network Load Balancer
C) Gateway Load Balancer
D) Classic Load Balancer

Share Your Feedback