AWS Application Load Balancer Setup: HTTPS, Target Groups, and Health Checks
Published on · Updated on
Rebuilt the guide as a multi-AZ Application Load Balancer setup, correcting network, TLS, health-check, Auto Scaling, and cost guidance.
Elastic Load Balancing (ELB) distributes client traffic across registered targets, but a load balancer alone does not make an application highly available. This guide shows how to configure an Application Load Balancer (ALB) for an EC2 web service, terminate HTTPS at the load balancer, and verify the path to healthy targets. It assumes you already have an AWS account, a VPC, and an application that can run on replaceable EC2 instances.
If you need a refresher on EC2 instances, VPCs, and security groups, start with our EC2 basics guide. For a broader explanation of how load balancing and Auto Scaling support availability, see EC2 Auto Scaling and high availability.
Before you begin
Choose the AWS Region where the application runs. You need permissions to create Elastic Load Balancing resources, security groups, and (if used) an Auto Scaling group. Check account quotas and estimate costs before a hands-on lab: an ALB has hourly and capacity-unit charges, while EC2 instances, public IPv4 addresses, and data transfer can add separate charges.
Prepare the VPC and application
Use a VPC with subnets in at least two Availability Zones. Each ALB subnet should have an IPv4 CIDR of at least /27 and at least eight free IPv4 addresses so the load balancer can scale and perform maintenance. For an internet-facing ALB, select public subnets whose route tables send internet-bound IPv4 traffic to an attached internet gateway. The ALB's internet-facing setting does not create that route for you. Targets can stay in private subnets with no public IP addresses; the ALB reaches them over the VPC network. An internal ALB instead serves clients with network access to its VPC.
Confirm the application is listening on a known port and has a readiness endpoint such as /health. The path shown here is illustrative: use a URL and success response your application actually provides.
Choose the right load balancer
AWS offers four load balancer types. This walkthrough uses an ALB because it handles HTTP and HTTPS and supports application-layer routing.
| Type | Use it for | Important distinction |
|---|---|---|
| Application Load Balancer (ALB) | HTTP and HTTPS applications, including host- or path-based routing. | Uses listeners and target groups; cross-zone balancing is always enabled at the load balancer level, though it can be disabled for a target group. |
| Network Load Balancer (NLB) | Layer 4 traffic, including TCP, TLS, UDP, TCP_UDP, QUIC, and TCP_QUIC listeners. | Cross-zone balancing is off by default. NLBs support security groups if one is associated at creation; you cannot add one later if the NLB was created without any. QUIC and TCP_QUIC listeners are incompatible with security-group-enabled or dual-stack NLBs and with NLBs that have UDP or TCP_UDP listeners. |
| Gateway Load Balancer (GWLB) | Scaling and routing traffic through virtual network appliances, such as firewalls. | Uses GENEVE to connect to appliance targets; cross-zone balancing is off by default. |
| Classic Load Balancer (CLB) | Existing applications that still depend on the earlier load balancer generation. | Legacy option; new designs generally use ALB or NLB. Its cross-zone default depends on whether it was created through the console or API/CLI. |
Do not assume every load balancer type has the same protocol features, security-group behavior, or cross-zone default. See AWS's current load balancer getting-started guide, NLB listener protocols, NLB security-group requirements, and cross-zone balancing behavior.
1. Create an EC2 target group
A target group identifies where a listener sends traffic and how it checks target health. For this EC2 example, create an instance target group in the same VPC as the ALB. Choose the application's protocol and port, such as HTTP on port 8080 if that is what the app listens on. You can use IP targets for supported VPC addresses, or Lambda targets for an ALB integration, but those are different configurations. See AWS's ALB target-group steps for the full console options.
- In the EC2 console, choose Target Groups under Load Balancing, then choose Create target group.
- Choose Instances as the target type, select the VPC, and enter the target protocol and port.
- Set a health-check protocol, port, and path that the application can answer without login or a redirect.
- Create the target group. Register a fixed test instance or attach the Auto Scaling group in step 3; check target health after the group is attached to an ALB listener and its Availability Zone is enabled.
A health check is a signal that this target can receive the target group's traffic; it is not a full proof that every dependency or user journey works. Keep the endpoint fast and meaningful. If it tests a shared dependency that is failing for every instance, the result can cause the whole fleet to be considered unhealthy.
2. Create the ALB and configure its network
- In the same Region as the VPC and targets, open Load Balancers in the EC2 console and choose Create load balancer > Application Load Balancer.
- Choose a name and select Internet-facing for a public website or Internal for clients that reach the service through the VPC or connected networks.
- Select the prepared VPC. Enable the public subnets with a route to the internet gateway in at least two Availability Zones, and enable the same Availability Zones in which you run targets.
- Choose an ALB security group that allows only the intended client sources to reach the listener. For a public HTTPS endpoint, that is commonly TCP 443; allow TCP 80 only if you will redirect HTTP to HTTPS.
- Before adding HTTPS, request or import and validate an ACM certificate in the ALB's Region. Then create an HTTPS listener on port 443 and select the target group as its default forward action. Add an HTTP listener on port 80 with a redirect action to HTTPS if plain HTTP requests should be upgraded.
A listener accepts traffic on a protocol and port, then forwards matching requests to a target group. An HTTPS listener terminates client TLS at the ALB. If the ALB-to-target connection must also be encrypted, configure an HTTPS target group and the application to serve TLS on that port; this is a separate connection.
Check the network path, not just the ALB scheme
For public access, the internet gateway route belongs on the ALB's public subnets. Private target subnets do not need a route to the internet for ALB traffic. An internal ALB needs reachable client networks and suitable route tables, such as within the VPC, through peering, Transit Gateway, or VPN.
The ALB and its target group must use the intended VPC and compatible address types. Enable at least two Availability Zones on the ALB and keep targets available in each enabled zone. For application-level availability, the targets and their required databases, storage, and other dependencies also need enough capacity to handle a zone loss.
Allow the security-group path
Security groups are stateful firewalls. Set the ALB security group's inbound rule for the client listener, and its outbound rules for the target and health-check ports. On each target's security group, allow those ports from the ALB security group; avoid opening the target port directly to the internet. When the health-check port differs from the application port, allow that port too. Return traffic is allowed for established connections because security groups are stateful.
AWS describes the recommended ALB and target security-group rules and the ALB subnet requirements.
Configure HTTPS, DNS, and HTTP redirect
Request or import the certificate in AWS Certificate Manager (ACM) in the same Region as the ALB, and validate the domain name the site will use. Select that certificate on the HTTPS listener and retain an AWS-recommended TLS security policy. ACM certificates are regional resources; a certificate in another Region will not appear for this ALB.
If the domain uses Route 53, create an Alias record that points the hostname to the ALB after the listener is ready. For another DNS provider, create the provider's supported alias or CNAME record to the ALB DNS name. Check the resolved name and the certificate's host name before directing production traffic.
For HTTP-to-HTTPS behavior, the port 80 listener should issue a redirect to HTTPS on port 443, preserving the hostname and request path. Do not forward both listeners to the app if the goal is to require HTTPS. See AWS's guides for an ALB HTTPS listener, redirect actions, and Route 53 records for a load balancer.
3. Connect targets or an Auto Scaling group
For a fixed test, register a running EC2 instance in the target group and make sure its application process and security-group rules match the target port. If you use an Auto Scaling group, attach the target group to the group; EC2 Auto Scaling then registers launched instances and deregisters instances it removes. Avoid treating a manually registered instance as the group's durable capacity.
With ALB, NLB, and GWLB, traffic reaches targets through target groups. CLB is the exception: it registers instances directly with the load balancer. This guide does not give a new CLB setup path because it is a legacy choice.
Attach the target group to EC2 Auto Scaling
When you create or edit the Auto Scaling group, choose the ALB target group under load balancing. Place instances in private subnets across multiple Availability Zones and set a tested minimum, desired, and maximum capacity. The ALB normally routes around targets that fail health checks, but it can fail open when every target is unhealthy. The Auto Scaling group replaces unhealthy targets only when you enable ELB health checks for the group in addition to EC2 status checks.
New instances need time to boot, start the application, and pass target health checks. Set the group's health-check grace period to cover the app's startup time, then set default instance warmup based on when a new instance is ready and its metrics have stabilized. These settings solve different problems. For step-by-step group setup, see our EC2 Auto Scaling setup and health-check guide.
Auto Scaling and ELB improve recovery only when the application can run on additional instances, enough capacity is available in other zones, and state lives in a suitable shared or replicated service. They do not promise zero downtime for deployments, dependency failures, exhausted quotas, or sudden bursts that exceed ready capacity. See AWS's Auto Scaling load-balancer integration.
4. Test the full request path
Start with target health
In the target group's Targets tab, confirm each expected instance is registered and healthy. A target that stays unhealthy may have the wrong port, path, protocol, response code, or security-group rule. Check the failure reason before loosening the health check or security group.
Test redirect, TLS, and application response
After the custom domain resolves to the ALB, send a GET request to that hostname and verify that HTTP redirects to the same host and path over HTTPS, the certificate covers the requested name, and HTTPS returns the expected application response. For a pre-DNS test, replace the example hostname and ALB_DNS_NAME with your domain and the ALB DNS name. --connect-to changes the network destination while preserving the URL hostname used for the Host header and TLS SNI:
curl -i --connect-to app.example.com:80:ALB_DNS_NAME:80 http://app.example.com/health
curl -i --connect-to app.example.com:443:ALB_DNS_NAME:443 https://app.example.com/healthConfirm requests reach more than one target
Repeatedly refreshing a browser is not proof of even distribution: DNS answers, client connections, cookies, and target-group stickiness can affect what you observe. Send representative requests and correlate application logs or a temporary response header with the target that handled each request. Check the ALB access logs or the target-group metrics if you need evidence from the load balancer.
There is an important health-check edge case: if all targets in all enabled Availability Zones are unhealthy, an ALB fails open and can route requests to those unhealthy targets. Health checks therefore do not guarantee that failed targets are isolated. Watch target health, test the actual failure mode, and size remaining zones to handle displaced traffic. AWS documents this ALB fail-open behavior.
5. Monitor health and review cost
Use CloudWatch metrics and alarms to monitor HealthyHostCount, UnHealthyHostCount, target-generated 5xx responses, and TargetResponseTime. AWS recommends monitoring nonzero minimum UnHealthyHostCount for more than one data point to detect when targets are unhealthy across load-balancer nodes and zones; also investigate nonzero average or maximum values. Some ALB metrics have no data when there is no traffic, so configure alarm treatment for missing data deliberately.
For each alarm, choose an evaluation period and threshold from the service's normal traffic and availability objective. An alarm can notify an on-call operator; it does not by itself repair a broken deployment or dependency. The ALB CloudWatch metrics reference explains metric names and reporting conditions.
Review listener rules, certificates, target health, and subnet IP capacity as the service changes. Estimate the Region-specific ALB hourly and LCU charges, plus compute, public IPv4, data transfer, and any network services the design uses, with the current ELB pricing and VPC pricing pages. For a disposable lab, terminate or delete the test instances and Auto Scaling group, then remove the ALB, unused target group, and security groups that are no longer attached. Verify the bill after cleanup.
Checklist
- Use an ALB for HTTP/HTTPS application routing; choose NLB, GWLB, or a legacy CLB only when their behavior fits.
- Enable at least two Availability Zones, and distinguish an internet-facing ALB from the subnet routes that make it reachable.
- Use an HTTPS listener with an ACM certificate from the ALB's Region, an HTTP redirect when needed, and a target group in the application VPC.
- Restrict traffic through security-group references, verify a meaningful readiness check, and enable ELB health checks on the Auto Scaling group if it should replace unhealthy targets.
- Test DNS, TLS, redirect, response, target distribution, and the all-unhealthy fail-open case. Monitor both target health and application outcomes.
Continue with our EC2 Auto Scaling setup guide for group sizing and policy choices, or read how Auto Scaling fits into an availability design.