Introducing Cross-Region Connectivity for AWS PrivateLink

This post was co-authored by: George Oakes, Senior Specialist Solutions Architect; Wafa Adeel, Senior Product Manager; and Devin Taylor, Senior Software Engineer

Overview

AWS PrivateLink offers a secure and simple way of sharing and accessing services across VPCs and accounts. All traffic stays on AWS network without going over the public internet. Until now the providers and consumers were required to be in the same AWS Region. With the launch of native cross-region connectivity for AWS PrivateLink, you can now share and access VPC endpoint services across different Regions. This helps service providers offer SaaS solutions privately to a global audience from a single Region. Consumers can simply use Interface endpoints to connect to cross-region enabled services, just as they would to services in the same Region. Cross-region connectivity over PrivateLink is simple, secure and customizable to fit a variety of use-cases.

This blog introduces how cross-region connectivity over AWS PrivateLink works and the controls you can use to secure your global data perimeter. It then demonstrates how you can establish end to end connectivity before diving into considerations and best practices to inform your architecture choices. Hereafter, the blog refers to VPC endpoint services as ‘services’, Interface VPC endpoints as ‘endpoints’ and AWS Regions as ‘regions’ for brevity.

Cross-Region Architecture

Today, many providers offer services in select regions but have consumers worldwide. Before this launch, consumers who wanted to access a service in another region had to setup inter-region VPC or Transit Gateway (TGW) peering. They were required to ensure that their networks didn’t have overlapping CIDRs, and had to establish guardrails to secure the network trust boundary. Alternatively, if providers wanted to expand their footprint to additional regions, they were required to provision additional infrastructure in each region. This added cost and complexity for both service providers and consumers

Figure 1: Previous topology diagram depicting the absence of native cross-region support

Figure 1 shows how consumers accessed services hosted outside their regions until now. Network Trust Boundary denotes the separation between the provider and the consumer. This may be a VPC, an account or an Organization boundary. To access the service, consumers were required to establish an inter-region VPC or TGW peering connection to a transit VPC in the provider region. They were then required to align their Availability Zones (AZs) in the transit VPC with those of the provider.

With this launch, PrivateLink abstracts away all this complexity and offers a simple, native cross-region connectivity experience for consumers and providers. Providers can simply enable cross-region connectivity to enable consumers from any region to access their services. Consumers can then use endpoints to connect to these remote services just as they connect to in-region services today.

Figure 2 shows an example of cross-region PrivateLink architecture. In contrast to chaining peering with in-region endpoints path shown above, cross-region connectivity does not require AZ alignment between service providers and consumers. Providers must use a minimum of two AZs to anchor the AWS Network Load Balancer (NLB) in the service region. Consumers can choose to create the Interface endpoint in as many AZs as required, although two or more AZs are recommended for high availability. This enables PrivateLink to dynamically weigh away traffic to a healthy AZ, transparent to the provider and consumer, in case of AZ impairment events in either region.

Figure 2: Simplified architecture example with cross-region PrivateLink

Controls for Cross-Region Access

PrivateLink’s cross-region connectivity is designed to be security first and offers defense in depth. Both the consumer and the provider must ensure that proper permissions are in place to share and access services across regions.

