VPC对等连接替代方案：跨AWS账户同区域服务通信咨询

Got it, let's break down the practical options when VPC peering isn't feasible due to overlapping CIDRs between your two AWS accounts in US-WEST-2. These are all battle-tested approaches that'll get your Consul servers talking to your API servers smoothly:

1. AWS Site-to-Site VPN with Static NAT Translation #

This is a straightforward managed solution that works around overlapping CIDRs by translating IP addresses at the VPN layer.

• How it works: Set up a Site-to-Site VPN connection between the two VPCs. Configure static NAT rules on each VPN gateway to map your overlapping local CIDRs to unique, non-overlapping ranges (e.g., if both VPCs use 10.0.0.0/16, translate Account A's range to 192.168.1.0/16 and Account B's to 192.168.2.0/16). The VPN handles translating traffic back and forth so both sides can communicate seamlessly.
• Pros: Fully managed by AWS, stable for most traffic volumes, no need to maintain additional servers.
• Best for: Medium to large workloads where you want a low-overhead, reliable connection.

2. AWS PrivateLink (VPC Endpoint Services) #

PrivateLink lets you expose Consul as a private service to the other account without routing traffic across overlapping CIDRs.

• How it works:
  1. In the Consul server's account, deploy a Network Load Balancer (NLB) that targets your Consul nodes (cover ports like 8500 for HTTP, 8300 for server-to-server communication).
  2. Create a VPC Endpoint Service linked to this NLB.
  3. In the API server's account, provision a VPC Endpoint that connects to this service. Update your API server config to use the endpoint's DNS name to reach Consul.
• Pros: No public IPs required, traffic stays within AWS's private network, minimal operational overhead.
• Best for: One-way or targeted service access (e.g., API servers querying Consul) where you want a secure, managed setup.

3. EC2 Proxy Instance with NAT Translation #

For more control over routing, set up a custom proxy server that handles IP translation between the two VPCs.

• How it works:
  1. Launch an EC2 instance in either a third "neutral" VPC (with a non-overlapping CIDR) or in each existing VPC (ensure the proxy's IP doesn't overlap with the other VPC's range).
  2. Enable IP forwarding on the instance: run sysctl -w net.ipv4.ip_forward=1 and update /etc/sysctl.conf to persist the setting.
  3. Configure iptables rules to perform source/destination NAT. For example, translate traffic from Account B's API servers to a unique range when sending to Account A's Consul servers, and vice versa.
  4. Update route tables in both VPCs to send traffic for the translated ranges to the proxy instance.
• Pros: Full control over routing logic, works for any traffic type.
• Best for: Smaller workloads or when you need custom routing rules that managed services don't support. Note: Requires ongoing maintenance of the EC2 proxy.

4. Consul WAN Federation (With Public IPs or AWS Global Accelerator) #

Leverage Consul's built-in WAN federation to connect servers across accounts, even with overlapping CIDRs.

• How it works:
  1. Enable WAN federation on your Consul servers. Configure each server to join the WAN cluster using either their public IPs (with strict security group rules) or AWS Global Accelerator endpoints.
  2. If using Global Accelerator: Create an accelerator pointing to your Consul servers' private IPs via an internal load balancer. Use the accelerator's static public IPs for WAN federation—this keeps your Consul servers' private IPs hidden and improves reliability.
  3. Update security groups in both accounts to allow inbound traffic on Consul's WAN ports (8302 for gossip, 8500 for HTTP) from the API servers' public IPs or Global Accelerator ranges.
• Pros: Integrates directly with Consul's native features, no need for additional AWS networking services.
• Best for: Environments already using Consul federation, or if you need flexibility for future cross-region expansion.

5. AWS CloudHub with Site-to-Site VPN #

CloudHub creates a hub-and-spoke topology for multiple VPN connections, making it easy to scale if you add more VPCs later.

• How it works:
  1. Set up a VPN gateway in a hub account (could be one of your existing accounts or a third) as the central hub.
  2. Create Site-to-Site VPN connections from both VPCs to this hub.
  3. Configure static NAT rules on each VPN connection to map overlapping CIDRs to unique ranges within the CloudHub network.
  4. Update route tables in both VPCs to send traffic for the translated ranges to their respective VPN connections.
• Pros: Scalable to multiple VPCs, managed by AWS, consistent routing model.
• Best for: Future-proofing if you plan to connect more than two VPCs down the line.

内容的提问来源于stack exchange，提问作者DeltaE Consulting