NAT ゲートウェイとプライベートサブネット

プライベートサブネット内のリソースはプライベート IP アドレスしか持たず、Internet Gateway へのルートもないため、インターネットへのアウトバウンド接続を開始できません。しかし実際には、OS のパッチをダウンロードしたり、Docker イメージを取得したり、サードパーティ API を呼び出したり、ソフトウェアを更新したりするために、インターネットへのアクセスが必要になることがよくあります。解決策は、インターネットにアクセスでき、NAT（Network Address Translation）を実行するデバイスを経由してプライベートサブネットのトラフィックをルーティングし、プライベート IP をパブリック IP の背後に隠すことです。AWS には、NAT Gateway（マネージド）と、自己管理するNAT Instance（レガシー）の 2 つの選択肢があります。

NAT Gateway は、プライベートサブネット内のインスタンスがインターネットへのアウトバウンド接続を開始できるようにしながら、未承諾のインバウンドトラフィックをブロックする、フルマネージドで高可用性のサービスです。パブリックサブネットに配置され、Elastic IP を持ち、最大 100 Gbps の帯域幅まで自動的にスケールします。基盤インフラストラクチャのパッチ適用、スケーリング、管理を行う必要はありません。NAT Gateway はアウトバウンドパケットのプライベートな送信元 IP を自身の EIP に変換し、応答を元のプライベート IP に返します。

NAT Gatewayを作成したら、プライベートサブネットのルートテーブルに、宛先 0.0.0.0/0 → NAT Gateway ID のルートを追加します。これにより、プライベートサブネット内のインスタンスからインターネット宛てに送信されるすべてのトラフィックがNAT Gatewayに送られ、NAT GatewayがInternet Gatewayを経由してインターネットへ転送します。ルートテーブルには、内部トラフィック用のローカルVPCルート（例: 10.0.0.0/16 → local）も引き続き存在します。このルートエントリがない場合、NAT Gatewayをデプロイしていても、プライベートサブネット内のインスタンスはインターネットにアクセスできません。

NAT GatewayはAZ固有であり、同じAZ内のサブネットからのトラフィックのみを処理します。高可用性を実現するには、AZごとに1つのNAT Gatewayをデプロイし、AZ固有のプライベートルートテーブルを作成します。AZ-aのプライベートルートテーブルでは 0.0.0.0/0 をAZ-aのNAT-GWにルーティングし、AZ-bのプライベートルートテーブルではAZ-bのNAT-GWにルーティングします。これにより、AZ間のデータ転送料金を回避でき、AZ-aに障害が発生した場合でも、独自のNATを持つAZ-bのインスタンスはインターネットアクセスを継続できます。

NAT Instanceは、NAT AMIを実行する自己管理型のEC2インスタンスです。NAT Gatewayが存在する前に使われていた従来の方式です。NAT Instanceでは、EC2インスタンスの送信元/送信先チェックの無効化、帯域幅とスケーリングの管理、OSへのパッチ適用、障害対応を自分で行う必要があります。非常に低帯域幅のユースケースでは安価であり、踏み台ホストとしても使用できます。NAT Gatewaysは、本番環境で推奨される選択肢です。完全マネージド型で自動的にスケーリングされ、AZ内で99.99%の可用性SLAが提供され、パッチ適用も不要です。この比較は、試験でもこれまで頻繁に出題されています。

NAT Gatewayの料金は2つの要素で構成されます。1つ目はNAT Gatewayごとの時間単位の料金（us-east-1では約0.045ドル/時間、月額約32ドル）で、2つ目はGB単位のデータ処理料金（us-east-1では約0.045ドル/GB）です。NAT経由で大量のデータを転送するワークロード（大容量のコンテナイメージの取得や一括ダウンロードなど）では、データ処理料金が大きな割合を占める可能性があります。NATのコストを最適化するには、S3およびDynamoDBのトラフィックをVPC Gateway Endpoint経由にルーティングしてNATを完全にバイパスし（無料）、AWS API呼び出しをNAT経由ではなくVPC Interface Endpoint経由にルーティングします。

