AWS - Application Load Balancer (ALB)

ALB

https://aws.amazon.com/elasticloadbalancing/application-load-balancer/

How do I find out the ALB name from the cluster in AWS?

The easiest way to find the Application Load Balancer (ALB) name associated with an Amazon ECS cluster is by looking at the ECS Service configuration within that cluster.

Here are the common methods, using both the AWS Management Console and the AWS Command Line Interface (CLI):

Using the AWS Management Console

This is the most straightforward visual method.

1. Navigate to ECS: Open the Amazon ECS console.
2. Select the Cluster: Click on the name of the ECS Cluster you are interested in.
3. View Services: Go to the Services tab for that cluster. An ECS cluster typically contains one or more Services.
4. Describe the Service: Click on the name of the relevant ECS Service.
5. Check Load Balancing:
   1. Go to the Networking or Configuration tab (the exact tab name can vary slightly).
   2. Look for the Load balancing section.
   3. Here, you will see the Load balancer name (or ARN) and its associated Target Group(s). The load balancer name is usually listed as the DNS name, like my-alb-123456789.us-east-1.elb.amazonaws.com.
6. Get the ALB Name: The part of the DNS name before the region is typically the friendly name or part of the unique ID used to identify the ALB in the EC2 Load Balancers section. For example, the load balancer name might be extracted from the ARN (e.g., arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb-name/1a2b3c4d5e6f7g8h).

Using the AWS Command Line Interface (CLI)

You can script this process using the aws ecs describe-services command and a JMESPath query.

Describe the ECS Service

The service configuration contains the ARN of the load balancer.

aws ecs describe-services \
    --cluster <your-cluster-name> \
    --services <your-service-name> \
    --query 'services[0].loadBalancers' \
    --output json

Replace <your-cluster-name> and <your-service-name> with the actual names.

The output will look something like this, providing the loadBalancerArn:

[
    {
        "targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/ecs-tg/abcdefghijk12345",
        "loadBalancerName": "my-alb-name",
        "containerName": "my-container",
        "containerPort": 80
    }
]

Note: In some versions and configurations, the output may directly include the loadBalancerName. If it only provides the loadBalancerArn (like arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb-name/1a2b3c4d5e6f7g8h), you can extract the load balancer name from the ARN (in this example, my-alb-name).

How to get the DNS Name for a Load Balancer

Using the AWS Management Console

1. Navigate to the ALB using the steps metioned above.
2. We should see the DNS name for the Load Balancer in that view.

Using the AWS Command Line Interface (CLI)

If you only have the ARN from Step 1, you can use the aws elbv2 describe-load-balancers command to get the friendly name and the DNS name.

LOAD_BALANCER_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb-name/1a2b3c4d5e6f7g8h"

aws elbv2 describe-load-balancers \
    --load-balancer-arns "$LOAD_BALANCER_ARN" \
    --query 'LoadBalancers[0].[LoadBalancerName, DNSName]' \
    --output text

The output will give you the load balancer name (e.g., my-alb-name) and its public DNS endpoint (e.g., my-alb-name-123456789.us-east-1.elb.amazonaws.com).

When I try sending curl requests to the ALB, I see this error: curl: (60) schannel

The error curl: (60) schannel almost universally indicates a problem with SSL/TLS certificate validation when you are making an HTTPS request, and specifically that the version of curl you are using is built with the Schannel SSL backend (which is the native Windows solution).

The error means that your client machine (where you are running curl) does not trust the certificate presented by the AWS Application Load Balancer (ALB).

Here are the four most common causes and their solutions, starting with the most likely in an AWS environment:

The Quick-and-Dirty Workaround (Development/Testing ONLY)

If you are only testing and are sure you are connecting to the correct ALB, you can disable the certificate verification.

The Problem

SSL verification adds security, but it slows down quick tests.

The Solution (Use with Caution\!)

Use the -k or --insecure flag in your curl command. This tells curl to proceed without verifying the peer’s certificate.

curl -k https://my-alb-1234567890.us-east-1.elb.amazonaws.com/
# OR (if using the custom domain)
curl -k https://api.example.com/

⚠️ Warning: Never use the -k flag in production environments or for requests involving sensitive data, as it defeats the security purpose of SSL/TLS.

Domain Name Mismatch (Most Common ALB Issue)

This is the most frequent cause when testing an ALB directly.

The Problem

When you provision a certificate in AWS Certificate Manager (ACM) and associate it with the ALB, the certificate is issued for a specific Domain Name (e.g., api.example.com).

If you try to access the ALB using its default AWS-provided DNS name (e.g., my-alb-1234567890.us-east-1.elb.amazonaws.com), the certificate presented by the ALB still only contains the domain name (api.example.com). Since the hostname in your curl request (the ALB’s DNS name) does not match the name on the certificate, the SSL validation fails.

The Solution

You must use the domain name for which the certificate was issued.

1. Create a CNAME/Alias Record: Set up a DNS record (a CNAME or an AWS Route 53 Alias record) that points your custom domain name (e.g., api.example.com) to the ALB’s DNS name.

2. Use the Custom Domain in curl: Send the curl request using the custom domain name:

   curl -v https://api.example.com/your/path
   

Missing Intermediate or Root CA Certificates (Client-Side)

If you are using a self-signed certificate, or a certificate from a non-standard Certificate Authority (CA), your client machine will not trust it by default.

