VPCでプライベートサブネットが必要なのはなぜですか？

Question

AWS VPCの構成には 4シナリオがあります。しかし、次の2つを見てみましょう。

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

パブリックサブネットで起動されたインスタンスには（割り当てられていない限り）EIPがないため、既にインターネットからアドレス指定できません。次に：

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

Michael - sqlbot · Accepted Answer

更新：2015年12月下旬、AWS 発表済み新機能、 Managed NAT VPCのゲートウェイ。このオプションのサービスは、プライベートサブネットのVPCインスタンスがインターネットにアクセスするための代替メカニズムを提供します。以前は、一般的なソリューションはVPC内のパブリックサブネット上のEC2インスタンスで、「NATインスタンス」として機能し、ネットワークアドレス変換（技術的には、他のプライベートサブネットのインスタンスのportアドレス変換）により、これらのマシンはアウトバウンドインターネットアクセスにNATインスタンスのパブリックIPアドレスを使用できます。

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

インターネットゲートウェイとNATゲートウェイは2つの異なる機能であることに注意してください。インターネットにアクセスできるすべてのVPC設定には、インターネットゲートウェイ仮想オブジェクトがあります。

Amazon VPCの「プライベート」サブネットと「パブリック」サブネットの違いを理解するには、IPルーティングとネットワークアドレス変換（NAT）の一般的な仕組みと、VPCでの具体的な実装方法を理解する必要があります。

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

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

各サブネットには、デフォルトルートが1つだけあります。デフォルトルートは、次の2つのうちの1つのみです。

「パブリック」サブネットの場合、VPCの「インターネットゲートウェイ」オブジェクト、または
NATデバイス-つまり、NAT GatewayまたはEC2インスタンスで、「プライベート」サブネットの場合は「NATインスタンス」ロールを実行します。

インターネットゲートウェイは、パブリックIPアドレスを持たないインスタンスのネットワークアドレス変換を行わないため、パブリックIPアドレスを持たないインスタンスは、インターネットに外部に接続できませんソフトウェアのダウンロードなどを行うために更新、またはS3などの他のAWSリソースへのアクセス¹ およびSQS-VPCサブネット上のデフォルトルートがインターネットゲートウェイオブジェクトである場合。したがって、「パブリック」サブネット上のインスタンスである場合、サーバーが通常行う必要のある多くのことを行うために、パブリックIPアドレスがneed必要です。

プライベートIPアドレスのみを持つインスタンスの場合、インターネットへのアウトバウンドアクセスの代替方法があります。これは、ネットワークアドレス変換²とNATインスタンスが入る場所です。

プライベートサブネット上のデフォルトルートはnotVPC「インターネットゲートウェイ」オブジェクトであるため、プライベートサブネット上のマシンはインターネットにアクセスできます。これは_として構成されたEC2インスタンスですNATインスタンス。

NATインスタンスは、パブリックIPと特定の構成を持つパブリックサブネット上のインスタンスです。これを行うために事前に構築されたAMIがありますが、独自に構築することもできます。

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

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

デフォルトゲートウェイが同じサブネット上にある従来のIPルーティングとは異なり、VPCでの動作方法は異なります。特定のプライベートサブネットのNATインスタンスは常に異なるサブネット上にあり、他のサブネットはNATインスタンスにはパブリック外部IPが必要であり、そのデフォルトゲートウェイはVPC「インターネットゲートウェイ」オブジェクトである必要があるため、常にパブリックサブネットです。

同様に、プライベートサブネット上にパブリックIPを持つインスタンスをデプロイすることはできません。プライベートサブネット上の既定のルートは（定義により）NATインスタンス（トラフィックでNATを実行する）であり、インターネットゲートウェイオブジェクトではないため、機能しません（しません）。インターネットからのインバウンドトラフィックはインスタンスのパブリックIPにヒットしますが、応答はNATインスタンスを介して外部にルーティングしようとし、トラフィックをドロップします（接続に対する応答で構成されるため）認識していないため、無効と見なされます）、または独自のパブリックIPアドレスを使用するように応答トラフィックを書き換えますが、外部のOriginは自分以外のIPアドレスからの応答を受け入れないため、動作しませんとの通信を開始しようとしていました。

