Networking & Content Delivery

Accessing private Application Load Balancers and EC2 instances through AWS Global Accelerator

Many Content Distribution Networks (CDNs) offer a feature to obfuscate the source origin through functionality commonly referred to as origin cloaking. Using AWS Global Accelerator with Client IP Address Preservation capability, similar functionally can be facilitated. Private Application Load Balancers (ALBs) and private EC2 instances can be accessed through Global Accelerator in a secure and simplified manner.

AWS Global Accelerator is an AWS service that improves global application availability and performance using the AWS global network. The Client IP Address Preservation feature allows you to make Global Accelerator the single internet-facing access point for your applications running in a single or multiple AWS Regions. The applications are centrally protected from distributed denial of service (DDoS) attacks through AWS Shield. You can also have greater control over how your end users reach your applications.

In this blog post, I dive into implementation best practices and walk through how to use client IP address preservation functionality in controlled environments. I also discuss ways to limit access in regulated or controlled environments where origin cloaking functionality might not be desirable.

How this functionality works in AWS Global Accelerator

The IP preservation functionally of AWS Global Accelerator is the key enabler for the origin cloaking capability. Jeff Barr’s blog post on IP preservation looks at how to implement this functionality for an Application Load Balancer (ALB).

Essentially an elastic network interface (ENI) is created within each AZ that contains the private ALB or private instances. Traffic flows from the AWS Global Accelerator elastic network interface to the backend instance or ALB. The connection is monitored and return traffic follows the same path back out over the AWS Global Accelerator elastic network interface. This traffic flow is depicted in the diagrams below for an ALB.

The data flow for private instances is very similar. This is shown in the diagram below.

In both data flows, the instances remain private with no route out to the internet. The Global Accelerator ENIs and instances are shown in the same subnet, but can be in multiple subnets if separate route tables are required for more granular control of traffic. The next section will go deeper into how we limit access to private VPC resources.

How we limit access to private VPC resources

To avoid internet traffic from inadvertently flowing into a private subnet, we require that an internet gateway is attached to the VPC that contains resources when a client address-preserving accelerator is created. The internet gateway does not need a route in the relevant subnet route table, or any subnet route table for that matter. The subnet essentially remains private (that is to say, no route to an internet gateway). This allows organization with traditional checks for IGWs to ensure that their network security perimeter is maintained and can still be audited.

The Global Accelerator ENIs that are created only allow traffic to and from AWS Global Accelerator service. They do not allow any type of broad access to the internet. They only allow inbound connections, even when the connections are logical only (for example, for UDP traffic). Access to an ALB or instance is further still governed by security groups and network access control lists (NACLs). NACLs and security groups provide granular control to allow traffic. With security groups, specific public IP addresses can be defined as allowed. Through the use of NACLs, traffic can also be explicitly denied access to specific outbound IP addresses.

For best practices in implementing IP client preservation with Global Accelerator, you can review the documentation here.

How to disable this functionality

We provide several options for customers that want to limit and control internet connectivity to their VPCs at an organizational level. AWS Organization supports Service Control Policies (SCPs). These allow policy to be applied at an organization unit (OU) level to govern access to AWS resources.

SCPs can be created to explicitly prevent any actions that would allow access from the internet. An example of such a policy is shown here. To prevent access to Global Accelerator from restricted accounts, the following actions should be denied in an SCP: globalaccelerator:Create* and globalaccelerator:Update*.


IP address source preservation with Global Accelerator opens up new capabilities for deploying global applications. Origins can be cloaked behind Global Accelerator to allow a single access point that is exposed to the internet.