プライベートサブネット内のデータベースインスタンスは、通常、NAT Gateway経由でルーティングすべきではありません。インターネットへの接続を開始する必要がないためです。データベースが必要とするのは、アプリケーション層（VPC内）からの接続を受け付けることと、場合によってはVPCエンドポイント経由でS3などのAWSサービスにアクセスしてエクスポートやインポートを行うことだけです。データベースのパッチ適用や更新については、RDSはマネージドサービスであるため、OSパッチを直接適用する必要はありません。EC2上の自己管理型データベースでは、Systems Manager Patch Managerを使用してください。SSM VPCエンドポイントを構成していれば、インターネットアクセスなしでSSM経由のパッチ適用が可能です。

NAT Gatewayはステートフルなアウトバウンド専用NATを提供します。開始したアウトバウンド接続とその応答は許可しますが、未承諾のインバウンドトラフィックはすべてブロックします。ただし、ファイアウォールではないため、トラフィックの内容を検査またはフィルタリングすることはありません。アウトバウンドトラフィックのフィルタリング（プライベートサブネットから特定の宛先ドメインまたはIPアドレスのみを許可する場合など）には、VPCにデプロイしたAWS Network Firewallや、Gateway Load Balancerの背後に配置したサードパーティ製ファイアウォールアプライアンスなど、追加の制御が必要です。NATを使用するかどうかにかかわらず、プライベートサブネット内のインスタンスにはセキュリティグループとNACLが適用されます。

インターネットアクセス用のEIPを持つパブリックNAT Gatewayに加えて、AWSはEIPを持たないプライベートNAT Gatewayもサポートしています。プライベートNAT Gatewayは、VPC間、またはVPCとオンプレミスネットワーク間で、CIDR範囲が重複している場合にプライベートIPアドレスを変換するために使用します。たとえば、VPC-A（10.0.0.0/16）が同じ10.0.0.0/16を使用するオンプレミスネットワークと通信する必要がある場合、VPC-A内のプライベートNAT Gatewayが送信元IPを重複しない範囲に変換してから、Transit Gateway経由でオンプレミスへルーティングします。

CloudWatch metricsを使用して、NAT Gatewayの状態とパフォーマンスを監視します。主なメトリクスは、ActiveConnectionCount（NAT経由で現在アクティブなTCP接続数）、BytesInFromDestination / BytesInFromSource（双方向のデータ転送量）、PacketDropCount（帯域幅の上限やエラーを示すパケット破棄数）、ErrorPortAllocation（NATがポート割り当てを使い果たしたことを示し、多すぎる接続によるポート枯渇の可能性があります）です。各NAT Gatewayは、宛先が一意であれば最大55,000件の同時接続をサポートします。これを超えると、接続が破棄される可能性があります。

すべてのプライベートサブネットのワークロードにNAT Gatewayが必要なわけではありません。アクセスパターンを検討してください。インスタンスが他のVPCリソースと、VPCエンドポイント経由でアクセスできるAWSサービス（S3、DynamoDB、SSM、ECR、Secrets Manager）との通信だけを必要とする場合、NAT Gatewayを完全に排除できます。これにより、AZごとに月額約32ドルに加えてデータ処理料金も節約できます。これは、すべてのAWSサービスへのアクセスにVPC Interface Endpointを使用する、完全にプライベートなマイクロサービスにとって理想的なパターンです。インスタンスが呼び出すすべてのサービスを確認し、無料のGateway Endpointまたは有料のInterface EndpointでNATを置き換えられるかを確認してください。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念を理解できているか確認しましょう。

このレッスンでは、NAT Gatewayによって、プライベートIPがElastic IPに変換され、プライベートサブネット内のインスタンスがアウトバウンドのインターネットアクセスを利用できるようになること、プライベートサブネットのルートテーブルにNAT Gatewayを指す0.0.0.0/0ルートを追加する必要があること、そして高可用性を実現し、AZ間のデータ転送料金を回避するには、AZごとに1つのNAT Gatewayをデプロイすることを学びました。次は、VPCの多層防御におけるNetwork ACLとSecurity Groupを比較します。