Application Load Balancer Target Groups

Application Load Balancer Target Groups

Application Load Balancer Target Groups

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed AWS ALB listener rules and different routing options available in ALB.

https://cloudaffaire.com/aws-application-load-balancer-listener-rules-and-advance-routing-options/

In this blog post, we will discuss the Application Load Balancer Target Groups.

Application Load Balancer Target Groups:

Target Groups:

Target groups are used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. You can define health check settings for your load balancer on a per target group basis. Each target group uses the default health check settings, unless you override them when you create the target group or modify them later on.

Target Group Routing Configuration:

By default, a load balancer routes requests to its targets using the protocol and port number that you specified when you created the target group. Alternatively, you can override the port used for routing traffic to a target when you register it with the target group.

Target groups support the following protocols and ports:

  • Protocols: HTTP, HTTPS
  • Ports: 1-65535

Target Group Target Type:

When you create a target group, you specify its target type, which determines the type of target you specify when registering targets with this target group. After you create a target group, you cannot change its target type.

The following are the possible target types:

  • instance: The targets are specified by instance ID.
  • ip: The targets are IP addresses.
  • lambda: The target is a Lambda function.

Target type instance:

If you specify targets using an instance ID, traffic is routed to instances using the primary private IP address specified in the primary network interface for the instance. If you specify targets using IP addresses, you can route traffic to an instance using any private IP address from one or more network interfaces. This enables multiple applications on an instance to use the same port. Each network interface can have its own security group.

Target type ip:

When the target type is ip, you can specify IP addresses from one of the following CIDR blocks:

  • The subnets of the VPC for the target group
  • 10.0.0.0/8 (RFC 1918)
  • 100.64.0.0/10 (RFC 6598)
  • 172.16.0.0/12 (RFC 1918)
  • 192.168.0.0/16 (RFC 1918)

These supported CIDR blocks enable you to register the following with a target group: ClassicLink instances, instances in a VPC that is peered to the load balancer VPC, AWS resources that are addressable by IP address and port (for example, databases), and on-premises resources linked to AWS through AWS Direct Connect or a VPN connection.

Note: You can’t specify publicly routable IP addresses.

Target type lambda:

You can register your Lambda functions as targets and configure a listener rule to forward requests to the target group for your Lambda function. When the load balancer forwards the request to a target group with a Lambda function as a target, it invokes your Lambda function and passes the content of the request to the Lambda function, in JSON format.

Limits:

  • The Lambda function and target group must be in the same account and in the same Region.
  • The maximum size of the request body that you can send to a Lambda function is 1 MB. For related size limits, see HTTP Header Limits.
  • The maximum size of the response JSON that the Lambda function can send is 1 MB.
  • WebSockets are not supported. Upgrade requests are rejected with an HTTP 400 code.

Registered Targets:

Your load balancer serves as a single point of contact for clients and distributes incoming traffic across its healthy registered targets. You can register each target with one or more target groups. You can register each EC2 instance or IP address with the same target group multiple times using different ports, which enables the load balancer to route requests to microservices.

If demand on your application increases, you can register additional targets with one or more target groups in order to handle the demand. The load balancer starts routing requests to a newly registered target as soon as the registration process completes and the target passes the initial health checks.

If demand on your application decreases, or you need to service your targets, you can deregister targets from your target groups. Deregistering a target removes it from your target group, but does not affect the target otherwise. The load balancer stops routing requests to a target as soon as it is deregistered. The target enters the draining state until in-flight requests have completed. You can register the target with the target group again when you are ready for it to resume receiving requests.

If you are registering targets by instance ID, you can use your load balancer with an Auto Scaling group. After you attach a target group to an Auto Scaling group, Auto Scaling registers your targets with the target group for you when it launches them.

Routing Algorithm:

By default, the round robin routing algorithm is used to route requests at the target group level. You can specify the least outstanding requests routing algorithm instead. Consider using least outstanding requests when the requests for your application vary in complexity or your targets vary in processing capability. Round robin is a good choice when the requests and targets are similar, or if you need to distribute requests equally among targets.

Deregistration Delay:

Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300 seconds before completing the deregistration process, which can help in-flight requests to the target to complete. To change the amount of time that Elastic Load Balancing waits, update the deregistration delay value.

Slow Start Mode:

By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check. Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests.

Sticky Sessions:

Sticky sessions are a mechanism to route requests to the same target in a target group. This is useful for servers that maintain state information in order to provide a continuous experience to clients. To use sticky sessions, the clients must support cookies.

Target Group Demo:

Step 1: Create a custom VPC for your ALB.

Step 2: Create two EC2 instances.

Step 3: Create your Application Load Balancer.

Step 4: Create a Target group with instances as targets.

Step 5: Create a target group with ip as targets.

Step 6: Create a target group with lambda as a target.

Application Load Balancer Target Groups

Step 7: Cleanup.

Hope you have enjoyed this article, In the next blog post, we will discuss Application Load Balancer health checks.

All the public cloud providers are changing the console user interface rapidly and due to this some of the screenshots used in our previous AWS blogs are no longer relevant. Hence, we have decided that from now onwards most of the demo will be done programmatically. Let us know your feedback on this in the comment section.

To get more details on AWS ELB, please refer below AWS documentation

https://docs.aws.amazon.com/elasticloadbalancing/index.html

 

Leave a Reply

Close Menu