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

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

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

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

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

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

新しいマネージドNATサービスは、以下の情報の適用性を根本的に変更するものではありませんが、このオプションは、以下の内容では扱われていません。説明されているように、NATインスタンスを引き続き使用できます。代わりに、マネージドNATゲートウェイサービスをプロビジョニングできます。NATゲートウェイに関する詳細とそれがNATインスタンスと比較する方法を統合するこの回答の拡張バージョンは、どちらもVPCのプライベート/パブリックサブネットパラダイムに関連しているため、間もなく発表されます。

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

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

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

次に、この構成により、その特定のサブネット上のインスタンスでパブリックIPアドレスを使用する、または使用しないことの妥当性が決まります。

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

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

インターネットゲートウェイは、パブリックIPアドレスのないインスタンスのネットワークアドレス変換を行わないため、パブリックIPアドレスのないインスタンスは、インターネットに外部に接続できません-ソフトウェア更新のダウンロードや、S3 ¹やSQS などの他のAWSリソースへのアクセスなどを行うため-VPCサブネットのデフォルトルートがインターネットゲートウェイオブジェクトの場合。あなたが「公共」のサブネット上のインスタンスであればそう、あなたが必要としますサーバは、一般的に行う必要があること、物事のかなりの数を行うために、パブリックIPアドレスを。

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

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

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アドレスを使用するように応答トラフィックを書き換えます。これは、外部発信元が、通信を開始しようとしたIPアドレス以外からの応答を受け入れないため、機能しません。 。

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

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

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

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

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

「プライベート」サブネットとNATインスタンス/ゲートウェイを分離する-別の方法をお勧めします。それらは必要ありません。マシンにインターネットからアクセスできないようにする場合は、そのようなアクセスを許可するセキュリティグループに配置しないでください。

NATインスタンス/ゲートウェイを廃止することで、インスタンス/ゲートウェイのランニングコストを排除し、速度制限（250メガビットまたは10ギガビット）を排除します。

直接インターネットにアクセスする必要のないマシンを使用している場合（そして、パッチをどのように適用しているかを尋ねます*）、必ず、パブリックIPアドレスを割り当てないでください。

*ここでの答えが何らかのプロキシである場合、まあ、あなたはオーバーヘッドを負担しますが、それぞれが独自に負担します。

上記のマイケルの回答にコメントを追加するという評判がないため、私のコメントを回答として追加します。

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

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

NATインスタンスとして構成されたt2.nanoインスタンス= $ 4.84 /月（$ 0.0065 * 744時間/月）+ $ 10（NATインスタンスを介して転送されるすべてのデータに対する$ .10 / GB標準AWSデータ転送料金）= $ 14.84

AWSが管理するNATゲートウェイには高可用性のための冗長性が組み込まれているため、冗長なNATインスタンスを使用すると、これはもちろん変わります。月額33ドルの追加料金を気にしない場合、マネージドNATインスタンスは、別のインスタンスを維持する必要がないという頭痛の軽減に値します。VPC内のインスタンスにアクセスするためにVPN（OpenVPNなど）インスタンスを実行している場合、NATゲートウェイとしても機能するようにそのインスタンスを構成するだけで、NATのためだけに追加のインスタンスを維持する必要はありません（ただし、VPNとNATを組み合わせるという考えに難色を示す人もいます）。

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

厳格なセキュリティポリシーを備えたパブリックサブネット内のサーバーに対して、NATインスタンスを備えたプライベートサブネット上のサーバーの利点は何ですか？– abhillman 2014年6月24日23:45

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

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

アマゾンウェブサービスでは、インターネット全体でパブリックIPv4アドレスの供給が制限されているため、パブリックIPv4アドレスの供給は制限されています。希少なパブリックIPv4アドレスを過度に消費するのではなく、事実上無制限のプライベートIPアドレスを使用することは、彼らにとって最善の利益になります。AWSがElastic IPをどのように価格設定しているかで、これのいくつかの証拠を確認できます。インスタンスにアタッチされたEIPは無料ですが、未使用のEIPには費用がかかります。

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

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

1.パブリックIPアドレスを関連付ける

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

短所は、少なくともCloudFormationを使用している場合、組み込みネットワークインターフェイスオブジェクトを使用しているインスタンスのセキュリティグループを変更すると、インスタンスが即座に置き換えられることです。

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

2. Elastic IP

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

...しかしAWSでは、リージョンごとに5 EIPに制限されています。さらにリクエストでき、リクエストが許可される場合もあります。しかし、AWSは、上で述べた理由に基づいて、その要求を拒否する可能性が高いです。そのため、リージョンごとに5つのEC2インスタンスを超えてインフラストラクチャをスケーリングする予定がある場合は、おそらくEIPに依存したくないでしょう。

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