AWS: Application Load Balancer 4th part
Health Checks for your Target Group
Each load balancer node routes requests only to the healthy targets in the enabled Availability zones for the load balancer.
Each load balancer node checks the health of each target, using the health check settings for the target group with which the target is registered.
After your target is registered, it must pass one health check to be considered healthy.
After each health check is completed, the load balancer node closes the connection that was established for the health check.
If no availability zone contains a healthy target, the load balancer nodes route requests to all targets.
Note that health checks do not support WebSockets.
Health Check Reason Codes
If the status of a target is any value other than Healthy, the API returns a reason code and a description of the issue, and the console displays the same description in a tooltip.
AWS ALB
Cloud Watch Metrics for your Application Load Balancer
Elastic Load Balancing reports metrics to Cloud Watch only when requests are flowing through the load balancer.
If there are requests flowing through the load balancer, Elastic Load Balancing measures and sends its metrics in 60-second intervals.
If there are no requests flowing through the load balancer or no data for a metric, the metric is not reported.
Request Tracing for your Application Load Balancer
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.
AWS Cloud Trail Logging for your Application Load Balancer
Elastic Load Balancing is integrated with AWS Cloud Trail, which captures API calls to AWS made by ort on behalf of your AWS account, and delivers log files to an Amazon S3 bucket that you specify.
There is no cost to use Cloud Trail. However, the standard rates for Amazon S3 apply.
Cloud Trail logs calls to the AWS APIs, including the Elastic Load Balancing API, whether you use them directly or indirectly through the AWS Management Console.
You can use the information collected by Cloud Trail to determine what API call was made, what source IP address was used, and so on.
- To monitor other actions for your load balancer, such as when a client makes a request to your load balancer, use access logs.
Access Logs for your Application Load Balancer
Elastic Load Balancing provides access logs that capture detailed information about 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.
You can use these access logs to analyze traffic patterns and troubleshoot issues.
Access logging is an optional feature of Elastic Load Balancing that is disabled by default.
After you enable access logging for your load balancer, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that you specify as compresses files.
You can disable access logging at any time.
There is no additional charges for access logs
- You are charged storage costs for Amazon S3, but not charged for the bandwidth used by Elastic Load Balancing to send log files to Amazon S3.
- The bucket must be in the same region as the ALB.
Access Log Entries
Elastic Load Balancing logs requests sent to the load balancer, including requests that never made it to the targets.
Elastic Load Balancing does not log health check request.
For WebSockets, an entry is written only after the connection is closed.
- If the upgraded connection cant be established, the entry is the same as for an HTTP or HTTPS request.
Important: Elastic Load Balancing logs requests on a best-effort basis.
We recommend that you use access logs to understand the nature of the requests, not as a complete accounting of all requests.
AWS ALB- Limits
Listeners per load balancer: 50
Targets per load balancer:1000
Rules per load balancer:100 (default rules)
Certificates per load balancer:25
Number of times a target can be registered per load balancer:100
Load balancers per target group: 1
Targets per target group:1000
Conditions per rule: 2 (one host and one path condition)
Action per rule: 1
Target groups per cation: 1
Benefits of Migration from CLB to ALB
AWS recommends that you use Application Load Balancer for your Amazon ECS services so that you can take advantage of these latest features, unless your service requires a feature that is only available with Network Load Balancer or Classic Load Balancers.
Benefits of Migration from CLB
- Support for Path-based routing
This enables you to structure your applications as smaller services and route requests to the correct service based on the content of the URL.
- Support for host-based routing
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
Amazon Elastic Container Service can select an unused port when scheduling a task and register the task with a target group using this port.
This enables you to make efficient use of your clusters
- Support for monitoring
Support for monitoring the health of each service independently, as health checks are defined at the target group level and many cloud watch metrics are reported at the target group level.
- Attaching a target group to an Auto Scaling group enables you to scale each service dynamically based on demand. This is valid for groups with EC2 instances as targets (not IP address).
- Access logs contain additional information and are stored in compressed format.
- Improved load balancer performance.
In my next blog, I will discuss on NLB (Network Load Balancing)
Thank you,
Bharathi.
