The terraform-aws-alb module exists as a Terraform implementation that creates Application and Network Load Balancer resources on AWS. The module is presented as a comprehensive overview of terraform-aws-alb which creates and manages AWS Application Load Balancers and Network Load Balancers through Terraform. The module offers a complete solution for provisioning load balancers in AWS with extensive configuration options and integration points. The terraform-aws-alb module enables users to provision AWS load balancers with a declarative Terraform configuration.
The module is described as a Terraform module containing common configurations for an AWS Application Load Balancer running over HTTP/HTTPS. It is available through the Terraform registry. The module documentation centers on a use case where a user wants to create a set of resources around an application load balancer, namely associated target groups and listeners. The prerequisites for use are that a Virtual Private Cloud and subnets where the ALB will be placed already exist, and one or more security groups to attach to the ALB are available. Additionally, if an HTTPS listener is planned, the ARN of an SSL certificate is required.
The module supports both internal ALBs and external ALBs as mutually exclusive deployment modes. A note is provided that it is strongly recommended that the autoscaling module is instantiated in the same state as the ALB module as in flight changes to active target groups need to be propagated to the ASG immediately or will result in failure. The value of targetgroup[n][name] also must change any time there are modifications to existing targetgroups.
The module is positioned as enabling ALB to replace what several ELBs can do by routing based on URI matchers. Additionally operating at layer 7 opens the ability to shape traffic using WAF. AWS documentation has a more exhaustive set of reasons. Alternatively, if using ALB with ECS look no further than the HashiCorp example. A full example leveraging other community modules is contained in the examples/albtestfixture directory.
Deploying an AWS Application Load Balancer Using Terraform is discussed with a last updated date of April 12, 2026. The narrative contrasts manual console work with code. If you have tried building an ALB manually in the AWS Console, you already know the drill create a VPC, configure subnets, set up security groups, launch Amazon EC2 instances, create a target group, add listeners, and then double check everything because one small misconfiguration can break the whole setup. It works, but it is time consuming and not something you want to repeat every time you need a fresh environment.
This is exactly where Terraform shines. Instead of clicking through multiple AWS console pages, you define your infrastructure in code and let Terraform handle the provisioning. Need to rebuild the lab? Just run terraform apply again and you are good to go.
In this lab, the stated goals are:
- Provision an Application Load Balancer
- Launch two EC2 instances
- Register them in a target group
- Test load balancing by refreshing the ALB DNS and observing the traffic alternate between instances
The diagram above highlights one of the powerful capabilities of an ALB 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. For this exercise, the focus is kept simple and focused on a single target group with two EC2 instances.
Module Purpose and Scope
The terraform-aws-alb module is described as a module which creates Application and Network Load Balancer resources on AWS. The comprehensive overview states the module creates and manages AWS Application Load Balancers and Network Load Balancers through Terraform. The module offers a complete solution for provisioning load balancers in AWS with extensive configuration options and integration points.
The practical impact of this scope is that users do not need to write separate awslb, awslblistener, awslbtargetgroup, and awslblistener_rule resources manually. The module consolidates these into a single source block. The declarative nature means a configuration can be versioned, reviewed, and applied repeatedly.
The module enables users to provision AWS load balancers with a declarative Terraform configuration. The shift from imperative console clicks to declarative code reduces human error during repeat environments. The extensive configuration options referenced include security group rules, access logging, listener actions, target group attributes, and tags.
Listener Rules and Action Requirements
When 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.
The impact of this requirement is direct operational stability. If a rule actions block terminates without a terminal action, the ALB cannot produce a response and requests will stall or error. The requirement ensures that every rule path has a deterministic outcome.
The module example shows listener configurations with redirect and forward actions.
hcl
listeners = {
ex-http-https-redirect = {
port = 80
protocol = "HTTP"
redirect = {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301"
}
}
ex-https = {
port = 443
protocol = "HTTPS"
certificate_arn = "arn:aws:iam::123456789012:server-certificate/test_cert-123456789012"
forward = {
target_group_key = "ex-instance"
}
}
}
The forward action routes to a target group key defined elsewhere. The redirect action moves HTTP to HTTPS with status code HTTP_301.
VPC Subnet Security Group Prerequisites
The module assumes prerequisite networking exists. You have created a Virtual Private Cloud and subnets where you intend to put this ALB. You have one or more security groups to attach to the ALB.
The impact for users is that the module does not create a VPC or subnets by default. If those resources are missing, the module will fail during apply with an invalid VPC ID or subnet error. Planning must therefore include VPC provisioning as a separate step or via another module.
If an HTTPS listener is planned, the ARN of an SSL certificate is required. This means certificate creation or import in AWS Certificate Manager must precede ALB deployment. Without a valid certificate ARN, the HTTPS listener will be unresolvable.
The module example illustrates security group ingress and egress definitions.
hcl
security_group_ingress_rules = {
all_http = {
from_port = 80
to_port = 80
ip_protocol = "tcp"
description = "HTTP web traffic"
cidr_ipv4 = "0.0.0.0/0"
}
all_https = {
from_port = 443
to_port = 443
ip_protocol = "tcp"
description = "HTTPS web traffic"
cidr_ipv4 = "0.0.0.0/0"
}
}
security_group_egress_rules = {
all = {
ip_protocol = "-1"
cidr_ipv4 = "10.0.0.0/16"
}
}
These rules shape inbound and outbound traffic for the ALB. The egress rule to 10.0.0.0/16 restricts outbound to internal VPC CIDR.
Internal Versus External Load Balancer Deployment
The module supports both mutually exclusive internal ALBs and external ALBs.
An external ALB receives traffic from the internet and is assigned a public DNS name. An internal ALB receives traffic only from within the VPC and is used for private service exposure. The choice affects the loadbalancertype and scheme settings and has security and cost implications.
The module parameter table summarizes essential parameters for configuring an ALB.
| Parameter | Type | Description |
|---|---|---|
| name | string | Name of the ALB |
| loadbalancertype | string | Default is "application" |
| vpc_id | string | VPC where the ALB will be created |
| subnets | list(string) | Subnets where the ALB will be deployed |
| securitygroupingress_rules | map | Ingress rules for the ALB security group |
| securitygroupegress_rules | map | Egress rules for the ALB security group |
| listeners | map | Listener configurations (port, protocol, actions) |
| target_groups | map | Target group configurations |
| access_logs | map | Access logging configuration |
| tags | map | Resource tags |
The table provides a quick reference for configuration. The name parameter sets the ALB name prefix. The loadbalancertype default is application, indicating the module leans to ALB but can create NLB. The vpcid and subnets locate the resource. Security group rules are maps allowing multiple named rules. Listeners and targetgroups are maps enabling multiple instances.
Autoscaling State Coupling and Target Group Naming
A note states it is strongly recommended that the autoscaling module is instantiated in the same state as the ALB module as in flight changes to active target groups need to be propagated to the ASG immediately or will result in failure.
The real world consequence is that if an autoscaling group and ALB target group are managed in separate Terraform states, a change to target group attributes may not be communicated to the ASG in the same apply cycle. This can cause targets to be deregistered or health checks to fail.
The value of targetgroup[n][name] also must change any time there are modifications to existing targetgroups. This means target group name is part of the resource identity. Changing attributes that require recreation will force a new name or explicit lifecycle management.
The module creates and manages security groups for the ALB. This centralizes security group lifecycle with the load balancer, preventing orphaned groups.
Target Type Support Matrix
The module supports multiple types.
| Target Type | Description | Use Case |
|---|---|---|
| instance | EC2 instances | Traditional application hosting |
| ip | IP addresses | Containers, on-premises servers |
| lambda | Lambda functions | Serverless applications |
| alb | Other load balancers | Complex routing architectures |
The impact is that a single ALB can fan out to diverse compute. Instance targets are common for EC2. IP targets enable ECS tasks or EC2 with custom networking. Lambda targets enable serverless fronting. ALB targets enable multi-tier load balancing.
The example target group shows:
hcl
target_groups = {
ex-instance = {
name_prefix = "h1"
protocol = "HTTP"
port = 80
target_type = "instance"
target_id = "i-0f6d38a07d50d080f"
}
}
The nameprefix, protocol, port, targettype, and target_id define the target group. Health checks ensure traffic is only sent to healthy targets. This prevents requests from reaching unhealthy instances and improves availability.
Access Logging and Observability
Access logs capture detailed information about requests sent to the ALB.
The module example includes:
hcl
access_logs = {
bucket = "my-alb-logs"
}
Enabling access logs provides request metadata for auditing and debugging. The bucket must exist and have appropriate permissions for the ALB to write logs. The impact is compliance and troubleshooting capability.
Tags are applied via:
hcl
tags = {
Environment = "Development"
Project = "Example"
}
Tags enable cost allocation and resource organization.
Path Based Routing and Layer Seven Capabilities
The module enables ALB to replace what several ELBs can do by routing based on URI matchers. Additionally operating at layer 7 opens the ability to shape traffic using WAF.
The diagram highlights routing traffic to different target groups using rules. Common use is path-based routing for example /api vs /web or host-based routing in multi-service architectures.
Operating at layer 7 means the ALB can inspect HTTP headers, host, and path. This enables microservice routing without additional hardware. Integration with WAF allows request inspection and blocking at the load balancer.
Manual Console Workflow Versus Terraform Declarative Provisioning
The reference describes the manual drill: create a VPC, configure subnets, set up security groups, launch Amazon EC2 instances, create a target group, add listeners, and then double check everything because one small misconfiguration can break the whole setup.
Terraform replaces this with code. Instead of clicking through multiple AWS console pages, you define your infrastructure in code and let Terraform handle the provisioning. Need to rebuild the lab? Just run terraform apply again and you are good to go.
The lab steps include provision an ALB, launch two EC2 instances, register them in a target group, test load balancing by refreshing the ALB DNS and observing traffic alternate between instances.
The declarative approach reduces time to repeat environments and enables peer review.
Production Readiness and Educational Limitations
Key points note that it is easy to configure, manage, and integrate the AWS ALB service with other services like Lambda functions and WAF. Please note the example discussed here is only for educational purposes, and using it in production environments is not recommended. For production, you may have to configure many more intricate Listener rules and WAF ACLs for security purposes and create the Terraform ALB module.
The implication is that the simplified examples omit hardening. Production deployments require additional listener rules, authentication, rate limiting, and WAF ACLs.
An archaic, largely manual approach to IaC was hampering development, causing multiple bugs, and intensifying developers stress levels. Supported by Spacelift's laser-sharp UI clarity, minutely detailed documentation, and exceptional flexibility, TrueCar has transformed how it manages and deploys Terraform at scale today.
Manage Terraform better with Spacelift. Spacelift helps manage Terraform state, build more complex workflows, and supports policy as code, programmatic configuration, context sharing, drift detection, resource visibility, and many more.
What is ALB Terraform? ALB Terraform refers to the use of Terraform to define and manage AWS Application Load Balancers.
Terraform Licensing and OpenTofu Context
Note: New versions of Terraform are placed under BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that expands on Terraform's existing concepts and offerings. It is a viable alternative to HashiCorp's Terraform, being forked from Terraform version 1.5.6.
This licensing context affects module compatibility and organizational policy. Teams using OpenTofu may need to verify provider support and module compatibility.
Example Configuration Anatomy
The complete module block from the reference shows:
hcl
module "alb" {
source = "terraform-aws-modules/alb/aws"
name = "my-alb"
vpc_id = "vpc-abcde012"
subnets = ["subnet-abcde012", "subnet-bcde012a"]
security_group_ingress_rules = {
all_http = {
from_port = 80
to_port = 80
ip_protocol = "tcp"
description = "HTTP web traffic"
cidr_ipv4 = "0.0.0.0/0"
}
all_https = {
from_port = 443
to_port = 443
ip_protocol = "tcp"
description = "HTTPS web traffic"
cidr_ipv4 = "0.0.0.0/0"
}
}
security_group_egress_rules = {
all = {
ip_protocol = "-1"
cidr_ipv4 = "10.0.0.0/16"
}
}
access_logs = {
bucket = "my-alb-logs"
}
listeners = {
ex-http-https-redirect = {
port = 80
protocol = "HTTP"
redirect = {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301"
}
}
ex-https = {
port = 443
protocol = "HTTPS"
certificate_arn = "arn:aws:iam::123456789012:server-certificate/test_cert-123456789012"
forward = {
target_group_key = "ex-instance"
}
}
}
target_groups = {
ex-instance = {
name_prefix = "h1"
protocol = "HTTP"
port = 80
target_type = "instance"
target_id = "i-0f6d38a07d50d080f"
}
}
tags = {
Environment = "Development"
Project = "Example"
}
}
The block demonstrates naming, VPC placement, subnet placement, security groups, access logging, listeners with redirect and forward, target group definition, and tags.
A second truncated module shows an ex-cognito listener on port 444 with HTTPS and certificate_arn.
The complete ALB example demonstrates a production-ready configuration with multiple features.
The terraform-aws-alb module provides a flexible, feature-rich way to implement Application Load Balancers in AWS.