1. Opt into cross-region PrivateLink connectivity: While all PrivateLink actions so far were included in the ec2 namespace, cross-region actions are gated behind the new vpce:AllowMultiRegion permission-only action. Without opting into this permission, you will retain undisrupted in-region PrivateLink connectivity but sharing or accessing services across regions will fail.
2. Control cross-region access for services and endpoints: As a service provider or consumer, the ec2:VpceMultiRegion boolean key indicates whether a service has cross region connectivity enabled, or whether a VPC endpoint is connected to a PrivateLink service in another region. For example, this statement allows sharing and accessing services in the local region. It also lets you enable cross-region access to your services but denies creation of endpoints to remote services.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "allowserviceshareandcreateendpoint",
      "Action": [
        "ec2:CreateVpcEndpointServiceConfiguration",
        "ec2:DeleteVpcEndpointServiceConfigurations",
        "ec2:DescribeVpcEndpointServiceConfigurations",
        "ec2:ModifyVpcEndpointServiceConfiguration",
        "vpce:AllowMultiRegion",
        "ec2:CreateVpcEndpoint",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeVpcEndpoints",
        "ec2:ModifyVpcEndpoint"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Sid": "denycrossregionendpoint",
      "Action": [
        "ec2:CreateVpcEndpoint",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeVpcEndpoints",
        "ec2:ModifyVpcEndpoint"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
      "Condition": {
        "StringEquals": {
          "ec2:VpceMultiRegion": "true"
        }
      }
    }
  ]
}

      3. Define regions your service can be accessed from: As a service provider, the ec2:VpceSupportedRegion key helps you restrict the regions from which you can enable remote access. For example, this statement prevents sharing your service outside the N. Virginia and Ireland regions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "limitserviceshare",
      "Action": [
        "ec2:CreateVpcEndpointServiceConfiguration",
        "ec2:DeleteVpcEndpointServiceConfigurations",
        "ec2:DescribeVpcEndpointServiceConfigurations",
        "ec2:ModifyVpcEndpointServiceConfiguration",
        "vpce:AllowMultiRegion"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:ec2:*:*:vpc-endpoint-service/*",
      "Condition": {
        "ForAllValues:StringLike": {
          "ec2:VpceSupportedRegion": [
              "us-east-1",
              "eu-west-1"
          ]
        }
      }
    }
  ]
}

4. Define the regions you can access services from: As a consumer, the ec2:VpceServiceRegion key helps you define the remote service regions you can access via endpoints. For example, this statement blocks access to services hosted in Tokyo or Ireland.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "allowcrossregionendpoints",
      "Action": [
        "ec2:CreateVpcEndpoint",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeVpcEndpoints",
        "ec2:ModifyVpcEndpoint",
        "vpce:AllowMultiRegion"
      ],
      "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
      "Effect": "Allow"
    },
    {
      "Sid": "denyselectedregions",
      "Action": [
        "ec2:CreateVpcEndpoint"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
      "Condition": {
        "StringLike": {
          "ec2:VpceServiceRegion": [
            "ap-northeast-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

5. Opt-In Regions: Although most regions are active by default for your AWS account, regions launched after March 20, 2019 are activated only when you manually select them. These are referred to as opt-in Regions. When enabling access to services from opt-in regions, the service provider must opt into these regions. Similarly, when consumers want to access services hosted in an opt-in region, they must opt into the region first. This guardrail helps prevent accidental access to or from regions that are not permitted by your account.

Together these controls help you or your Organization establish a robust security perimeter. You can choose to opt in or out of cross-region connectivity without impacting your existing in-region PrivateLink operations. This helps you roll out the feature in a controlled manner, supporting legal and business needs for data localization.

Step By Step Setup

This section walks through the steps to create a service in N. Virginia and access it from Oregon. These steps assume your policy allows vpce:AllowMultiRegion and required AWS PrivateLink actions.

Service Provider Setup

Step 1: Create a PrivateLink service

You can enable cross-region access to new or existing NLB-based services. This setup assumes that your NLB and NLB targets are already operational. In the AWS VPC Console in N. Virginia region, select Endpoint Services, and then click on ‘Create endpoint service’. Select the load balancer type of ‘Network’ for NLB. Under the available load balancers, select the appropriate NLB. The ‘my-xrpl-svc’ here is created across 4 AZs of the N. Virginia region:

Step 2: Configure Supported Regions

Use the Supported Regions dropdown to select the regions from where consumers will be able to access your service. Enable access to this service from the Oregon, Singapore and Ireland regions. Note: this example deselects ‘Acceptance required’ and selects ‘IPv4’ in additional settings for simplicity. Your selections may vary based on your NLB and VPC configuration.

Step 3: Share Your Service

Once the service has been created, it may take a few minutes for the state to go from ‘Pending’ to ‘Available’ in each of the supported regions. Share the service name generated here with your consumers to help them discover the service. The remaining steps to setup and share your PrivateLink service remain the same as described in this blog. If you’re building your service using an Application Load Balancer (ALB), instructions are available here.

Service Consumer Setup

Step 1: Discover the PrivateLink service

As a consumer, you can access a service that has been shared with you, from any of its supported regions. In the AWS VPC Console, switch to the Oregon region. Then under PrivateLink and Lattice, click on Endpoints and then ‘Create endpoint’. Select ‘Endpoint Services that use NLBs and GWLBs’. Note that cross-region connectivity is only supported for NLB based services, and does not currently support AWS or Marketplace services.

Check the box under Service Region to ‘Enable Cross Region endpoint’ and specify the region the service is hosted in- N. Virginia in this example. Enter the service name generated in the final provider step above and click on ‘Verify service’. If a service with the provided name exists in the specified region and has permitted access to you, a ‘Service name verified’ message will be displayed. Here a VPC endpoint tagged ‘my-xrpl-consumer’ is created in Oregon, to connect to the service in N. Virginia.

Step 2: Create an Interface Endpoint

You must now select the VPC and subnets you want to create the VPC endpoint in. Cross-region connectivity does not require any AZ alignment, unlike in-region PrivateLink where the consumer can only create an endpoint in the AZs supported by the service provider. You can choose as many AZs as your resiliency posture requires and choose the subnets that best fit your needs.

Once the endpoint is created and enters ‘Available’ state, cross-region connectivity can be successfully established. You can see the configuration details as below.

Notice that there are multiple endpoint DNS names generated. The first DNS entry is the regional DNS name, followed by an entry for each endpoint AZ’s DNS name. This example used two AZs so there are a total of three DNS names. Using the regional DNS name for your application is recommended for better availability and resiliency. You can also enable Private DNS names on the endpoint to use a custom name to access the provider’s services. For more information in Private DNS, Subnets and AZs, see refer to section in the AWS PrivateLink User Guide.

Considerations

Providers

• There are no limits on how many regions you can enable access to a service from. However, you can only enable access from regions in the same partition.
• You can only enable cross-region access for NLB-based services. AWS services and Marketplace services are not supported at this time.
• You can revoke access to your service from a remote region by removing it from the supported regions list. This will prevent any new endpoints from accessing your service from the removed region, but existing endpoints will persist. If required, these endpoints must be manually rejected.

Consumers

• Cross-region connectivity is only supported for Interface type VPC endpoints.
• VPC endpoints to services in the local region or remote regions both count towards the ‘Interface VPC endpoints per VPC’ quota. you can see details and request a quota increase here.

Conclusion

As AWS expands its global footprint, cross-region support for AWS PrivateLink seamlessly connects your SaaS offering from one region to your customers across the globe. Both providers and consumers can opt into accessing each other privately, without having to setup infrastructure in the same regions.

Get started with AWS PrivateLink using the Endpoint Services and Endpoints options in the VPC console. For more information, refer to the AWS PrivateLink User Guide and the Securely Access Services Over AWS PrivateLink whitepaper.