Section 7: AWS Fundamentals: ELB + ASG Flashcards
Elastic Load Balancer
A server that forwards traffic to multiple servers (e.g., EC2 instances) downstream. It’s a managed load balancer.
Users can access load balancers from anywhere using HTTPS/HTTP
Reasons for using a load balancer:
1. Spread load across multiple downstream instances.
2. Expose a single point of access (DNS) to your application.
3. Seamlessly handle failures of downstream instances.
4. Do regular health checks to your instances.
5. Provide SSL termination (HTTPS) for your websites.
6. Enforce stickiness with cookies.
7. High availability across zones.
8. Separate public traffic from private traffic.
Health Checks
They let the load balancer to know if instances it forwards traffic to are available to reply to requests.
The health check is done on a port and a route.
If the response is not 200 (OK), then the instance is unhealthy.
Application Load Balancer (ALB)
v2 - new generation
Year: 2016
Layer 7 (HTTP)
Load balancing to multiple HTTP applications across machines (target groups). Load balancing to multiple applications on the same machine (ex: containers).
Support for HTTP/2 and Websocket. Supports redirects (from HTTP to HTTPS for example).
Routing tables can be based on path in URL, hostname in URL, or query string and headers.
Great for microservices & container-based applications.
Has a port mapping feature to redirect to a dynamic port in ECS.
Can route based on which application the user is engaging with.
Has a fixed hostname. The application servers don’t see the IP of the client directly. The tru 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)
Network Load Balancer (NLB)
v2 - new generation
Year: 2017
Layer 4
Forward TCP & UDP traffic to your instances. Handle millions of requests per second. Ultra-low latency.
NLB has one static IP per AZ, and supports assigning Elastic IP.
Used for extreme performance, TCP or UDP traffic. Not included in the AWS free tier.
Gateway Load Balancer (GWLB)
Year: 2020
Operates at layer 3 (Network layer) - IP Protocol
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,…
Can forward traffic to and from target group, and then to application (destination).
Combines the following functions:
- Transparent Network Gateway - single entry/exit for all traffic
- Load Balancer - distributes traffic to your virtual appliances
Uses the GENEVE protocol on port 6081
ALB Target Groups
EC2 instances - HTTP
ECS tasks - HTTP
Lambda functions - HTTP request is translated into a JSON event
IP Addresses - must be private IP’s
NLB Target Groups
EC2 instances
IP Addresses - must be private IP’s
Application Load Balancer
Health checks support the TCP, HTTP and HTTPS Protocols
GWLB Target Groups
EC2 instances
IP Addresses - must be private IP’s
Sticky Sessions: Session Affinity
This is when you implement stickiness so that the same client is always redirected to the same instance behind a load balancer.
This works for CLB, ALB, and NLB.
The “cookie” used for stickiness has an expiration date you control.
Great for making sure the user doesn’t lose his session data.
Enabling stickiness may bring imbalance to the load over the backend EC2 instances.
Sticky Sessions: Application-based Cookies
Application-based Cookies
1. 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)
2. Application cookie: generated by the load balancer; cookie name is AWSALBAPP
Sticky Sessions: Duration-based Cookies
Cookie generated by the load balancer. Cookie name is AWSALB for ALB, AWSELB for CLB.
Cross-Zone Load Balancing
Each load balancer instance distributes evenly across all registered instances in all AZ’s.
Without Cross-Zone Load Balancing, requests are distributed in the instances of the node of the Elastic Load Balancer. If there are two AZ’s, each AZ gets 50% of the traffic, with the EC2 Instances in each AZ splitting the incoming traffic equally.
ALB enables this by default. No charges for inter AZ data.
NLB & GWLB disable this by default. You pay for charges for inter AZ data if enabled.
SSL/TLS - Basics
An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit (in-flight encryption).
SSL refers to Secure Sockets Layer, used to encrypt connections.
TLS refers to Transport Layer Security, which is a newer version.
Nowadays, TLS certificates are mainly used, but people still refer as SSL.
SSL certificates have an expiration date that you set, and must be renewed.
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.
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)
ALB supports multiple listeners with multiple SSL certificates. Uses SNI to make it work.
NLB supports multiple listeners with multiple SSL certificates. Uses SNI to make it work.
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.
SNI only works for ALB & NLB, CloudFront.
