Target groups are the bridge between your load balancer and your backend resources. They define where traffic goes, how health is checked, and how connections are managed. Whether you are running EC2 instances, containers in ECS, Lambda functions, or IP-based targets, you need target groups to tie everything together.
This guide covers the common target group types and configurations available in Terraform. The material is built from operational patterns for provisioning an Application Load Balancer with Terraform, attaching EC2 instances through target group attachments, and routing traffic with listeners and rules. The discussion also incorporates module-based approaches for ALB provisioning and map-based target group definitions.
The real world impact of target group design is immediate. A misconfigured target type or health check causes traffic to be sent to unhealthy destinations, resulting in 5xx responses for end users. A correct target group definition ensures that the ALB can discover healthy instances, distribute requests, and recover automatically when instances are replaced by autoscaling.
Target Group Fundamentals in AWS and Terraform
Target groups serve as the destination routing endpoint for Application Load Balancers and Network Load Balancers. They contain the configuration for registering targets such as EC2 instances, Lambda functions, or IP addresses, health checks, and traffic distribution rules.
Target groups are essential components that define where your load balancer routes traffic and how it determines whether destinations are healthy. This page covers configuration options, health checks, stickiness, advanced features, and integration examples. For information on listener rules that direct traffic to target groups, see Listener Rules and Traffic Routing.
Health checks are critical for determining whether targets can receive traffic. The health check configuration inside a target group determines whether a target is considered healthy and therefore eligible for new connections.
Target Group Types Supported by Application Load Balancers
Application Load Balancers support three target types, each suited to different architectures.
- instance
Routes to EC2 instances by instance ID. The ALB uses the instance's primary private IP. - ip
Routes to specific private IP addresses. Works with containers, cross-VPC targets, or on-premises resources via Direct Connect or Site-to-Site VPN. - lambda
Routes to Lambda functions. Only supported with ALBs.
The instance target group is the most common type. Instance mode is used when the backend is EC2 instances managed by Auto Scaling Groups or static fleets.
IP target mode is used for containerized workloads, cross-VPC targets, or on-premises resources via Direct Connect or Site-to-Site VPN. IP mode requires explicit IP registration and does not rely on instance metadata.
Lambda target mode is exclusive to ALBs. It allows the ALB to invoke Lambda functions directly without a proxy layer.
| Target Type | Routing Basis | Typical Backend | ALB Support |
| instance | EC2 instance ID, primary private IP | EC2 instances | ALB, NLB |
| ip | Specific private IP address | Containers, ECS, Fargate, cross-VPC, on-prem | ALB, NLB |
| lambda | Lambda ARN | AWS Lambda | ALB only |
Terraform Module Context for ALB and Target Groups
A Terraform module containing common configurations for an AWS Application Load Balancer running over HTTP/HTTPS is available through the Terraform registry.
The module is intended for scenarios where you want to create a set of resources around an application load balancer: namely associated target groups and listeners. Prerequisites for use are:
- 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.
- Additionally, if you plan to use an HTTPS listener, the ARN of an SSL certificate is required.
The module supports both mutually exclusive modes:
- Internal ALBs
- External ALBs
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.
ALB has the ability 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.
Map-Based Target Group Definition
The module uses a map-based approach for defining target groups, allowing multiple target groups to be created with different configurations.
Here is an example of a basic target group configuration:
The map approach enables the same module call to produce several target groups with distinct health check settings, ports, protocols, and stickiness policies. Each entry in the map becomes an independent target group resource that can be referenced by listeners and rules.
Target Group Attachment Pattern
As far as target groups are concerned, recognizing them with paths is a matter of intent, which listener rules and EC2 instances should fulfill.
Add the ALB Target Group attachment. Add the configuration below to associate EC2 instances with the Target Groups:
- Instance A :: Target Group A
- Instance B :: Target Group B
- Instance C :: Target Group C
resource "aws_lb_target_group_attachment" "tg_attachment_a" {
target_group_arn = aws_lb_target_group.my_tg_a.arn
target_id = aws_instance.instance_a.id
port = 80
}
resource "aws_lb_target_group_attachment" "tg_attachment_b" {
target_group_arn = aws_lb_target_group.my_tg_b.arn
target_id = aws_instance.instance_b.id
port = 80
}
resource "aws_lb_target_group_attachment" "tg_attachment_c" {
target_group_arn = aws_lb_target_group.my_tg_c.arn
target_id = aws_instance.instance_c.id
port = 80
}
Use terraform apply on the updated configuration, and make sure the instance placement is as intended in the target groups, as seen in the screenshots below.
The attachment resource decouples instance lifecycle from target group definition. Changing instance IDs or ports requires updating the attachment, not the target group itself.
ALB Listener and Load Balancer Provisioning
Create an ALB Listener. Now that we have provisioned the EC2 instances and placed them in appropriate target groups, we are ready to provision the ALB and configure the rules.
The resource awslb specified in the Terraform configuration provisions an ALB. The attribute loadbalancer_type specifies the type as "application". We have also specified the security groups and subnets already created with appropriate routing tables.
Each instance is configured with a Nginx web server, which responds uniquely.
To manage AWS Application Load Balancers with Terraform ALB resources, follow the steps below:
- Configure the EC2 instances
- Create an ALB Target Group
- Add the ALB Target Group attachment
- Create an ALB Listener
- Manage custom ALB Listener rules
- Test the path-based routing on ALB
The full source code for the examples discussed in this post is available here.
Note: The example discussed here is only for educational purposes, and using it in production environments is not recommended.
Path-Based Routing and Multi-Service Architecture
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, we will keep things simple and focus on a single target group with two EC2 instances. The ALB will distribute incoming requests across both instances, and we will validate the behavior by refreshing the ALB DNS endpoint.
We want to serve requests based on what path they are targeted at. Incoming requests can be classified based on whether:
- They are targeted toward the homepage
- They are registration requests
- They are related to images.
Each of the types described above needs to be served separately.
Let us provision three EC2 instances serving the corresponding requests, as seen in the Terraform configuration below. We have used the user_data attribute to supply a script that installs and runs the nginx service.
Path-based routing relies on listener rules that inspect the request URI and forward to the appropriate target group. The target group itself remains unaware of routing logic; the listener rule provides the mapping.
Prerequisites and Security for Terraform ALB Deployments
Before we start writing Terraform code, make sure your environment is ready. Terraform needs a way to authenticate to AWS so it can provision resources on your behalf. This setup was tested using Tutorials Dojo PlayCloud, but the same steps apply to any AWS account.
Your IAM user must have permissions to create:
- VPC networking resources
- EC2 instances
- Application Load Balancers
Security Reminder: Never hardcode access keys inside Terraform files. This is a common cause of credential leaks. Always use secure credential management methods such as the AWS CLI configuration, environment variables, or IAM roles.
Create an IAM User for Terraform. To allow Terraform to interact with AWS programmatically, we will create a dedicated IAM user for CLI access. In real-world environments, you should apply the principle of least privilege and grant only the required permissions.
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, 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
Operational Notes and Limitations
Health checks are critical for determining whether targets can receive traffic. Misconfigured health check paths cause targets to be marked unhealthy even though the application is serving traffic.
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 example discussed here is only for educational purposes, and using it in production environments is not recommended.
Conclusion
Terraform ALB target group configuration provides a declarative way to define where load balancer traffic is routed and how backend health is evaluated. Target groups bridge the load balancer and backend resources, defining routing, health checking, and connection management for EC2 instances, IP targets, containers, and Lambda functions.
The map-based module approach allows multiple target groups with distinct health checks and stickiness settings to be created from a single definition. Attachments link specific instances or IP addresses to target groups without coupling lifecycle. Listeners and rules provide layer 7 routing such as path-based and host-based forwarding to the appropriate target group.
Prerequisites such as VPC, subnets, security groups, and IAM permissions must be satisfied before ALB provisioning. Security best practices require avoiding hardcoded credentials and using least privilege IAM roles. When combined with autoscaling, target group names and attachments must be kept in sync to avoid deployment failures.
The patterns described enable repeatable ALB deployments that can be rebuilt with terraform apply, replacing manual console steps with versioned infrastructure code.