Skip to content

Directing AWS Global Accelerator Traffic to a Secondary Network Interface of an EC2 Instance

3 minute read
Content level: Intermediate
0

A solution allowing AWS Global Accelerator users to direct traffic to secondary ENIs of EC2 instances.

Problem Statement

In some cases AWS Global Accelerator users need to direct traffic to specific elastic network interfaces (ENIs) on their EC2 instances, particularly when using multi-ENI configurations for network segmentation or specialized workloads. By default, AWS Global Accelerator routes traffic to the primary ENI of an EC2 instance when used as an accelerator endpoint. This means we require an alternate solution for those who want to direct traffic toward a secondary ENI attached to their EC2 instance endpoint.

Solution

To address this challenge, we can associate our secondary ENI IP address with a Network Load Balancer (NLB) target group and configure the NLB as an endpoint for an accelerator. With this configuration Global Accelerator routes traffic to the NLB, which then directs traffic to the target group containing the IP address of the required interface as shown in Figure 1 below.

Figure 1 - Architecture Diagram

The traffic flow is as follows:

  1. Client traffic enters through AWS Global Accelerator edge location
  2. AWS Global Accelerator routes traffic to the NLB endpoint
  3. NLB routes traffic to the Target Group
  4. Target Group directs traffic to the specified IP address of the secondary ENI on the EC2 instance

Considerations

When implementing this solution, it’s important to keep the following points in mind:

  • NLB Configuration: The NLB must be configured to use IP-based targets rather than instance-based targets [1].
  • Scalability: If using Auto Scaling groups, consider how to automatically register and de-register secondary ENI IP addresses with the NLB target group [2].
  • Cost: There are costs associated with the addition of an NLB [3].
  • Latency: While Global Accelerator generally improves latency, adding an NLB to the architecture may introduce a small amount of latency. It is recommended to test this solution to ensure it meets any latency requirements of your application [4].

Conclusion

By leveraging AWS Global Accelerator in conjunction with a Network Load Balancer, users can effectively direct traffic to secondary ENIs on their EC2 instances. This solution provides flexibility in network design and global traffic management, allowing for specialized configurations. While there are considerations to review, such as cost, latency, and scalability, this approach can be beneficial for customers with specific networking requirements.

Resources

[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type

[2] https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html

[3] https://aws.amazon.com/elasticloadbalancing/pricing/

[4] https://aws.amazon.com/blogs/networking-and-content-delivery/measuring-aws-global-accelerator-performance-and-analyzing-results/

1 Comment

This seems very clunky compared to just convincing the relevant AWS team to remove the restriction to only connect to some (publicly undefined!) concept of a "primary interface", which is obviously not the same as the interface with the "primary IPv6 address" (I just tried, and the AWS Global Accelerator just repeated the error that the instance has no "primary IPv6 elastic network interface" ).

replied 6 months ago