AWS Fundamentals: ELB + ASG

I. Elastic Load Balacing overview

1. What is load balacing?

Load Balances are servers that forward traffic to multiple servers(e.g., EC2 instances) downstream

2. Why use a load balacer?

• Spread load across multiple downstream instances
• Expose of single point of access (DNS) to your application
• Seamlessly hanle failures of downstream instances
• Do regular health checks to your instances
• Provide SSL termination (HTTPS) for your websites
• Enforce stickiness with cookies
• High availability across zones
• Separate public traffic from private traffic

3. Why use an Elastic load balancer?

• An Elastic load balancer is a managed load balancer
• AWS guarantees that it will be working
• AWS takes care of upgrades, maintenance, hight availability
• AWS provides only a few configuration knobs
• It costs less to setup your own load balancer but it will be a lot more effort on your end
• It's intergrated with many AWS offerings/ services
• EC2, EC2 Auto Scaling Groups, Amazon ECS
• AWS Certificate Manager (ACM), CloudWatch
• Route 53, AWS WAF, AWS Global Accelerator

4. Health Checks

Heal Checks are crucial for load Balancers

They enable the load balancers to know if instances it forward traffic to are available to reply to requests

The health check is done on a port and a route (/health is common)

If the response is not 200 (OK), then the instance is unhealthy

5. Types of Load Balancer on AWS

• AWS has 4 kinds of managed Load Banlancers
• Classic Load Balancer(v1 - old generation) - 2009 - CLB
• HTTP, HTTPS, TCP, SSL (secure TCP)
• Application Load Balancer (v2 - new generation) - 2016 - ALB
• HTTP, HTTPS, WebSocket
• Network Load Balancer  (v2 - new generation) - 2017 - NLB
• TCP, TLS (secure TCP), UDP
• Gateway Load Balancer - 2020 - GWLB
• Operates at layer 3 (Network layer) - IP protocol
• Overall, it is recommended to use the newer generation load balancers as they provide more features
• Some Load Balancers can be setup as internal (private) or external (public) ELBs

6. Load Balancer Security Groups

II. Application Load Balancer (ALB)

• Application load balancers is layer 7 (HTTP)
• Load balancing to multiple HTTP aplications across machines (target groups)
• Load balancing to multiple applications on the same machine (ex: containers)
• Support for HTPP/2 and Websocket
• Support redirects (from HTTP to HTTPS for example)
• Routing tables to different target groups:
• Routing based on path in URL (example.com/uses & example.com/posts)
• Routing based on hostname in URL  (one.example.com & other.example.com)
• Routing based on query string, headers (example.com/users?id=123&order=false)
• ALB are a great fit for micro services & container-based application (ex: Docker & Amazon ECS)
• Has a port mapping feature to redirect to a dynamic port in ECS
• In comparison, we'd need multiple Classic Load Balancer per application 

1. HTTP Based Traffic

2. Target Groups 

• EC2 instances (can be managed by an Auto Scaling Group) -HTTP
• ECS tasks (managed by ECS itself) - HTTP
• Lamda functions - HTTP request is translated into a JSON event
• IP - Addresses - must be private IPs
• ALB can route to multiple target groups
• Health checks are at the target group level

3. Query Strings/ Paramaters Routing

4. Good to Know

• Fixed hostname (XXX.region.elb.amazonaws.com)
• The application servers don't see the IP of the client directly
• The true IP of the client is inserted in the header X-Forwarded-For
• We can also get port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

III. Aplication Load Balancer (ALB) - Hands on

Create Application Load Balancer

create security group for ALB

create target group for ALB

add instances for Target Group

Only allow traffic from the load balancer to access my EC2 Instances

Add Rules for Load Balancer

IV. Network Load Balancer (NLB)

• Network load balancers (layer 4) allow to :
• Forward TCP & UDP traffic to your instances
• Handle millions of request per seconds
• Less latency ~100 ms (vs 400ms for ALB)
• NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelist specific IP)
• NLB are used for extreme performance, TCP or UDP traffic
• Not included in the aws free tier

1. TCP (Layer 4)  Based traffic

2. Network Load Balancer - Target Groups

• EC2 instances
• IP addresses - must be private IPs
• Application Load Balancer
• Health Checks support the TCP, HTTP and HTTPS Protocols

V. Network Load Balancer (NLB) - Hands on

similarly application load balancers

IV. Gateway Load Balancer (GWLB)

• Deploy, scale, manage a fleet for 3rd party network virtual appliances in AWS
• Example: Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, payload manipulations, ...
• Operates at Layer 3 (network layer) - IP Packets
• Combines the following fuctions:
• Transparent Network Gateway - single entry/exit for all traffic
• Load Balancer - Distributes traffic to your virtual appliances
• Uses GENEVE protocol on port 6081

Gateway Load Balancer - Target Groups

• EC2 instances
• IP addresses - must be private IPs

VI. Elastic Load Balancer - Sticky Sessions

• It's possible to implement stickiness so that the same client is alway to redirected to the same instance behind a load balancer
• This works for Classic Load Balancer, Application Load Balaner, Network Load Balancer.
• The "cookie" used for stickiness has an expiration date you control
• Use case: make sure the user doesn't lose his session data
• Enabling stickiness may bring imbalance to the load over the backend EC2 instances

Sticky Sesstions - Cookie Names

