DAY-8 AWS-CSA

1] What is Network Loadbalancer in AWS

An AWS Network Load Balancer (NLB) is a high-performance Layer 4 (Transport Layer) load balancer that distributes incoming traffic across multiple targets (EC2 instances, containers, or IP addresses) based on TCP, UDP, or TLS protocols.

Key Features of NLB

Layer 4 Load Balancing

• Works at the transport layer (OSI Layer 4), distributing traffic based on IP address and port.
• Supports TCP, UDP, and TLS (Secure TCP) protocols.

High Performance & Low Latency

• Can handle millions of requests per second.
• Ideal for real-time applications, gaming, and financial services.

Static IP & Elastic IP Support

• Each availability zone gets a static IP (can also use Elastic IPs).
• Useful for applications requiring a fixed entry point.

Zonal Failover & Health Checks

• Routes traffic only to healthy targets.
• Supports multi-AZ failover to ensure high availability.

TLS Offloading

• Terminates TLS (SSL) connections at the load balancer to reduce the workload on backend servers.

Target Types Supported

• EC2 instances
• IP addresses
• AWS PrivateLink endpoints
• Kubernetes (EKS) pod

Cross-Zone Load Balancing (Optional)

• By default, NLB routes traffic within an AZ but can distribute across AZs if enabled.

Use Cases of NLB

• High-performance applications requiring low latency.
• Gaming servers, VoIP, and real-time streaming (UDP support).
• Financial applications needing high-speed transactions.
• IoT applications handling a large number of connections.
• Hybrid cloud networking with on-premises integration.

2] What is Gateway loadbalancer ?

The AWS Gateway Load Balancer (GWLB) is a Layer 3 (Network Layer) load balancer designed specifically for deploying, managing, and scaling third-party virtual appliances like firewalls, intrusion detection systems (IDS), deep packet inspection (DPI), and network monitoring tools

Key Features of Gateway Load Balancer (GWLB)

Works at Layer 3 (Network Layer)

• Operates using the Geneve Protocol (Port 6081) for tunneling traffic.
• Enables seamless insertion of network security appliances.

Intelligent Traffic Distribution

• Routes network traffic across multiple security appliances.
• Supports automatic failover and scaling.

Transparent Deployment

• No need to modify application code or VPC networking.
• Automatically redirects traffic to security appliances.

Inline Security Inspection

• Allows you to integrate firewalls (Palo Alto, Fortinet, Check Point, etc.) to inspect incoming/outgoing traffic.
• Useful for deep packet inspection, malware detection, and intrusion prevention.

Highly Scalable & Resilient

• Automatically scales up/down based on traffic load.
• Redundant by design, ensuring high availability.

Simplifies Security & Traffic Control

• Eliminates the need for complex manual routing.
• Can be shared across multiple VPCs.

Use Cases of GWLB

• Security Virtual Appliances → Deploy firewalls (e.g., Fortinet, Palo Alto, Sophos, etc.) for traffic inspection.
• Intrusion Detection & Prevention (IDS/IPS) → Monitor and block malicious activities.
• DDoS Protection & Threat Prevention → Filter and mitigate network attacks.
• Deep Packet Inspection (DPI) → Analyze and control network packets at a detailed level.
• Centralized Traffic Monitoring → Route traffic through monitoring appliances.
• Hybrid Cloud Networking → Integrate on-premise security with AWS traffic.

How Gateway Load Balancer Works

1. User Traffic Arrives → Traffic destined for an application or network reaches GWLB.
2. Traffic Encapsulation (Geneve Protocol) → GWLB tunnels traffic to the security appliances (firewalls, IDS, etc.).
3. Security Inspection → The appliances analyze, filter, or block traffic as needed.
4. Forwarding Decisions → GWLB routes legitimate traffic to the target servers.

3] OSI 7 layers

The OSI (Open Systems Interconnection) Model is a conceptual framework used to understand how different network protocols interact in a communication system. It has 7 layers, each with a specific function.

4] Elastic load balancer-sticky sessions

What are Sticky Sessions in AWS ELB?

Sticky sessions (also called session affinity) allow a client to be consistently routed to the same backend instance for the duration of the session. This is useful for applications that store session-specific data on a particular instance, like shopping carts or login sessions.

How Does It Work?

• When a client makes a request, the load balancer assigns a session cookie.
• The client is always directed to the same backend instance as long as the session is active.
• Once the session expires, new requests may be routed to a different instance.

Types of Load Balancers Supporting Sticky Sessions:

1. Application Load Balancer (ALB)
2. Classic Load Balancer (CLB)

Network Load Balancer (NLB) does not support sticky sessions.

How to Enable Sticky Sessions in ALB?

1. Go to AWS Console → EC2 → Load Balancers.
2. Select your Application Load Balancer (ALB).
3. Under Target Groups, go to Attributes.
4. Find Stickiness and enable it.
5. Choose either:AWSALB Cookie (Default)Custom Application Cookie
6. Set the duration for the session.
7. Save changes.

