# Target group

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/target-group

## Quick definition

A target group is a collection of compute resources, like virtual machines or containers, that you set up to receive traffic from a load balancer. When a request arrives, the load balancer sends it to one of the healthy targets in the group based on rules you define. This helps distribute workloads evenly and ensures high availability by checking the health of each target. Target groups are a core component in modern cloud networking, especially in AWS and similar platforms.

## Simple meaning

Imagine you are the manager of a busy juice bar. You have several blenders, each operated by a different team member. Customer orders come in one after another, and you need to decide which blender handles which order. Instead of sending every order to the same blender and overwhelming that person, you group all the blenders and their operators together as a single pool. You then create a rule: whenever a new juice order arrives, send it to whichever blender operator is free and ready to work. This pool is like a target group. Each blender operator is a target. The person who assigns the orders is the load balancer. If one blender breaks down, you stop sending orders to it until it is fixed, which is like health checking.

In IT terms, a target group holds a set of backend servers or container instances. A load balancer is configured to forward client requests to this group. The load balancer uses health checks to know which targets are healthy and can accept traffic. If a target fails a health check, traffic is not sent to it until it becomes healthy again. Target groups can also have rules that route specific types of requests to different groups, like sending traffic for images to a group optimized for image processing. This abstraction makes scaling easy, because you can add or remove targets without changing the load balancer configuration, as long as the target group membership is updated.

## Technical definition

A target group is an AWS resource (or similar concept in other cloud providers like Azure and Google Cloud) that defines a group of backend targets, such as EC2 instances, IP addresses, Lambda functions, or even other load balancers. It is used primarily with an Application Load Balancer (ALB) or Network Load Balancer (NLB) to route incoming traffic. The target group specifies the protocol and port on which the targets listen for requests, such as HTTP on port 80 or HTTPS on port 443. It also defines health check settings, including the protocol, path, interval, timeout, unhealthy threshold, and healthy threshold. These settings determine how the load balancer monitors the availability of each target.

When a client sends a request to the load balancer, the load balancer evaluates the listener rules. Each rule can forward traffic to a specific target group based on conditions like host header, path pattern, HTTP method, query string, or source IP address. The load balancer then selects a healthy target from the target group using the configured routing algorithm, which is typically round-robin for ALB and flow hash for NLB. For ALB, the target group can also use stickiness (session affinity) by generating a cookie that binds a client to a specific target for the duration of the session.

Target groups support multiple target types. Instance targets are identified by their instance ID and require that the instance is registered in the target group. IP targets are identified by private IPv4 or IPv6 addresses and can be used for on-premises servers or containers that are not EC2 instances. Lambda targets allow you to route requests directly to a Lambda function, which is useful for serverless architectures. Target groups also support deregistration delay, which allows in-flight requests to complete before a target is removed from service.

Registering and deregistering targets can be done manually or automatically through auto scaling groups. When an auto scaling group launches a new instance, it can automatically register that instance with a target group. Similarly, when an instance is terminated, it is deregistered. This integration provides seamless scaling and high availability. The target group also maintains a state per target, which can be initial, healthy, unhealthy, draining, or unused. The load balancer only sends traffic to targets with a healthy state.

## Real-life example

Think of a popular food truck rally. Each food truck is a target, and all the trucks that serve savory dishes are grouped together as one target group. The central announcement board acts as the load balancer. When a hungry customer tells the board what they want, the board says, go to truck number 3 in the savory group. But the board first checks that truck 3 is actually open and has food ready. If that truck is closed, the board sends the next customer to another truck in the same group.

Now imagine that the rally also has a dessert target group and a drinks target group. A customer who wants dessert is directed only to the dessert group, not the savory group. This is exactly how path-based or host-based routing works with target groups. The announcement board reads the customer request and decides which group to send them to based on the request type.

Just like food trucks can join or leave the rally without the announcement board needing to be rewired, targets can be added or removed from the target group dynamically. A truck might leave early, and the board automatically stops sending customers there after a short drain period. If a new truck joins, it is added to the group and starts receiving customers. This flexibility is why cloud architects prefer target groups: they make scaling and updates smooth and reliable, without downtime.

## Why it matters

