Integrations for your Application Load Balancer

You can optimize your Application Load Balancer architecture by integrating with several other AWS services to enhance the performance, security, and availability of your application.

Amazon Application Recovery Controller (ARC)

Amazon Application Recovery Controller (ARC) helps you prepare for and accomplish faster recovery operations for applications running on AWS. Zonal shift and zonal autoshift are features of Amazon Application Recovery Controller (ARC).

With zonal shift, you can shift traffic away from an impaired Availability Zone with a single action. This way, you can continue operating from other healthy Availability Zones in an AWS Region.

With zonal autoshift, you authorize AWS to shift away resource traffic for an application from an Availability Zone during events, on your behalf, to help reduce time to recovery. AWS starts an autoshift when internal monitoring indicates that there is an Availability Zone impairment that could potentially impact customers. When AWS starts an autoshift, application traffic to resources that you've configured for zonal autoshift starts shifting away from the Availability Zone.

When you start a zonal shift, your load balancer stops sending new traffic for the resource to the affected Availability Zone. ARC creates the zonal shift immediately. However, it can take a short time for existing, in-progress connections in the Availability Zone to complete, depending on client behavior and connection reuse. Depending on your DNS settings and other factors, existing connections can complete in just a few minutes, or might take longer. For more information, see Limit the time that clients stay connected to your endpoints in the Amazon Application Recovery Controller (ARC) Developer Guide.

To use zonal shift features on Application Load Balancers, you must have the ARC zonal shift integration attribute set to Enabled.

Before you enable the Amazon Application Recovery Controller (ARC) integration and start utilizing zonal shift, review the following:

• You can start a zonal shift for a specific load balancer only for a single Availability Zone. You can't start a zonal shift for multiple Availability Zones.

• AWS proactively removes zonal load balancer IP addresses from DNS when multiple infrastructure issues impact services. Always check current Availability Zone capacity before you start a zonal shift. If your load balancers have cross-zone load balancing turned off and you use a zonal shift to remove a zonal load balancer IP address, the Availability Zone affected by the zonal shift also loses target capacity.

• When an Application Load Balancer is a target of a Network Load Balancer, always start the zonal shift from the Network Load Balancer. If you start a zonal shift from the Application Load Balancer, the Network Load Balancer doesn't recognize the shift and continues to send traffic to the Application Load Balancer.

For more information, see Best practices for zonal shifts in ARC in the Amazon Application Recovery Controller (ARC) Developer Guide.

Cross-zone enabled Application Load Balancers

When a zonal shift is started on an Application Load Balancer with cross-zone load balancing enabled, all traffic to targets is blocked in the availability zone being impacted, and zonal IP addresses are removed from DNS.

Benefits:

• Quicker recovery from availability zone failures.

• The ability to move traffic to a healthy availability zone if failures are detected in an availability zone.

• You can test application integrity by simulating and identifying failures to prevent unplanned downtime.

Zonal shift administrative override

Targets that belong to a Application Load Balancer will include a new status AdministrativeOverride, which is independent from the TargetHealth state.

When a zonal shift is started for a Application Load Balancer, all targets within the zone being shifted away from are considered administratively overridden. The Application Load Balancer will stop routing new traffic to the administratively overridden targets, however existing connections remain intact until they are organically closed.

The possible AdministrativeOverride states are:

unknown

State cannot be propagated due to an internal error

no_override

No override is currently active on target

zonal_shift_active

Zonal shift is active in target Availability Zone

Amazon CloudFront + AWS WAF

Amazon CloudFront is a web service that helps improve the performance, availability, and security of your applications that use AWS. CloudFront acts as a distributed, single point of entry for your web applications that use Application Load Balancers. It extends your Application Load Balancer's reach globally, allowing it to serve users efficiently from nearby edge locations, optimizing content delivery and reducing latency for users worldwide. The automatic content caching at these edge locations significantly reduces the load on your Application Load Balancer, improving its performance and scalability.

The one-click integration available in the Elastic Load Balancing console creates a CloudFront distribution with the recommended AWS WAF security protections, and associates it to your Application Load Balancer. The AWS WAF protections block against common web exploits before reaching your load balancer. You can access the CloudFront distribution and its corresponding security dashboard from the load balancer’s Integrations tab in the console. For more information, see Manage AWS WAF security protections in the CloudFront security dashboard in the Amazon CloudFront Developer Guide and Introducing CloudFront Security Dashboard, a Unified CDN and Security Experience at aws.amazon.com/blogs.

As a security best practice, configure your internet-facing Application Load Balancer's security groups to allow inbound traffic only from the AWS-managed prefix list for CloudFront, and remove any other inbound rules. For more information, see Use the CloudFront managed prefix list, Configure CloudFront to add a custom HTTP header to requests and Configure an Application Load Balancer to only forward requests that contain a specific header in the Amazon CloudFront Developer Guide>.

Note

CloudFront only supports ACM certificates in the US East (N. Virginia) us-east-1 region. If your Application Load Balancer has an HTTPS listener configured with an ACM certificate in a region other than us-east-1, you will need to either change the CloudFront origin connection from HTTPS to HTTP, or provision an ACM certificate in the US East (N. Virginia) region and attach it to your CloudFront distribution.

AWS Global Accelerator

To optimize application availability, performance, and security, create an accelerator for your load balancer. The accelerator directs traffic over the AWS global network to static IP addresses that serve as fixed endpoints in the nearest Region to the client. AWS Global Accelerator is protected by Shield Standard, which minimizes application downtime and latency from DDoS attacks.

For more information, see Adding an accelerator when you create a load balancer in the AWS Global Accelerator Developer Guide.

AWS Config

To optimize monitoring and compliance of your load balancer, set up AWS Config. AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time. AWS Config streamlines audits, compliance, and troubleshooting.

For more information, see What Is AWS Config? in the AWS Config Developer Guide.

AWS WAF

You can use AWS WAF with your Application Load Balancer to allow or block requests based on the rules in a web access control list (web ACL).

By default, if the load balancer cannot get a response from AWS WAF, it returns an HTTP 500 error and does not forward the request. If you need your load balancer to forward requests to targets even if it is unable to contact AWS WAF, you can enable AWS WAF fail open.

Pre-defined web ACLs

When enabling AWS WAF integration you can choose to automatically create a new web ACL with pre-defined rules. The pre-defined web ACL includes three AWS managed rules which offer protections against the most common security threats.

• AWSManagedRulesAmazonIpReputationList ‐ The Amazon IP reputation list rule group blocks IP addresses typically associated with bots or other threats. For more information, see Amazon IP reputation list managed rule group in the AWS WAF Developer Guide.

• AWSManagedRulesCommonRuleSet ‐ The core rule set (CRS) rule group provides protection against exploitation of a wide range of vulnerabilities, including some of the high risk and commonly occurring vulnerabilities described in OWASP publications such as OWASP Top 10. For more information, see Core rule set (CRS) managed rule group in the AWS WAF Developer Guide.

• AWSManagedRulesKnownBadInputsRuleSet ‐ The Known bad inputs rule group blocks request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities. For more information, see Known bad inputs managed rule group in the AWS WAF Developer Guide.

For more information, see Using web ACLs in AWS WAF in the AWS WAF Developer Guide.