AWS VPCについて

こんにちは！
最近好きでインフラ周りを担当させてますが、なかなか知識が足りなくて、苦労をしてるキムです。
皆さんが開発してるサービスて、オンプレと、クラウドどちらを利用してますでしょうか？？
私は今まで働きながら両方経験してもらいましたが、この最近クラウド環境を利用してることが多くなりました。
そして普段、ネットワークて詳しいでしょうか？？どなたかにおまかせしたりとかはしてないですか？
私はそれはそれでいいと思いますが、AWSを担当してる以上「なんとなくできました。」て言ってる自分がすごく嫌でした。
なので、最近AWSで一番基本になる、ネットワーク周りを勉強してます。
本日はその中で、VPCについて勉強したことを共有しようと思います。
もし、足りないことや、追加しなきゃ行けない情報があればコメントお願いします。

入る前に　VPCって理解しなきゃいけないの？

AWSを使うときによく出会う概念があります。　VPCと、サブネットですね。そして、AWSの一番根本になるサービスのEC2インスタンを作るときにもVPCと、サブネットを指定しなきゃいけません。　もちろん、このような概念を細かく知らなくても、AWSを使うには特に問題はないと思います。
なら、VPCを絶対理解しなきゃいけないですかね？AWSを十分に有効活用するためにはそうだと思います。

AWSにはサーバーホスティングサービスではなく、Cloudサービスとして分類されてます。Cloudサービスでは既存サーバホスティングとは差別された重要な特徴があります。その一つがネットワーク環境を直接設定できることです。初めからこのような差が出てはなかったです。独立されたネットワーク環境を構成できる仮想プライベートクラウド(VPC:Virtual Private Cloud)は2011年8月に初リリースされました。　現在はAWSで提供されるほとんどのサービスがVPCに依存されてます。　VPCを認識せずにAWSを使うのは可能だが、その裏にはAWSアカウントを作る時に一緒に作成された基本（Default） VPCがあります。

したがって、AWSのサービスたちを正しく理解して、使うためにはVPCに対する基本的な理解は必須的だと思います。　
この記事では基本VPCの構成項目を見ながら、それぞれどんな意味を持ってるのかを確認してみましょう。

Amazon VPCの理解

Amazon　VPCの公式ドキュメントにはVPCを下記のように紹介してます。

Amazon Virtual Private Cloud (Amazon VPC) では、AWS クラウドの論理的に分離されたセクションをプロビジョニングし、お客様が定義した仮想ネットワーク内の AWS リソースを起動することができます。自分の IP アドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境を完全に制御できます。VPC では、リソースやアプリケーションに安全かつ簡単にアクセスできるよう、IPv4 と IPv6 を両方とも使用できます。
Amazon Virtual Private Cloud

この紹介には論理的に隔離された空間をプロビジョニングする。ていう内容に注目する必要があります。　AWSは基本的にいろんな顧客たちが利用する共用環境であります。　利用者たちはこの環境の上にEC2インスタンスと、RDSインスタンスなど、様々なリソースを作って利用してます。クラウド上でリソースたちだけ隔離されたネットワークを作ってくれる機能がVPCであります。　VPCを利用したら、特定ユーザーたちのリソースたちは論理的に隔離されたネットワーク上で作られるので、他の人達が接近するのはもちろん見ることもできないです。

現在、VPCはすべてのユーザーに対して強制的に適用されています。なので、VPCなしにはほとんどのサービスを利用するのは不可能であります。先話しましたが、AWS VPCが最初から強制的に適用されたものではないです。　AWS VPCが正式にリリースされた2011年8月以前にはEC2-Classicネットワーク環境が利用されてました。

