Load balancers Flashcards
Classic Load Balancers (v1
Supports TCP (Layer 4), HTTP &
HTTPS (Layer 7)
* Health checks are TCP or HTTP
based
Application Load Balancer (v2)
Application load balancers is Layer 7 (HTTP)
* Load balancing to multiple HTTP applications across machines
(target groups)
* Load balancing to multiple applications on the same machine
(ex: containers)
- Routing tables to different target groups:
- Routing based on path in URL (example.com/users & 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)
Application Load Balancer (v2)
Target Groups
Application Load Balancer (v2)
Query Strings/Parameters Routing
Network Load Balancer (v2)
- Network load balancers (Layer 4) allow to:
- Forward TCP & UDP traffic to your instance
- Ultra-low latency
NLB has one static IP per AZ, and supports assigning Elastic IP
Health Checks support the TCP, HTTP and HTTPS Protocols
Gateway Load Balancer
Operates at Layer 3 (Network Layer) – IP
Packets
- Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS
Example: Firewalls, Intrusion Detection and
Prevention Systems, Deep Packet Inspection
Systems, payload manipulation, …
Combines the following functions:
* Transparent Network Gateway – single entry/exit for all traffic
* Load Balancer
Uses the GENEVE protocol on port 6081
Target Groups
.EC2 instances
* IP Addresses – must be private IPs
Sticky Sessions (Session Affinity)
This works for Classic Load Balancer, Application Load Balancer, and Network Load
Balancer
CLB & ALB, the “cookie” used for
stickiness has an expiration date you control
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
Cross-Zone Load Balancing
With Cross Zone Load Balancing:
each load balancer instance distributes evenly
across all registered instances in all AZ
Without Cross Zone Load Balancing:
Requests are distributed in the instances of the
node of the Elastic Load Balancer
Cross-Zone Load Balancing
Enabled by default in Application load balancer
disabled by deafult in Network Load balancer
You pay charges ($) for inter AZ data if enabled
classic load balancer disbaled by default
Load Balancer - SSL Certificates
Public SSL certificates are issued by Certificate Authorities (CA)
* Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc…
- SSL certificates have an expiration date (you set) and must be renewed
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 versions of SSL / TLS (legacy clients)
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 the initial SSL handshake
The server will then find the correct
certificate, or return the default one
Only works for ALB & NLB (newer generation), CloudFront
not for classic load balancer
Elastic Load Balancers – SSL Certificates
Classic Load Balancer (v1)
- Support only one SSL certificate
- Must use multiple CLB for multiple hostname with multiple SSL certificates
- Application Load Balancer (v2)
- Supports multiple listeners with multiple SSL certificates
- Uses Server Name Indication (SNI) to make it work
- Network Load Balancer (v2)
- Supports multiple listeners with multiple SSL certificates
- Uses Server Name Indication (SNI) to make it wor
Connection Draining -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
What’s an Auto Scaling Group?
in the cloud, you can create and get rid of servers very quickly
* The goal of an 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 maximum number of EC2 instances running
* Automatically register new instances to a load balancer
* Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy
Auto Scaling Group Attributes
- A Launch 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
- Min Size / Max Size / Initial Capacity
- Scaling Policies
Auto Scaling - CloudWatch Alarms & Scaling
ASG based on CloudWatch alarms
An alarm monitors a metric (such as Average CPU, or a 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)
Auto Scaling Groups – Scaling Policies
Dynamic Scaling
- Target Tracking Scaling
- Simple 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 < 30%), then remove 1
- Scheduled Scaling
- Anticipate a scaling based on known usage patterns
- Example: increase the min capacity to 10 at 5 pm on Fridays
Good metrics to scale on
CPUUtilization: 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
Auto Scaling Groups - Scaling Cooldowns
After a scaling activity happens, you are in
the cooldown period (default 300 seconds)
* During the cooldown period, the ASG will
not launch or terminate additional
instances (to allow for metrics to stabilize)
* Advice: Use a ready-to-use AMI to reduce
configuration time in order to be serving
request fasters and reduce the cooldown
period