本質的に、「プライベート」および「パブリック」の指定は、インターネットからのアクセス可能性またはアクセス不可能性に関するものではありません。それらは、そのサブネット上のインスタンスに割り当てられるアドレスの種類に関するものであり、インターネット相互作用のためにそれらのIPアドレスを変換する（または変換を回避する）必要があるために関連しています。

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

プライベートIPアドレスを持つインスタンスが、どのような状況でもアウトバウンドインターネットトラフィックを発信する必要がない場合、技術的には「パブリック」サブネットにデプロイできますが、インターネットからはまだアクセスできませんが... S3のような他のAWSインフラストラクチャサービスとの接続を含むインターネットへのアウトバウンドトラフィックを発信することは不可能です¹ またはSQS。

^{1.特に、インターネットアクセスが常に必要であると言うには、S3については、VPCの機能として、時間の経過とともに範囲が拡大し、他のAWSサービスに広がる可能性が高い単純化です成長と進化を続けます。 VPCエンドポイントと呼ばれる比較的新しいコンセプトがあり、プライベートIPアドレスのみを持つインスタンスを含むインスタンスが、「インターネット」に触れることなく、VPC内の選択されたサブネットからS3に直接アクセスできます。 NATインスタンスまたはNATゲートウェイを使用しますが、これには追加の構成が必要であり、VPCと同じAWSリージョン内のバケットへのアクセスにのみ使用できます。デフォルトでは、S3（これを書いている時点ではVPCエンドポイントの作成機能を公開している唯一のサービス）は、インターネットを介してVPC内からのみアクセスできます。 VPCエンドポイントを作成すると、VPCルートテーブルで使用できるプレフィックスリスト（pl-xxxxxxxx）が作成され、その特定のAWSサービスにバインドされたトラフィックを仮想「VPCエンドポイント」オブジェクト経由でサービスに直接送信できます。また、特定のインスタンスのS3への発信アクセスを制限する問題も解決します。これは、宛先IPアドレスまたはブロックの代わりにプレフィックスリストを発信セキュリティグループで使用でき、S3 VPCエンドポイントが追加のポリシーステートメントの対象になる可能性があるためです、必要に応じて、内部からのバケットアクセスを制限します。}

^{2.ドキュメントに記載されているように、ここで実際に議論されているのは、ポートとネットワークアドレス変換です。技術的には少し正確ではありませんが、結合された操作を「NAT」と呼ぶのが一般的です。これは、実際に「TLS」を意味するときに、多くの人が「SSL」と言う傾向に似ています。私たちは何を話しているのかは知っていますが、最も正確なWordを使用して説明していません。 "注NATデバイスの実際の役割は両方ともアドレスですが、このドキュメントでは用語NATを使用して一般的なITプラクティスに従います変換およびポートアドレス変換（PAT）。 "}

Jim Walker · Answer

上記のMichaelの回答にコメントを追加する評判がありません。したがって、回答としてコメントを追加します。

AWSマネージドゲートウェイは、独自のインスタンスを実行する場合と比較して、現在の3倍のコストがかかることに注意してください。もちろん、これは1つのNATインスタンス（つまり、複数のNATインスタンスがフェールオーバー用に構成されていないなど）のみを必要とすることを前提としています。ユースケースシナリオ。 NATゲートウェイを介して毎月100GBのデータ転送を想定すると、

マネージNATインスタンスの毎月のコスト= 33.48ドル/月（0.045ドル/時間* 1か月で744時間）+ 4.50ドル（処理されたGBデータあたり0.045ドル* 100GB）+ 10ドル（GBの標準AWSデータ転送料金NATゲートウェイ経由で転送されるすべてのデータ）= 47.98ドル

