Cross-Region Private Connectivity for Bedrock Models

Introduction

The architecture 

1. Traffic from the application in the source region is routed through Transit Gateway 
2. This traffic is inspected by AWS Network Firewall 
3. After inspection, the traffic is routed to a VPC with the cross-region PrivateLink endpoint through a Transit Gateway attachment 
4. Traffic is routed through the AWS backbone to a Network Load Balancer in the destination region.  
5. The Network Load Balancer routes traffic to the Bedrock endpoint. 
6. Return traffic to the application traverses the same network path.  

• It allows you to expose models in a destination region to multiple consumers easily – they simply need to route traffic to the PrivateLink endpoint 
• Traffic is routed through the AWS backbone network and never touches the public internet. 
• Traffic can only be initiated from the source region. Resources in the destination region cannot initiate any connections to resources in the source region through the PrivateLink endpoint. 
• Since Bedrock does not store your prompts and responses (unless you configure it to), you can meet your data residency requirements while leveraging models available outside your primary region.  

• The generation and storing of logs outside the primary region, as discussed earlier. 
• Deploying resources in a region outside your primary region will result in a broader AWS estate that you will have to operate and secure. If this is a blocker, consider using models supported by Global Cross Region Inference instead.  
• Network Load Balancer charges per hour that it runs. This may not be suitable for test or POC workloads. A lower cost option would be VPC peering 

Setting up the architecture

1. Create a VPC in the destination region.
2. Create at least two private subnets across different Availability Zones.
3. Attach a route table with local-only routes (no internet gateway is required).
4. Create a security group that allows inbound TCP/443 from within the VPC CIDR — this will be used by the Bedrock interface endpoint.

1. Create an interface VPC endpoint for the Bedrock service (e.g. com.amazonaws.us-east-2.bedrock-mantle) in the provider VPC.
2. Place the endpoint in both private subnets and attach the security group from Step 1.
3. Set PrivateDnsEnabled to false — traffic will be routed to the endpoint via the Network Load Balancer rather than VPC private DNS.
4. Note the private IP addresses of the endpoint's elastic network interfaces (ENIs), as these will be used as targets for the NLB.

1. Create an internal Network Load Balancer in the same two private subnets.
2. Create a target group with the target type set to IP, using the private IP addresses of the Bedrock endpoint ENIs from Step 2.
3. Configure a TCP/443 listener that forwards to the target group.
4. The NLB operates as a pure L4 TCP pass-through — it does not terminate TLS.

1. Create a VPC Endpoint Service backed by the Network Load Balancer.
2. Enable cross-region support by specifying the source region in the list of supported regions.
3. Configure the allowed principals to restrict which AWS accounts can connect.
4. Note the resulting endpoint service name (e.g. com.amazonaws.vpce.us-east-2.vpce-svc-0123456789abcdef0) — you will need this on the consumer side.

1. Create a VPC in the source region.
2. Create public subnets across two Availability Zones for your application workloads (or connect to your existing network via Transit Gateway).
3. Create private subnets across two Availability Zones to host the cross-region PrivateLink endpoint ENIs — these only need local routes since they are reached by private IP from within the VPC.
4. Create a security group that allows inbound TCP/443 from the VPC CIDR for the PrivateLink endpoint.

1. Create an interface VPC endpoint in the consumer VPC that connects to the endpoint service name from Step 4.
2. Specify the provider's region as the service region.
3. Place the endpoint in the private subnets and attach the security group from Step 5.
4. Set PrivateDnsEnabled to false — DNS resolution will be handled by a private hosted zone instead.

1. Create a Route 53 private hosted zone using the default Bedrock domain name for the destination region (e.g. bedrock-runtime.<destination-region>.amazonaws.com).
2. Associate the hosted zone with the consumer VPC.
3. Add an apex alias A record pointing to the DNS name of the cross-region PrivateLink VPC endpoint from Step 6.
4. This overrides public DNS resolution within the VPC so that any SDK or CLI call to the Bedrock endpoint resolves to the private endpoint IP, without requiring any application code changes.

1. From a resource within the consumer VPC, run a DNS lookup against the Bedrock hostname:

1. Confirm that the result returns a private IP address (e.g. 10.1.x.x) rather than a public one, confirming the private hosted zone is resolving correctly.
2. Verify that the TLS handshake completes against the real Bedrock certificate. TLS is never terminated in the middle — the NLB and both interface endpoints operate at L4 (TCP pass-through), so the client's TLS/SNI handshake flows end to end to the real Bedrock service.

1. Apply IAM policies using the aws:SourceVpce condition key with the Bedrock interface endpoint ID from the provider side to enforce that Bedrock requests can only originate through the PrivateLink endpoint.
2. Apply a VPC endpoint policy on the provider-side interface endpoint to restrict which models can be invoked through the endpoint.
3. Use Service Control Policies at the organizational level for broader enforcement across multiple accounts.

Conclusion