• Application-based Cookies
• Custom cookie
• Generated by the target
• Can include any custom attributes required by the application
• Cookie name must be specified individually for each target group
• Don't use AWSALB, AWSALBAPP, or AWSALBTG (reserved for use by the ELB)
• Application cookie
• Generated by the Load Balancer
• Cookie name is AWSALBAPP
• Duration-based Cookies
• Cookie generated by the load balancer
• Cookie name is AWSALB for ALB, AWSELB for CLB 

VII. Elastic Load Balancer - Cross-Zone Load Balancing

• Application Load Balancer
• Enable by default (can be disabled at the Target Group level)
• No charges for inter AZ data

• Network Load Balancer & Gateway Load Balancer
• Disable by default
• You pay charges ($) for inter AZ data if enabled

Network Load Balancer

Gateway Load Balancer

VIII. Elastic Load Balancer - SSL Certificates

1. SSL/TLS - Basics

• An SSL Certificate allows traffic between your client and your load balancer to be encrypted in transit (in-flight encryption)
• SSL refers to Secure Socket Layer, used to encrypt connections
• TLS refers to Transport Layer Security, which is a newer version
• Nowadays, TLS certificates are mainly used, but people refer to SSL
• Public SSL certificates are issued by Certificate Authorities (CA)
• Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc, ...
• SSL certificates have an expiration data (you set) and must have renewed

2. Load Balancer - SSL Certificates

• The load balancer uses an X.509 certificate (SSL/TLS server certificate)
• You can manage certificates using ACM (AWS Certificate Manager) 
• you can create upload your own certificates alternatively
• HTTPS listener:
• You must specify a default certificate
• You can add an optional list of certs to support multiple domains
• Clients can use SNI (Server Name Indication) to specify the hostname they reach
• Ability to specify a security policy to support older version of SSL/TLS (legacy clients)

3. SSL - Server Name Indication (SNI)

• SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)
• It's a "newer" protocol, and requires the client to indicate the hostname of the target server in initial SSL handshake
• The server will the find the correct certificate, or return the default one

note: 

• Only works for ALB & NLB (newer generation), Cloudfront
• Does not work for CLB

IX. Elastic Load Balancer - SSL Certificates -Hands on

X. Elastic Load Balancer - Connection Draining

• Feature naming
• Connection Draining - for CLB
• Deregistration Delay for ALB & NLB
• Time to complete "in-flight requests" while the instance is de-registering or unhealthy
• Stops sending new requests to the EC2 instance which is de-registering
• Between 1 to 3600 seconds (default: 300 seconds )
• Can be disabled (set value to 0)
• Set to a low value if your requests are short

 XI. Auto Scaling Groups (ASG) - Overview
1. What is an Auto Scaling Group ?

• In real-life, the load on your websites and application can change
• In the cloud, you can create and get rid of the server very quickly
• The goal of Auto Scaling Group (ASG) is to:
• Scale out (add EC2 instances) to match an increased load
• Scale in (remove EC2 instances) to match a decreased load
• Ensure we have a minimum and a maximun number of EC2 instances running
• Automatically register new instances to a load banlancer
• Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy)
• ASG are free (you only pay for the underlying EC2 instances)

2. Auto Scaling Group in AWS

3. Auto Scaling Group in AWS with Load Balancer

4. Auto Scaling Group Attributes

• A Lauch Template (older "Launch Configurations" are deprecated)
• AMI + Instance type
• EC2 User Data
• EBS Volumes
• Security Groups
• SSH Key pair
• IAM Roles for your EC2 instances
• Network + Subnets information
• Load balancer information

5. Auto Scaling - CloudWatch Alarms & Scaling

• It's possible to scale an ASG based on CloudWatch alarms
• An alarm monitors a metric (such as Average CPU, or custom metric)
• Metrics such as Average CPU are computed for the overall ASG instances
• Based on the alarm:
• We can create scale-out policies (increase the number of instances)
• We can create scale-in policies (decrease the number of instances)

XII. Auto Scaling Groups (ASG) - Hands on

change group size

XIII. Auto Scaling Groups (ASG) - Scaling Policies

1. Auto Scaling Groups - Dynamic Scaling Policies

• Target Tracking Scaling 
• Most simple and easy to set-up
• example: I want the average ASG CPU to stay at around 40%
• Simple / Step scaling
• When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units
• When a CloudWatch alarm is triggered (example CPU < 70%), then remove 1
• Scheduled Actions
• Anticipate a scaling based on known usage patterns
• Example: increase the min capacity to 10 at 5pm on Fridays

2. Auto Scaling Groups - Predictive Scaling

Predictive Scaling: continuously forecast load and schedule scaling ahead

3. Good metrics to scale on

• CPU Utilization: Average CPU utilization across your instances
• RequestCountPerTarget: to make sure the number of requests per EC2 instances is stable
• Average Network in / out (if you're application is network bound)
• Any custom metric (that you push using CloudWatch)

4. Auto Scaling Groups - Scaling Cooldowns

• After a scaling activity happens, you are in the cooldown period (default 300seconds)
• During the cooldown period, the ASG will not launch or terminate additional instances (to allow for metrics to stabilize)
• Advice: use the read-to-use AMI to reduce configuration time in order to be serving request fasters and reduce the cooldown period

XIV. Auto Scaling Groups (ASG) - Scaling Policies -Hands on

XV. Auto Scaling - Instance Refresh

• Goal: update launch template and then re-creating all EC2 instances
• For this we can use the native feature of Instance Refresh
• Setting in minimun healthy percentage
• Specify warm-up time (how long until the instance is ready to use)

Reference: Content based on "Ultimate AWS Certified Developer Associate 2023 NEW DVA-C02."