EC2-Classicは、お客様のインスタンスは他のユーザー様と共有する単一のフラットネットワーク内で稼働します。Amazon VPCは、お客様のインスタンスはご自分の AWS アカウントから論理的に独立した仮想プライベートクラウド (VPC) 内で稼働します。
EC2-Classic プラットフォームは、Amazon EC2 のオリジナルリリースで導入されました。2013 年 12 月 4 日以降に AWS アカウントを作成した場合は、EC2-Classic をサポートしていないため、VPC で Amazon EC2 インスタンスを起動する必要があります。
アカウントが EC2-Classic をサポートしていない場合は、デフォルトの VPC が作成されます。デフォルトでは、インスタンスを起動すると、デフォルトの VPC でインスタンスが起動されます。または、デフォルト以外の VPC を作成して、インスタンスを起動するときに VPC を指定することもできます。
- EC2-Classic

上の内容からわかるようにEC-Classicのネットワーク環境は他のユーザーとともに利用する共用スペースであります。過去にはEC-Classicと、EC2-VPCネットワーク環境を選択して利用できることが可能でした。もちろんAWS VPCリリース前にはEC2-Classicネットワーク環境だけ提供されてました。

AWS VPCがリリースされ、2年が過ぎた2013年12月4日以降作成されたAWSアカウントではEC2-Classicネットワーク環境をもう利用できなくなりました。　したがって、これ以上AWS VPCは選択項目ではないです。しかし、EC2インスタンス一つを作るためにはユーザーが直接ネットワーク環境を直接構築しなきゃいけないのは不便だし、複雑なことです。ユーザーが直接ネットワーク構成を設計できるていうのはすごくメリットですが、すぐ使える基本環境を提供するのも大事です。したがって、AWSではAWSアカウントを作成するときに、Regionごとに基本VPCをDefaultで作成してくれます。このDefault VPCを利用すれば、AWS VPCをあんまり認識せずに、簡単にAWSが提供してくれるサービスが利用できます。またDefault VPCを使っても以前のEC2-Classicとは違う隔離されたネットワーク環境のいいところを使えることが可能です。

しかし、AWS上でプロダクト環境を構築するためにはAWS VPCについて、より深い理解を必要とします。　直接VPCをデザインして、構築する立場ではなくても、最小限VPCがどのように構成されてるのか理解することだけでもすごく助かると思います。　この記事では基本的はVPCの構成を確認しながら、内容や、各項目ごとにどのようなことを担当してるのがを確認して、理解するのがゴールになります。

Default VPCの構成項目

アカウントを初めて作ったとき一つのRegionで作られるリソースは下記のとおりになります。

- 1 VPc
- n Subnet
- 1 Route Table
- 1 Network ACL
- 1 Security Group
- 1 Internet Gateway
- 1 DHCP options Set

このように７つのリソースがすべてです。
項目ごとに見てみましょう

VPC

VPCはPrivate Cloudを作るときに一番ベースになるリソースであります。　VPCは論理的に独立ネットワークを構成するリソースで、名前とIPv4 CIDRブロックを必須として持ちます。

CIDRブロックはIPの範囲を指定する方法です。　CIDRブロックはIPアヅレストスラッシュ（/）の後ろについてくるネットマスク数字で構成されてます。　この数字はIPの範囲を表せてます。この数字が32だったら、前記述されたIPを明確に一つ表してます。　例えば 192.168.0.0/32 は192.168.0.0を指してます。
範囲は指定されたIPから、2^(32-n)こになります。　例えば後ろの数字が24だったら2^(32-24)=256このIPアドレスを意味してます。　例えば、192.168.0.0/24は192.168.0.0から192.168.1.255までのIPを意味してます。

クラウド上で作成されるリソースたちは基本的に特定ネットワーク上で作成され、これに接近するためにはPrivate IPを持ちます。このリソースたちは特定VPC上で作られます。　したがってVPCのCIDR範囲内で、適切なIPをしてされます。例えば、192.168.0.0/24　CIDRブロックを持ってるVPCで新しく作られた、EC2インスタンスは192.168.0.127ていうIPを指定されるこのができます。　VPCの範囲内で、使える範囲のIPが全部使えきったら、それ以上リソースが作られないでしょう。　なので、適切なサイズのVPCを作る必要があります。一つのVPCの最大のサイズは16です。　この場合2^(32-16)=65536個のIPを使えるようになります。　
これ以上大きいなサイズのVPCはつくられないです。