Target groups are fundamental to building resilient, scalable applications in the cloud. Without them, a load balancer would need to be manually reconfigured every time a server is added or removed. This is impractical in dynamic environments where instances are frequently launched and terminated based on demand. Target groups abstract the backend server pool, allowing the load balancer to treat the group as a single logical endpoint. This enables features like blue-green deployments, where a new version of the application is deployed to a new target group, and traffic is switched by updating the load balancer rule.

In practice, target groups are used for health monitoring, which is critical for uptime. By configuring health checks, you ensure that traffic is only sent to healthy servers. If a server crashes or becomes unresponsive, it is automatically taken out of rotation. This reduces the impact of failures and improves user experience. Target groups also allow fine-grained traffic routing. For example, you can route requests with a specific URL prefix, such as /api, to a target group optimized for API servers, while routing static content like images to a different target group with caching servers.

Another important use case is integration with container orchestration services like Amazon ECS and Kubernetes. When containers are scheduled on different hosts, target groups automatically register the container IP addresses as targets. This ensures that traffic is routed correctly even as containers move between hosts. For certification learners, understanding target groups is essential for passing exams like AWS Solutions Architect, because they appear in many architecture scenarios, from simple web applications to complex microservices.

## Why it matters in exams

For general IT certifications, the concept of a target group is most heavily tested in AWS certification exams, particularly the AWS Certified Solutions Architect Associate, AWS Certified Developer Associate, and AWS SysOps Administrator Associate. It also appears in the AWS Certified Advanced Networking Specialty. In these exams, target groups are a core component of the Elastic Load Balancing (ELB) section. You need to understand how target groups differ from classic load balancers, how they work with auto scaling groups, and how to configure health checks, routing, and stickiness.

Exam questions often present a scenario where an application experiences downtime or performance issues. The correct answer frequently involves misconfiguration of the target group, such as incorrect health check path, wrong port, or improper security group settings that prevent the load balancer from communicating with the targets. Another common pattern is a question about traffic routing: you may be asked how to route requests to different target groups based on URL paths or domain names. You must know that ALB supports path-based and host-based routing through listener rules that forward to target groups.

In the AWS Certified Solutions Architect exam, expect questions about high availability and fault tolerance. You may be asked to design an architecture that distributes traffic across multiple Availability Zones using target groups. The correct approach is to register targets from different AZs into the same target group, and the load balancer automatically distributes traffic across them. Also, know that registering the same EC2 instance in multiple target groups is allowed, but each target group can have its own health check settings.

For the AWS Certified Developer exam, questions may focus on integrations with Lambda. You need to know that a target group can have a Lambda function as a target. This is used for serverless architectures where the ALB invokes the Lambda function in response to HTTP requests. The Lambda function receives an event object containing the request details and returns a response. Understanding how to configure this, including the required permissions and the request/response format, is important.

Even for general IT certifications like CompTIA Cloud+, target groups are covered as part of cloud load balancing concepts. While the term may differ (e.g., backend pool), the core idea remains the same. In Azure, a similar concept is the backend address pool used with Azure Load Balancer. In Google Cloud, it is a backend service. So grasping the underlying principle helps across multiple platforms.

## How it appears in exam questions

Multiple choice scenario questions: The question describes a company deploying a web application on EC2 instances across two Availability Zones. The application runs on port 8080. They want to use an Application Load Balancer to distribute traffic. The solution must also include health checks that test the /health endpoint every 30 seconds. The candidate is asked which configuration steps are required. The correct answer includes creating a target group with protocol HTTP, port 8080, health check path /health, and registering the instances. Distractors might include using HTTPS on the target group, setting the health check interval to 60 seconds, or registering instances by public IP instead of private IP.

Another pattern: An operations team notices that some instances are receiving no traffic even though they appear healthy. The exam question asks you to troubleshoot. The most likely cause is that the instances are not registered in the target group, or they are registered but the target group is not associated with a listener rule. Alternatively, the security group of the instances might not allow traffic from the load balancer on the target port. Candidate must select the reason and the fix.

Configuration drag-and-drop type questions: You are given a list of steps and must arrange them in the correct order to set up a load balanced application. The correct order is: create a target group, specify health check settings, register targets, create a load balancer, create a listener, then associate the target group with the listener rule. A common mistake is trying to register targets before creating the target group, or associating the listener before creating the load balancer.

