When building distributed applications on AWS, it’s common to host your primary data services (like ElastiCache for Redis or Amazon RDS) in one “hub” region, while deploying application stacks in multiple “spoke” regions. By default, services like ElastiCache and RDS are only reachable inside the same VPC and region.

So how do you securely connect remote VPCs across regions? One of the simplest solutions is VPC Peering.

This guide walks you through setting up an inter-region VPC peering connection and configuring network and security so your remote workloads can talk to services in your hub region.

What You Need Before You Start

Gather these details to make the setup smoother:

• Hub VPC ID and CIDR block
  (the VPC in ap-southeast-2 hosting ElastiCache/RDS)
• Remote VPC ID and CIDR block
  (the VPC in us-west-2, or another region, hosting your app instances)
• Service endpoints
  • ElastiCache: Primary endpoint (cluster mode disabled) or Configuration endpoint (cluster mode enabled)
  • RDS: Instance or cluster endpoint
• Service port numbers
  • Redis: 6379 (TLS or non-TLS depending on config)
  • Postgres: 5432
  • MySQL: 3306
• Authentication credentials
  • RDS database username/password
  • ElastiCache AUTH token or ACL credentials (if enabled)
• IAM permissions to create VPC peering connections, edit route tables, and update security groups

Step 1: Create the Inter-Region VPC Peering Connection

1. In the AWS Console, go to VPC → Peering Connections → Create peering connection.
2. Choose your remote VPC (e.g., us-west-2) as the requester.
3. Select My account and Peer Region = ap-southeast-2.
4. Enter the VPC ID of your hub region VPC (ap-southeast-2).
5. Click Create.
6. Switch to the hub region, go to Peering Connections, and Accept the request.

Step 2: Enable DNS Resolution

For service endpoints to resolve to private IPs across the peering:

1. In VPC → Peering connections, select your peering → Actions → Edit DNS settings.
2. Enable Allow DNS resolution from remote VPC on both sides.
3. Ensure both VPCs have DNS hostnames and DNS resolution enabled under VPC settings.

Step 3: Update Route Tables

Each side must know how to reach the other:

• In the remote region VPC route table (attached to your app subnets), add a route:
  • Destination = Hub VPC CIDR
  • Target = VPC Peering connection
• In the hub region VPC route table (used by ElastiCache/RDS subnets), add a route:
  • Destination = Remote VPC CIDR
  • Target = VPC Peering connection

Step 4: Create a Customer-Managed Prefix List

Instead of hardcoding remote CIDRs in your security groups, use a prefix list:

1. In ap-southeast-2, go to VPC → Prefix lists → Create prefix list.
2. Name it (e.g., remote-vpcs-access).
3. Set max entries (e.g., 10 for future remotes).
4. Add the remote VPC CIDR (e.g., 10.1.0.0/16).
5. Save.

Later, just add new remote VPC CIDRs to this prefix list—no SG edits required.

Step 5: Update Security Groups

On the ElastiCache or RDS security group:

1. Go to EC2 → Security Groups → select SG.
2. Inbound rules → Add rule:
   • Type: Custom TCP
   • Port: 6379 (Redis) or 3306 (MySQL) / 5432 (Postgres), etc.
   • Source: Prefix list → select your prefix list
3. Save.

Step 6: Validate Connectivity

From an EC2 instance in the remote region:

Redis (ElastiCache):

Postgres (RDS):

Step 7: Add More Regions in the Future

When you onboard a new remote region:

• Create a new peering connection to the hub.
• Update route tables on both sides.
• Add the new VPC CIDR to the prefix list.

No SG changes required beyond that.

Notes and Gotchas

• VPC peering is non-transitive: each remote must peer directly with the hub.
• Cross-region traffic rides the AWS backbone but incurs data transfer charges and latency.
• For low-latency local reads, consider RDS read replicas or ElastiCache Global Datastore.
• If you add many regions, look into Transit Gateway for cleaner routing.

Conclusion

VPC peering provides a quick, secure way to let workloads in one AWS region access shared services like ElastiCache and RDS in another. By combining prefix lists with peering, you make your setup easier to maintain as you scale out to multiple regions.