advertisement
Elastic Load Balancing Application Load Balancers
Routing Configuration
Target Groups for Your Application
Load Balancers
Each target group is 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 create different target groups for different types of requests. For example, create one target group for general requests and other target groups for
.
You 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. After you specify a target group in a rule for a listener, the load balancer continually monitors the health of all targets registered with the target group that are in an Availability
Zone enabled for the load balancer. The load balancer routes requests to the registered targets that are healthy.
Contents
•
•
•
•
Target Group Attributes (p. 39)
•
•
•
•
Health Checks for Your Target Groups (p. 41)
•
Register Targets with Your Target Group (p. 44)
•
Tags for Your Target Group (p. 47)
•
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
If a target group is configured with the HTTPS protocol or uses HTTPS health checks, SSL connections to the targets use the security settings from the ELBSecurityPolicy2016-08 policy.
37
Elastic Load Balancing Application Load Balancers
Target Type
Target Type
When you create a target group, you specify its target type, which determines how you specify its targets. 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 specified by IP address.
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 peered 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.
Important
You can't specify publicly routable IP addresses.
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. Note that each network interface can have its own security group.
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.
38
Elastic Load Balancing Application Load Balancers
Target Group Attributes
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. For more information, see Attaching a Load Balancer to
Your Auto Scaling Group in the Amazon EC2 Auto Scaling User Guide.
Target Group Attributes
The following are the target group attributes: deregistration_delay.timeout_seconds
The amount of time for Elastic Load Balancing to wait before deregistering a target. The range is
0-3600 seconds. The default value is 300 seconds.
stickiness.enabled
Indicates whether sticky sessions are enabled.
stickiness.lb_cookie.duration_seconds
The cookie expiration period, in seconds. After this period, the cookie is considered stale. The minimum value is 1 second and the maximum value is 7 days (604800 seconds). The default value is
1 day (86400 seconds).
stickiness.type
The type of stickiness. The possible value is lb_cookie.
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 inflight requests to the target to complete. To change the amount of time that Elastic Load Balancing waits, update the deregistration delay value. Note that you can specify a value of up to 1 hour, and that
Elastic Load Balancing waits the full amount of time specified, regardless of whether there are in-flight requests.
If a deregistering target terminates the connection before the deregistration delay elapses, the client receives a 500-level error response.
The initial state of a deregistering target is draining. After the deregistration delay elapses, the deregistration process completes and the state of the target is unused. If the target is part of an Auto
Scaling group, it can be terminated and replaced. However, connections between load balancer nodes and a deregistering target are kept for up to one hour if there are in-flight requests.
To update the deregistration delay value using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under
LOAD BALANCING, choose Target Groups.
3. Select the target group.
4. On the Description tab, choose Edit attributes.
5. On the Edit attributes page, change the value of Deregistration delay as needed, and then choose
Save.
To update the deregistration delay value using the AWS CLI
39
Elastic Load Balancing Application Load Balancers
Sticky Sessions
Use the modify-target-group-attributes command.
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.
When a load balancer first receives a request from a client, it routes the request to a target and generates a cookie to include in the response to the client. The next request from that client contains the cookie. If sticky sessions are enabled for the target group and the request goes to the same target group, the load balancer detects the cookie and routes the request to the same target.
Application Load Balancers support load balancer-generated cookies only. The name of the cookie is
AWSALB. The contents of these cookies are encrypted using a rotating key. You cannot decrypt or modify load balancer-generated cookies.
WebSockets connections are inherently sticky. If the client requests a connection upgrade to
WebSockets, the target that returns an HTTP 101 status code to accept the connection upgrade is the target used in the WebSockets connection. After the WebSockets upgrade is complete, cookie-based stickiness is not used.
You enable sticky sessions at the target group level. You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds. The duration is set with each request. Therefore, if the client sends a request before each duration period expires, the sticky session continues. If you enable sticky sessions on multiple target groups, we recommend that you configure the same duration for all target groups.
To enable sticky sessions using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select the target group.
4. On the Description tab, choose Edit attributes.
5. On the Edit attributes page, do the following: a. Select Enable load balancer generated cookie stickiness.
b. For Stickiness duration, specify a value between 1 second and 7 days.
c.
Choose Save.
To enable sticky sessions using the AWS CLI
Use the modify-target-group-attributes command.
Create a Target Group
You register your targets with a target group. By default, the load balancer sends requests to registered targets using the port and protocol that you specified for the target group. You can override this port when you register each target with the target group.
After you create a target group, you can add tags.
To route traffic to the targets in a target group, specify the target group in an action when you create a listener or create a rule for your listener. For more information, see
40
Elastic Load Balancing Application Load Balancers
Configure Health Checks
You can add or remove targets from your target group at any time. For more information, see
Targets with Your Target Group (p. 44)
. You can also modify the health check settings for your target group. For more information, see
Modify the Health Check Settings of a Target Group (p. 44) .
To create a target group using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Choose Create target group.
4. For Target group name, type a name for the target group.
5. (Optional) For Protocol and Port, modify the default values as needed.
6. For Target type, select instance to specify targets by instance ID or ip to specify targets by IP address.
7. For VPC, select a virtual private cloud (VPC).
8. (Optional) For Health check settings and Advanced health check settings, modify the default settings as needed.
9. Choose Create.
10. (Optional) Add one or more tags as follows: a. Select the newly created target group.
b. On the Tags tab, choose Add/Edit Tags.
c.
On the Add/Edit Tags page, for each tag you add, choose Create Tag and then specify the tag key and tag value. When you have finished adding tags, choose Save.
11. (Optional) To add targets to the target group, see
Register Targets with Your Target Group (p. 44)
.
To create a target group using the AWS CLI
Use the create-target-group command to create the target group, the add-tags command to tag your target group, and the register-targets command to add targets.
Health Checks for Your Target Groups
Your Application Load Balancer periodically sends requests to its registered targets to test their status.
These tests are called health checks.
Each load balancer node routes requests only to the healthy targets in the enabled Availability Zones for the load balancer. Each load balancer node checks the health of each target, using the health check settings for the target group with which the target is registered. After your target is registered, it must pass one health check to be considered healthy. After each health check is completed, the load balancer node closes the connection that was established for the health check.
If no Availability Zone contains a healthy target, the load balancer nodes route requests to all targets.
41
Elastic Load Balancing Application Load Balancers
Health Check Settings
Note that health checks do not support WebSockets.
Health Check Settings
You configure health checks for the targets in a target group using the following settings. The load balancer sends a health check request to each registered target every
HealthCheckIntervalSeconds
seconds, using the specified port, protocol, and ping path. It waits for the target to respond within the response timeout period. If the health checks exceed the threshold for consecutive failed responses, the load balancer takes the target out of service. When the health checks exceed the threshold for consecutive successful responses, the load balancer puts the target back in service.
Setting
HealthCheckProtocol
HealthCheckPort
HealthCheckPath
HealthCheckTimeoutSeconds
HealthCheckIntervalSeconds
HealthyThresholdCount
UnhealthyThresholdCount
Matcher
Description
The protocol the load balancer uses when performing health checks on targets. The possible protocols are HTTP and HTTPS. The default is the
HTTP protocol.
The port the load balancer uses when performing health checks on targets. The default is to use the port on which each target receives traffic from the load balancer.
The ping path that is the destination on the targets for health checks. The default is /.
The amount of time, in seconds, during which no response from a target means a failed health check. The range is 2 to 60 seconds. The default is
5 seconds.
The approximate amount of time, in seconds, between health checks of an individual target.
The range is 5 to 300 seconds. The default is 30 seconds.
The number of consecutive successful health checks required before considering an unhealthy target healthy. The range is 2 to 10. The default is
5.
The number of consecutive failed health checks required before considering a target unhealthy.
The range is 2 to 10. The default is 2.
The HTTP codes to use when checking for a successful response from a target. You can specify values or ranges of values between 200 and 499.
The default value is 200.
Target Health Status
Before the load balancer sends a health check request to a target, you must register it with a target group, specify its target group in a listener rule, and ensure that the Availability Zone of the target is enabled for the load balancer. Before a target can receive requests from the load balancer, it must pass the initial health checks. After a target passes the initial health checks, its status is Healthy.
42
Elastic Load Balancing Application Load Balancers
Health Check Reason Codes
The following table describes the possible values for the health status of a registered target.
Value
initial healthy unhealthy unused draining
Description
The load balancer is in the process of registering the target or performing the initial health checks on the target.
The target is healthy.
The target did not respond to a health check or failed the health check.
The target is not registered with a target group, the target group is not used in a listener rule for the load balancer, or the target is in an Availability Zone that is not enabled for the load balancer.
The target is deregistering and connection draining is in process.
Health Check Reason Codes
If the status of a target is any value other than Healthy, the API returns a reason code and a description of the issue, and the console displays the same description in a tooltip. Note that reason codes that begin with Elb originate on the load balancer side and reason codes that begin with Target originate on the target side.
Reason code Description
Elb.InitialHealthChecking
Initial health checks in progress
Elb.InternalError
Elb.RegistrationInProgress
Health checks failed due to an internal error
Target registration is in progress
Target.DeregistrationInProgress Target deregistration is in progress
Target.FailedHealthChecks
Health checks failed
Target.InvalidState
Target is in the stopped state
Target is in the terminated state
Target is in the terminated or stopped state
Target.IpUnusable
Target.NotInUse
Target.NotRegistered
Target is in an invalid state
The IP address cannot be used as a target, as it is in use by a load balancer.
Target group is not configured to receive traffic from the load balancer
Target is in an Availability Zone that is not enabled for the load balancer
Target is not registered to the target group
43
Elastic Load Balancing Application Load Balancers
Check the Health of Your Targets
Reason code
Target.ResponseCodeMismatch
Target.Timeout
Description
Health checks failed with these codes: [code]
Request timed out
Check the Health of Your Targets
You can check the health status of the targets registered with your target groups.
To check the health of your targets using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select the target group.
4. On the Targets tab, the Status column indicates the status of each target.
5. If the status is any value other than Healthy, view the tooltip for more information.
To check the health of your targets using the AWS CLI
Use the describe-target-health command. The output of this command contains the target health state, and it includes a reason code if the status is any value other than Healthy.
Modify the Health Check Settings of a Target Group
You can modify the health check settings for your target group at any time.
To modify the health check settings of a target group using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select the target group.
4. On the Health checks tab, choose Edit.
5. On the Edit target group page, modify the settings as needed, and then choose Save.
To modify the health check settings of a target group using the AWS CLI
Use the modify-target-group command.
Register Targets with Your Target Group
You register your targets with a target group. You can register targets by instance ID or by IP address. For more information, see
Target Groups for Your Application Load Balancers (p. 37)
.
If demand on your currently registered targets increases, you can register additional targets in order to handle the demand. When your target is ready to handle requests, register it with your target group. The load balancer starts routing requests to the target as soon as the registration process completes and the target passes the initial health checks.
If demand on your registered targets decreases, or you need to service a target, you can deregister it from your target group. The load balancer stops routing requests to a target as soon as you deregister it.
When the target is ready to receive requests, you can register it with the target group again.
44
Elastic Load Balancing Application Load Balancers
Target Security Groups
When you deregister a target, the load balancer waits until in-flight requests have completed. This is known as connection draining. The status of a target is draining while connection draining is in progress.
When you deregister a target that was registered by IP address, you must wait for the deregistration delay to complete before you can register the same IP address again.
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 and the group scales out, the instances launched by the Auto Scaling group are automatically registered with the target group. If you detach the target group from the Auto Scaling group, the instances are automatically deregistered from the target group. For more information, see Attaching a Load Balancer to Your Auto Scaling Group in the Amazon
EC2 Auto Scaling User Guide.
Target Security Groups
When you register EC2 instances as targets, you must ensure that the security groups for your instances allow the load balancer to communicate with your instances on both the listener port and the health check port.
Recommended Rules
Inbound
Source
load balancer security group load balancer security group
Port Range Comment
instance listener
Allow traffic from the load balancer on the instance listener port
health check
Allow traffic from the load balancer on the health check port
We also recommend that you allow inbound ICMP traffic to support Path MTU Discovery. For more information, see Path MTU Discovery in the Amazon EC2 User Guide for Linux Instances.
Register or Deregister Targets
When you create a target group, you specify whether you must register targets by instance ID or IP address.
Tasks
•
Register or Deregister Targets by Instance ID (p. 45)
•
Register or Deregister Targets by IP Address (p. 46)
•
Register or Deregister Targets Using the AWS CLI (p. 47)
Register or Deregister Targets by Instance ID
The instance must be in the virtual private cloud (VPC) that you specified for the target group. The instance must also be in the running state when you register it.
To register or deregister targets by instance ID
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
45
Elastic Load Balancing Application Load Balancers
Register or Deregister Targets
3. Select your target group.
4. On the Targets tab, choose Edit.
5. To register instances, select them from Instances, modify the default instance port as needed, and choose Add to registered.
6. To deregister instances, select them from Registered instances and choose Remove.
7. Choose Save.
Register or Deregister Targets by IP Address
The IP addresses that you register must be from the subnets of the VPC for the target group, the RFC
1918 range (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and the RFC 6598 range (100.64.0.0/10).
You cannot register publicly routable IP addresses.
To register or deregister targets by IP address
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select your target group.
4. On the Targets tab, choose Edit.
5. To register IP addresses, choose the Register targets icon (the plus sign) in the menu bar. For each IP address, select the network, type the IP address, type the port, and choose Add to list. When you are finished specifying addresses, choose Register.
46
Elastic Load Balancing Application Load Balancers
Update Tags
6. To deregister IP addresses, choose the Deregister targets icon (the minus sign) in the menu bar. If you have many registered IP addresses, you might find it helpful to add a filter or change the sort order. Select the IP addresses and then choose Deregister.
7. To leave this screen, choose the
Back to target group icon (the back button) in the menu bar.
Register or Deregister Targets Using the AWS CLI
Use the register-targets command to add targets and the deregister-targets command to remove targets.
Tags for Your Target Group
Tags help you to categorize your target groups in different ways, for example, by purpose, owner, or environment.
You can add multiple tags to each target group. Tag keys must be unique for each target group. If you add a tag with a key that is already associated with the target group, it updates the value of that tag.
When you are finished with a tag, you can remove it.
Restrictions
• Maximum number of tags per resource—50
• Maximum key length—127 Unicode characters
• Maximum value length—255 Unicode characters
• Tag keys and values are case sensitive. Allowed characters are letters, spaces, and numbers representable in UTF-8, plus the following special characters: + - = . _ : / @. Do not use leading or trailing spaces.
• Do not use the aws: prefix in your tag names or values because it is reserved for AWS use. You can't edit or delete tag names or values with this prefix. Tags with this prefix do not count against your tags per resource limit.
To update the tags for a target group using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select the target group.
47
Elastic Load Balancing Application Load Balancers
Delete a Target Group
4. On the Tags tab, choose Add/Edit Tags, and then do one or more of the following: a. To update a tag, edit the values of
Key and Value.
b. To add a new tag, choose Create Tag and then type values for Key and Value.
c.
To delete a tag, choose the delete icon (X) next to the tag.
5. When you have finished updating tags, choose Save.
To update the tags for a target group using the AWS CLI
Use the add-tags and remove-tags commands.
Delete a Target Group
You can delete a target group if it is not referenced by any actions. Note that deleting a target group does not affect the targets registered with the target group. If you no longer need a registered EC2 instance, you can stop or terminate it.
To delete a target group using the console
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ .
2. On the navigation pane, under LOAD BALANCING, choose Target Groups.
3. Select the target group, and then choose Actions, Delete.
4. When prompted for confirmation, choose Yes.
To delete a target group using the AWS CLI
Use the delete-target-group command.
48
advertisement
advertisement
Table of contents
- 1 Elastic Load Balancing
- 3 Table of Contents
- 6 What Is an Application Load Balancer?
- 6 Application Load Balancer Components
- 6 Application Load Balancer Overview
- 7 Benefits of Migrating from a Classic Load Balancer
- 7 How to Get Started
- 7 Pricing
- 7 Getting Started with Application Load Balancers
- 8 Before You Begin
- 8 Step 1: Select a Load Balancer Type
- 9 Step 2: Configure Your Load Balancer and Listener
- 9 Step 3: Configure a Security Group for Your Load Balancer
- 9 Step 4: Configure Your Target Group
- 10 Step 5: Register Targets with Your Target Group
- 10 Step 6: Create and Test Your Load Balancer
- 10 Step 7: Delete Your Load Balancer (Optional)
- 12 Tutorials for Application Load Balancers
- 12 Tutorial: Use Path-Based Routing with Your Application Load Balancer
- 12 Before You Begin
- 12 Create Your Load Balancer
- 14 Tutorial: Use Microservices as Targets with Your Application Load Balancer
- 14 Before You Begin
- 15 Create Your Load Balancer
- 16 Tutorial: Create an Application Load Balancer Using the AWS CLI
- 16 Before You Begin
- 16 Create Your Load Balancer
- 17 Add an HTTPS Listener
- 18 Add Targets Using Port Overrides
- 18 Add Path-Based Routing
- 19 Delete Your Load Balancer
- 20 Application Load Balancers
- 20 Load Balancer Security Groups
- 20 Load Balancer State
- 21 Load Balancer Attributes
- 21 IP Address Type
- 21 Deletion Protection
- 22 Connection Idle Timeout
- 23 Application Load Balancers and AWS WAF
- 23 Create an Application Load Balancer
- 9 Step 1: Configure a Load Balancer and a Listener
- 24 Step 2: Configure Security Settings for an HTTPS Listener
- 24 Step 3: Configure a Security Group
- 9 Step 4: Configure a Target Group
- 25 Step 5: Configure Targets for the Target Group
- 25 Step 6: Create the Load Balancer
- 26 Availability Zones for Your Application Load Balancer
- 26 Security Groups for Your Application Load Balancer
- 26 Recommended Rules
- 27 Update the Associated Security Groups
- 28 IP Address Types for Your Application Load Balancer
- 28 Tags for Your Application Load Balancer
- 29 Delete an Application Load Balancer
- 30 Listeners for Your Application Load Balancers
- 30 Listener Configuration
- 30 Listener Rules
- 31 Default Rules
- 31 Rule Priority
- 31 Rule Actions
- 31 Rule Conditions
- 31 Host Conditions
- 32 Path Conditions
- 32 Create a Listener for Your Application Load Balancer
- 33 Prerequisites
- 33 Add a Listener
- 33 HTTPS Listeners for Your Application Load Balancer
- 34 SSL Certificates
- 34 Security Policies
- 36 Update the Security Policy
- 36 Listener Rules for Your Application Load Balancer
- 36 Prerequisites
- 36 Add a Rule
- 37 Edit a Rule
- 38 Reorder Rules
- 39 Delete a Rule
- 39 Update Server Certificates
- 40 Add Certificates
- 40 Replace the Default Certificate
- 41 Remove Certificates
- 41 Delete a Listener for Your Application Load Balancer
- 42 Target Groups for Your Application Load Balancers
- 42 Routing Configuration
- 43 Target Type
- 43 Registered Targets
- 44 Target Group Attributes
- 44 Deregistration Delay
- 45 Sticky Sessions
- 45 Create a Target Group
- 46 Health Checks for Your Target Groups
- 47 Health Check Settings
- 47 Target Health Status
- 48 Health Check Reason Codes
- 49 Check the Health of Your Targets
- 49 Modify the Health Check Settings of a Target Group
- 49 Register Targets with Your Target Group
- 50 Target Security Groups
- 50 Register or Deregister Targets
- 50 Register or Deregister Targets by Instance ID
- 51 Register or Deregister Targets by IP Address
- 52 Register or Deregister Targets Using the AWS CLI
- 52 Tags for Your Target Group
- 53 Delete a Target Group
- 54 Monitor Your Application Load Balancers
- 54 CloudWatch Metrics for Your Application Load Balancer
- 55 Application Load Balancer Metrics
- 59 Metric Dimensions for Application Load Balancers
- 60 Statistics for Application Load Balancer Metrics
- 60 View CloudWatch Metrics for Your Load Balancer
- 62 Access Logs for Your Application Load Balancer
- 62 Access Log Files
- 63 Access Log Entries
- 64 Syntax
- 65 Examples
- 66 Bucket Permissions
- 69 Enable Access Logging
- 70 Disable Access Logging
- 70 Processing Access Log Files
- 70 Request Tracing for Your Application Load Balancer
- 71 Syntax
- 71 Limitations
- 72 AWS CloudTrail Logging for Your Application Load Balancer
- 72 Enable CloudTrail Event Logging
- 73 Elastic Load Balancing Event Records in CloudTrail Log Files
- 75 Troubleshoot Your Application Load Balancers
- 75 A registered target is not in service
- 76 Clients cannot connect to an Internet-facing load balancer
- 76 The load balancer sends requests to unhealthy targets
- 76 The load balancer generates an HTTP error
- 76 HTTP 400: Bad Request
- 76 HTTP 403: Forbidden
- 77 HTTP 460
- 77 HTTP 463
- 77 HTTP 502: Bad Gateway
- 77 HTTP 503: Service Unavailable
- 77 HTTP 504: Gateway Timeout
- 77 A target generates an HTTP error
- 78 Limits for Your Application Load Balancers
- 79 Document History for Application Load Balancers