The Problem

The curl: (60) error, which often includes the description “SSL certificate problem: unable to get local issuer certificate,” means the client is missing the Root CA or intermediate CA certificates required to complete the chain of trust for the ALB’s certificate.

The Solution (Recommended for Production)

1. Install the Certificate Chain: Ensure the root and intermediate certificates are installed in your Windows Trusted Root Certification Authorities store. Schannel relies on this store.

2. Specify the CA Bundle (Alternative): If you have the CA certificate saved in a file (e.g., ca-bundle.pem), you can tell curl to use it explicitly:

   curl --cacert /path/to/ca-bundle.pem https://your.domain.com
   

Problem with the Certificate Revocation List (CRL)

The Problem

In some corporate environments, outbound network traffic, including connections to the CRL (Certificate Revocation List) server, might be blocked or proxied. Since Schannel checks the CRL by default, this can cause the connection to fail if the check can’t complete.

The Solution

You can try using the --ssl-no-revoke flag with curl to skip the CRL check, which may resolve the issue in a restricted network environment.

curl --ssl-no-revoke https://your.domain.com/

To diagnose further, you can always add the -v (verbose) flag to your curl command, which will provide more detailed output about the SSL handshaking process:

curl -v https://your.alb.url/

Important considerations for ALBs

AWS Application Load Balancers (ALBs) are the Layer 7 (Application layer) entry point for most web applications on AWS. To ensure your application is scalable, highly available, and performs well, you must consider the following factors when configuring and sending requests through an ALB.

1. Timeout Management

Incorrect timeout settings are one of the most common causes of 504 Gateway Timeout errors. The ALB has its own idle timeout settings that must be coordinated with your application servers.

Setting	Default Value	Important Consideration
Connection Idle Timeout	60 seconds (1-4000s range)	This is the maximum time the ALB will wait for data to be sent or received on an existing connection before closing it. If you have long-polling or file uploads, you must increase this value.
Backend Keep-Alive	N/A (Set on Target)	The Keep-Alive timeout on your target server (e.g., Apache, Nginx) should be set to a value greater than the ALB’s Idle Timeout. If the target closes the connection first, the ALB will fail, potentially resulting in a 502 Bad Gateway error.

2. Security and Encryption (HTTPS/TLS)

ALBs are the ideal place to handle SSL/TLS termination, significantly reducing the load on your backend servers.

1. SSL/TLS Termination: Terminate the SSL connection at the ALB by configuring an HTTPS listener and associating an AWS Certificate Manager (ACM) certificate. This is highly recommended as it offloads encryption processing.
2. Enforce HTTPS: Create a listener rule to redirect all incoming HTTP (port 80) requests to HTTPS (port 443) to ensure secure traffic.
3. Security Groups:
   1. ALB Security Group: Must allow inbound traffic on ports 80 and 443 (or your listener port) from the internet (0.0.0.0/0).
   2. Target Security Group: Must only allow inbound traffic from the ALB’s Security Group on the port your application is listening on (e.g., 80 or 8080). This ensures no one can bypass the ALB.

3. Request Routing

ALBs operate at Layer 7, giving you granular control over how requests are directed to different backend applications.

1. Listener Rules: Rules determine how the ALB routes traffic based on conditions. You define a default rule and can add conditional rules based on:
   1. Path-based Routing: Route /api/users/* to the User Service Target Group and /images/* to an S3 target.
   2. Host-based Routing (Multi-Domain): Route app.domain.com to one target group and admin.domain.com to another, all using the same ALB.
2. Target Group Configuration: Each target group should logically represent a distinct application or service. Key configurations include:
   1. Target Type: Can be an Instance ID, IP address (including those outside the VPC), or a Lambda function.
   2. Protocol/Port: The protocol and port the targets are listening on.

4. Health Checks

Health checks are critical for high availability, determining which targets are eligible to receive traffic. They are defined at the Target Group level.

1. Dedicated Path: Always use a simple, dedicated, and fast health check path (e.g., /healthz or /status) instead of checking your application’s home page. This page should return a 200-level HTTP status code if the application is ready to serve traffic.
2. Thresholds:
   1. UnhealthyThresholdCount (Default: 2): Number of consecutive failed checks before a target is marked unhealthy. A low number speeds up failure detection.
   2. HealthyThresholdCount (Default: 5): Number of consecutive successful checks needed to mark an unhealthy target healthy. A high number ensures stability.
3. Connectivity: Ensure the security groups and Network ACLs allow traffic between the ALB Nodes and the Target Group on the health check port.

5. Scalability and Availability

For your application to handle traffic spikes and remain resilient, ensure the ALB is configured for multi-zone availability.

1. Availability Zones (AZs): The ALB must be deployed across at least two Availability Zones (AZs) where your targets are also registered. If an AZ fails, the ALB traffic automatically routes to the remaining healthy AZs.
2. Cross-Zone Load Balancing (Recommended): By default, this is enabled at the ALB level. It ensures that each ALB node distributes traffic equally across all registered targets in all enabled AZs, promoting even resource utilization.
3. Pre-Warming: While ALBs auto-scale, they scale best with a gradual traffic increase. If you anticipate an immediate, massive surge (like a flash sale), you may need to contact AWS Support to “pre-warm” the ALB to the required capacity ahead of time.