AWS Application Load Balancer Setup (ALB): HTTP to HTTPS

Simple explanation

An Application Load Balancer sits in front of your EC2 instances and accepts incoming web requests so your instances do not have to be exposed directly to the internet. Instead of users hitting one EC2 instance directly, they hit the ALB, and the ALB decides which healthy instance should handle each request.

The ALB also handles your HTTPS certificate. It accepts encrypted traffic from browsers, decrypts it, and forwards plain HTTP to your instances internally. Your application code never has to deal with TLS. The ALB handles it at the edge so each instance sees ordinary HTTP requests regardless of whether the user connected over HTTP or HTTPS.

How it works

Traffic flows through several layers before reaching your application. Each layer has a specific job:

• Listener: the front door of the ALB. A listener is bound to a port and protocol (for example, HTTP on port 80). Every ALB needs at least one listener. When you add HTTPS, you add a second listener on port 443.
• Listener rules: conditions that decide what happens to each request. The default rule forwards everything to a target group. You can add path-based or host-based rules later to route different requests to different backends.
• Target group: a collection of backend resources (EC2 instances in this guide) that will receive requests. The target group also runs health checks to know which instances are available. Only healthy instances receive traffic.
• Health check: a periodic HTTP request the ALB sends to each target on a defined path (for example, /health). If the instance responds with HTTP 200, it is considered healthy. If it fails enough consecutive checks, it is removed from rotation until it recovers.

The ALB itself lives in public subnets so it can receive traffic from the internet. Your EC2 instances do not need to be publicly reachable. They can sit in private subnets and receive traffic only from the ALB. This is one of the main reasons to use a load balancer instead of exposing instances directly. See Subnets in AWS for how public and private subnets work.

What you are building

After completing this guide you will have created the following resources in AWS:

• ALB security group: allows inbound TCP on ports 80 and 443 from anywhere (0.0.0.0/0). This is intentional for a public-facing load balancer.
• EC2 instance security group: allows inbound TCP on port 80 only from the ALB security group. Instances are not reachable directly from the internet.
• Target group: contains your EC2 instances and runs health checks against /health every 30 seconds.
• Application Load Balancer: internet-facing, deployed across two public subnets in different Availability Zones for high availability.
• HTTP listener (port 80): initially forwards to the target group, then modified to redirect all traffic to HTTPS.
• HTTPS listener (port 443): terminates TLS using an ACM certificate and forwards decrypted traffic to the target group.
• Route 53 alias record: maps your domain name to the ALB’s DNS name.

What you need before starting

• A VPC with at least two public subnets in different Availability Zones. The ALB requires subnets in at least two AZs.
• At least one EC2 instance running a web server, with a port your application listens on (this guide uses port 80).
• AWS CLI installed and configured with IAM permissions for ec2, elbv2, acm, and route53.
• A domain name managed in Route 53 (required for the HTTPS section). If you have not set this up yet, see Route 53 Setup.

When to use this

This setup is the right choice when:

• You are running a web application or REST API on EC2 and need a stable public entry point.
• You want HTTPS without managing certificates on each instance.
• You want instances to be unreachable directly from the internet, accessible only through the ALB.
• You plan to scale horizontally (add more instances) and want traffic distributed automatically.
• You want automatic failover if one of your instances goes down.

This is not the right setup if your traffic is non-HTTP (use a Network Load Balancer for TCP/UDP), if you only have one instance and no plans to scale (a simpler Elastic IP may be sufficient), or if all traffic is internal between services (use an internal load balancer instead).

Step 1: Create security groups

You need two security groups: one for the ALB and one for your EC2 instances. They work together. The ALB security group accepts traffic from the internet, and the EC2 security group accepts traffic only from the ALB security group. This keeps your instances unreachable directly from outside, even if they have public IP addresses.

Create the ALB security group first, then use its ID when writing the EC2 rule. Referencing the security group ID directly (rather than a CIDR block) is a core AWS pattern. If you later swap out the ALB’s security group, the EC2 rule automatically stops accepting traffic from the old group.

# Security group for the ALB — allows internet traffic on ports 80 and 443
aws ec2 create-security-group \
  --group-name alb-sg \
  --description "Security group for ALB" \
  --vpc-id vpc-0123456789abcdef0

ALB_SG_ID=$(aws ec2 describe-security-groups \
  --filters Name=group-name,Values=alb-sg \
  --query 'SecurityGroups[0].GroupId' --output text)

aws ec2 authorize-security-group-ingress \
  --group-id $ALB_SG_ID \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id $ALB_SG_ID \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# Security group for EC2 instances — allows traffic from the ALB security group only
