Enabling cross-region private access to Amazon S3 with existing application configuration

Many organizations need to maintain strict private network communications between their AWS resources across different Regions, particularly when handling sensitive data or meeting compliance requirements. To optimize performance and minimize costs, it’s an architectural best practice to maintain data flows within AWS’s private network, even when using public IP addresses. However, regulated industries and enterprises often require private IP addresses for internal communications to meet their security policies.While AWS has supported private addressing for cross-region connectivity and Amazon Simple Storage Service (Amazon S3) interface endpoints since 2022, implementing these features typically requires application modifications to use specific domain names. This post demonstrates how to leverage private DNS support for Amazon S3 to enable cross-region private access while keeping current configuration. This solution extends native resolution of private endpoints across AWS Regions, allowing applications to consume Amazon S3 resources in a remote Region over private connectivity without any updates. As a result, public Amazon S3 URLs in a remote Region automatically resolve to private IP addresses for direct access, improving security while maintaining application compatibility.

Overview of native Amazon S3 cross-Region access over private connectivity

To demonstrate the solution, consider an enterprise operating in two AWS Regions: Frankfurt (eu-central-1) and Ireland (eu-west-1). The following figure contains business applications running in the Frankfurt VPC ‘Client Side’, consuming data stored in Ireland through Amazon S3 interface endpoints in the VPC ‘Remote’.

Figure 1: Resolve Amazon S3 interface endpoints in a remote Region with Amazon Route 53 Resolver.

For this solution walkthrough, we’ll use Ireland (eu-west-1) and Frankfurt Regions as example locations, where Ireland hosts the S3 resources and Frankfurt contains the client applications. While these Regions are used to demonstrate the concept, the solution can be implemented between any two AWS Regions.There are three main components in the solution:

1. Private DNS support for Amazon S3 is configured in Ireland (eu-west-1), the remote Region hosting the S3 resources. This configuration updates the Amazon Route 53 record for the Regional DNS name (s3.eu-west-1.amazonaws.com) with the private IP addresses of the interface endpoint within the Ireland Region.
2. Route 53 Resolver endpoints are established to enable cross-Region resolution of the Amazon S3 interface endpoints from the Frankfurt Region, where our client applications reside.
3. Applications in Frankfurt can then connect to Amazon S3 in Ireland over private connectivity, as the remote Regional DNS name (s3.eu-west-1.amazonaws.com) now resolves to the private interface endpoint IP addresses.

This regional setup serves as a practical example of how the solution can be implemented in your environment, regardless of which Regions you choose to use.

Implementing solution components

This walkthrough outlines the steps required for each part of the solution. Your environment may differ and have components that can use this solution without modifying existing applications.

Prerequisites

The following prerequisite is necessary to complete this solution:

• An AWS Account with permissions to establish connectivity between AWS Regions and create endpoints for Amazon S3 and Route 53 Resolver.

Step 1. Establish private connectivity between AWS Regions

Inter-region connectivity across the AWS backbone network is required to provide a private path to Amazon S3 resources in the remote Region. This allows your workloads to connect to Amazon S3 in a remote Region without NAT or using any public IP addresses. The AWS backbone network is built with fully redundant 400 GbE fiber, often providing many terabits of capacity between AWS Regions. Two AWS Regions can be connected with AWS Transit Gateway peering attachments or Amazon Virtual Private Cloud (Amazon VPC) peering. If you are setting up connectivity between AWS Regions for the first time, then review the key considerations when choosing between AWS Transit Gateway and VPC peering. You can also use AWS Cloud WAN, which offers logical separation between routing domains and is a simple way to build a scalable global network.

Step 2. Enable Private DNS Support for Amazon S3 in the remote Region

Private DNS for Amazon S3 enables regional Amazon S3 DNS queries to resolve to the private IP addresses of the Amazon S3 interface endpoint. The post Introducing private DNS support for Amazon S3 with AWS PrivateLink covers the different types of VPC endpoints for Amazon S3 and gives a detailed walkthrough to optimize access within a Region, including hybrid connectivity to on-premises locations. When Private DNS support is enabled, as shown in the following figure, Route 53 Resolver is updated with private IP addresses for the Amazon S3 interface endpoints with the following format: s3.<Region>.amazonaws.com. When creating an Amazon S3 VPC endpoint the security group associated with the endpoint should have the appropriate permissions allowing access from applications in each AWS Region scope.

Figure 2: Private DNS for Amazon S3 enabled on interface endpoints

The following figure shows the private IP addresses assigned to the elastic network interfaces (ENIs) of the Amazon S3 interface endpoint.

Figure 3: Private IP addresses for Amazon S3 interface endpoints

