Skip to main content
This lesson demonstrates how to create an Application Load Balancer (ALB) to provide a single DNS endpoint that distributes HTTP traffic across multiple EC2 web servers in different Availability Zones (AZs). The example assumes some networking and EC2 instances are already provisioned to avoid repetitive setup steps. Prerequisites
You should have a VPC and two EC2 instances already running (one in each AZ). The web servers should be listening on HTTP:80 (NGINX in this demo), and you should have a default route to an Internet Gateway for public subnets. If you plan to use HTTPS later, have a certificate ready in AWS Certificate Manager (ACM).
Current environment summary
  • Two EC2 instances: web-server1 and web-server2
  • Deployed in different AZs (us-east-1a and us-east-1b)
  • Running NGINX with the default page modified to show which server handled the request (H1 shows “this is server one” or “this is server two”)
  • Instances currently have public IPs (we’ll discuss hardening later)
A screenshot of the AWS EC2 Management Console listing two running t2.micro instances named "web-server1" and "web-server2" with 2/2 status checks passed. The details pane for web-server2 is open, showing its instance ID and public/private IP information.
You can hit each instance directly in a browser (for example http://54.210.5.199) to confirm the NGINX page displays the modified H1 indicating which server responded.
A screenshot of the AWS EC2 Management Console showing two running EC2 instances named web-server1 and web-server2 (t2.micro) with green status checks. The details pane for web-server1 is open, showing its instance ID and IP address information.
Goal Provide one unified address (a single DNS name) that routes requests to both back-end web servers and balances traffic across them. Preparing load-balancer subnets An ALB launches nodes into the subnets you choose. To achieve cross-AZ redundancy, create at least one subnet per AZ for the ALB. In this demo, two dedicated public subnets were created for the ALB: The VPC now contains four subnets: two web server subnets (one per AZ) and the two ALB subnets above. Because this ALB is internet-facing, the ALB subnets must be public (route to an Internet Gateway). Creating the Application Load Balancer (ALB) From the EC2 console → Load Balancers, choose Create load balancer → Application Load Balancer. AWS offers multiple load balancer types; choose the ALB for HTTP/HTTPS traffic:
A screenshot of the AWS EC2 console showing a "Load balancer types" comparison with three panels for Application Load Balancer, Network Load Balancer, and Gateway Load Balancer, each with illustrative diagrams and a "Create" button. The page explains differences (HTTP/HTTPS, TCP/UDP/TLS, and GWLB use cases) with icons and brief descriptions.
Basic configuration
  • Name the load balancer (example: web-lb)
  • Scheme: Internet-facing
  • IP address type: IPv4 (or dualstack for IPv6 + IPv4)
A screenshot of the AWS Management Console showing the "Create application load balancer" basic configuration page with the load balancer name set to "web-lb". The scheme is set to Internet-facing and the IP address type is IPv4, with network mapping options visible below.
Network mapping (subnets and AZs) Select at least two AZs and one subnet per AZ for the ALB. Select the dedicated ALB subnets (lb-us-east-1a and lb-us-east-1b) — do not select the web server subnets here. ALB nodes will run in the lb-* subnets and forward traffic to targets in the web subnets. Security groups Assign a security group to the ALB that allows inbound HTTP (port 80) and/or HTTPS (port 443). In this demo a security group named launch-wizard-16 was pre-created to allow these ports.
A screenshot of the AWS Management Console showing the Create Application Load Balancer wizard with subnet selection and a dropdown list for choosing security groups. The security group "launch-wizard-16" is selected in the list.
Listeners and target groups
  • Listener: Defines how the ALB accepts incoming traffic (protocol + port). For this demo, use HTTP on port 80.
  • Target group: Logical group of targets that receive traffic from the ALB (EC2 instances in this case). Configure protocol and port to match what the web servers are listening on (HTTP:80).
Listeners can have routing rules; the default rule forwards to a target group. Target group creation Create a target group for instances (example name: tg-web) with:
  • Protocol: HTTP
  • Port: 80
  • VPC: same VPC as the instances
  • Health check: HTTP against / (or your app’s /health endpoint)
Verify the NGINX default page exists at each instance (or a dedicated health endpoint) so the ALB health checks succeed.
A browser window showing the default "Welcome to nginx!" page. The address bar displays the IP 54.210.5.199:80 and several open tabs about VPC/load balancer setup.
A screenshot of the AWS EC2 console showing the "Create Target Group" form for an Application Load Balancer. It shows fields like target group name "tg-web", protocol HTTP on port 80, VPC selection, and the HTTP1 protocol version with health check options below.
Register targets Register web-server1 and web-server2 as targets on port 80. Initially they will appear as pending until health checks pass and the ALB marks them healthy.
A screenshot of the AWS Management Console showing the Target Groups/EC2 view with two running web-server instances listed as pending targets and port 80 specified. The "Create target group" button is visible in the bottom-right.
Finish ALB configuration
  • In the ALB creation wizard, set the listener’s default action to forward to tg-web.
  • Confirm security groups and subnet selections.
  • Create the load balancer.
You can add additional listeners (for example HTTPS:443) and routing rules later.
A screenshot of the AWS Management Console showing the "Listeners and routing" section while creating an Application Load Balancer. It displays configured listeners for HTTP:80 and HTTPS:443 with fields for protocol, port, default action (target group), and options to add/remove listener tags.
A screenshot of the AWS EC2 console showing the "Create load balancer" summary page with sections for basic configuration, security groups, network mapping, listeners and routing. The page includes a highlighted "Create load balancer" button at the bottom.
Provisioning and DNS Provisioning can take a couple of minutes. When the ALB becomes active, copy its DNS name from the load balancer details (for example http://web-lb-xxxx.elb.amazonaws.com) and use that for testing.
A screenshot of the AWS EC2 Load Balancers console showing one application load balancer named "web-lb" listed as Active. The details pane shows its VPC, availability zones, DNS name and creation date.
Testing the load balancer Open the ALB DNS name in a browser: http://web-lb-xxxx.elb.amazonaws.com. Refresh repeatedly to observe the ALB distributing requests between the two instances — the H1 should alternate between “this is server one” and “this is server two”. You can also test from the command line. Example (replace with your ALB DNS name):
  • Single request: curl http://web-lb-xxxx.elb.amazonaws.com
  • Repeated requests to observe distribution: for i in {1..6}; do curl -s http://web-lb-xxxx.elb.amazonaws.com | sed -n 's/.*<h1>\(.*\)<\/h1>.*/\1/p'; sleep 1; done
Security considerations and hardening In this demo the backend EC2 instances still have public IPs and can be accessed directly. In production you should prevent direct client access to backends. Two common approaches:
  • Move backend instances to private subnets (no public IPs). Keep ALB in public subnets to receive internet traffic and forward to private backends.
  • Restrict backend security groups so they only accept inbound traffic from the ALB security group (allow traffic on port 80 only from the ALB SG).
Either approach ensures traffic must go through the ALB and reduces the attack surface.
A screenshot of the AWS EC2 management console showing two running EC2 instances (web-server1 and web-server2) with t2.micro instance type and 2/2 status checks passed. The details pane for instance i-0d304af1a69b4cd22 (web-server1) is open, showing its public IPv4 address and private IP.
Best practice: Put backend servers in private subnets and restrict their security groups so they only accept traffic from the load balancer. This ensures clients cannot bypass the ALB and improves the overall security posture.
Further reading and references That concludes this lesson on creating an Application Load Balancer and configuring it to distribute HTTP traffic across two EC2 instances.

Watch Video