Use Cases for Sticky Sessions

? E-commerce websites (Shopping carts, user preferences) ? Login-based applications (Session-based authentication) ? Applications with in-memory caching (e.g., Redis, Memcached)

Limitations & Considerations

? May cause uneven load balancing (One instance may get overloaded) ? Not recommended for stateless applications ? Sessions tied to a single instance (If the instance fails, session data is lost)

5] Sticky sessions-Cookie names

Sticky sessions (session affinity) in AWS Elastic Load Balancer (ELB) ensure that requests from the same client are always routed to the same backend instance during a session. This is achieved using cookies, which can be categorized as follows:

1?? Application-Based Cookies

These cookies are managed by the Application Load Balancer (ALB) and are used when stickiness is enabled at the target group level.

?? Types of Application-Based Cookies

1.1 Custom Cookie

• The application itself creates and manages the cookie.
• ALB uses this cookie to route requests to the same target.
• Use Case: When you want full control over session management.

? Example: If your application creates a cookie called session_id, you can configure the ALB to use it for stickiness.

1.2 Application Cookie (AWS-Generated Cookie)

• AWS automatically generates and manages this cookie.
• The cookie is called AWSALB (Application Load Balancer Cookie).
• The expiration time can be configured (e.g., 5 minutes, 1 hour, etc.).
• Use Case: When you want the load balancer to handle session stickiness without modifying your application.

? Example: ALB sets a cookie like:

2?? Duration-Based Cookies

Used by Classic Load Balancer (CLB) and managed by AWS.

2.1 AWS-Generated Cookie (AWSELB)

• The Classic Load Balancer (CLB) generates a cookie called AWSELB to track the session.
• The session duration is defined at the load balancer level (e.g., 5 minutes, 1 hour).
• Works only with CLB, not with ALB or NLB.
• Use Case: Legacy applications using CLB that require sticky sessions.

? Example: The CLB sets a cookie like:

6] Elastic load balancer-cross-Zone load balancing

?? What is Cross-Zone Load Balancing?

Cross-Zone Load Balancing is a feature in AWS Elastic Load Balancer (ELB) that distributes incoming traffic evenly across all registered instances in multiple Availability Zones (AZs), rather than only within a single AZ.

?? How It Works?

?? Without Cross-Zone Load Balancing (Disabled by Default in NLB & CLB)

• Each AZ gets an equal portion of the traffic.
• Instances within an AZ share that portion of the load.
• If one AZ has fewer instances, those instances receive more requests per instance, leading to imbalance.

?? With Cross-Zone Load Balancing (Enabled in ALB by Default)

• Traffic is evenly distributed across all available instances in all AZs.
• Prevents some instances from being overloaded while others remain underutilized.
• Provides better fault tolerance and high availability.

?? How to Enable Cross-Zone Load Balancing?

?? For Classic Load Balancer (CLB)

1. Open AWS Console → EC2 → Load Balancers.
2. Select your Classic Load Balancer.
3. Click Attributes → Enable Cross-Zone Load Balancing.
4. Save changes.

?? For Network Load Balancer (NLB)

1. Open AWS Console → EC2 → Load Balancers.
2. Select your Network Load Balancer.
3. Click Edit Attributes → Enable Cross-Zone Load Balancing.
4. Save changes.

?? Advantages of Cross-Zone Load Balancing

? Better Resource Utilization - Prevents uneven traffic distribution across instances.

? Higher Availability - If one AZ has fewer instances, traffic is balanced across all AZs.

? Prevents Overloading - Ensures no single instance receives excessive traffic.

?? When Should You Use It?

• If some AZs have fewer instances and you want equal distribution.
• If you need high availability and fault tolerance.
• If your instances are unevenly distributed across AZs.

7] What is SSL/TLS in ELB?

AWS Elastic Load Balancer (ELB) supports SSL/TLS termination, which helps secure traffic between clients and the load balancer. ELB can manage SSL certificates and offload the encryption/decryption process from backend instances.

?? SSL/TLS Certificate Management in ELB

To enable HTTPS on your ELB, you need an SSL certificate. ELB supports certificates issued by AWS Certificate Manager (ACM) or imported manually.

? Where Does ELB Use SSL Certificates?

• Application Load Balancer (ALB) → SSL Termination at ALB, then HTTP to backend.
• Network Load Balancer (NLB) → Supports SSL passthrough (decryption at the instance level).
• Classic Load Balancer (CLB) → Can handle SSL termination like ALB

?? Types of SSL Termination in ELB

1?? SSL Termination (Managed at ELB Level)

• ELB handles the SSL handshake.
• Backend instances receive traffic as HTTP (unencrypted).
• Best for reducing load on backend servers.

2?? SSL Passthrough (Managed at Instance Level)

• ELB does not decrypt SSL traffic.
• Traffic remains encrypted until it reaches the backend instance.
• Used when end-to-end encryption is required.

3?? SSL Re-encryption

