AWSを駆使したクラウドデータサイエンティストになるための教科書：AWSのネットワーク「VPC」を理解する
前回の「AWSを駆使したクラウドデータサイエンティストになるための教科書：ネットワークを理解しよう」の記事の中でネットワークとは何か？について配送業務に例えて説明をしてきました。
今回は、それを踏まえてAWSのネットワークを理解していきましょう。
AWSにおけるネットワークセキュリティはとても重要
前回見てきたように一般的な家庭のネットワークは、一つのインターネットプロバイダーから１つのグローバルIPを保有しており、そのIPアドレスのネットワーク部をもとに一つのホームローカルネットワークを構築しています。このホームローカルネットワークはグローバルIPアドレスで特定された一つの住所に存在する家のような存在です。
このホームネットワークにご自身で「どういう通信は許可して、どういう通信は拒否するのか」を設定することができます。そうすることで、家の不法侵入を防いだり、逆にご自身で外に機密情報を漏洩してしまうようなリスクを減らすことができます。
つまりホームネットワークという家にSECOMのような警備を入れることができるということです。
AWSを利用する際も同様に、あるいはホームネットワーク以上にこうした警備をいれることは重要です。なぜなら、たいていAWSを利用するのは企業であり、そのAWSのネットワーク空間にあるデバイスや保持されている情報は秘匿性の高い情報も含まれるためです。そのため、ホームネットワークよりも強固なネットワークセキュリティを考えなければなりません。
AWSにおけるネットワーク空間「VPC」
ＡＷＳでご自宅のようなホームネットワークはあるのでしょうか？ご自身でセキュリティを設定できるネットワークはあるのでしょうか？
当然ですが答えは「YES」です。
それがVirtual Private Cloud（VPCと呼ばれます）です。VPCはAWS上に独立したプライベートネットワーク空間を作成できるサービスです。
ネットワークの話をしすぎて、そもそもなんでネットワークの話なんだっけ？という本来の目的を見失ってしまっているかもしれませんが、今回は
EC2インスタンスを立ち上げて、Jupyternotebookをインストールし、RDPを使ってローカルPCからそのデータ分析環境にアクセスできる環境を構築することが目的です。
EC2インスタンスというデバイスとの通信を行う上でVPCの設定が必要ということですね。今回のようにRemote desktopによってご自宅のパソコンからEC2インスタンスにアクセスするということはご自宅のパソコンとEC2インスタンスの間で通信を行う（荷物を配達する）ということです。ご自身のパソコン以外からアクセスはされたくないですよね？そうしたケースを防ぐためにVPCを設計し、ネットワークのセキュリティを高めるのです。
VPCとは？
VPCをAWSで作成すると、「1XX.XX.0.0/16」のようにご自身で設定することができるIPアドレスの範囲を与えられます。このIPアドレスの範囲でネットワークを構築するということですね。基本的にIPv4であれば16ビット以上28ビット以内のCIDR方式で指定することができます。「/16」であれば最初の２つのオクテットである「XXX.XXX」まではネットワーク部ということになりますね。
VPCの設計は「家」というより「事業所」
先ほどはVPCを家のようなものと説明しましたが、実際VPCはどちらかというと大企業の事業所に近いかもしれません。事業所への荷物の配達って普通の一般戸建て住宅のそれよりもうちょっと複雑ですよね？例えば自社ビルでの住所は一個だけど、建物中には複数の部署があって、荷物の配送という意味では自分のデスクまで荷物を配送できて初めて配達完了になります。また事業所の中には大概の人が立ち入り禁止のエリアがあったり、ある書庫の情報は持ち出し厳禁だったり複雑な条件が存在します。
VPCも同様にさまざまな通信を行うデバイスがあったり、逆にインターネット通信をさせてはいけないデバイスがあったりします。また部署のようにデバイスのまとまりとして扱いたいケースもあります。こうしたケースに対応できるようにVPCには細かな管理ができる仕組みや機能があります。
VPCにおける通信の基本はゲートウェイ
VPC内にはEC2インスタンスを含め様々なデバイスがあり、各デバイス同士や、デバイスからインターネット、インターネットからデバイスなどさまざまな通信が行われます。
これらの通信においてこれからいろいろ見ていきますが、基本として先に抑えておきたいのはVPCにおいて通信をする主語、つまり実際にパケットを送ったり、もらったりする主体は誰なのかという点です。仮にHTTPリクエストをするEC2インスタンスがあるならEC2インスタンスがパケットの送り主ですよね？またそのレスポンスとして帰ってきたものを受け取るのもやはりEC2インスタンスのようなデバイスです。ということは通信の送り主や受け取り主たるデバイスはまず通信の主体です。
しかし、主体はそれだけではありません。実は多くの場合、VPCの通信というのはVPC空間内のデバイス同士であっても直接通信をやり取りせず、ほぼ必ずゲートウェイというものが間に入ってパケットの送受信を経由しています。ゲートウェイが介在する理由は実際に通信の荷札を見て配送先に荷物を送りだすのはゲートウェイだからです。
イメージしてもらいたいのですが、皆さんも荷物をどこかに送る場合は自分で直接宛先住所に訪ねて行って送ったりしないですよね？たいていの場合、クロネコヤマトや佐川急便、郵便局に持っていきますよね？この配送業者がVPC空間ではゲートウェイなのです。そしてゲートウェイが正しく荷物を自社トラックや委託先トラックに載せて配送をしているのです。場合によっては、配送業者からまた別の配送センターに荷物が集約されて、そこから個別に配送されることも現実世界にあるようにVPC内でも通信パケットがゲートウェイから別のゲートウェイに渡されてそこから別のところへパケットが送られることがあります。
例えば、先ほどのHTTPリクエストをEC2インスタンスが送る場合、そのリクエストをまず最初に受け取るのはデフォルトゲートウェイです。デフォルトゲートウェイが「ルートテーブル」というものを見て、そのパケットを次にどこに届けるべきかを決定しています。次の配送先が最終目的地かもしれませんし、また別の配送センターのような経由地かもしれません。いづれにせよ、どんなVPC内のデバイスからのリクエスト通信はまずこのデフォルトゲートウェイに送られます。ちなみにこのデフォルトゲートウェイの正体はAWS社が管理しているサブルーターというものです。
さて、デフォルトゲートウェイが受信したのはインターネットのどこかにあるサーバーへのHTTPリクエストという荷物（パケット）でした。インターネット行きはすべてインターネットゲートウェイという次なるゲートウェイにパケットが送られます。そういう風にルートテーブルに書いてあるのです。
現実世界でいえば、国際便を郵便局に持っていったら郵便局が国際郵便を担当する配送センターに荷物をまず送ったという感じでしょうか。
以上のようにVPCの通信でパケットをやり取りする主体は送り主、受け取り主以外だとゲートウェイなんだということを覚えておくと今後VPCを勉強していくうえで混乱しないと思います。
ただし例外的にデフォルトゲートウェイを介さないで通信を行うケースもあります。これも現実世界で考えるとわかりやすいのですが、いくら荷物配送といってもご近所だったら郵便局にもっていかずに、直接自分で届けますよね？VPCでも同じです。近いIPアドレスの場合はデフォルトゲートウェイを介さずに通信を行います。この近いIPアドレスというのは範囲が決まっていて、後述しますがサブネットという単位で定義されています。つまり同じサブネットであれば基本的に直接通信をするということです。
そしてゲートウェイはデフォルトゲートウェイが基本ですが、それ以外にインターネットゲートウェイやNATゲートウェイなどいくつかの種類があります。
ルートテーブルとは？
ルートテーブルは上記で説明した通り、次の配送先を定義している配送表です。ルートテーブルには「送信先（最終目的地）」と「ターゲット（パケットを次に送る先）」が書かれています。送信先はIPアドレスの場合とIPアドレスの範囲（CIDRブロック)の場合と二つあります。デフォルトゲートウェイはこのルートテーブルの送信先からターゲットを判定し、ターゲットにパケットを配送するという感じです。以下は典型的なルートテーブルです。
デフォルトのVPCには、デフォルトのルートテーブルが自動的に作成されます。このルートテーブルには以下のルールが含まれます：
送信先 10.0.0.0/16（VPC内のCIDR範囲）
ターゲット: local（VPC内の全ての通信を許可）
今回のユースケースの要件を詳しく考えてみる
今回のEC2インスタンスにRDPでローカルPCからアクセスするというユースケースについてネットワークに求める要件を詳しく考えてみましょう。
まず、EC2インスタンスと通信を直接行うのは、同じVPC内にある別のデバイスではなくインターネット空間に一度でて、ご自宅のホームネットワークにあるご自身のノートPCです。
できれば、他のパソコンからの通信は受けたくないので、この自宅のホームネットワークのグローバルIPからのリクエストのみを受け付けるようなVPCネットワークである必要がありますね。
逆にこのEC2インスタンスはデータ分析環境ですから、Pythonで利用するSklearnのような外部ライブラリを利用する場合は一度インターネット空間からそれらのライブラリーをとってくる必要がありますし、Githubなども利用するならやはりインターネット通信は必要です。ということはこのEC2インスタンスからのインターネット空間へのリクエストは許可されておく必要があるということです。
もし、このデータ分析環境で分析するデータが秘匿性の高いデータだとしたら、あまりこのデータ自体を外部からアクセスされるのは情報が漏洩するリスクがあるのでよくありません。できればデータ本体を保管するインスタンスと、データ分析環境を構築するインスタンスは分けておきたいですね。そうするとデータ分析環境を構築するインスタンスはHTTPリクエストとHTTPレスポンスは許可しますが、データそのものを保管するインスタンスはこのデータ分析環境を持つEC2インスタンスとのプライベートネットワーク内での通信のみで、インターネット空間との通信は行わないようにしておきたいという要件につながります。
しかし完全にインターネットとの通信を拒否してしまうと不都合が出てきます。例えばデータを保持するといったってそのインスタンスにはRDBMS（Relational database management system）として、例えばPrestoSQLを導入しておきたいなどの要件もあるはずです。するとPrestoSQLをインスタンス立ち上げ時にはインターネット空間からダウンロードしてインストールする必要がありますし、仮にPrestoSQLのアップデートが行われた場合、アップデート情報を適宜受信して更新してやる必要もあります。
とりあえずは以上のような要件が少なくとも今回は発生しそうだと理解しておいてください。
要件の整理
EC2インスタンスそのものはインターネット空間へのHTTPリクエストとHTTPレスポンスを通信として行える必要がある。
EC2インスタンスへのアクセスリクエストは自宅ネットワークのみにしたい
データを保持するEC2インスタンスは基本的にインターネット通信を許可しない。
ただし必要な場合においてはインターネット通信を行えるようにする
EC2インスタンスそのものはインターネット空間へのHTTPリクエストとHTTPレスポンスを通信として行える必要がある
さて、上記のように今回のネットワークの要件を整理したところで、まずEC2インスタンスのようなVPC内のデバイスがインターネットの通信をする必要があります。
前回の記事で解説した内容を思い出していただきたいのですが、ホームネットワークの場合、インターネットの通信は直接各デバイスが行うのではなく、一度ルーターを経由して、ルーターが自身に割り当てられたグローバルIPを使ってインターネットとの通信を実現していました。
VPC空間でも同様にルーターのようにプライベートIPをインターネットの住所となるグローバルIPに変換して行う存在がいます。それがInternet Gataway(IGWと呼ぶ)です。VPC内のデバイスがインターネットの通信を行う際基本的にはこのIGWを経由して行うことになります。
ただし、ホームネットワークと少し違う点があります。それはIGWがグローバルIPを持つのではなく、VPCではインターネット通信を行うデバイスがグローバルIPを持つという点です。
なぜ、VPCのデバイスはグローバルIPを持つのか？
そもそもなぜVPCのデバイスはグローバルIPを持っているのでしょう？これは前回の記事で説明した「基本的にネットワーク空間の荷物配送は「基本的にリクエストしてそのレスポンスという双方向で行われる」という点がポイントになります。
ホームネットワーク空間では例えば皆さんのスマホのように「ブラウザで何かを検索してみたい」というリクエストがあって、そのレスポンスとして要求されたどこかのサーバーがレスポンスを返しています。しかし基本的に皆さんのスマホに対して「Webページの内容をくれ」というようなHTTPリクエストが来ることはありません。
つまり、多くの場合ホームネットワーク空間にあるデバイスというのは自らリクエストをするばかりでレスポンスはしないのです（このように何かしらのリクエストがあってレスポンスを返すようなデバイスは「サーバー」と呼ばれます）。
では、VPC空間内にあるデバイスはどうでしょうか？AWSはそもそも企業のデジタルサービスを支える開発基盤であり、VPC空間に配置されるデバイスというのはサーバーです。言い換えれば、VPC空間にあるデバイスはリクエストするだけじゃなく、リクエスト「される」側でもあるのです。リクエスト「される」ためにはインターネット空間上にそのデバイスの住所となるグローバルIPを公開していなければいけないのはわかるかと思います。以上の理由からVPC空間内のデバイスはグローバルIPを持つのです。
なお、ここまでVPC内空間内でのデバイスは「グローバルIP」を持つという言い方をしましたが、厳密には「グローバルIP」ではなく「パブリックIP」です。呼び名が違うのは、パブリックIPはインターネットプロバイダから直接割り当てられるものではなく、インターネットプロバイダからAWS社から事前にもらっているグローバルIPを、さらにAWS社がユーザーに対して払い出すような形で割り当てているため、一般的なグローバルIPとは異なるためです。
どのようにしてVPC空間内のデバイスはパブリックIPを持つのか？
AWSでは基本的にAWSアカウントを作成すると１つのVPCが自動的に作成されます。その後ユーザー自身で作成するVPCと区別するために、このVPCをデフォルトVPCと呼びます。デフォルトVPC内では、インスタンスを立ち上げると自動的にパブリックIPアドレスが割り当てられる設定になっています。
ご自身でVPCを作成した場合、パブリックIPの割り当ての設定はご自身で考えることになります。
AWSのパブリックIPは基本的に動的（Dynamic）である
AWSで扱うパブリックIPは、実は割り当てられたインスタンスの停止、再起動のたびに変わります。このようにパブリックIPアドレスが動的に（ダイナミックに）変化するため、ダイナミックIPと呼ばれたりします。これはAWS社がAWSの提供する範囲内のネットワークすべてのデバイスに固定したパブリックIPアドレスを与えることが非効率でコストもかかるためです。実際グローバルIPは割り当てるだけで費用がかかるのでインスタンスはあるけど、ずっと停止中のデバイスにもパブリックIPを付与していたら無駄なコストが発生し続けます。そのため、停止中のデバイスにはパブリックIPを割り当てず、起動されたら新たなパブリックIPを与えるダイナミックIP方式をとることでコストを抑えているのです。
しかし、動的にIPアドレスが変わるというのはサーバーにとっては不都合があります。なぜなら、パブリックIPは自身の公開している住所なので、そのサーバーに誰かがリクエストを送ろうとしたら、サーバーの再起動によって住所が変わってしまっていたという事態につながるからです。こうした事態を回避するための方法はいくつかあるのですが、その一つが静的IP（StaticIP）を付与してもらうことです。これは動的の対義語なので固定的なパブリックIPをAWSから割り当ててもらうことを指します。こうすることでサーバーの住所が再起動や停止によって変わらず存在することができます。言わずもがな、StaticIPはグローバルIPの割り当てはお金をAWSがインターネットプロバイダに支払うので、その支払金額に見合ったコストを別途ユーザーが支払うことになります。このIPサービスをElasticIPと呼びます。
EC2インスタンスへのアクセスリクエストは自宅ネットワークのみにしたい
VPC空間内のデバイスがインターネット通信をするためにはIGWが必要であるという説明をしました。次のネットワーク要件はEC2インスタンスのようなデバイスへのアクセスリクエストの送信元を限定するというものです。
実際今回のケースですとRDPの接続リクエストなのでHTTPリクエストをうけるわけではないのですが、ここではこれまでHTTPリクエストを題材に説明しているので、わかりやすさのためHTTPリクエストに置き換えて考えます。
さて、インターネットを介して別のネットワーク空間の送信元から自分のVPC空間へのHTTPリクエストが来るとして、今あなたはそのHTTPリクエストの送信元は限定したいわけですが、どうすればいいでしょうか？
ここまでの開設を踏まえて、お分かりの方もいらっしゃるかと思いますが、純粋にHTTPリクエストの送信元IPアドレスを制限すればいいわけですね。このIPアドレスを制限するなどのセキュリティ対策は実際には「セキュリティグループ」と「ネットワークアクセスコントロールリスト（ACL)」のような機能を利用することで実装することが可能です。
セキュリティグループとACL
通信の宛先や送信元をIPアドレスによって制限するとはより具体的にはやりとりされる荷物（パケット）についている荷札（IPヘッダー等）に記載されているIPアドレスなどをチェックすることで成立します。その荷札をチェックするスキャナみたいなものがセキュリティグループやACLです。
セキュリティグループは各インスタンス事に受け取る荷物の配送（インバウンド）と送る荷物の配送（アウトバウンド）の荷札をチェックするスキャナです。
セキュリティグループの特徴は、デフォルトだと送る荷物はすべて通しますが、届く荷物はすべて拒否するという点です。これによって万が一設定し忘れでも変な荷物（ウイルスのような）を受け取ることは防ぐことができます。
そして、セキュリティグループのもう一つのは送信・受信のどちらかのルールを変更するともう一方にも同じルールが適用されるという点です（この特徴をステートフルと呼びます）。
インスタンス単位での荷札スキャナーに対し、ACLはサブネットで設置されるセキュリティゲートのようなものです。サブネットについては後述しますが、VPC空間に割り当てられたプライベートIPのレンジをさらに細かいサブレンジにわけたものです。
この記事の冒頭でVPCは事業所の配送のようなものだといいましたが、まさしくサブネットという概念はこうした事業所の配送を効果的に行うためのものです。イメージとしては特定の部署の荷物の受取、送付はこの部署の前に設置されている大型の荷札チェックゲートを通して確認されるという感じです。
サブネットごとにセキュリティの設定をすることで、インスタンス単位のセキュリティの設定忘れなどを防ぐことができますし、わざわざ一個一個インスタンス事にセキュリティを設定せずに一括して同様の設定を行うことができるので効率的なセキュリティ設定を実現することができます。
ACLはセキュリティグループとは異なり、デフォルトで送信・受信すべての荷物を通します。また、こちらもセキュリティグループとは異なり、ACLは送信・受信それぞれ別々にルールを設定することが必要になります（この特徴をステートレスと呼びます）。
サブネットとは？
VPC内に構成するネットワークセグメントで、平たく言えばVPCで扱えるIPアドレスの範囲をさらに細かい範囲で定義したIPアドレスの範囲ということになります。
例えば、XXX.XXX.00.0/16のようなVPCの場合、サブネットは「XXX.XXX.0.0/20」、「XXX.XXX.16.0/20」、「XXX.XXX.32.0/20」のようにVPCよりも細かい範囲でIPアドレス空間を定義したものとなります。
前述のとおりサブネットはセキュリティを構築するうえで、インスタンス単位の設定のし忘れや、一括した設定による効率的なセキュリティ構築を実現することができる手段です。
なお、デフォルトVPCでは、リージョン内のすべてのアベイラビリティゾーン（AZ)ごとに１つのサブネットが作成されます。
リージョンとは？
ここまで触れてきませんでしたが、AWSにはリージョンという概念が存在します。リージョンとはAWSが持つ地理的に離れたデータセンター群を分ける概念です。2022年12月時点で世界に30か所あり、例えば東京であれば「ap-northeast」という風に表記されています。AWSは「クラウドサービス」と呼ばれますが、クラウドサービスはその実、AWSが世界のどこかに保有する物理的なデバイスであり、そのデバイスに付随する仮想的なサービスです。例えばEC2インスタンスを立ち上げるとは、AWSが保有するどこかのデータセンターのどこかの物理的なデバイスを一時的にお金を払って借りているというだけにすぎません。もし万が一そのデータセンターが地震などの天災によって破壊されてしまったら、当然そこのデバイスを借りて行っていたあなたのサービスは停止してしまいます。だからこそこうした天災でもAWSは安定的にサービスを提供し続けられるように地理的に離れた場所にデータセンターを複数持つことでどこかのデータセンターが不能になってもほかのデータセンターでカバーできる体制をとっているのです。そのためリージョンという概念がAWSには存在します。
アベイラビリティゾーン（AZ)とは？
AZはリージョンをさらに複数のデータセンター群に分けたグループをさし、2022年12月時点では世界の96か所に存在しているとされています。AZはそれぞれ地理・電源、ネットワークが独立しているので、地震や火災が発生して1つのAZが動かなくなっても、ほかのAZで継続できるという点においてリージョンとは同じです。ただしリージョンよりは地理的に離れているわけではないので、著しく通信の速度が変わるというような弊害は受けません。
AZはリージョンに「a」とか「b」などの記号を付けて表記するので東京リージョンの場合、あるAZは「ap-northeast-a」のように表記されます。
データを保持するEC2インスタンスは基本的にインターネット通信を許可しない
今回のケースですと機密データをもつデータセットはデータへの不正アクセスがインターネットから行われないようにインターネット通信を基本的に行わないことを要件としています。それを実現するために利用したいのがプライベートサブネットです。
サブネットには「パブリックサブネット」と「プライベートサブネット」という２つのサブネットがある
パブリックサブネットとは、インターネットとの通信を許可するサブネットです。一方でプライベートサブネットはインターネットとの通信をする必要がないサブネットです。このようにサブネット単位でデバイスをインターネットの通信をするグループとそうでないグループに分けることでより効率的にセキュリティ設定を行うことができます。プライベートサブネットに大事なデータを保持するインスタンスは一括して配置しておくことでそれらのインスタンスへの不正なアクセスを防ぐことができる状態を簡単に構築できるということです。今回のケースもデータを保持するEC2インスタンスはプライベートサブネットに配置することでセキュアな環境を構築することができます。もちろんこのEC2インスタンス本体にパブリックIPを持たせずセキュリティグループからデータ分析環境のEC2インスタンス以外とのインバウンド・アウトバウンドを拒否するという形で設定してもいいです。ただし、仮に同じようなデータを保持するEC2インスタンスを２つも３つも立てていくなら、その都度そうした設定をインスタンス単位で行うのは手間ですし、設定もれやミスも発生する可能性も高まるため初めからプライベートサブネットに配置して設定をしておくほうが効率性がいいのです。
なお、デフォルトVPCでAZごとに設定されるサブネットはすべてパブリックサブネットになります。
サブネットを利用することはセキュリティを効率的に高めるだけでなく、可用性を高めることにもつながります。可用性とは、「サーバーなどがダウンせずに正常に稼働できている」という状態（時間）です。可用性を高めるとは、つまり常に正常に稼働できる状態を作り上げることを意味します。これはサービスを提供する側にとってはとても大事な考え方の一つです。
もしサーバーを稼働させているAZが地震によってダメになった場合でもスムーズに別のAZでサーバーの稼働を継続できるようにすることが可用性を高めます。そのためには同じ役割を設定したサブネットを別のAZに複製して持っておくことが必要になります。言い換えれば、サブネットもこのように複製しておくことで可用性を高めることができるといえるのです。
なお、１つのサブネットは一つのAZ範囲内で定義する必要があり、複数のAZにまたがって１つのサブネットを定義することはできません（VPCは複数のAZにまたがって定義することはできますが、１つのリージョン内で定義する必要があります）。
サブネット間のルーティングやサブネットとIGWのルーティングはルートテーブルが行っている
これまでEC2インスタンスがIGWを介してインターネットと通信をすることを見てきました。しかしより正確に言えば、IGWとEC2インスタンスの通信の間にはルートテーブルというものが介在していて、ルートテーブルがルーティングを行っています。
ルートテーブルは、VPC内のサブネット間や、サブネットと外部ネットワーク（インターネットや他のVPC）との間のトラフィックのルーティング情報を管理します。
ただし必要な場合においてはインターネット通信を行えるようにする
今回、データを保持するEC2インスタンスはセキュリティを担保するため基本的にはインターネット通信を直接しません。しかし、データを保持するために内部的に例えばRDBMSのPostgreSQLやOracleSQLをインストールするかもしれません。そのソフトウェアのアップデートをしたい場合もあるかもしれませんし、そのインスタンスのOSのセキュリティパッチを充てる必要も時にはあるでしょう。そうしたケースはやはりインターネット通信ができないとソフトウェアベンダーが配布しているアップデートを受け取ったりすることができます。では、こうした場合どうすればいいのでしょうか？AWSではこうしたプライベートサブネットに配置されてインターネット通信を直接行えないデバイスがインターネットからの情報を受け取ることができるようにNATゲートウェイという仕組みが用意されています。
NATゲートウェイがインターネット通信を行えないデバイスに代わってインターネット通信をする
プライベートサブネットは、いわば事業所外と情報をやりとりできない居室です。イメージとしては社外秘情報を集めた書庫のような場所だと思ってください。社外秘の情報ファイルを外部に持ち出されないように、事業所外から来た人（通信）が勝手に「この情報ファイルください！」（HTTPリクエスト）されても困ります。
しかしいくら事業所外との情報のやり取りができない書庫でも、書庫内では事業所外にあるソフトウェアを使っていろいろ業務を行いたいものです。そういう場合は書庫が直接事業所外からソフトウェアを仕入れるのではなく、書庫の人に代わって事業所外からソフトウェアを仕入れてくれる人が必要です。それがNATゲートウェイです。
なので、もし書庫の人がインターネットを介して外部から何かしらの荷物の送受信を行いたい場合はNATゲートウェイという人にリクエストをしますし、配送されたものもNATゲートウェイから受け取るという形になります。
こうすることで外部には書庫という存在をさらすことなく、書庫では事業所外の便利な情報を仕入れることができるようになるのです。
終わりに
いかがでしたでしょうか。今回はあるデータサイエンスのユースケースを想定してそれに関連する形でVPCの解説を行いました。VPCの全容はもっと大きいです。例えばオンプレミスのサーバーとの通信をする場合はどうするのか？別のVPCとの通信は？HTTP以外の通信は？など学ぶべきことはたくさんあります。しかし目的なくVPCを学ぼうとしても頭に入りませんし、全容が大きすぎて勉強しきれません。
都度、自分のユースケースを明確にし、それに必要なネットワーク上の要件を整理した上で、自分がまだ知らない概念があればそれを勉強していくというようなスタイルで継続的に学んでいくことで効率的な学習ができると思います！
さて、次回は知識だけでなく実際にAWSを触りながらどのようにVPCを構築していくのかを解説できたらと思います。