Deploying an Application Load Balancer in AWS by hand requires creating a VPC, configuring subnets, setting up security groups, launching Amazon EC2 instances, creating a target group, adding listeners, and then verifying each step because a single misconfiguration can break the whole setup. Terraform replaces repetitive console clicks with code that can be versioned, reviewed, and reapplied. The approach allows rebuilding labs or environments by running terraform apply again without manual duplication.
An Application Load Balancer operates at Layer 7 of the OSI model. It can inspect HTTP requests and route traffic based on paths, headers, hostnames, query strings, and more. It is one of the most commonly used components in scalable AWS architectures. Managing it through Terraform lets you version, review, and reproduce entire routing configurations as code.
Core Components of an ALB Terraform Configuration
A typical ALB setup that forwards traffic to an application needs three things: the load balancer itself, at least one target group, and at least one listener.
The following table summarizes the key building blocks referenced in Terraform ALB patterns:
| Component | Purpose | Typical Terraform Resource |
|---|---|---|
| Application Load Balancer | Layer 7 traffic distribution | aws_lb |
| Target Group | Registration of EC2, Lambda, IP targets | awslbtarget_group |
| Listener | Defines port and protocol rules | awslblistener |
| Security Group | Controls access to ALB and instances | awssecuritygroup |
| Subnets | Placement of ALB across availability zones | var.publicsubnetids |
An Application Load Balancer operates at the application layer and enables advanced routing based on HTTP and HTTPS traffic characteristics. The architecture includes the load balancer, listeners, rules, target groups, and the registered targets.
A common pattern for web applications is to redirect HTTP traffic to HTTPS.
Module-Based ALB Deployment
A Terraform module for building an application load balancer in AWS can simplify repeatable deployments. The module requires an existing VPC, some existing subnets, and a domain name and public and private hosted zones.
The application load balancer consists of:
- An ALB deployed across the provided subnet IDs
- Either internal or internet-facing as specified
- With a health check using the specified target
- With connection draining as specified
- A security group allowing access to/from the load balancer according to the specified access control and egress CIDRs configuration
- A security group for use by instances allowing access from the load balancer according to the specified access control configuration
- A DNS entry in the public hosted zone if specified
- In the private hosted zone if specified
To use the module, include something like the following in your Terraform configuration:
module "application_load_balancer" {
source = "infrablocks/application-load-balancer/aws"
version = "4.0.0"
region = "eu-west-2"
vpc_id = "vpc-fb7dc365"
subnet_ids = "subnet-ae4533c4,subnet-443e6b12"
component = "important-component"
deployment_identifier = "production"
domain_name = "example.com"
public_zone_id = "Z1WA3EVJBXSQ2V"
private_zone_id = "Z3CVA9QD5NHSW3"
listeners = [
{
lb_port = 443
lb_protocol = "HTTPS"
instance_port = 443
instance_protocol = "HTTPS"
ssl_certificate_id = "arn:aws:iam::123456789012:server-certificate/default"
},
{
lb_port = 6567
lb_protocol = "TCP"
instance_port =
The module creates the ALB, the associated security groups, and DNS records. The security group for the ALB is configured with access control and egress CIDRs, while a separate security group for instances allows access from the load balancer.
Terraform module which creates Application and Network Load Balancer resources on AWS is also available for more granular control. When you're using ALB Listener rules, make sure that every rule's actions block ends in a forward, redirect, or fixed-response action so that every rule will resolve to some sort of an HTTP response.
Manual Resource Configuration
Setting up ALB with Terraform gives you repeatable, version-controlled load balancer configurations that you can deploy across environments. This guide covers everything from a basic ALB to advanced setups with multiple target groups, SSL certificates, and redirect rules.
Start with the security group.
```
Security group for the ALB
resource "awssecuritygroup" "alb" {
nameprefix = "alb-"
description = "Security group for the Application Load Balancer"
vpcid = var.vpcid
ingress {
fromport = 80
toport = 80
protocol = "tcp"
cidrblocks = ["0.0.0.0/0"]
description = "Allow HTTP from anywhere"
}
ingress {
fromport = 443
toport = 443
protocol = "tcp"
cidrblocks = ["0.0.0.0/0"]
description = "Allow HTTPS from anywhere"
}
egress {
fromport = 0
toport = 0
protocol = "-1"
cidrblocks = ["0.0.0.0/0"]
description = "Allow all outbound"
}
tags = {
Name = "${var.name}-alb-sg"
}
lifecycle {
createbeforedestroy = true
}
}
```
Now create the ALB.
```
The Application Load Balancer
resource "awslb" "main" {
name = "${var.name}-alb"
internal = false # Internet-facing
loadbalancertype = "application"
securitygroups = [awssecuritygroup.alb.id]
subnets = var.publicsubnetids # Must be in public subnets
Enable deletion protection for production
enabledeletionprotection = var.environment == "production"
```
The ALB must be placed in public subnets for internet-facing deployments. Deletion protection can be toggled per environment.
The declarative syntax structure works on infrastructure management, empowering users to define the ideal condition of their AWS environment and apply changes reliably. The integration with AWS services, for example Elastic Load Balancing, works with high availability, fault tolerance, and scalability of applications.
Listener Rules and Routing Behavior
With Terraform you can provision an Application Load Balancer, launch two EC2 instances, register them in a target group, and test load balancing by refreshing the ALB DNS and observing the traffic alternate between instances.
One of the powerful capabilities of an ALB is routing traffic to different target groups using rules. This is commonly used for path-based routing for example /api vs /web or host-based routing in multi-service architectures.
In a typical tutorial you will:
- Provision EC2 instances and organize them into target groups
- Set up an ALB listener with a default forwarding rule
- Write listener rules for path-based routing e.g., /images, /register
- Test the end-to-end routing behavior
- Integrating ALB with AWS Lambda for serverless workloads
- Attaching an AWS WAF ACL to protect your load balancer
When running multiple services behind a single domain such as a homepage, an API, an image server, a registration flow, you need something smarter than a basic load balancer. AWS Application Load Balancer operates at Layer 7 which means it can inspect HTTP requests and route traffic based on paths, headers, hostnames, query strings, and more.
Target Groups and Instance Registration
Provisioning EC2 instances and registering them in a target group is a core lab pattern. The lab keeps things simple and focuses on a single target group with two EC2 instances to demonstrate traffic distribution.
By arranging load balancer configurations, listeners, target groups, and related resources, groups can automate the provisioning system, ensuring consistency and reliability quality across deployments. With Terraform, associations can increase assets or down, adjust to evolving responsibilities, and integrate load balancing into CI/CD pipelines for continuous delivery.
Generally speaking, deploying AWS load balancers with Terraform upgrades functional effectiveness, speeds up infrastructure deployment, and enables groups to fabricate versatile and scalable architectures in the cloud.
Advanced Patterns and Integrations
A comprehensive guide to configuring and implementing an Application Load Balancer using the terraform-aws-alb module covers basic and advanced configuration patterns with practical examples. For Network Load Balancer configurations, see Network Load Balancer Example.
Sources for minimal configuration structures show that an Application Load Balancer operates at the application layer and enables advanced routing based on HTTP/HTTPS traffic characteristics. The following components are necessary for configuring an ALB:
- Load balancer resource
- Target group resource
- Listener resource
- Security groups
- Subnet placement
The module supports both basic and advanced patterns with practical examples. Terraform's declarative syntax allows infrastructure to be defined and applied reliably.
Conclusion
Application Load Balancer Terraform provisioning combines Layer 7 routing capabilities with code-driven lifecycle management. Manual console work is replaced by reusable modules and explicit resources for load balancers, target groups, listeners, and security groups. Module-based approaches abstract VPC, subnet, DNS, and health check requirements into a single call with parameters for internal or internet-facing placement, connection draining, and access control. Manual resource approaches provide fine-grained control over security groups, deletion protection, subnet selection, and listener rule actions.
Path-based and host-based routing rules can be expressed as code, enabling consistent multi-service fronting behind one domain. Integration points such as AWS Lambda and AWS WAF ACLs extend the ALB beyond simple instance load balancing to serverless and protected workloads. Version control, repeatable applies, and CI/CD integration make Terraform ALB configurations suitable for production environments that require high availability, fault tolerance, and scalability.