[解決済み] なぜVPCにプライベートサブネットが必要なのですか？

質問

あるのは 4つのシナリオ があります。しかし、この2つを見てみましょう。

• シナリオ1：1つのパブリックサブネット。
• シナリオ 2: 1 つのパブリック サブネットと 1 つのプライベート サブネット。

パブリックサブネットで起動したインスタンスは EIP を持たないので (割り当てられない限り)、インターネットからはすでにアドレス指定できない状態になっています。次に

• なぜプライベート サブネットが必要なのですか?
• プライベートサブネットとパブリックサブネットの具体的な違いは何ですか?

どのように解決するのですか?

更新しました。 は、2015年12月下旬に、AWS を発表しました。 という新機能を発表しました。 VPC向けマネージドNATゲートウェイ . このオプション サービスは、プライベート サブネットにある VPC インスタンスがインターネットにアクセスするための代替メカニズムを提供します。従来は、VPC 内のパブリック サブネットにある EC2 インスタンスが、ネットワーク アドレス変換（技術的には NAT インスタンス。 ポート アドレス変換）を提供し、これらのマシンが NAT インスタンスのパブリック IP アドレスを使用して送信するインターネット アクセスを可能にします。

新しいマネージド NAT サービスは、以下の情報の適用性を根本的に変えるものではありませんが、このオプションは以降のコンテンツでは扱われません。 NAT インスタンスを説明どおりに使用することもできますし、代わりにマネージド NAT ゲートウェイ サービスをプロビジョニングすることもできます。 これらは両方とも VPC のプライベート/パブリック サブネットのパラダイムに関連しているため、NAT ゲートウェイに関する詳細と NAT インスタンスとの比較を統合したこの回答の拡張版が近日中に公開される予定です。

は インターネット ゲートウェイ と NATゲートウェイ は、2つの異なる機能です。 インターネットにアクセスできるすべてのVPC構成は、インターネットゲートウェイ仮想オブジェクトを持ちます。

Amazon VPC におけるプライベート サブネットとパブリック サブネットの区別を理解するには、IP ルーティングとネットワーク アドレス変換 (NAT) が一般的にどのように動作し、それらが VPC で具体的にどのように実装されるかを理解する必要があります。

VPC におけるパブリック サブネットとプライベート サブネットの間の中核的な区別は、VPC ルーティング テーブルにおいて、そのサブネットのデフォルト ルートが何であるかによって定義されます。

この構成は、順番に、その特定のサブネット上のインスタンスでパブリック IP アドレスを使用するかしないかの有効性を決定します。

各サブネットはちょうど1つのデフォルトルートを持ち、それは2つのうちの1つであることができるだけです。

• VPC の "インターネット ゲートウェイ オブジェクト ("public" サブネットの場合)、または
• NAT デバイス、つまり NAT ゲートウェイまたは EC2 インスタンスで、quot;プライベート サブネットの場合は NAT インスタンスの役割を実行します。

インターネットゲートウェイは、パブリックIPアドレスを持たないインスタンスのネットワークアドレス変換を行わないため、パブリックIPアドレスを持たないインスタンスは接続できない。 外部に に接続することができないため、ソフトウェアアップデートのダウンロードやS3 ¹ やSQSのような他のAWSリソースにアクセスすることができます -- そのVPCサブネット上のデフォルトルートがInternet Gatewayオブジェクトである場合。 つまり、あなたが "public" サブネット上のインスタンスである場合、あなたは が必要です。 である場合、サーバーが通常行う必要がある多くのことを行うには、パブリック IP アドレスが必要です。

プライベート IP アドレスのみを持つインスタンスの場合、インターネットへのアウトバウンド アクセスの代替手段があります。 ここで、Network Address Translation² と NAT インスタンスの出番です。

プライベート サブネット上のマシンは、プライベート サブネットのデフォルトルートが ではなく VPC "Internet Gateway"オブジェクトではなく、NATインスタンスとして構成されたEC2インスタンスであるためです。

NATインスタンスとは、パブリックIPを持つパブリックサブネット上のインスタンスで、特定の設定を行います。 NATインスタンスは、パブリックIPを持つパブリックサブネット上のインスタンスで、特定の設定が必要です。