NATインスタンスとして構成されたt2.nanoインスタンス= $ 4.84 /月（$ 0.0065 * 1か月で744時間）+ $ 10（$ [10/GBの標準AWSデータ転送料金はNATインスタンス）= $ 14.84

AWS管理NATゲートウェイには高可用性のための冗長性が組み込まれているため、これはもちろん、冗長NATインスタンスを選択すると変わります。余分な月額$ 33を気にしない場合、マネージNATインスタンスは、別のインスタンスを維持する必要がないという頭痛の種を減らす価値があります。 VPC内のインスタンスにアクセスするためにVPN（OpenVPNなど）インスタンスを実行している場合は、そのインスタンスをNATゲートウェイとしても機能するように設定するだけでよく、その後、 NATの追加インスタンス（VPNとNATを組み合わせるという考えを嫌う人もいますが）。

Nic · Answer

Michael-sqlbot による答えは、プライベートIPアドレスが必要であるという暗黙の仮定をしています。その仮定に疑問を呈する価値があると思います-そもそもプライベートIPアドレスを使用する必要さえありますか？少なくとも1人のコメント作成者が同じ質問をしました。

NATインスタンスを備えたプライベートサブネット上のサーバーと、厳格なセキュリティポリシーを備えたパブリックサブネットのサーバー[a]の利点は何ですか？ – abhillman 14年6月24日23時45分

VPCを使用していて、パブリックIPアドレスをすべてのEC2インスタンスに割り当てるシナリオを想像してください。セキュリティグループを使用して、EC2クラシックで機能するのとまったく同じ方法でアクセスを制限するため、心配する必要はありません。必ずしもインターネット経由でアクセスできるというわけではありません。パブリックIPアドレスを使用すると、ELBのようなものを使用する必要なく、特定のサービスを限られたユーザーに簡単に公開できるという利点があります。これにより、NATインスタンスまたはNATゲートウェイをセットアップする必要がなくなります。また、必要なサブネットの数が半分なので、VPCにより小さいCIDR割り当てを使用するか、同じサイズのVPCでより大きなサブネットを作成することもできます。また、サブネットが少ないほど、AZ間のトラフィックに対しても支払うコストが少なくなります。

それでは、なぜこれを行わないのでしょうか？なぜAWSはベストプラクティスがプライベートIPの使用だと言っているのですか？

インターネット全体のパブリックIPv4アドレスの供給は限られているため、Amazon WebサービスのパブリックIPv4アドレスの供給は限られています。希少なパブリックIPv4アドレスを過度に消費するのではなく、事実上無制限のプライベートIPアドレスを使用することは、お客様にとって最大の関心事です。 AWSがElastic IPを価格設定する方法で、このことのいくつかの証拠を見ることができます。インスタンスに接続されたEIPは無料ですが、未使用のEIPには費用がかかります。

しかし、議論のために、インターネット上のパブリックIPv4アドレスの不足を気にしないと仮定しましょう。結局、myアプリケーションは特別です。次は何が起こる？

VPCのEC2インスタンスにパブリックIPアドレスをアタッチする方法は2つしかありません。

1。パブリックIPアドレスの関連付け

新しいEC2インスタンスを起動するときに、パブリックIPアドレスをリクエストできます。このオプションは、aws-cliを使用する場合は -associate-public-ip-address フラグとして、埋め込みでは AssociatePublicIpAddress フラグとして、コンソールのチェックボックスとして表示されますCloudFormationを使用する場合のネットワークインターフェイスオブジェクト。いずれにしても、パブリックIPアドレスはeth0（DeviceIndex = 0）に割り当てられます。この方法は、新しいインスタンスを起動するときにのみ使用できます。ただし、これにはいくつかの欠点があります。

欠点は、少なくともCloudFormationを使用している場合、埋め込みネットワークインターフェイスオブジェクトを使用しているインスタンスのセキュリティグループを変更すると、インスタンスの即時置換が強制されることです。

もう1つの欠点は、この方法で割り当てられたパブリックIPアドレスが、インスタンスの停止時に失われることです。

2。エラスティックIP

一般に、Elastic IPはより安全であるため、推奨されるアプローチです。同じIPアドレスを使用し続けることが保証されます。EC2インスタンスを誤って削除するリスクはありません。いつでもElastic IPを自由にアタッチ/デタッチでき、EC2インスタンスに適用されるセキュリティグループを自由に変更できます。

...ただし、AWSではリージョンごとに5 EIPに制限されています。さらにリクエストすることができ、リクエストmightが許可されます。ただし、AWSは、前述の理由に基づいて、そのリクエストを拒否する可能性があります。そのため、リージョンごとに5つのEC2インスタンスを超えてインフラストラクチャを拡張することを計画している場合は、おそらくEIPに依存したくないでしょう。

結論として、パブリックIPアドレスを使用するといくつかの利点がありますが、パブリックIPアドレスを排他的に使用しようとすると、管理またはスケーリングの問題が発生します。うまくいけば、これがベストプラクティスがそうである理由を説明し、説明するのに役立つことを願っています。