By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
Stickiness can be setup thru console or CLI
Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
Duration based session stickiness:
On the Edit stickiness page, select Enable load balancer generated cookie stickiness.
(Optional) For Expiration Period type the cookie expiration period, in seconds. If you do not specify an expiration period, the sticky session lasts for the duration of the browser session.
If there is no cookie (first request), the load balancer chooses an instance based on the existing load balancing algorithm (least loaded EC2). A cookie is inserted into the response for binding subsequent requests from the same user to that instance. After a cookie expires (after duration from above step), the session is no longer sticky.
Application-Controlled session stickiness:
The load balancer uses a special cookie 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.
The 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 requests to that instance, and 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.
On the Edit stickiness page, select Enable application generated cookie stickiness.
For Cookie Name, type the name of your application cookie.
ELB can distribute load across EC2 instances running across AZs within a region only.
You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target. Any services or applications between the load balancer and the target can also add or update this header. If you enable access logs, the contents of the X-Amzn-Trace-Id header are logged
You can use a microservices architecture to structure your application as services that you can develop and deploy independently. You can install one or more of these services on each EC2 instance, with each service accepting connections on a different port. You can use a single Application Load Balancer to route requests to all the services for your application. When you register an EC2 instance with a target group, you can register it multiple times; for each service, register the instance using the port for the service.
When you deploy your services using Amazon Elastic Container Service (Amazon ECS), you can use dynamic port mapping to support multiple tasks from a single service on the same container instance. Amazon ECS manages updates to your services by automatically registering and de-registering containers with your target group using the instance ID and port for each container.
If your web servers must be connected to the Internet and database servers are only connected to the web servers
Create an Internet-facing load balancer and register the web servers with it.
Create an internal load balancer and register the database servers with it.
The web servers receive requests from the Internet-facing load balancer and send requests for the database servers to the internal load balancer.
The database servers receive requests from the internal load balancer.
If you have ten instances in Availability Zone 1 and two instances in AZ2, the requests are distributed evenly between the two Availability Zones. As a result, the two instances in us-west-2b serve the same amount of traffic as the ten instances in us-west-2a. Instead, you should have six instances in each Availability Zone
Advantages of ALB over CLB:
Support for host-based routing. You can configure rules for your listener that forward requests based on the host field in the HTTP header. This enables you to route requests to multiple domains using a single load balancer
Support for routing requests to multiple applications on a single EC2 instance. You can register each instance or IP address with the same target group using multiple ports.
Support for registering targets by IP address, including targets outside the VPC for the load balancer.
Support for containerized applications in Amazon Elastic Container Service (Amazon ECS)
Advantages of ALB over NLB:
NLB is at layer 4, does not understand applications, uses simple ICMP ping to determine the health as opposed to actual application health
ALB can distribute traffic to to different web servers with own ips but port 80 running on the same host. NLB can’t