NAT はパケットのソース IP アドレス (プライベート マシンのプライベート IP アドレス) を自身のパブリック IP アドレスに置き換え、トラフィックをインターネットに送信し、応答パケットを受け入れ、それらを発信元のマシンのプライベート アドレスに転送します。 (NATは送信元ポートを書き換えることもあり、いずれの場合もマッピングを記憶しているので、どの内部マシンが応答パケットを受信すべきかがわかる）。 NAT インスタンスは、特にそうするように構成されていない限り、予期しない受信トラフィックをプライベート インスタンスに到達させません。

したがって、プライベート サブネットから外部のインターネット リソースにアクセスする場合、トラフィックは NAT インスタンスを通過し、宛先には NAT インスタンスのパブリック IP アドレスから発信されたように見えます...したがって、応答トラフィックは NAT インスタンスに戻ります。 NATインスタンスに割り当てられたセキュリティグループもプライベートインスタンスに割り当てられたセキュリティグループも、セキュリティグループがステートフルであるため、このレスポンストラフィックを「quot;allow"」するように設定する必要はないのです。 セキュリティ・グループはステートフルであるため、応答トラフィックが内部で発生したセッションに関連していることを認識しており、自動的に許可されます。 予期しないトラフィックは、もちろん、セキュリティ グループがそれを許可するように設定されていない限り、拒否されます。

デフォルト ゲートウェイが同じサブネット上にある従来の IP ルーティングとは異なり、VPC での動作方法は異なります。任意のプライベート サブネットの NAT インスタンスは、常に別のサブネット上にあり、その別のサブネットは常にパブリック サブネットです。

同様に...プライベート サブネットにパブリック IP を持つインスタンスをデプロイすることはできません。 なぜなら、プライベート サブネットのデフォルト ルートは (定義上) NAT インスタンス (トラフィックに NAT を実行する) であり、インターネット ゲートウェイ オブジェクト (実行しない) ではないからです。 インターネットからの受信トラフィックはインスタンスのパブリック IP をヒットしますが、返信は NAT インスタンスを介して外部へルーティングしようとします。NAT インスタンスはトラフィックをドロップするか (認識していない接続への返信で構成されるため、無効と見なされる)、返信トラフィックを自身のパブリック IP アドレスを使用するように書き換えます。

本質的に、プライベートとパブリックの指定は、インターネットからのアクセス可能性と不可能性についてのものではありません。 これらは、そのサブネット上のインスタンスに割り当てられるアドレスの種類に関するもので、インターネットでのやり取りのためにそれらの IP アドレスを翻訳する、または翻訳を避ける必要があるため、関連性があるのです。

VPC には、すべての VPC サブネットから他のすべての VPC サブネットへの暗黙のルートがあるので、デフォルトルートは VPC 内部のトラフィックで役割を果たしません。 プライベート IP アドレスを持つインスタンスは、宛先アドレスが VPC 内の別のプライベート アドレスである限り、(パブリック IP アドレスがある場合は) "from" ではなく、そのプライベート IP アドレスから VPC 内の他のプライベート IP アドレスに接続されます。

プライベート IP アドレスを持つインスタンスが、どんな状況でもインターネットへのアウトバウンドトラフィックを発信する必要がない場合、技術的には "public" サブネットに展開することができ、インターネットからまだアクセスできません。しかしそのような構成の下では、インターネットへのアウトバウンドトラフィックを発信することは不可能で、それには S3 など、他の AWS インフラサービスとの接続も含まれます。 ¹ やSQSのような他のAWSインフラストラクチャサービスとの接続も含まれます。

^{1. S3について、具体的に言うと、インターネット接続は 常に VPCの機能拡張が進めば、他のAWSサービスにも広がっていくでしょう。 比較的新しい概念として VPCエンドポイント という比較的新しい概念があり、プライベートIPアドレスのみを持つインスタンスも含め、VPC内の選択されたサブネットから、インターネットに触れることなく、NATインスタンスやNATゲートウェイを使用せずに直接S3にアクセスできるようになりますが、これは追加の設定を必要とし、VPCと同じAWSリージョン内のバケットにのみ使用可能です。 デフォルトでは、S3（この記事を書いている時点では、VPCエンドポイントを作成する機能を公開している唯一のサービス）は、インターネット経由でVPC内部からしかアクセスできません。 VPCエンドポイントを作成すると、プレフィックスリスト( pl-xxxxxxxx ) が作成され、これをVPCルートテーブルで使用することで、特定のAWSサービス向けのトラフィックを仮想の "VPC Endpoint" オブジェクトを介してサービスに直接送信することができます。 また、特定のインスタンスのS3へのアウトバウンドアクセスを制限する問題も解決します。プレフィックスリストは、宛先IPアドレスまたはブロックの代わりに、アウトバウンドセキュリティグループで使用できるため、S3 VPCエンドポイントには、必要に応じて内部からバケットアクセスを制限する、追加のポリシーステートメントが適用されることができます。}

^{2. ドキュメントに記載されているように、ここで実際に議論されているのは、ネットワーク アドレス変換と同様にポート変換です。 これは、私たちの多くが、実際には TLS を意味するのに、SSL と言いがちなのと似ています。 注意 NAT デバイスの実際の役割はアドレス変換とポート アドレス変換 (PAT) の両方ですが、このドキュメントでは一般的な IT 慣行に従うために NAT という用語を使用しています。}