AWS：小規模システムのNATゲートウェイのコストを削減
ほとんどのトラフィックはないが、必要に応じて拡張できるスタートアップのインフラストラクチャをセットアップしています。
専用プライベートサブネット（3つのアベイラビリティーゾーンを超える）のフロントエンドノードにトラフィックを分散するLBを使用したセットアップを優先します。これにより、専用のプライベートサブネット上のバッキングされたノードにリクエストが送信され、専用のプライベートサブネットにリクエストが送信されます。 mongodbは、アトラスとvpcピアリングを介して管理されます。
各ノードをプロビジョニングするには、インターネットアクセスが必要です。また、バックエンドノードはサードパーティのサービスにリクエストを送信するため、実行中もインターネットアクセスが必要です。
3つのオプションが表示されます。
各アベイラビリティーゾーンの各プライベートサブネットにNATゲートウェイをセットアップします。ロケーションに応じて、これはアベイラビリティーゾーンごとのサブネットあたり約30 $になります。 3つのアベイラビリティーゾーンと2つのサブネットがある場合、これは月あたり約180ドルになり、システムにトラフィックと負荷が少ないときに、ec2インスタンスに使用する予定よりも実際には多くなります。それを削減して、すべてのプライベートサブネットの各アベイラビリティーゾーンで1つのNATゲートウェイを使用するだけにすることもできますが、それでも約90ドルです。
ec2インスタンスをnatゲートウェイとしてセットアップします。これはおそらく少し安価ですが、メンテナンスとセットアップが必要です。
ルートテーブルエントリを介して、1つのプライベートサブネットを使用し、各ノードにパブリックIPを割り当て、インターネットゲートウェイを使用するだけです。いずれにしても、ノードはゲートウェイを介して相互に接続できるはずなので、専用のプライベートサブネットを使用してもあまり意味がないと思います。
最後のオプションは、ec2インスタンス内にすでに1つのElastic IPが含まれており、専用ゲートウェイが不要であるため、最も安価なオプションとなる可能性が高いです。しかし、それを行うことには重大なマイナス面やリスクがあるのかと思いました。必要な場合（大量のトラフィックがある場合など）は、専用サブネットを使用するという考えに戻る予定ですが、最初はコストをできるだけ低く抑えたいと思います。
VPCのネットワークの基本について誤解しているようです。
各アベイラビリティーゾーンのプライベートサブネットごとにNATゲートウェイをセットアップします。
すべての実用的な目的のために、これは実際に行う必要があるものではありません。
NAT単一のVPCで必要になるゲートウェイの最大数は、AZごとに1つです。
NATゲートウェイは、サービスを提供するサブネット（のいずれか）に決して配置されません。 NATゲートウェイは、インターネットゲートウェイを指すデフォルトルートを持つパブリックサブネットに配置されます。次に、NAT上のインスタンスにサービスを提供しますその他のサブネット、ここでNATゲートウェイは、これらのサブネットのデフォルトゲートウェイとして指定されています。
したがって、AM AZのプライベートサブネットの数は、NATゲートウェイの数とは関係ありません。AZあたり45ギガビット/秒を超えるインターネット帯域幅が必要でない限り、複数の=は必要ありません。 NATゲートウェイ。
次に、技術的には必要ありませんが、1つNAT VPCあたりのゲートウェイです。ANATゲートウェイはlogicalエンティティであり、物理的なエンティティではないため、「失敗」する可能性のある既知のメカニズムはありません（最初の作成時を除き、定義に失敗する可能性がある場合を除きます）。 a NATリージョン間のゲートウェイは次のとおりです：
- ゲートウェイを使用して、クロスリージョントラフィックの料金を支払います。これがゲートウェイのコストよりも低い限り、それでも意味があります。
- NATインターネットにアクセスするためのゲートウェイを使用するクロスゾーントラフィックの場合、通常は1桁のミリ秒単位のレイテンシのわずかな増加が見られます。これはトレードオフですが、重要ではない場合があります。
- ゲートウェイをホストしているAZが完全に停止、障害、損失、または破壊すると、すべてのAZでゲートウェイの使用が失われますが、これは明らかにこれまでに起こったことはありません。
次に、EC2インスタンスをNATデバイスとして使用する場合、ほとんどセットアップは必要ありません。NATインスタンスのストックAMIはインスタンスレベルでゼロ構成です。ビルドすることもできます。 EC2インスタンスのリカバリ は、NATインスタンスを修復できます。基盤となるハードウェアに実際に障害が発生した場合、またはハイパーバイザーが応答しなくなった場合（まれですが可能））。
いずれにしても、ノードはゲートウェイを介して相互に接続できるはずなので、専用のプライベートサブネットを使用してもあまり意味がないと思います。
これはどちらの方法でも関係ありません。専用サブネットまたはそれらの欠如は、インスタンスが相互に通信する方法に実際の影響を与えません-それらが通信している信じる方法にのみ影響します。 VPCの各サブネットの「デフォルトルーター」は、IP over Ethernetの動作方法との互換性のために存在する架空のデバイスです。 VPC内の2つのインスタンスがセキュリティグループとネットワークACLによって通信を許可されている場合、2つのインスタンスが同じサブネット上にあるかどうかに関係なく、実際のトラフィックが1つのインスタンスから別のインスタンスに到達する方法は同じです。
クロスサブネットの場合、インスタンスはデフォルトゲートウェイをarpingし、それにトラフィックを送信します。一方、ハイパーバイザーはそれを果たしますが、事実上すべてを無視し、トラフィックを他のインスタンスのハイパーバイザーに直接送信します。サブネット内で、インスタンスはそのピアをarpし、ハイパーバイザーはその応答を偽装します（「持っている」ARPはターゲットインスタンスに表示されませんが、ソースインスタンスはターゲットが生成した応答を表示しません）。ノード間トラフィック以前とまったく同じパスをたどります。
EC2インスタンスをNAT Instancesが唯一のオプションだったため、私たちは何年もうまくいきました-NAT Gatewayは比較的新しいサービスです。コストを節約するには、それを使用します。または、1つを除くすべてのAZでそれを使用し、1つのNATゲートウェイをその1つのAZで使用します。
S3やDynamoDBなど、それらをサポートするサービスのVPCエンドポイントを追加します。これらのエンドポイントを使用すると、NATデバイスなしでこれらのサービスにアクセスできます。
複数のプライベートサブネットからの発信トラフィックを同じnatgwインスタンスにルーティングできます。
時々、natgw（または同様のリソース）が配置されている別個のパブリック「管理」サブネットを作成し、そのnatgwへのルートに従ってインターネットにアクセスできるはずのすべてのプライベートサブネットを提供します。
そのレイアウトにより、このサブネットが特別な目的のためであり、最終的に他のいくつかの分離されたサブネットによって使用されることがより明確になります。通常、そのようなサブネットには小さなCIDRを割り当てます。