VPCを作るときにもう一つ気にしなきゃいけないことがあります。　CIDRの範囲を指定するのに特別な制約は内ですが、ネットにつないたことで、問題が発生する可能性があります。　例えば52.12.0.0/16をCIDRブロックで指定したことを香料しましょう。このVPCで52.12.0.0/16で接続するトラフィックはVPC内部でRouteされます。なのにこの範囲のIPはインタネットで使えるIPになります。　したがって、このVPCには52.12.0.0/16に入ってるネットIPに接近するのは根本的に不可能になります。　ネットの接続が必要な場合必ず、私設網帯域を使わなきゃいけない市、ネットの接続が必要ないとしても、可能であれば、私設網帯域を使うことをおすすめします。　私設網帯域は10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16があります。

VPCは独立したネットワーク環境で構成されるため、CIDRが同じか重なっても作成することが可能です。 しかし、後ほど多数のVPCを同時に使用する場合、IPアドレスが重なると、問題が発生することがあります。 VPCを作ることは簡単ですが、一度作った後は既存のCIDRを変更することはできません。 問題が発生した場合、VPC内部のリソースを移動することは非常に大変です。 したがって、本番環境を構築する際には、VPCの制約事項を十分に理解してCIDRを決める必要があると思います。 基本VPCのCIDRブロックは172.31.0.0/16です。

参考

1. 基本的なVPCが必要な状況で誤って削除してしまったら、問題になるかもしれません。 その場合、アマゾンサポートセンターのSupport Centerに問い合わせると基本VPCが復旧してくれます。 基本VPCは基本VPCという特別な標識が付いてはいますが、実は自分でVPCを構成したからといって違うところがあるわけではありません。 したがって、VPCの構成原理が理解できれば、VPCが消えると心配することはありません。
2. IPv4のCIDRブロックを指定するには私設網帯域の範囲内で指定してください。 私設網帯域としては、10.0.0.0/8、172.16.0.0/12、192.168.0/16があります。
3. DNS関連設定があります。　
   1. DNS 解析機能：DNS ホストネームをIP で解析するときにAWS が提供するDNS サーバを使用する機能で、新しく作ったVPCでも基本的に有効になっています。
   2. DNS ホストネーム：VPC 内部で生成されるインスタンスにパブリック DNS ホストネームを割り当てる機能です。この機能はデフォルトで無効になっています。

Subnet

VPCだけではまだ何もできません。 VPCは、再度、CIDRブロックを持つ単位に分かれます。 サブネットは、実際にリソースが生成される物理的空間である可用ゾーンAvailable Zoneと繋がりがあります。 VPCが論理的な範囲を意味するのであれば、サブネットはVPCの中で実際にリソースが生成できるネットワークと考えられます。 他のサービスのリソースを作成する際に、VPC だけを指定することはありません。 VPC とサブネットの両方を指定するか、サブネットを指定すると、VPC は自動的に類推されることもあります。

1つのVPCは、N個のサブネットを有することができます。 サブネットの最大サイズは、VPC のサイズと同じです。 VPC と同じサイズのサブネットを 1 つだけ作ることも可能です。 サブネットを作らないこともありますが、その場合、VPCでは何もできません。 一般的に使用できる可用範囲を考慮して、適切なサイズのサブネットを可用範囲の数だけ生成して使用します。 N可用範囲分だけサブネットを作ってリソースを分散すれば、災害対応面でも有利です。

