Best practices for deployment with AWS Global Accelerator

Users everywhere expect stable, consistent, and high-performing applications, regardless of where an application is hosted. However, end users often experience variability and congestion over the public internet, which can be especially problematic when users are geographically distant from the application. These issues can be a major obstacle to providing your users with the online experience that they expect.

AWS Global Accelerator is a networking service that helps mitigate these challenges. This service improves availability and performance for internet-facing applications by onboarding your traffic to the fast, reliable AWS global network infrastructure. With Global Accelerator, your end users access your application with global static IP addresses to edge locations for the AWS network based on geographic location and application health, as well as routing policies that you can configure.

To help maximize Global Accelerator performance for your users, configure your accelerator in Global Accelerator to avoid connection collision issues that can cause network delays. In this post, we explain the scenarios that cause connection collisions and provide configurations and architectures that you can use to avoid them and the delays they can create.

Overview

Global Accelerator provides global static public IP addresses that act as a fixed entry point into your application endpoints, which are AWS resources such as Application Load Balancers, Network Load Balancers, Amazon Elastic Compute Cloud (Amazon EC2) instances, and Elastic IP addresses. You can enable client IP address preservation for most resources that you add as endpoints to Global Accelerator, including Network Load Balancers. In addition, using an accelerator with added support through security groups can increase your security inside an Amazon Virtual Private Cloud (VPC) by restricting access to your targeted endpoints.

When you deploy Global Accelerator, you can maximize performance for your users by being aware of, and configuring your accelerators to avoid scenarios that can lead to connection collisions. A connection collision is when a target endpoint sees concurrent connections from the same client IP address with the same source and destination ports. These collisions cause load balancers to drop the connection, resulting in network delays for users.

Using client IP address preservation

Before we look at best practices for avoiding connection collisions, it’s helpful to understand how Global Accelerator’s client IP address preservation feature works. When you create a new accelerator, you can configure it with client IP address preservation for supported endpoints: Application Load Balancers, EC2 instances, and Network Load Balancers with security groups. Global Accelerator identifies every connection by a 5-tuple: source IP address, source port, destination IP address, destination port, and protocol. When client IP address preservation is disabled, the source IP address in the 5-tuple becomes the Network Address Translation (NAT) IP address with Global Accelerator. With the client IP address preservation feature enabled, the source IP address is the actual client IP address.

As a customer, you can use client IP address preservation for several use cases. For example, you can meet security and compliance restrictions around client IP addresses, apply client-specific logic for IP address or location-based filters, gather connection statistics, or serve personalized content in your applications. However, when client IP address preservation is enabled, there are potential scenarios where Global Accelerator might perceive different connections as being identical because of the 5-tuple hashing mechanism.

In this post, we define the specific scenarios that create this situation and propose different architectural options that you can use to avoid them. Connection collisions can also occur when NAT routing is enabled for traffic to an accelerator. In the following sections, we describe methods that you can use to prevent connection collisions without having to disable client IP address preservation.

For more information on using client IP address preservation, see the Global Accelerator Developer Guide.

Connection collision scenarios

It’s not uncommon for customers to use one of the following architectures with Global Accelerator, each of which can lead to connection collisions and thus to connection time delays:

• Configuring the same load balancer as an endpoint with multiple (separate) accelerators
• Configuring load balancers as endpoints behind Global Accelerator while also sending traffic directly over the public internet from end users to the same load balancers
• Configuring load balancer with cross-zone traffic enabled as endpoints for accelerators

For each of these scenarios, you can follow the guidance provided here to avoid connection collisions.

Using the same load balancer as an endpoint with multiple accelerators

To avoid connection collisions when you have an architecture where you use the same resource as an endpoint with multiple accelerators, you can configure port overrides for the accelerators in Global Accelerator. With a port override, you can avoid port collisions by using different port mappings for accelerators’ listeners when the accelerators route to the same backend resource. After you set up the port mapping overrides, each accelerator uses a different destination port (on the same resource), so the 5-tuples that Global Accelerator uses for hashing are different and collisions are avoided.

Here’s how this works. An accelerator, by default, routes user traffic to endpoints using the protocol and port ranges that you specify when you create a listener for the accelerator. For example, if you specify that a listener for an accelerator accepts TCP traffic on ports 80 and 443, the accelerator automatically routes traffic to those same ports on its endpoints. However, you can remap the listener port that Global Accelerator uses to route traffic to endpoints by using port overrides. For example, you can create a port override so that a listener receives user traffic on ports 80 and 443, but the accelerator routes that traffic to ports 8080 and 8443, respectively, on its endpoints.

Let’s use a simple infrastructure example, shown in the following diagram (Figure 1), to illustrate how this works in practice. In this example, we’ll say that you have two accelerators, myTestAcceleratorA and myTestAcceleratorB, and a single Application Load Balancer resource.

Figure 1: Two accelerators configured to override the default port mappings for a target endpoint Application Load Balancer