• ELB decrypts the SSL traffic.
• Then, it re-encrypts it before forwarding to backend instances.
• Used for secure internal communication.

?? Steps to Attach SSL Certificate to ELB

?? Using AWS Console

1. Go to EC2 Dashboard → Load Balancers.
2. Select your ALB or CLB.
3. Navigate to the Listeners tab → Click Edit.
4. Select HTTPS (443) as a new listener.
5. Choose AWS Certificate Manager (ACM) or Upload a Certificate.
6. Select or upload your SSL certificate.
7. Save changes.

?? AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) allows you to create and manage free SSL/TLS certificates for ELB.

• Auto-renewal (no manual updates required).
• Works only with AWS services (not external use).

?? Requesting a Certificate in ACM

1. Open AWS Certificate Manager (ACM).
2. Click Request a Certificate.
3. Choose Public Certificate.
4. Enter your domain name (e.g., example.com).
5. Select DNS or Email validation.
6. Validate ownership → Issue certificate.

?? Benefits of Using SSL on ELB

? Improved Security – Encrypts data between clients and ELB.

? SSL Offloading – Reduces CPU load on backend servers.

? Compliance – Meets security standards like PCI DSS.

? Free SSL with ACM – Saves costs on SSL certificates.

8] What is Server Name Indication (SNI)?

Server Name Indication (SNI) is an extension of the TLS (Transport Layer Security) protocol that allows multiple SSL certificates to be hosted on a single IP address. This enables hosting multiple domains or subdomains with different SSL certificates on the same AWS Elastic Load Balancer (ELB).

?? Why is SNI Needed?

• Traditional SSL/TLS requires a dedicated IP for each SSL certificate.
• With SNI, multiple SSL certificates can be used on a single Application Load Balancer (ALB) or Network Load Balancer (NLB).
• Reduces costs and IP address usage.

?? How SNI Works in AWS ELB

1. When a client connects to the HTTPS (443) listener, it sends the hostname in the TLS handshake.
2. The ELB checks the hostname against the available SSL certificates.
3. If a matching certificate is found, ELB presents it to the client.
4. If no matching certificate exists, ELB serves the default certificate.

?? How to Enable SNI in AWS ELB

?? Step 1: Create or Import SSL Certificates in AWS Certificate Manager (ACM)

1. Go to AWS Certificate Manager (ACM).
2. Click Request a Certificate or Import an existing certificate.
3. Validate your domain.
4. Certificate is now ready for use.

?? Step 2: Attach SSL Certificates to ELB

1. Navigate to EC2 Dashboard → Load Balancers.
2. Select your ALB or NLB.
3. Go to the Listeners tab → Click Edit.
4. Select HTTPS (443) and click Add Certificate.
5. Add multiple SSL certificates for different domains.
6. Save changes.

?? Benefits of SNI in AWS ELB

? Host multiple domains with SSL on one ELB

? Saves IP addresses (No need for dedicated IPs)

? Cost-effective (No extra ELB needed for each certificate)

? Works seamlessly with AWS Certificate Manager (ACM)

9] What is Connection Draining / Deregistration Draining?

Connection Draining (for Classic Load Balancer) or Deregistration Draining (for Application & Network Load Balancers) is a feature that ensures active requests are completed before a backend instance is deregistered or terminated.

This prevents abrupt disconnections and improves the user experience by allowing ongoing requests to finish before the instance stops receiving new traffic.

?? How Connection/Deregistration Draining Works?

1. When an instance is deregistered (manual removal or auto-scaling down), ELB stops routing new requests to it.
2. Ongoing requests continue to be served by the instance.
3. After a configured timeout period, the instance is removed from the load balancer.
4. If all requests finish before the timeout, the instance is removed immediately.

?? Connection Draining in Classic Load Balancer (CLB)

• Enabled by default (but can be configured).
• Timeout setting: 0 - 3,600 seconds (default: 300 seconds).
• If requests complete before timeout, the instance is deregistered.
• If timeout expires, any remaining connections are terminated.

?? How to Enable Connection Draining in CLB?

1. Go to EC2 Dashboard → Load Balancers.
2. Select your Classic Load Balancer.
3. Navigate to the Attributes tab.
4. Enable Connection Draining and set the timeout.

1. .

?? Deregistration Draining in ALB & NLB

• Same functionality as CLB but named "Deregistration Draining".
• Ensures smooth instance removal in ALB (Layer 7) & NLB (Layer 4).
• Works with target groups instead of directly registered instances.

?? How to Enable Deregistration Draining in ALB/NLB?

1. Go to EC2 Dashboard → Target Groups.
2. Select the Target Group linked to your ALB/NLB.
3. Click on Deregistration Delay settings.
4. Set the timeout (default: 300 seconds, max: 3,600 seconds).

?? Benefits of Connection/Deregistration Draining

? Prevents abrupt termination of user sessions.

? Ensures a smooth removal of instances in Auto Scaling.

? Improves application reliability and user experience.

? Helps maintain graceful shutdowns of backend servers.