サブネットのネットマスク範囲は、16（65535）から28（16）が使用でき、VPC CIDR ブロック範囲に属する CIDR ブロックを指定できます。 1つのサブネットは、1つの可用ゾーンと接続されます。 Regionによって使用可能な可用範囲の数は異なります。 そのため、災害対応のために可用範囲分のサブネットを分ける場合には、特定のRegionで使用可能な可用範囲の数を予め確認する必要があります。 すべての可用範囲を使用しなくても、2つ以上の可用範囲を使用することが一般的です。 基本VPCでは、使用可能な範囲数だけ、ネットマスク20のサブネットを自動的に生成します。

参考

• サブネットを作成するときにはVPCのCIDR範囲が出て、その範囲より小さいCIDRブロックを指定する必要があります。
• たとえ、現在、VPCのIP範囲が、10.10.0.0から10.10.255.255までです。このサブネットのIP範囲は10.10.0.0から10.10.0.255まで使用します。 CIDRブロック表現法としては10.10.0.0/24です。
• サブネットを作ったからといって追加費用が発生するわけではないです。

サブネットはなぜ2個を作成するでしょうか？
サブネットを2つ作るのは変に思われるかもしれません。 AZ1つと連結された1つのサブネットのみでもEC2インスタンスを生成することは可能です。しかし、EC2をはじめとする多くのAWSのサービスではマルチAZという概念に対応しています。 これは、1つ以上の可用ゾーンに類似したリソースを同時に配置する機能です。
このようにする理由は障害対応と関連があります。 1つのリージョンには多数のAZがあります。 このAZは、単に仮想的に分離されているということではなく、物理的なスペースも分離されています。 したがって、多数のAZに類似したリソースを配置することで、1つのAZに問題が生じても、サービスに障害が発生しないよう設計することが可能です。 AWS では、リージョンあたり2つ以上のAZを提供し、2つ以上のAZ（サブネット）を前提にネットワークを設計することを推奨します。

VPCサブネットのインスタンスに対して、インターネットにアクセスを活性化するには次の手順が必要です。

1. VPC にインターネットゲートウェイを接続します。
2. サブネットのルーティング テーブルがインターネット ゲートウェイを指していることを確認します。
3. サブネットのインスタンスに全域的に固有のIP アドレス（パブリックIPv4 アドレス、弾力的IP アドレスまたはIPv6 アドレス）があるかどうかを確認します。
4. ネットワークアクセス制御およびセキュリティグループ規則において、適切なトラフィックがインスタンスへ、そしてインスタンスから流れることを確認します。

この4つの条件すべてを満たしている場合、インスタンスからのインターネットアクセスが可能になり、逆に外部からSSHに接続することも可能になります。

Route Table

Route Tableは、サブネットと接続されているリソースです。 サブネットでネットワークを利用するときは、このRoute Tableを使用して目的地を探します。 Route Tableはサブネットと接続されていますが、VPCを作成する際に作られ、VPCにも接続されています。 このRoute Tableは、VPC に属するサブネットを作成するときにデフォルトのRoute Tableとして使用されます。

1つのRoute Tableは、VPCに属する多数のサブネットで使用できます。 自動生成されるRoute Tableには、1つのルールだけが定義されています。 VPCのCIDRブロックを目的地と指定する場合、ターゲットはローカルルールになります。 たとえば、VPC の CIDR ブロックが 172.31.0.0/16 である場合に、このネットワークの中で目的地が 172.31.0.0/16 の範囲にある範囲を見つける場合は、VPC 内部で探します。 この規則は削除できません。*1 そして、インターネット接続や他のVPCと通信するためには、Route Tableにルートルールを追加定義する必要があります。

*1
先ほどVPC節ではVPCをデザインする際の注意すべき内容について紹介しました。 たとえば、私設網の CIDR ブロックを使用しなければならない理由は、Route Tableのデフォルト規則が VPC の CIDR ブロックによって占有されるためです。 したがって、私設網ではなく CIDR を使用すると、インターネットと接続するルート規則を定義しても通信できなくなります。 また、同様の理由で私設網に該当するCIDRブロックを使用しても、他のVPCと通信する際にCIDRが重なる部分とは通信できません。

Internet Gateway