To avoid connection collisions, configure port overrides for the listeners on the two accelerators, as shown in this diagram. Set up myTestAcceleratorA’s listener on port 443 to map to destination port 8443, and then set up myTestAcceleratorB’s listener on port 443 to map to destination port 9443. Finally, configure the Application Load Balancer endpoint to listen on ports 8443 and 9443.

Now, when traffic comes from one user with a single user IP address, incoming on port 443 for the listeners for both accelerators, it will arrive at the destination Application Load Balancer at the distinct destination port numbers without connection collisions. Because the port override maps the traffic to separate ports on the Application Load Balancer, the 5-tuple that Global Accelerator that uses for hashing has a different value, but traffic still arrives at the correct resource. For more information on how to configure port overrides, see Avoiding connection collisions that result in TCP connection time delays.

Making resources accessible through Global Accelerator and direct internet access

When customers add Global Accelerator to an existing architecture, it’s common to start by shifting a small amount of traffic to the service to test the new configuration. For example, you might create an accelerator, and then move just a little traffic to the global static IP addresses so that you can verify that everything’s working properly. However, during this testing phase, a client’s connection could enter your application from multiple paths directly from the public internet, using the existing architecture, and through the listener for the new accelerator. This can create connection collisions.

To prevent this, create a port override on the accelerator’s listener to remap the default port mapping. This is similar to the solution when you have one resource configured as an endpoint for two accelerators. As with that scenario, you will configure incoming traffic to arrive on an endpoint resource at two separate destination ports. When you map traffic to two different destination ports, traffic still arrives at the resource but the 5-tuple hash that Global Accelerator creates for each traffic stream is different since the destination ports are different. Different 5-tuple hashes prevent collisions between direct client traffic and traffic that arrives through the accelerator.

Let’s use another common setup to demonstrate how this works, as shown in the following diagram (Figure 2).

Figure 2: An accelerator configured with an Application Load Balancer endpoint where the Application Load Balancer is also accessible on the public internet

In our example, we have a public Application Load Balancer that has been added to an accelerator in Global Accelerator to improve performance. When the default destination port for the Application Load Balancer is used by both Global Accelerator and traffic arriving through the internet gateway, incoming traffic to the application looks the same, regardless of when it comes from Global Accelerator or directly from the public internet. To differentiate the traffic and prevent collisions for traffic coming from the same user and client IP address, we configure Global Accelerator to override the destination port (the Application Load Balancer’s listener port) on the load balancer for accelerator traffic from port 443 to port 8443. Then, we configure the load balancer to listen on port 8443 for accelerator traffic and port 443 for direct internet traffic.

Configuring client IP address preservation with cross-zone load balancing

When you enable client IP preservation in Global Accelerator for a Network Load Balancer endpoint that has cross-zone load balancing enabled, a client using an accelerator to access different IP addresses on the Network Load Balancer might be routed to the same target. If the client uses the same source port for both connections, the target will receive what appears to be a duplicate connection, which can lead to connection collisions errors and TCP delays in establishing new connections. To prevent this, you can disable cross-zone load balancing for the Network Load Balancer. Then, the client’s connections are routed to different targets, avoiding the potential for duplicate connections and the associated issues.

To learn more about network load balancers and cross-zone traffic, see the Network Load Balancer Network Load Balancer documentation.

Best practice: Replicate infrastructure with different paths

As best practice, instead of using port overrides to correct connection collision issues, you can change your application architecture to prevent the problem.

When you consider how to avoid or resolve connection collisions by modifying your architecture, there are different approaches that you might take, depending on your application and needs. For example, you might be exploring moving to a smaller infrastructure footprint, or you might need an infrastructure that supports ongoing A/B testing. Or, perhaps you want to create redundancy in your architecture so that you can more easily expand your infrastructure in the future.

Consider the following solutions to determine if these mitigations align with your business and technical paths.

• One way to mitigate potential connection collision issues is to replicate your infrastructure and then use two accelerators that direct traffic to redundant instances of your application. Not only does this resolve issues with connection collisions, but it enables you to easily run A/B testing for new features or application updates.
• Another way to mitigate connection collisions when you add Global Accelerator to an existing architecture is to create an additional endpoint that only traffic through the accelerator can reach. Just as with the scenario where you create two accelerators, you add a second Application Load Balancer to support client traffic, but here, you have a single accelerator. Depending on your application, you might use this additional Application Load Balancer with your existing backend stack. Alternatively, you might duplicate your application stack and temporarily have two redundant stacks during the migration period, each fronted by a different Application Load Balancer.

The following diagram (Figure 3) illustrates the first suggestion, where you have a configuration with two accelerators and two Application Load Balancers, and the Application Load Balancers each front separate, redundant application stacks.

Figure 3: Configuration with two accelerators and two Application Load Balancer endpoints, each targeting a redundant application replica

Summary

In this post, we identified scenarios where using Global Accelerator can lead to connection collisions and explained why this happens and how to mitigate it. We also provided guidance on how you might architect your application with Global Accelerator to prevent connection collisions. To begin using Global Accelerator with your AWS application, visit our getting started page today!

About the authors