AWS: ELASTIC LOAD BALANCER Part2
ELB Listeners
An ELB Listener is the process that checks for connection requests.
You can configure the protocol/port on which your ELB listener listens on for connection requests.
Frontend listeners check for traffic from the client to the ELB.
Backend listeners are configured with protocol/port to check for traffic from the ELB to the EC2 instances.
You can configure multiple listeners with different protocols/ports both on the frontend and backend.
If you create your ELB in a Non-default VPC, you can choose a security group for the ELB from existing. If you do not specify one, the default security group of the VPC is assigned to the ELB.
ELB- Security Group and N ACLs
You must assign a security group to your ELB
- This will control traffic that can reach your ELB’s frontend listeners.
- It must also allow health check protocols/pots and listener protocol/port to reach your registered EC2 instances in the backend
You must also ensure that the subnet N ACLs allow traffic to/from the ELB both ways(on the front and backend side).
ELB Listeners
- Both frontend and backend listeners can listen on ports 1–65535
- The ELB supports Layer 4 TCP/SSL listeners for both frontend and backend, as well as, Layer 7 HTTP/HTTPs listeners for both frontend and backend.
When TCP (layer 4) listeners have used for frontend and backend connections, the ELB forwards the request to the EC2 registered, back-end, instances without modifying the headers.
When the ELB receives the request, it tries to open a TCP connection to the EC2, backend, instance on the port specified in the listener configuration.
Because of the interception, EC2 instance logs would show ELB IP address as the source IP at the EC2 instance received packets.
Enable proxy protocol on the ELB to force the ELB to carry the connection request details with the request sent to the EC2 instance.
ELB L4/TCP Listeners- Proxy Protocol
To enable proxy protocol on your ELB:
Ensure the request from the client to the ELB does not pass through a proxy server with proxy protocol enabled.
- This will cause the backend instance to receive the requests with two proxy headers.
Confirm that your EC2 instances can process proxy/protocol information.
ELB L7/TCP Listeners- Proxy Protocol
To use an HTTPS listener, the ELB must have a X.509 SSL/TLS server certificate, which will be used to terminate the client to ELB HTTPS connection.
Using this certificate the ELB will terminate then decrypt the client session on the ELB itself before sending the request to the Backend EC2 Instances.
- This is called SSL Termination
The certification can be generated using AWS Certification Manager (ACM) or you can upload your own IAM.
ELB-HTTP/HTTPS Listeners
When using HTTP/S for frontend listeners, the ELB terminates the session, carries the headers in the request, and then sends the request to the EC2, back-end, Instances.
Since the ELB intercepts the request, and in order for the backend EC2 instances to find the actual source information (original headers),
You can use the HTTP X-Forwarded-For header for the request sent from the ELB to the backend instances.
ELB- HTTP/HTTPS Session Stickiness
Whereby the ELB binds a client/user session/requests to a specific backend EC2 instance.
It is not fault-tolerant (in case the backend EC2 instance fails)
It requires SSL termination (SSL Off-loading) on the ELB,
- This in turn, requires an X.509 (SSL Server) certificate configured on the ELB
ELB- Session Stickiness Duration
The duration of the session stickiness is determined by either:
The application inserting session cookies, the case in which the ELB can be configured to follow the duration defined in the application’s session cookies.
(ELB duration based stickiness) If the application does not have its own cookies, then the ELB can be configured to create one and determine the stickiness duration
- The ELB inserts a cookie in the responses to bind subsequent from user to the same backend instance
- the cookie helps the ELB identity which user/session should be sticky to which backend instance
When using application cookie sticky sessions
If the cookie expires or is removed, the session is no longer a sticky session and ELB uses the normal, route to least loaded backend instance until a new cookie is inserted
For application cookie sticky sessions
If the cookie did not expire, but the backend instance becomes unhealthy, the ELB will route the traffic to anew, healthy, instance and keep the session stickiness
For ELB, duration-based, cookie stickiness
If the backend instance to which a session was sticky, fails or becomes unhealthy, the ELB routes the new session/requests to a new, healthy, instance and the session is no longer a sticky one.
In next blog, I will discuss more on ELB. So, Stay connected!
Thanks,
Bharathi.