When a DNS resolution is conducted against the Amazon S3 Regional DNS name in Ireland (s3.eu-west-1.amazonaws.com) from an instance within the Region where the endpoint resides (eu-west-1), it resolves to the private IP addresses as depicted in the following figure. This validates that private DNS is enabled, as Route 53 Resolver is updated with private IP addresses for the Amazon S3 interface endpoint.

Figure 4: Terminal DNS resolution in-Region showing private interface endpoint IPs for Amazon S3

Step 3. Configure cross-Region resolution of Amazon S3 interface endpoints with Route 53 Resolver

When an Amazon S3 interface endpoint is created in a VPC, it enables Regional private access to S3 buckets within the same Region. The resolution of the S3 bucket domain name returns the IP addresses of the ENIs associated with the interface endpoint in the Availability Zone (AZ). However, the interface endpoint doesn’t resolve from peered VPCs in other AWS Regions. To address this, we use Route 53 Resolver endpoints.

Referencing Figure 1, a Route 53 Resolver inbound endpoint is created in the remote VPC in the Ireland Region (eu-west-1) containing the Amazon S3 interface endpoint. The following figure details the inbound endpoint IPs that accept DNS queries from remote sources, in our example the VPC in the Frankfurt Region (eu-central-1).

Figure 5: Route 53 Resolver inbound endpoint in the Ireland Region.

To avoid needing to change existing or future applications, a Route 53 Resolver outbound endpoint is created in the client-side VPC in the Frankfurt Region (eu-central-1) to forward name resolution requests for the remote Amazon S3 resource to the inbound endpoints configured in the previous step.

Figure 6: Route 53 Resolver outbound endpoint in the client-side Frankfurt Region

The following figure details the Route 53 Resolver rule matching the remote resource (s3.eu-west-1.amazonaws.com) and the target IP addresses to forward DNS queries to.

Figure 7: Outbound Resolver rule to forward matching DNS queries to the VPC in Ireland Region

With the Route 53 Resolver endpoints in place, when the DNS name of the remote Amazon S3 Regional endpoint is queried from the client-side VPC in the Frankfurt Region, it resolves the private IPs for the Amazon S3 interface endpoint located in the remote Ireland Region. The following figure shows a DNS resolution of s3.eu-west-1.amazonaws.com from an instance in the Frankfurt Region returning the private IPs of the Amazon S3 interface endpoint in Ireland.

Figure 8: Terminal DNS resolution from client-side AWS Region resolving private IPs for the Amazon S3 interface endpoint in the remote Region

The US East (N. Virginia) Region is backward compatible for legacy global endpoints. To accommodate resolution of private endpoints in this Region, Route 53 Resolver forwarding rules should include s3.amazonaws.com in addition to us-east-1.amazonaws.com.

Step 4. Test access to remote Amazon S3 buckets over private connectivity

With the solution in place, any applications making requests to Amazon S3 in the configured remote AWS Region traverse private connectivity, avoiding the internet and associated NAT processing charges from private subnets. Observe the following figure:

Figure 9: Terminal curl getting data from remote AWS Region bucket using private connectivity

Not only do existing applications experience improved performance efficiency without requiring changes, but also future applications benefit from the optimized architecture by default.

Considerations

Although this solution optimizes Amazon S3 access between AWS Regions, be mindful of introducing cross-Region dependencies to production systems. For a deeper dive, review the AWS Multi-Region Fundamentals whitepaper. It is also worth reviewing quotas on Route53 Resolver endpoints and AWS PrivateLink when operating at scale.

Conclusion

In this post we discussed the benefits of extending Private DNS support for Amazon S3 across AWS Regions using the secure and highly-available AWS backbone network. Amazon Route 53 Resolver endpoints and associated forwarding rules enable the resolution of remote Amazon S3 interface endpoints so that existing and future applications can use the more secure, performant, and cost optimized path. This is achieved without requiring application awareness or change, thereby simplifying the adoption of best practices for Platform and Cloud Center of Excellence (CCoE) teams.

About the authors

Onyekachi Uchendu is an Enterprise Senior Solutions Architect at AWS. He is deeply passionate about technology and helping customers explore the art of the possible on AWS to solve their business challenges. He enjoys designing highly scalable, resilient and cost-effective Networking and Security solutions leveraging AWS services. Onyekachi loves travelling, playing soccer and listening to all genres of music.

Abiola Babsalaam serves as a Senior Technical Account Manager (TAM) at Amazon Web Services, with extensive expertise across network architecture, security, and big data domains. Through deep customer engagement, Abiola conducts technical deep-dives and architectural reviews, providing prescriptive guidance aligned with the AWS Well-Architected Framework, and developing custom solutions for complex AWS environments.