aws ec2 create-security-group \
  --group-name web-instance-sg \
  --description "Security group for web instances behind ALB" \
  --vpc-id vpc-0123456789abcdef0

WEB_SG_ID=$(aws ec2 describe-security-groups \
  --filters Name=group-name,Values=web-instance-sg \
  --query 'SecurityGroups[0].GroupId' --output text)

# Allow inbound from the ALB security group on port 80 only
aws ec2 authorize-security-group-ingress \
  --group-id $WEB_SG_ID \
  --protocol tcp --port 80 \
  --source-group $ALB_SG_ID

Success looks like: both commands return without error, and echo $ALB_SG_ID and echo $WEB_SG_ID each print an sg- prefixed ID.

Step 2: Create the target group

A target group is the list of backends the ALB can send traffic to. It is also where you configure the health check: the periodic request the ALB sends to each instance to confirm it is alive and ready.

The health check path /health must exist on your web server and return HTTP 200. If your application does not have a dedicated health endpoint, you can use / temporarily. A proper health endpoint that verifies your application is actually working (not just that the web server is running) is better practice. Register your EC2 instance IDs at the bottom, substituting real IDs from your account.

# Create a target group on port 80
aws elbv2 create-target-group \
  --name web-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-0123456789abcdef0 \
  --target-type instance \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200

