Professional Documents
Culture Documents
AWS ELB Monitoring: Jayendra's Blog
AWS ELB Monitoring: Jayendra's Blog
AWS ELB Monitoring: Jayendra's Blog
Jayendra's Blog
HOME
ABOUT ME
CONTACT ME
Elastic Load Balancer
HealthyHostCount, UnHealthyHostCount
Number of healthy and unhealthy instances registered with the load
balancer.
Most useful statistics are average, min, and max
RequestCount
Number of requests completed or connections made during the specified
interval (1 or 5 minutes).
Most useful statistic is sum
Latency
Time elapsed, in seconds, after the request leaves the load balancer until the
headers of the response are received.
Most useful statistic is average
SurgeQueueLength
Total number of requests that are pending routing.
Load balancer queues a request if it is unable to establish a connection with
a healthy instance in order to route the request.
Maximum size of the queue is 1,024. Additional requests are rejected when
the queue is full.
Most useful statistic is max, because it represents the peak of queued
requests.
SpilloverCount
The total number of requests that were rejected because the surge queue is
full. Should ideally be 0
Most useful statistic is sum.
HTTPCode_ELB_4XX, HTTPCode_ELB_5XX
Client and Server error code generated by the load balancer
Most useful statistic is sum.
HTTPCode_Backend_2XX, HTTPCode_Backend_3XX,
HTTPCode_Backend_4XX, HTTPCode_Backend_5XX
Number of HTTP response codes generated by registered instances
Most useful statistic is sum.
Elastic Load Balancing provides access logs that capture detailed information
about all requests sent to your load balancer.
Each log contains information such as the time the request was received, the
client’s IP address, latencies, request paths, and server responses.
Elastic Load Balancing captures the logs and stores them in the Amazon S3
bucket
Access logging is disabled by default and can be enabled without any
additional charge. You are only charged for S3 storage
CloudTrail Logs
AWS CloudTrail can be used to capture all calls to the Elastic Load Balancing
API made by or on behalf of your AWS account and either made using Elastic
Load Balancing API directly, or indirectly through the AWS Management
Console or AWS CLI
CloudTrail stores the information as log files in an Amazon S3 bucket that you
specify.
Logs collected by CloudTrail can be used to monitor the activity of your load
balancers and determine what API call was made, what source IP address was
used, who made the call, when it was made, and so on
References
Pre-Warming ELB
DNS Resolution
Availability Zones/Subnets
Elastic Load Balancing allows subnets to be added and creates a load balancer
node in each of the Availability Zone where the subnet resides.
Elastic Load Balancer should have atleast one subnet attached
Only one subnet per AZ can be attached to the ELB. Attaching a subnet with
an AZ already attached replaces the existing subnet
Each Subnet must have a CIDR block with at least a /27 bitmask and has at
least 8 free IP addresses, which ELB uses to establish connections with the
back-end instances.
For High Availability, it is recommended to attach one subnet per AZ for at
least two AZs, even if the instances are in a single subnet.
Subnets can be attached or detached from the ELB and it would start or stop
sending requests to the instances in the subnet accordingly
Security Groups & NACL
Security groups & NACLs should allow Inbound traffic, on the load balancer
listener port, from the Client for an Internet ELB or VPC CIDR for an Internal
ELB
Security groups & NACLs should allow Outbound traffic to the back-end
instances on both the instance listener port and the health check port
NACLs, in addition, should allow responses on the ephemeral ports
All EC2 instances should allow incoming traffic from ELB
For HTTPS load balancer, Elastic Load Balancing uses an Secure Socket Layer
(SSL) negotiation configuration, known as a security policy, to negotiate SSL
connections between a client and the load balancer.
A security policy is a combination of SSL protocols, SSL ciphers, and the
Server Order Preference option
Elastic Load Balancing supports the following versions of the SSL
protocol TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0 (deprecated now)
SSL protocols use several SSL ciphers to encrypt data over the Internet.
Elastic Load Balancing supports the Server Order Preference option for
negotiating connections between a client and a load balancer.
During the SSL connection negotiation process, this allows the load
balancer to control and select the first cipher in its list that is in the client’s
list of ciphers instead of the default behavior of checking matching first
cipher in client’s list with server’s list.
Elastic Load Balancer allows using a Predefined Security Policies or creating
a Custom Security Policy for specific needs. If none is specified, ELB selects
the latest Predefined Security Policy.
Health Checks
Load balancer performs health checks on all registered instances, whether the
instance is in a healthy state or an unhealthy state.
Load balancer performs health checks to discover the availability of the EC2
instances, the load balancer periodically sends pings, attempts connections, or
sends request to health check the EC2 instances.
Health check is InService for status of healthy instances and OutOfService for
unhealthy ones
Load balancer sends a request to each registered instance at the Ping
Protocol, Ping Port and Ping Path every HealthCheck Interval seconds. It
waits for the instance to respond within the Response Timeout period. If the
health checks exceed the Unhealthy Threshold for consecutive failed
responses, the load balancer takes the instance out of service. When the health
checks exceed the Healthy Threshold for consecutive successful responses, the
load balancer puts the instance back in service.
Load balancer only sends requests to the healthy EC2 instances and stops
routing requests to the unhealthy instances
Listeners
Listeners is the process which checks for connection requests from client
Listeners are configured with a protocol and a port for front-end (client to load
balancer) connections, and a protocol and a port for back-end (load balancer to
back-end instance) connections.
Listeners support HTTP, HTTPS, SSL, TCP protocols
A X.509 certificate is required for HTTPS or SSL connections and load
balancer uses the certificate to terminate the connection and then decrypt
requests from clients before sending them to the back-end instances.
If you want to use SSL, but don’t want to terminate the connection on the load
balancer, use TCP for connections from the client to the load balancer, use the
SSL protocol for connections from the load balancer to the back-end
application, and deploy certificates on the back-end instances
handling requests.
If you use an HTTPS/SSL connection for your back end, you can enable
authentication on the back-end instance. This authentication can be used to
ensure that back-end instances accept only encrypted communication, and to
ensure that the back-end instance has the correct certificates.
ELB HTTPS listener does not support Client-Side SSL certificates
For each request that a client makes through a load balancer, it maintains two
connections, for each client request, one connection with the client and the
other connection is to the back-end instance.
For each connection, the load balancer manages an idle timeout that is
triggered when no data is sent over the connection for a specified time
period. If no data has been sent or received, it closes the connection after the
idle timeout period (defaults to 60 seconds) has elapsed
For lengthy operations, such as file uploads, the idle timeout setting for the
connections should be adjusted to ensure that lengthy operations have time to
complete.
As the Elastic Load Balancer intercepts the traffic between the client and the
back end servers, the back end server does not know the IP address, Protocol
and the Port used between the Client and the Load balancer.
ELB provides X-Forwarded headers support to help back end servers track the
same when using HTTP protocol
X-Forwarded-For request header to help back end servers identify the IP
address of a client when you use an HTTP or HTTPS load balancer.
X-Forwarded-Proto request header to help back end servers identify the
protocol (HTTP/S) that a client used to connect to the server
X-Forwarded-Port request header to help back end servers identify the
port that an HTTP or HTTPS load balancer uses to connect to the client.
ELB provides Proxy Protocol support to help back end servers track the same
when using non-HTTP protocol or when using HTTPS and not terminating the
SSL connection on the load balancer.
Proxy Protocol is an Internet protocol used to carry connection information
from the source requesting the connection to the destination for which the
connection was requested.
Elastic Load Balancing uses Proxy Protocol version 1, which uses a
human-readable header format with connection information such as the
source IP address, destination IP address, and port numbers
If the ELB is already behind a Proxy with the Proxy protocol enabled,
enabling the Proxy Protocol on ELB would add the header twice
Cross-Zone
Connection Draining
Requirements
Load balancer uses a special cookie only to associate the session with the
instance that handled the initial request, but follows the lifetime of the
application cookie specified in the policy configuration.
Load balancer only inserts a new stickiness cookie if the application response
includes a new application cookie. The load balancer stickiness cookie does not
update with each request.
If the application cookie is explicitly removed or expires, the session stops
being sticky until a new application cookie is issued.
If an instance fails or becomes unhealthy, the load balancer stops routing
request to that instance, instead chooses a new healthy instance based on the
existing load balancing algorithm. The load balancer treats the session as now
“stuck” to the new healthy instance, and continues routing requests to that
instance even if the failed instance comes back.
Deleting a load balancer does not affect the instances registered with the load
balancer and they would continue to run
References
Categories
Tags
Options TroubleshootingVPC Whitepaper
Recent Posts