Troubleshooting questions: A developer reports that users are experiencing intermittent timeouts while accessing the application. The load balancer and target group are set up correctly. What could be the issue? Possible answers: health check thresholds are too low, causing healthy instances to be marked unhealthy; deregistration delay is too short, causing in-flight requests to be lost; the target group stickiness is enabled but the application does not support session persistence. The exam expects you to identify the misconfiguration.

Multi-part questions: You are asked to design a solution where traffic to /images goes to a group of instances optimized for image processing, and traffic to /api goes to another group. You need to create two target groups, then create a listener rule on the ALB that forwards requests based on the path pattern. The exam will test whether you know that path patterns are case-sensitive by default and can include wildcards.

## Example scenario

A small company, BrightCode, runs an online store on AWS. They have two EC2 instances: one for the main website and one for the inventory management system. The website is accessed at www.brightcode.com, and the inventory system is accessed at inventory.brightcode.com. They want to use a single Application Load Balancer to handle traffic for both. The solution involves creating two target groups: one called WebTargetGroup for the website instances, and another called InventoryTargetGroup for the inventory instance. The Website listens on port 80, and the Inventory system listens on port 5000.

First, the administrator creates the WebTargetGroup with protocol HTTP and port 80. He registers the main website EC2 instance using its instance ID. Then he creates the InventoryTargetGroup with protocol HTTP and port 5000, and registers the inventory instance. Next, he creates an Application Load Balancer and attaches it to a public subnet. He creates a listener on port 80 with a default rule that forwards traffic to the WebTargetGroup. Then, he adds a rule to the listener that says: if the host header is inventory.brightcode.com, then forward to InventoryTargetGroup.

Now, when a customer visits the main website, the request goes to the WebTargetGroup, which sends it to the website instance. When an employee visits inventory.brightcode.com, the request goes to the InventoryTargetGroup. Both groups benefit from health checks. The website instance is checked every 30 seconds by hitting the /health endpoint. If it fails three times consecutively, the load balancer stops sending traffic to it until it becomes healthy again. The inventory instance is checked similarly but on a different path.

One day, the inventory instance crashes. The health check detects the failure, and the load balancer stops routing traffic to it. Employees see an error page when trying to access inventory. The administrator quickly launches a new instance with the inventory software and registers it with the InventoryTargetGroup. Within minutes, health checks pass, and traffic is restored. This scenario illustrates how target groups help maintain availability and allow separate traffic routing for different services.

## Common mistakes

- **Mistake:** Registering targets using public IP addresses instead of private IP addresses.
  - Why it is wrong: Target groups require private IP addresses because the load balancer communicates with targets over the internal network. Using public IPs would route traffic through the internet, increasing latency and cost, and often failing due to security group rules.
  - Fix: Always register targets using their private IP addresses or instance IDs. For EC2 instances, use the instance ID; for on-premises servers, use the private IP address that is reachable from the load balancer.
- **Mistake:** Setting the health check interval to a very short value, such as 1 second.
  - Why it is wrong: A very short health check interval can overwhelm the target with requests, causing unnecessary load and potential false failures due to timeouts. It also increases the load balancer's own resource usage.
  - Fix: Use a reasonable interval, such as 30 seconds, and adjust based on the application's expected response time. The default is usually 30 seconds and works well for most cases.
- **Mistake:** Forgetting to associate the target group with a listener rule after creating it.
  - Why it is wrong: A target group is not automatically associated with a load balancer. Without a listener rule, the load balancer does not know which target group to forward traffic to, so the target group receives no traffic, even if targets are healthy.
  - Fix: After creating the target group, ensure that the load balancer's listener has a rule that forwards traffic to that target group. You can set it as the default action or as a rule with a condition.
- **Mistake:** Configuring the target group to use a different protocol than the one the application actually uses.
  - Why it is wrong: If the target group expects HTTPS on port 443 but the application listens on HTTP port 80, the health checks will fail because the application cannot respond to HTTPS requests. This causes all targets to be marked unhealthy.
  - Fix: Match the target group's protocol and port exactly to the application's listener protocol and port. If the application uses HTTP, set the target group to HTTP on the same port.
- **Mistake:** Not allowing inbound traffic from the load balancer's subnet in the target's security group.
  - Why it is wrong: The load balancer sends health check requests and client traffic to the target using its private IP address. If the target's security group does not allow inbound traffic from the load balancer's private IP range, the connection is dropped, causing health checks to fail and traffic to be blocked.
  - Fix: Add a security group rule that allows inbound traffic from the load balancer's security group (or from the VPC CIDR range) on the target port. For example, allow HTTP from the load balancer security group.

