AWS PrivateLink extends cross-region connectivity to AWS services

AWS announced the launch of cross-region PrivateLink (XRPL) connectivity to AWS services. You can now use interface VPC endpoints to privately and securely connect to AWS services in other Regions of the Commercial partition. In this post, we discuss potential use cases, getting started and access control options for cross-region connectivity.

Overview

AWS PrivateLink provides a secure, simple way to share and access services across VPCs and accounts. You can access VPC endpoint services from private subnets without an Internet Gateway – your traffic stays on the AWS backbone. You can secure endpoints with security groups and VPC endpoint policies.

Previously, PrivateLink only supported intra-region connectivity, requiring service providers and consumers to be in the same AWS Region. At re:Invent 2024, AWS launched support for cross-region connectivity to VPC Endpoint (VPCE) services that were not Amazon managed.

With today’s announcement, PrivateLink has extended cross-region connectivity to Amazon managed services in the Commercial partition. You can now access services hosted in other XRPL-supported Regions, natively over an interface endpoint, without the need to manage inter-region connectivity like VPC peering or resorting to the public internet. This feature supports endpoint policies, introduces new access control mechanisms to ensure cross-region connectivity meets your organizational policies, and simplifies building regional controls for your data.

Use cases

This feature extends core PrivateLink benefits of simplicity and security from intra-region to inter-region connectivity. Whether you’re accessing VPCE services in the same region or another, the implementation and security posture remains consistent. While most AWS services are available in all Regions, you may want to access services in a different Region for use cases below:

• You need to access resources shared by a third-party provider in another Region. For example, you’re building a modeling tool in US East (N. Virginia) that is trained on various datasets, in-house and external. Your model needs access to datasets vended by one of your data-aggregators, through an Amazon Simple Storage Service (S3) bucket in the Africa (Cape Town) Region.
• You are a multinational financial corporation that operates in a country with strict data residency requirements. All data from consumers in the country must be stored in an AWS Region within the country. Your forex workflows hosted in another Region need transient access to user metadata to authorize transactions.
• You are a SaaS provider with globally distributed infrastructure, that wants to stream monitoring data to a central data lake in Ireland. This data is used to power a near-real-time dashboard for global health monitoring.
• You have critical workloads in Oregon that require undisrupted connectivity to Amazon Data Firehose. You have a primary VPCE to Firehose in US West (Oregon), with a secondary VPCE to Firehose in US East (Ohio). Your workloads are configured to fail over to Ohio in case of connectivity issues in Oregon.

Controls for cross-region access

Before you can start using the cross-region connectivity feature, you must ensure you have the right permissions in place.

1. [Required] Opt into the cross-region PrivateLink connectivity feature: So far, all PrivateLink actions have been part of the Amazon Elastic Compute Cloud (EC2) namespace. However, the cross-region connectivity feature is gated by the vpce:AllowMultiRegion permission-only action, in the different VPCE namespace. Without this permission, you will be able to create VPC endpoints to AWS services in your local Region, but not to AWS or VPCE services in other Regions.
   Make sure your identity policy allows vpce:AllowMultiRegion and your service control policy (SCP) does not deny it. Both policies must be configured correctly to enable the cross-region connectivity feature.
2. [Required] 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. AWS refers to these as opt-in Regions. When you want to access AWS services hosted in an opt-in Region over PrivateLink, you must opt into the Region first. This guardrail helps prevent accidental access to or from Regions that are not permitted by your account.

Getting started

Service discovery

After you configure the required permissions, use the AWS Management Console to discover AWS services that can support cross-region connectivity. Go to the VPC Console and select Endpoints in the navigation pane, then click on Create endpoint shown in Figure 1.

Figure 1: AWS Console for creation of VPC Endpoint

Select ‘AWS services’ for Type and then select the Enable Cross Region endpoint checkbox. You should now be able to select the Service Region that you want to connect to, from the drop down menu.

The Services tab will then show all AWS services in that region that are supported over cross-region PrivateLink connectivity feature, as shown below in Figure 2.

Figure 2: AWS Console UI for configuring Cross Region PrivateLink

To discover services using the CLI, use the describe-vpc-endpoint-services command with the service-region filter set to the Region which you want to access services from. The following example lists all AWS services in US East (Ohio), that can be accessed over VPC endpoints in US West (Oregon).

aws ec2 describe-vpc-endpoint-services \
--filters Name=service-type,Values=Interface Name=owner,Values=amazon \
--region us-west-2 \
--service-region us-east-2 \
--query ServiceNames

Creating an interface endpoint

The remaining steps to create an interface endpoint are the same for in-region and cross-region enabled services. Select the required Service Name from the Console and proceed to select your VPC, subnets and other configuration options. Finally, click on Create endpoint. Once your endpoint status turns to Available, your setup is complete and you will be able to access the remote AWS service over the interface endpoint.