VPCは基本的に隔離されますが、ネットワーク環境です。 したがって、VPCで生成されたリソースは基本的にインターネットを使用できません。 インターネットに接続するためにはインターネットゲートウェイが必要となります。 Route Tableにインターネット ゲートウェイ向けの適切なルールを追加すると、特定のサブネットがインターネットと接続されます。 でも、サブネットとゲートウェイをつなぐだけではインターネットが使えないのです。 インターネットを利用したいリソースはPublic IPを持っている必要があります。

DHCP Options Set

DHCP オプションセットとはTCP/IP ネットワーク上のホストで設定情報を配信するDHCP 標準であります。 この機能を使用するとドメインネームサーバー、ドメインネーム、NTPサーバー、NetBIOSサーバーなどの情報を設定できるようになります。 一般的に、VPC生成時に作られるDHCPオプションセットをそのまま使用します。

参考

• DHCPオプションセットはドメインネームサーバー、ドメインネーム、NTPサーバー、NetBIOSサーバーなどの情報を持っています。 一般的にはデフォルト値をそのまま使用します。

NetWork ACL/Security Group

ネットワークACLは、渡す(outbound)、貰う(inbound)トラフィックを制御する仮想ファイアウォールです。 1つのネットワークACLは、多数のサブネットで再利用できます。 EC2インスタンスを使ってみたらACLよりはセキュリティグループに慣れているはずです。 セキュリティ グループは、インスタンスの前段でトラフィックを制御する仮想ファイアウォールであるのに対し、ネットワーク ACL はサブネットの前段でトラフィックを制御する役割を果たします。 したがって、ネットワーク ACL のルールを通過しても、セキュリティ グループのルールを通過できなければ、インスタンスとは通信できなくなる場合があります。 この2つのリソースにより、安全なネットワーク環境を構築することができます。

Security Group

ACLがサブネットのトラフィックを制御するなら、セキュリティ グループはインスタンスのトラフィックを制御します。
VPCを作成する際に生成されるセキュリティグループは、VPC内部の通信を許可するための特別なルールを持っています。
まず、このセキュリティグループのアウトバウンド規則は、すべてのトラフィックに対して許可されています。
しかし、インバウントのルールが興味深いです。トラフィックを制御する規則のには、通常、CIDRを指定します。 興味深いのは、CIDRの代わりにセキュリティグループのIDを指定すると、該当するセキュリティグループを持つリソースに対してのみトラフィックをまわすことが可能です。 さらに興味深い点は、基本セキュリティグループ唯一のインバウンド規則のソースが、他ならぬセキュリティグループ自身のIDであるという点です。 一見変に見えますが、これらの規則を持つインスタンス間でトラフィックを許可するために使用されます。 したがって、VPC 内部のリソース間の通信を許可するためには、それぞれのリソースがすべてこのセキュリティ グループを使用する必要があります。

参考

1. ACL は、サブネットの先頭でファイアウォールの役割をするリソースです。
2. ACL には、インバウンドとダウンバウンドのルールが別にあります。
3. VPCと共に生成されるACLには、インバウンドとアウトバウンドルールがそれぞれ2つのルールがあります。
4. ルールの番号は優先順位を示します。
5. 番号が*のルールは、他のどのルールにもマッチしない場合に使用する基本ルールです。

まとめ

いかがでしょうか？？
そんなに難しい概念はないですね？
もちろんCIDRや、IPv4がなんや、IPv6がなんやするのがまだ良くわからないかもしれません。
しかし、AWSて、基本的に操作しやすいUI/UXを提供してるし、そこまで細かく見なくても、使えるには問題ないです。
入る前にも話しましたが、この記事で作成してる内容をすべて理解しなきゃいけない、とか理解しないと使えないとかではないです。
皆さんのAWSをより有効活用するためも一歩だと思い、これからもより深いベース知識を勉強し続けましょう。

次回、またネットワーク関連記事を持ってくるように私もガンガン勉強し続けます！