The terraform-aws-alb module provides a declarative mechanism for creating and managing AWS Application Load Balancers and Network Load Balancers through Terraform. The module enables users to provision AWS load balancers with a declarative Terraform configuration. The module offers a complete solution for provisioning load balancers in AWS with extensive configuration options and integration points. This capability shifts load balancer creation from manual console interactions in the AWS Management Console to version controlled infrastructure code.
Manual construction of an ALB in the AWS Console requires creation of a VPC, configuration of subnets, setup of security groups, launch of Amazon EC2 instances, creation of a target group, addition of listeners, and then verification of the entire chain because one small misconfiguration can break the whole setup. The process works but is time consuming and not something desired to repeat every time a fresh environment is needed. Terraform addresses this friction by allowing infrastructure to be defined in code and letting Terraform handle provisioning. Need to rebuild the lab and the environment can be recreated with terraform apply again.
The operational pattern demonstrated in instructional material involves provisioning an Application Load Balancer, launching two EC2 instances, registering them in a target group, and testing load balancing by refreshing the ALB DNS and observing traffic alternate between instances. This validation confirms that distribution and health checking operate as intended. The diagram that accompanies the exercise 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 configuration is kept simple and focuses on a single target group with two EC2 instances.
Module Overview and Core Capabilities
The terraform-aws-alb module creates Application and Network Load Balancer resources on AWS. The module supports multiple types of load balancer targets and provides a flexible, feature-rich way to implement Application Load Balancers in AWS. The document that describes the module provides a comprehensive overview of the terraform-aws-alb module, which creates and manages AWS Application Load Balancers and Network Load Balancers through Terraform.
The module enables users to provision AWS load balancers with a declarative Terraform configuration. The impact for teams is a reduction in repetitive manual steps and an increase in repeatability across environments. The contextual connection is that the module sits between raw AWS API calls and higher level orchestration, allowing teams to compose ALB configurations as part of larger Terraform workspaces that also manage VPCs, EC2 instances, and security groups.
Listener Rules and Action Resolution 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. This requirement prevents dangling rules that would cause undefined behavior for incoming requests.
The rule action termination requirement influences how listener maps are authored inside the module. A listener configuration block typically contains port, protocol, and an actions object that can include redirect parameters or forward parameters pointing to a targetgroupkey. The need for a terminal action ensures that the ALB can always produce a deterministic HTTP response for a given request.
In practice the module example shows:
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 listener block ex-http-https-redirect terminates with a redirect action to port 443 with status code HTTP301. The listener ex-https terminates with a forward action to targetgroup_key ex-instance. Both satisfy the rule termination requirement.
Target Types Health Checks and Routing Behavior
The module supports multiple types of targets:
| 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 |
Health checks ensure traffic is only sent to healthy targets. This behavior reduces error surface for end users because unhealthy instances are removed from rotation automatically. The contextual impact is that teams can rely on the ALB to provide self-healing routing without writing custom health monitoring logic.
The target group configuration in the example uses targettype instance with protocol HTTP on port 80 and a specific targetid. The module creates and manages security groups for the ALB and access logs capture detailed information about requests sent to the ALB.
Security Group Management and Access Logging
The module creates and manages security groups for the ALB. The example defines securitygroupingressrules with two entries allhttp and allhttps allowing inbound TCP on ports 80 and 443 from cidripv4 0.0.0.0/0 with descriptions. The securitygroupegressrules defines an all rule with ipprotocol -1 and cidr_ipv4 10.0.0.0/16.
Access logs capture detailed information about requests sent to the ALB. The access_logs block specifies bucket = "my-alb-logs". The practical impact is auditability and troubleshooting. Teams can correlate request latency with application logs and enforce compliance retention policies in the specified S3 bucket.
The key takeaway from instructional labs is using security groups to allow traffic only from the ALB improves security. This principle reduces the attack surface of backend instances by restricting ingress to the load balancer tier.
Parameter Reference Configuration Table
The following 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 |
Sources: README.md387-436
The parameter set maps directly to AWS API properties but exposes them through Terraform's declarative map syntax. This allows bulk definition of listeners and target groups within a single module invocation.
Production Example Configuration Patterns
The complete ALB example demonstrates a production-ready configuration with multiple features. The module provides a flexible, feature-rich way to implement Application Load Balancers in AWS.
A second module invocation fragment shows a listener on port 444 with protocol HTTPS and a certificate_arn reference, illustrating how different listener ports can be combined in the same module.
The contextual layer is that production environments typically require multiple listeners for HTTP to HTTPS redirection, TLS termination, and path based routing to distinct target groups. The module's map based inputs support that composition without duplicating resource definitions.
Integration With Lambda WAF and Educational Scope
In this post we saw how easy it is to configure, manage, and integrate the AWS ALB service with other services like Lambda functions and WAF. The example discussed 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.
ALB Terraform refers to the use of Terraform to define and manage AWS Application Load Balancers. The integration point with Lambda functions uses the lambda target type, allowing serverless backends to be registered as targets. Integration with WAF allows request filtering before traffic reaches target groups.
The module's ability to define target_groups with different target types enables architectures where some paths route to EC2 instances while others route to Lambda functions or another ALB.
Infrastructure as Code Advantages and Cleanup
Deploying an AWS Application Load Balancer using Terraform eliminates manual console steps. If you have tried building an ALB manually in the AWS Console you already know the drill. With Terraform the infrastructure is defined in code and deployed with a few commands.
Key takeaways from the lab exercise:
- Terraform makes AWS deployments faster and repeatable
- ALB distributes traffic only to healthy targets
- Using security groups to allow traffic only from the ALB improves security
- terraform destroy makes cleanup easy
This is one of the biggest advantages of Infrastructure as Code—no manual cleanup needed. The lab concludes with confirmation that load balancing and health checks were working properly after refreshing the ALB DNS and observing traffic alternate between instances.
The last updated date for the tutorial material is April 12, 2026. This indicates ongoing relevance of the module patterns.
Licensing and OpenTofu Alternatives
Note: New versions of Terraform are placed under the 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.
The licensing note impacts module compatibility decisions. Teams evaluating long term open source continuity may consider OpenTofu as an alternative runtime for existing terraform-aws-alb configurations.
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.
The module remains a central building block for ALB provisioning across both Terraform and OpenTofu workflows.
Conclusion
The terraform-aws-alb module transforms ALB provisioning from a manual console workflow into a declarative, version controlled process. The module creates and manages AWS Application Load Balancers and Network Load Balancers through Terraform with extensive configuration options and integration points. Listener rules must terminate in forward, redirect, or fixed-response actions to guarantee deterministic HTTP responses. Target types include instance, ip, lambda, and alb with health checks ensuring only healthy targets receive traffic. Security group management and access logging are built into the module inputs, enabling auditability and least privilege networking.
Parameter coverage spans name, loadbalancertype, vpcid, subnets, securitygroupingressrules, securitygroupegressrules, listeners, targetgroups, access_logs, and tags. Production readiness requires additional listener rules and WAF ACLs beyond educational examples. Infrastructure as Code advantages include repeatability, faster deployments, health aware routing, and easy cleanup via terraform destroy. Licensing considerations around BUSL and OpenTofu provide context for long term adoption choices. The module provides a flexible, feature-rich way to implement Application Load Balancers in AWS and remains a core component for teams standardizing on Terraform for AWS networking.