目标是在不同区域的 VPC 之间建立数据链接，并且即使某个 VPC 中的可用区域出现故障，该链接也应保持工作。
在两端各有一个 VPN 实例的简单 VPN 隧道是行不通的；如果一端的错误 AZ 出现故障，则隧道就会中断。
我原本希望亚马逊能允许您创建从一个 VGW 到另一个 VGW 的 VPN 隧道，但这似乎目前还无法实现。太糟糕了，因为这将是在不同区域的 VPC 之间实现完全冗余互连选项的简单方法。
如果设置得当，Direct Connect 也可以提供一定的冗余（至少在 AWS 级别）。但建立 DC 链接需要时间，而且成本相当高。这不是你为了测试一个想法而做的事情。
理论上，在两端各有一对 VPN 实例，使用 BGP 和某种心跳可能会有效，但设置必须非常复杂（实例必须相互监视并将路由更改推送到 VPC）。有关于这个主题的任何 HOWTO 吗？
还有其他想法吗？
答案1
你说得对——这是一个棘手的提议。
我不知道我的配置是出色还是荒谬，但我决定通过为每个可用区域提供自己的硬件来避免网络重新配置的需要……以下是我使用的：
在每个可用区中，我都有一个 VPN 实例，因此对于两个区域，每个区域有 3 个可用区，总共有 6 个。它们是 t2 级机器，因此非常经济高效，性能也很好。其中每台机器都有一条通往远程区域所有设备的隧道，因此这 3 台机器中的每一台都有 3 条通往远程区域 3 个可用区的隧道。
VPC 路由是静态的 - 每个可用区中远端 IP 块的所有流量都会路由到本地可用区中的隧道服务器，该服务器会对其进行加密和封装，然后将其发送。每个隧道服务器都有到远程可用区中子网的静态路由，终止于远端目标可用区的正确 VPN 节点。（每个可用区中的子网都是连续的 /21 网络块，因此每个子网只有一条路由）。
而在另一端，情况正好相反。
因此，VPN 节点的丢失只会导致该节点所在的可用区域中的计算机与远程区域的所有区域隔离，因此与故障位于同一区域中的其他可用区域不依赖于任何类型的故障转移机制 - 它们不会受到影响。
采用此设置后，整个可用区域中所有内容的实际丢失不会影响任何其他区域与未受影响区域的 VPN 连接。
VPN 机器实际上有两种方式到达每个对等点；第一种是“正常”路由，通过互联网到达对等点的弹性 IP，另一种是通过备份路由，其中 VPN 服务器全部以中心辐射的方式连接到不在 AWS 网络中的集中器——理论上，隧道可能会在直接互联网路由部分丢失的情况下继续存在，流量通过不同的主干网到达备用中心站点并中继到对等点，允许它们通过更慢、更隐蔽的备份路径传递流量，而不会在互联网连接丢失的情况下丢失隧道连接。由于主路径和备用路径在两端都终止于同一个实例，并且备份“中心”不跟踪流量，因此在发生抖动期间短暂的非对称隧道流量路由不会引起任何问题。
为了恢复与受影响区域的连接，必须解决 VPN 节点故障。或者更改路由表。