2つのAWSリージョンの接続：2つの仮想プライベートゲートウェイを使用しないのはなぜですか？
2つのAWSリージョンを接続しようとしています。 AWSのドキュメントでは、両側でインスタンスを起動してソフトウェアIPSec（OpenSWANまたはStrongSWAN）を実行し、両方のインスタンスにエラスティックIPを与え、それをトンネルとして使用することを推奨しています。これで問題は解決しましたが、現在、両側に単一障害点があります。
AWSは VPC接続ガイド を7月にリリースし、2つのVPCを接続するための可能なオプションを詳しく説明しています。 PDFは15ページにディープリンクしており、オプションについて説明しています。
ほとんどの場合、すべてのトラフィックが単一の（クラッシュ可能な）インスタンスを通過するため、リストされているすべてのオプションには重大な欠点があります。これまでのところ、最良のオプションは、一方の側でソフトウェアトンネルを使用し、もう一方の側で仮想プライベートゲートウェイを使用することです。彼らは、少なくともあなたは片側で冗長性を得ると言います。それでもまだ最適ではないようです。
2つの仮想プライベートゲートウェイを一緒に接続して、Amazonが管理する冗長性とVPC構成内にこれをすべて維持するというシンプルさの両方の利点を得る方法はありますか？それともVGWは本質的にクライアントのみですか？
いいえ、現時点では、異なるリージョンにある2つの仮想プライベートゲートウェイを接続する方法はありません。 VPCピアリングが単一リージョンのVPCで利用可能であることを考えると、これは今後の機能になると確信しています。
「すべてのVPNエンドポイントにHAソリューションを実装する責任があります（必要な場合）」については、 前の回答 で説明したように、さまざまな処理方法があります。 VPN/NATインスタンスの障害。最近、自動スケーリングとスクリプトを使用してフルメッシュVPNをセットアップし、失敗したVPN/NATインスタンスを再プロビジョニングするだけでなく、別のAZによるルートの即時テイクオーバーのためにVPCルートテーブルを変更する追加のスクリプトも持っている同僚と話していました失敗したVPN/NATインスタンスが再生成を完了するまで。また、VPC/NATインスタンスが起動してENIが再接続されると、ルートは失敗しました。同様のことを行う多くの「NATモニター」スクリプトがgithubにあります。プロセスを説明する AWS記事 もあります。
適切な高可用性？はい。簡単な設定？残念ながら違います。