TG_ARN=$(aws elbv2 describe-target-groups \
  --names web-targets \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

# Register your EC2 instances with the target group
aws elbv2 register-targets \
  --target-group-arn $TG_ARN \
  --targets Id=i-0123456789abcdef0 Id=i-0987654321fedcba0

The —healthy-threshold-count 2 setting means an instance must pass two consecutive health checks (2 x 30 seconds = 60 seconds minimum) before it is considered healthy. During this window, the instance will not receive any traffic even if the ALB is already active. This is normal. Do not immediately assume something is broken if targets show “initial” or “unhealthy” right after creation.

Step 3: Create the load balancer

This command creates the actual ALB resource. The two most important flags are —scheme internet-facing (makes the ALB reachable from the public internet) and —subnets (which must be public subnets with a route to an internet gateway). Provide subnet IDs from two different Availability Zones. The ALB requires at least two AZs for high availability.

Why public subnets? The ALB nodes need to receive packets from internet users. If you place the ALB in a private subnet, it has no path to receive those packets, even if the scheme is set to “internet-facing.” The subnets are where the ALB nodes themselves live. Your EC2 instances’ subnets are separate and can be private. See Private vs Public IP Addresses for how this maps to actual network reachability.

# Create the ALB in two public subnets across different AZs
aws elbv2 create-load-balancer \
  --name web-alb \
  --type application \
  --scheme internet-facing \
  --subnets subnet-public-1a subnet-public-1b \
  --security-groups $ALB_SG_ID

ALB_ARN=$(aws elbv2 describe-load-balancers \
  --names web-alb \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

ALB_DNS=$(aws elbv2 describe-load-balancers \
  --names web-alb \
  --query 'LoadBalancers[0].DNSName' --output text)

echo "ALB DNS name: $ALB_DNS"

The $ALB_DNS value is your ALB’s DNS name, something like web-alb-0123456789.us-east-1.elb.amazonaws.com. You will use this to test the setup and later to create a Route 53 alias record. The ALB typically takes 1 to 3 minutes to reach the “active” state.

Step 4: Create the listener on port 80

A listener is the rule that tells the ALB what to do when it receives a connection on a specific port. Here you create the HTTP listener on port 80. The default action is forward: send all incoming requests to the target group you created in Step 2.

Later, once HTTPS is working, you will modify this listener to redirect HTTP traffic to HTTPS instead of forwarding it. For now, forward is correct. It lets you verify the basic setup before adding the certificate layer.

# Create a listener that forwards all HTTP traffic to the target group
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

echo "Listener created. ALB DNS: $ALB_DNS"
echo "Wait 1-3 minutes for the ALB to become active, then test:"
echo "curl http://$ALB_DNS/"

Step 5: Verify health checks and test

Before adding HTTPS, confirm the basic HTTP path works end-to-end. Check that your instances are showing as healthy in the target group, then make a real HTTP request to the ALB DNS name.

# Check the health of registered targets
aws elbv2 describe-target-health \
  --target-group-arn $TG_ARN \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State,TargetHealth.Description]' \
  --output table

# Test the load balancer
curl -I http://$ALB_DNS/

A healthy target shows healthy in the State column. A successful curl response shows HTTP/1.1 200 OK (or whatever status code your application returns). If targets are healthy but curl fails, check that the ALB security group allows inbound port 80 from 0.0.0.0/0.

Add HTTPS with ACM

Once HTTP is working, adding HTTPS requires three things: an ACM certificate for your domain, a new HTTPS listener on port 443, and updating the port 80 listener to redirect to HTTPS instead of forward.

First, request and validate an ACM certificate. See SSL Certificates with ACM for the full process. DNS validation is usually the simplest method and completes in minutes.

Once your certificate is validated and shows status “Issued” in ACM, run the following commands:

# Get the ACM certificate ARN
CERT_ARN=$(aws acm list-certificates \
  --query 'CertificateSummaryList[?DomainName==`app.example.com`].CertificateArn' \
  --output text)

# Create HTTPS listener using the ACM certificate
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS \
  --port 443 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --certificates CertificateArn=$CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

# Get the ARN of the HTTP listener you created in Step 4
HTTP_LISTENER_ARN=$(aws elbv2 describe-listeners \
  --load-balancer-arn $ALB_ARN \
  --query 'Listeners[?Port==`80`].ListenerArn' --output text)

# Modify the port 80 listener: redirect HTTP to HTTPS with a 301
aws elbv2 modify-listener \
  --listener-arn $HTTP_LISTENER_ARN \
  --default-actions Type=redirect,RedirectConfig='{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

After running these commands, traffic to http://app.example.com automatically redirects to https://app.example.com with a 301 (permanent redirect). Browsers cache this redirect, so future visits go straight to HTTPS without an extra round-trip. Verify by running curl -I http://$ALB_DNS/ and checking for HTTP/1.1 301 Moved Permanently with a Location: https://… header in the response.

The TLS policy ELBSecurityPolicy-TLS13-1-2-2021-06 supports TLS 1.2 and 1.3 and is a safe default for most applications. It blocks TLS 1.0 and 1.1, which have known vulnerabilities.

Point your domain to the ALB

ALBs do not have static IP addresses. AWS changes the underlying IPs when it scales load balancer nodes, which means you cannot put an ALB IP address in a regular DNS A record. It will break without warning.

An alias record is a Route 53-specific feature that points to an AWS resource by its DNS name. Route 53 resolves it to the current IPs automatically, at no extra charge per query. It also works on root domains (like example.com), where a standard CNAME is not allowed by DNS specifications.

The HostedZoneId inside the AliasTarget block is the hosted zone ID of the ALB itself, not your domain’s hosted zone ID. This value is region-specific. For us-east-1, it is Z35SXDOTRQ7X7K. For more on Route 53 hosted zones, see Route 53 Setup.

# Create a Route 53 alias record pointing to the ALB
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDE \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "web-alb-0123456789.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

Replace Z1234567890ABCDE with your Route 53 hosted zone ID (found under Route 53 → Hosted zones), and replace the DNSName with the value of $ALB_DNS. DNS changes propagate in seconds within Route 53 but may take a few minutes to clear downstream resolver caches.

Troubleshooting

Most ALB problems fall into one of two categories: targets are unhealthy, or the ALB is reachable but requests return errors. For broader network diagnosis, see Troubleshooting Network Issues.

Targets show as unhealthy:

• Check that the EC2 instances’ security group has an inbound rule allowing port 80 from the ALB security group, not from a CIDR range. It must reference the security group ID directly.
• SSH into the instance and test the health check path locally: curl http://localhost/health. If this fails, the application is not running or the path is wrong.
• Check the health check settings in the target group. If your application takes more than the default timeout (5 seconds) to respond, increase the timeout.
• Enable ALB access logs or use VPC Flow Logs to confirm packets are actually reaching the instances.

ALB is reachable but returns 502 or 504:

• 502 Bad Gateway: the ALB reached the target but got an invalid response. The application may be crashing or returning a non-HTTP response on certain requests.
• 504 Gateway Timeout: the ALB reached the target but it did not respond within the idle timeout (default 60 seconds). Check for slow database queries or blocking operations in your application.

Internet-facing ALB vs Internal Load Balancer

The setup in this guide creates an internet-facing ALB. The choice between internet-facing and internal comes down to one question: who is making the requests?

• Internet-facing ALB: used when the caller is a user on the public internet. The ALB gets a public DNS name and its nodes have public IP addresses. This is the right choice for any public website, API, or application that users access from a browser or external client.
• Internal ALB: used when the caller is another service inside your VPC or a connected network. The ALB gets a private DNS name that is only resolvable inside the VPC. This is the right choice for microservices talking to each other, backend APIs called only by other AWS services, or services accessed over a VPN or Direct Connect. For details, see Internal Load Balancers.

Both types use the same ALB features: target groups, health checks, listener rules, and TLS termination. The only difference is whether the ALB nodes get public or private IPs and how the DNS name resolves.