## Exam trap

{"trap":"An exam question states that an Application Load Balancer is configured with a target group that has two EC2 instances registered. The instances are healthy, but only one instance receives all the traffic. The candidate is asked to select the cause. Many learners incorrectly assume it is a round-robin issue or that one instance is not registered.","why_learners_choose_it":"Learners might think that if traffic is not evenly distributed, the problem must be with the routing algorithm or registration. They may not consider that stickiness (session affinity) is enabled. When stickiness is enabled, the load balancer sends requests from the same client to the same target, which can lead to an uneven distribution if one client sends many requests.","how_to_avoid_it":"In exam questions, if you see that traffic is not balanced despite all targets being healthy, look for indications of sticky sessions. Remember that stickiness is disabled by default on ALB target groups. If the question mentions that users are logged in or that the application stores session data locally, stickiness might be enabled intentionally. Also, consider that if the load balancer only has one rule and the target group uses round-robin, distribution should be even unless there is a difference in connection longevity. Always check the target group attributes."}

## Commonly confused with

- **Target group vs Auto Scaling Group:** An Auto Scaling group manages the lifecycle of EC2 instances based on scaling policies, ensuring the correct number of instances runs. A target group is a destination for load balancer traffic. They often work together: the ASG can automatically register new instances with a target group. However, they are separate resources. The ASG does not route traffic; it only manages instances. (Example: You have an ASG that launches two EC2 instances. Those instances are automatically added to a target group. The load balancer then sends traffic to the target group, which distributes it to the instances.)
- **Target group vs Listeners:** A listener is a process on the load balancer that checks for connection requests from clients. It uses the protocol and port you configure. The listener then forwards requests to a target group based on rules. Without a listener, the load balancer would not know what to do with incoming traffic. The target group does not listen for requests; it only defines where traffic should go. (Example: The listener is like a receptionist who answers the phone. The target group is the list of departments that the receptionist can transfer the call to. The receptionist decides which department to send the call to based on the caller's request.)
- **Target group vs Network Load Balancer (NLB) Target Group:** NLB target groups work at the transport layer (Layer 4) and can handle TCP, UDP, and TLS traffic. They preserve the client IP address. ALB target groups operate at the application layer (Layer 7) and can inspect HTTP headers. NLB target groups support IP targets and instance targets, while ALB target groups also support Lambda targets. The main difference is the layer of operation and the types of routing supported. (Example: If you need to route traffic based on HTTP paths like /images or /api, use an ALB target group. If you need ultra-low latency or need to handle non-HTTP protocols, use an NLB target group.)

## Step-by-step breakdown

1. **Create a target group** — Define a name, choose the target type (instance, IP, or Lambda), set the protocol (e.g., HTTP) and port (e.g., 80), and select the VPC. This step creates the logical container that will hold your backend resources.
2. **Configure health checks** — Set the health check path (e.g., /health), interval (e.g., 30 seconds), timeout (e.g., 5 seconds), and thresholds for healthy and unhealthy counts. These determine how the load balancer checks if a target is available. Getting this wrong leads to false positives or negatives.
3. **Register targets** — Add EC2 instances (by instance ID), IP addresses, or Lambda functions to the target group. You can register multiple targets. The load balancer will only send traffic to targets that pass health checks. Registration can be manual or automatic via auto scaling.
4. **Create a load balancer and listener** — Provision an Application Load Balancer or Network Load Balancer. Then create a listener (e.g., HTTP on port 80) that specifies the protocol and port for incoming client traffic. The listener is the entry point for requests.
5. **Associate the target group with the listener** — Define a listener rule that forwards traffic to the target group. The rule can be a default action (for all requests) or a rule with conditions like host header or path pattern. This connects the load balancer to your backend pool.
6. **Verify traffic flow** — Access the load balancer's DNS name from a browser or use curl to confirm that requests are being distributed to the targets. Check the target group's health status in the AWS console to ensure all targets are healthy. Troubleshoot any connectivity issues by reviewing security groups and health check logs.

## Practical mini-lesson

In a real-world cloud environment, setting up a target group correctly is critical for application availability. Let's say you are deploying a containerized web application on Amazon ECS. You create an ECS service that runs two tasks across two Availability Zones. Each task runs on Fargate and listens on port 3000. To make this service accessible via an ALB, you must create a target group that uses IP target type, because Fargate tasks have dynamic IP addresses. You set the target group protocol to HTTP on port 3000.

Next, you need to configure health checks. The application exposes a /ready endpoint for health. You configure the health check path as /ready, interval of 30 seconds, timeout of 5 seconds, and unhealthy threshold of 2. This means if the /ready endpoint fails to respond within 5 seconds two times consecutively, the target is marked unhealthy.

Then, you create an ALB with a listener on port 80 that forwards to the target group. You also add a security group to the target group (actually to the Fargate tasks) that allows inbound traffic from the ALB's security group on port 3000. Without that rule, the health checks will fail because the load balancer cannot reach the /ready endpoint.

A common issue that arises in practice is that the health check path returns a 404 or 500 instead of a success code. This happens when developers forget to expose the health endpoint, or the endpoint requires authentication. Another issue is that the health check timeout is too low for a slow-starting application, causing it to be marked unhealthy even though it would have responded given more time. In such cases, increase the timeout or adjust the thresholds.

Another practical aspect is deregistration delay. By default, this is 300 seconds. When you remove a target from the target group, the load balancer waits for this duration before completely closing connections, allowing in-flight requests to complete. If your application has long-running requests, you may need to increase this value. If you reduce it too much, you risk dropping active connections.

Finally, for troubleshooting, use the AWS CLI commands to describe target group health: aws elbv2 describe-target-health --target-group-arn <arn>. This shows the health status of each target. If you see the status as unhealthy, the reason is often provided in the output, such as Target.FailedHealthChecks or Target.NotRegistered. These clues help you quickly fix misconfigurations.

## Memory tip

Target Group = Traffic Team: Think of the group as a team of targets that the load balancer (the coach) sends the ball (traffic) to. Each player must be healthy to receive the ball.

## FAQ

**Can a single EC2 instance be registered in multiple target groups?**

Yes, an EC2 instance can be registered in multiple target groups, each with different ports or protocols. For example, one target group for HTTP and another for HTTPS, or one for a web app and another for an API on a different port.

**What is the difference between a target group and a load balancer?**

A load balancer is the entry point that accepts client traffic. A target group is the destination where the load balancer sends that traffic. The load balancer uses rules to decide which target group to forward requests to.

**How do health checks work in a target group?**

The load balancer sends periodic requests to each target at the specified health check path (e.g., /health). If the target responds with a HTTP 200 or 302 within the timeout period, it is considered healthy. After a set number of consecutive failures, the target is marked unhealthy and traffic is stopped.

**What happens if all targets in a target group are unhealthy?**

The load balancer will not have any healthy targets to forward traffic to, so it returns a 503 Service Unavailable error to the client. This is why it is important to have enough targets and robust health check configuration.

**Can a target group be used with multiple load balancers?**

No, a target group can only be associated with one load balancer at a time. However, a single load balancer can have multiple target groups associated through different listener rules.

**What is deregistration delay in a target group?**

Deregistration delay is the time the load balancer waits before completing the removal of a target from service. It allows any in-flight requests to finish. The default is 300 seconds, but you can adjust it up to 3600 seconds.

## Summary

A target group is a fundamental building block in cloud-based load balancing, especially in AWS environments. It acts as a logical grouping of backend resources that handle client requests forwarded by a load balancer. By decoupling the load balancer from the actual compute instances, target groups enable dynamic scaling, health monitoring, and fine-grained traffic routing. They can include EC2 instances, IP addresses, or Lambda functions, and support both instance-level and IP-level registration.

Understanding target groups is crucial for anyone preparing for cloud certification exams, particularly AWS certifications. You need to know how to configure health checks, associate target groups with listener rules, and integrate them with auto scaling groups. Common exam pitfalls include confusing target groups with auto scaling groups, misconfiguring health check paths, and neglecting security group rules. The ability to design architectures that use multiple target groups for different services (e.g., microservices) is a key skill.

For real-world practice, always remember that the load balancer communicates with targets using their private IP addresses, and security groups must allow inbound traffic from the load balancer. Regularly monitor the health status of targets using the AWS management console or CLI, and adjust health check parameters based on application behavior. Target groups are not just an exam topic; they are a daily tool for cloud professionals. Mastering this concept will help you build resilient, scalable, and maintainable applications in the cloud.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/target-group