Infrastructure as code transforms how teams build and operate Layer 7 traffic distribution. Application Load Balancers expose HTTP and HTTPS routing decisions to the user, and Terraform lets those decisions be versioned, reviewed, and reproduced across environments. The reference material covers AWS Application Load Balancer creation with Terraform, path-based routing, integration with Lambda and WAF, and a comparable Google Cloud regional internal load balancer example.
Why Application Load Balancers Require Code
Application Load Balancer operates at Layer 7 of the OSI model, which means it can inspect HTTP requests and route traffic based on paths, headers, hostnames, query strings, and more. It’s one of the most commonly used components in scalable AWS architectures, and managing it through Terraform lets you version, review, and reproduce your entire routing configuration as code.
Load balancers are one of the crucial components of a distributed architecture. They help assign incoming requests to multiple target servers to ensure efficiency and avoid avoiding delays and downtimes.
When you’re running multiple services behind a single domain, a homepage, an API, an image server, a registration flow, you need something smarter than a basic load balancer.
If you’ve 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’s 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’re good to go.
AWS ALB Core Components in Terraform
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.
Security Group for the ALB
Start with the security group.
hcl
resource "aws_security_group" "alb" {
name_prefix = "alb-"
description = "Security group for the Application Load Balancer"
vpc_id = var.vpc_id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
description = "Allow HTTP from anywhere"
}
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
description = "Allow HTTPS from anywhere"
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
description = "Allow all outbound"
}
tags = {
Name = "${var.name}-alb-sg"
}
lifecycle {
create_before_destroy = true
}
}
Application Load Balancer Resource
Now create the ALB.
hcl
resource "aws_lb" "main" {
name = "${var.name}-alb"
internal = false
load_balancer_type = "application"
security_groups = [aws_security_group.alb.id]
subnets = var.public_subnet_ids
enable_deletion_protection = var.environment == "production"
}
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.
Target Groups and Instances
In this lab, we will:
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
For this exercise, we’ll keep things simple and focus on a single target group with two EC2 instances.
Provisioning EC2 instances and organizing them into target groups is a core step. Setting them up 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.
Listener Rules and Path-Based Routing
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.
Writing listener rules for path-based routing e.g., /images, /register is covered in the tutorial flow. Testing the end-to-end routing behavior follows provisioning.
The tutorial covers:
Provisioning EC2 instances and organizing them into target groups
Setting up an ALB listener with a default forwarding rule
Writing listener rules for path-based routing e.g., /images, /register
Testing the end-to-end routing behavior
Integrating ALB with AWS Lambda for serverless workloads
Attaching an AWS WAF ACL to protect your load balancer
Terraform Module Guidance
Terraform module which creates Application and Network Load Balancer resources on AWS.
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.
By arranging load balancer configurations, listeners, target groups, and related resources, groups can automate the provisioning system, ensuring consistency and reliability quality across deployments. Terraform's 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. With Terraform, associations can undoubtedly increase assets or down, adjust to evolving responsibilities, and integrate load adjusting into their 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.
Step-by-Step AWS Deployment Example
Step 1: Launch An Instance
Launch EC2 instance with Amazon Linux2 Kernel 5.10 AMI along with port numbers set SSH – 22, HTTP 80 and allow all traffic and select storage t2.micro.
Now connect with git bash terminal or any other terminals like putty, command prompt and PowerShell e.t.c.
Step 2: Install Terraform
Now install terraform packages from official site of hashicorp or follow below commands
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform
Step 3: Create A File And Write Terraform Script for to create AWS load balancer
Creation of VPC
In this section we are creating VPC for our EC2 Instance
hcl
resource "aws_vpc" "siva" {
cidr_block = var.vpc_cidr
instance_tenancy = "default"
tags = {
Name = "siva-vpc"
}
}
Provider Configuration
hcl
provider "aws" {
region = "us-east-1"
}
Creation of Subnet
In this section we are creating subnets to VPC
hcl
resource "aws_subnet" "public-subnet1" {
vpc_id = aws_vpc.siva.id
cidr_block =
}
These load balancers are highly adaptable, effectively configurable, and flawlessly coordinated with cloud environments.
Cloud load balancers, like the AWS Elastic Load Balancer, offer extra elements like automatic scaling, health checks, and integration with other cloud services, pursuing famous decisions for present-day cloud-native applications.
Google Cloud Regional Internal Application Load Balancer with Terraform
You can use the following examples to deploy a sample regional internal Application Load Balancer.
If you are new to using Terraform for Google Cloud, see Get started with Terraform.
Regional internal Application Load Balancer with a MIG backend
You can use Terraform resources to bring up an internal HTTP load balancer with a managed instance group backend.
For information about the load balancer setup, see the primary setup guide.
VPC network
hcl
resource "google_compute_network" "ilb_network" {
name = "l7-ilb-network"
provider = google-beta
auto_create_subnetworks = false
}
Proxy-only subnet
hcl
resource "google_compute_subnetwork" "proxy_subnet" {
name = "l7-ilb-proxy-subnet"
provider = google-beta
ip_cidr_range = "10.0.0.0/24"
region = "europe-west1"
purpose = "REGIONAL_MANAGED_PROXY"
role = "ACTIVE"
network = google_compute_network.ilb_network.id
}
Backend subnet
hcl
resource "google_compute_subnetwork" "ilb_subnet" {
name = "l7-ilb-subnet"
provider = google-beta
ip_cidr_range = "10.0.1.0/24"
region = "europe-west1"
network = google_compute_network.ilb_network.id
}
Forwarding rule
hcl
resource "google_compute_forwarding_rule" "google_compute_forwarding_rule" {
name = "l7-ilb-forwarding-rule"
provider = google-beta
region = "europe-west1"
depends_on = [google_compute_subnetwork.proxy_subnet]
ip_protocol = "TCP"
load_balancing_scheme = "INTERNAL_MANAGED"
port_range = "80"
target = google_compute_region_target_http_proxy.default.id
network =
}
Resource Comparison
| Component | AWS ALB | Google Cloud Internal L7 LB |
|---|---|---|
| Layer | Layer 7 HTTP/HTTPS | Layer 7 HTTP |
| Scope | Regional, internet-facing or internal | Regional internal |
| Routing basis | Path, host, headers, query strings | Path, host |
| Terraform provider | awslb, awslblistener, awslbtargetgroup | googlecomputeregiontargethttpproxy, googlecomputeforwardingrule |
| Typical backend | EC2 instances, ECS, Lambda | MIG, GCE VMs |
Integration Patterns
Integrating ALB with AWS Lambda for serverless workloads is a documented workflow. Attaching an AWS WAF ACL to protect your load balancer completes the security layer.
Setting them up with Terraform gives you repeatable, version-controlled load balancer configurations that you can deploy across environments.
The integration with AWS services, for example, Elastic Load Balancing works with high availability, fault tolerance, and scalability of applications.
Conclusion
Terraform application load balancer work is about translating routing intent into declarative resources. AWS Application Load Balancer operates at Layer 7 and enables path, host, header and query based routing. Terraform codifies the security group, load balancer, target group and listener resources needed to make that routing repeatable.
The reference material demonstrates provisioning EC2 instances into target groups, setting up listeners with default forwarding, writing listener rules for path-based routing such as /images and /register, testing end-to-end behavior, integrating with Lambda for serverless workloads, and attaching WAF ACLs for protection.
For AWS, the basic ALB setup requires the load balancer itself, at least one target group and at least one listener. Security groups open ports 80 and 443, subnets are specified from public subnets, and deletion protection can be toggled per environment.
Module guidance reinforces that every ALB listener rule action must terminate in forward, redirect or fixed-response. The step-by-step AWS example shows VPC creation, provider configuration, subnet creation and instance launch before load balancer definition.
Google Cloud provides a comparable regional internal Application Load Balancer pattern with a dedicated proxy-only subnet purpose REGIONALMANAGEDPROXY, a backend subnet, and an internal forwarding rule with loadbalancingscheme INTERNAL_MANAGED.
Across both clouds, Terraform delivers version-controlled, reproducible load balancer configurations that support path-based routing, multi-service architectures, and CI/CD integration while maintaining consistency and reliability across deployments.