Figure 3: Cross Region PrivateLink Endpoint for S3

To create an endpoint to S3 in US East (Ohio), from a VPC in US West (Oregon), through the CLI, you can use this example

aws ec2 create-vpc-endpoint \
--vpc-id <vpc-id> \
--service-name com.amazonaws.us-east-2.s3 \
--vpc-endpoint-type Interface \
--subnet-ids <subnet-id-1> <subnet-id-2> \
--region us-west-2 \
--service-region us-east-2

By default, private DNS is enabled for all interface endpoints to AWS services. This simplifies migration from public to private connectivity by retaining the public endpoint DNS syntax. To see the DNS names associated with your endpoint, click on your VPC endpoint ID and see DNS names in the Details tab shown in Figure 4.

Figure 4: DNS Names for Cross Region PrivateLink Endpoint

Additional controls for cross-region access

PrivateLink provides multiple layers of control to ensure usage complies with your role’s permissions and your Organizational policies. You can use these controls to ensure only trusted entities can take PrivateLink actions, for permitted services and regions. In addition to the required controls discussed earlier, the following keys provide enhanced functionality targeted specifically towards cross-region connectivity.

1. [Optional] 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 through endpoints. For example, this identity policy only allows creating and deleting VPC endpoints to services hosted in Asia Pacific (Tokyo) or Europe (Ireland).

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

1. [Optional] Define the Regions your AWS resources can be accessed from: As a resource owner, you can use resource policies to establish a data perimeter. This allows you to limit which resources can be accessed, by whom, and over which networks. While you can continue to use keys like aws:VpceAccount and aws:VpceOrgID, the new aws:SourceVpcArn key helps implement Region based access controls, when the resources are accessed over VPC endpoints. All AWS services accessible over cross-region VPC endpoints support this key. You can use this key to define which Regions your resource can be accessed from, over VPC endpoints. You can also include Account and VPC Id to make the policy more or less granular. Refer to the IAM guide for details, and supported services. For example, this resource policy denies all access to an S3 bucket unless connectivity originates from VPC endpoints from the specified Account and VPC in the Europe (London) Region.

{
    "Version":"2012-10-17",                   
    "Statement": [
        {
            "Sid": "AccessToSpecificVpcOnly",
            "Principal": "*",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1",
                "arn:aws:s3:::amzn-s3-demo-bucket1/*"
                ],
            "Condition": {
                "ArnNotLike": {
                    "aws:SourceVpcArn": "arn:aws:ec2:eu-west-2:<Account-Id>:vpc/<VPC-Id>"
                }
            }
        }
    ]
}

Considerations and best practices

1. For resiliency and high availability, we recommend that you create a VPC endpoint in a minimum of two Availability Zones (AZs). This enables PrivateLink managed failover across AZs in both consumer and service Regions. Unlike in-region connectivity, when accessing a VPCE service in another Region, you do not need to align AZs. You can create an interface endpoint to a remote VPCE service in any and as many AZs as you require.
2. Cross-region connectivity to AWS services in other Regions does not support Zonal DNS. Only regional DNS records are generated for these endpoints. This aligns with resiliency guidance and ensures your endpoints can benefit from PrivateLink managed failover feature.
3. Cross-region connectivity is only supported for interface endpoints. Gateway, Gateway Load Balancer and Resource endpoint types do not support cross-region connectivity.
4. At the time of writing, this feature supports services including Amazon S3, AWS Identity and Access Management (IAM), Amazon Elastic Container Registry (ECR), and Amazon Data Firehose, with more services to follow. For a current list of supported services see the PrivateLink User Guide or follow the service discovery steps mentioned in this blog.
5. PrivateLink integrates with AWS Fault Injection Service (FIS) to simulate regional events and model failure scenarios for in-region and cross-region enabled interface endpoints. To learn more, see AWS FIS documentation.
6. Standard PrivateLink pricing for hours and data processed applies to all interface endpoints, whether to services in a local or remote Region. Additionally, we charge the interface endpoint owner standard EC2 inter-region data transfer charges for each Gigabyte transferred inter-region regardless of the directionality of the data transfer. Please visit the PrivateLink pricing page to learn more.

Summary

We recommend that you use AWS services in your local Region for regional isolation and resiliency. Cross-region PrivateLink connectivity is designed to address use cases where you need to share or access resources homed in a specific Region, meet data residency regulations, or implement multi-region disaster recovery plans. This feature ensures consistent and secure networking as your workloads expand to more Regions. It simplifies how globally distributed applications connect to regional AWS resources, access centralized data lakes or connect to vendors, partners and teams in other Regions – all through private endpoints.

You can get started using the Console, CLI, APIs or CloudFormation. For more information, refer to the PrivateLink User Guide, the introducing cross-region connectivity for non-Amazon managed VPCE services blog and the Securely Access Services Over AWS PrivateLink whitepaper.

About the authors