More than 3 years have passed since last update.

AWSアソシエイト試験に向けて4(VPC関係）

Posted at 2021-04-24

VPCの前にネットワークでのアドレス周りの知識について

IPアドレス

ネットワーク機器やWEBサイトの場所を特定するために使われるもの。
住所……というより識別コードみたいな印象が個人的にはある。
TCPやIPというプロトコル(通信に関する規則・手順。語彙としては儀礼という意味になるのでかなり厳格な意味合いを持つ)に則って使われている。
機器に付与されるのではなく、NIC(ネットワークインターフェースカード)という部分に付与される。

2進法かつ8bit×4の32bit値で構成されているものを10進法に直して表示されている。
つまり、180.16.1.10というIPアドレスの実体は10110100.00010000.00000001.00001010ということになる。
(10進数から2進数へ変換→8bitにするために8桁にならないところは前の桁に0で埋める)
ちなみにIpv4が一般的だが、振り当てがいっぱいいっぱいになってきているのでIPv6という規格に移行が始まっている。
IPアドレスはグローバル(一意)とプライベート(ユーザーの通信環境内で利用され、決められた範囲で自由に割り振れる)に分かれる。
個人レベルの話で大雑把な言い方をするとルーターにグローバルIPが振られていて、ルーターがそれをルーター内の目的の各プライベートIPへ通信を振り分ける形で普段の通信が行われているイメージ。

ネットワークの範囲とIPアドレスの関係

IPアドレスの利用可能な範囲がネットワークの範囲となる。
1番単純な例であると、ルーターの接続台数である。
例えばルーターが5台まで端末を接続できるといった場合に振り分けられるIPアドレスは5つとなり、すなわちその5つのIPアドレスがそのルーターのプライベートネットワークの範囲ということになる。
さらに細かくするとIPアドレスにはサブネットマスクが定義されることで、そのIPアドレスの範囲が決まることになる。
10.0.1.0/16のIPアドレスを例にして考えてみる。
この場合、サブネットは/16の部分で16bitまでをロックするという意味になる。
したがってこのIPアドレス内では10.0を頭にして、残りの1.0の部分(00000001~.00000000)の16bitの範囲でIPアドレスをさらに作成することでネットワークを分割できることになる。
その際に分割するときはサブネットマスクの値をさらに上げる(/16のままだと同階層のネットワークになるので、例えば/24にして固定する範囲をさらに広くする)。
このとき固定される範囲のことをネットワーク部と呼び、それ以外の利用可能な範囲をホスト部と呼ぶ。
こうしてサブネットを使ってIPアドレスの割当を行い、ネットワークの範囲を定義することをCIDR(Classeless Inter-Domain Routing)と呼ぶ。
プライベートIPアドレスの割り当ては余裕をもたせて行うのがベター。
ちなみにCIDR基準で割り当てられるサブネットあたりのIPアドレスの数はサブネットマスクが2進むごとに約1/4ずつ減っていく。
つまり、1つ下がるごとに約1/2で求められる。

ex.

/16 → 16379
/20 → 4091
/22 → 1019
/23 → 521

サブネットについて

まず、グローバルとプライベートのネットワークの間にはそれを仲介するNATと呼ばれるものが存在する。
例えば、AWSのVPCならNATゲートウェイがそれにあたる。
例えば端末は個々に割り当てられたプライベートIPアドレスでネットワークに繋がろうとするが、プライベートIPアドレスはグローバルネットワークにおいては一意とはなり得ないのでこのままでは利用できない。
そこでNATがプライベートIPアドレスをグローバルIPアドレスに変換する形で仲介することで、端末はネットワークに接続できるようになる……というのがNATの役割になる。
1対多の関係でグローバルIPアドレスとプライベートIPアドレスを変換する場合はNATではなく、IPマスカレードというものを使うことになる。
ちなみにAWSではデフォルトで1つアカウント作成時にパブリックサブネットが1つあるVPCが用意されている。

VPC

ここからが本題でVPC(Virtual Private Cloud)とはAWSにおける仮想ネットワーク空間をユーザー専用に切り出したものを指す。
特徴は以下の5点。

任意のIPアドレスを範囲選択して仮想ネットワークを構築
サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定
クラウド内外のネットワークの接続
インターネット経由での接続かVPN/Direct Connectでの接続かを選択できる。
同一リージョン内では複数のAZに跨がせることができる

またVPCにおける設定の上限数は以下の通り。

リージョンあたりのVPCは5まで
VPCあたりのサブネットの数は200まで
1リージョン内のElasticIPの数は5個まで
ルートテーブルあたりのルート上限数は100
VPCあたりのセキュリティグループの数は500まで
セキュリティグループあたりのルールの数は50まで

またAWSアカウントを作成するとデフォルトで以下のようなものが作成される。

サブネットマスク/16のIPv4のCIDRブロックのVPC(最大6万強のプライベートIPv4が作れる)
各AZ(アベイラビリティーゾーン)に/20のサブネット(最大4000強のIPアドレス、一部は使えない)
インターネットゲートウェイの作成(デフォルトのVPCに接続されている)
セキュリティグループ(デフォルトのVPCに適用)
ネットワークアクセスコントロール(ACL、これもデフォルトのVPCに適用)
DHCPオプションセット(AWSアカウントに紐付く)
パブリック、プライベートどちらにもDNSホスト名が付与される

VPCはVPCで用途別にウィザードで作成できる、そこで作成したものをカスタマイズするのがベターな作成方法。
つまり整理すると

AZにCIDR区分(サブネットマスク)でVPCが作られる
VPCのIPアドレスとサブネットマスクによって任意の数サブネットが作られる
必要に応じて作られたサブネットのうちインターネットゲートウェイにルーティングされるようなルートテーブルを持つサブネットを設定する(パブリックサブネット。インターネットゲートウェイへのルーティングがないものはプライベートサブネット)

という手順でVPCのネットワークレンジが決まる。
ちなみにCIDRは/16、サブネットは/24で作ることが推奨されているらしい。
プライベートサブネットからインターネットへ接続するためにはパブリックにNATゲートウェイを置き、そこからパブリックのゲートウェイに渡す手法を取る。
ではリソースとの通信はどうするのか?
VPCの外側にあるリソースとの通信はパブリックAWSネットワークかエンドポイントを利用する。
VPCを設計するときのポイントは以下の通り。

将来の拡張を考えた余剰性や他のネットワークとの接続性を考慮する
CIDRは既存のVPC及び社内ネットワークなどと被らないアドレス帯を設定し、既存の組織構成やシステム構成の将来像を考慮する
VPC構成は単体ではなく、VPC全体の関係性も考慮する
組織とシステム境界からVPCをどのように分割するかなど、将来の構成も考慮して設計する
複数AZを利用して可用性の高いシステムを構築する
サブネットは大きいサブネットを使い、パブリック/プライベートサブネットへのリソースの配置をインターネットアクセスの可否から検討する
セキュリティーグループを使って、リソース間のトラフィックを適切に制御する
実装や運用を補助するツールも有効活用し、VPC Flow Logsを使ってモニタリングできるようにする

VPCの分割

VPCを分割するケースとして考えられる例は以下の通り

アプリケーション毎にVPCを作る
監査の際に区分しやすいようにスコープとして分割
リスクレベルによって分割する
本番/検証/開発とフェーズごとに分割
部署や共通サービスごとに分割

通信プロトコルとOSI参照モデル

ネットワークにおける通信にはプロトコルと呼ばれる規格がある(ex.TCP/IP)。
例えばメールなら送信と受信とでSMTPとPOPとそれぞれプロトコルがある。
このプロトコルが通信においてどの層の規格なのかを表した1つのモデルがOSI参照モデル。

アプリケーション層

WEBアプリケーションなどの通信サービスの通信方式のプロトコルはここ。
メールなら前述の通りSMTP/POP、WEBならHTTP/HTTPSなど。

プレゼンテーション層

文字の送受信、文字コード、暗号についてのプロトコルはここ。
文字コード・圧縮・データ暗号及び復号……と文字の通信に関わる規定を作っている。

セッション層

アプリケーション間での一連の継続的な通信処理の継続やつながり(これらをセッションと呼ぶ)の仕方に関するプロトコルはここ。
セッションの確立・維持・終了までの手順を規定する。

トランスポート層

通信をする際に通信先との通信を許可するか否かチェックが入る。
この処理のことを信頼の確立といい、セッション開始前にそれを行うことやバケットの到着順序やその確認を行うためのプロトコルがここ。
セッション開始のための論理的回線の確立し、セッションを開始するためにポート番号の割り当てを規定する。

ネットワーク層

IPアドレスを利用したルーティング方法のプロトコルはここ。
ノード(通信の起点や終点(エンドポイント))間の通信を規定し、IPアドレスを利用した割り当てやルーターから宛先の端末への最適なパスの選択を行っている

データリンク層

MACアドレス(NICの識別番号)を利用したノート間の通信の方法のプロトコルはここ。
1つのネットワーク回線上で直接接続されたノード同士の通信を規定している。
例えばLANは同じネットワークセグメント(ネットワークのグループのようなもの)内におけるノード間の通信をEthernetを使ってMACアドレスを利用し実施している。

物理層

bitによるコンピュータ間の物理的なデータ伝送形式に関わるプロトコルはここ。
0と1のビット列を電気信号に変換することでネットワークへ伝送したりしているらしい。

TCP/IPモデル

OSI参照モデルをさらに実務的にまとめたモデル。
以下の4層へと圧縮される。

アプリケーション～セッション層 → アプリケーション層(HTTP、SSH、DNS、SMTP、POP、FTP……etc)
トランスポート層(TCP、UDP)
ネットワーク層(IP、ICMP、ARP、BGP)
物理層(Ethernet、PPP)

さてここで通信の処理フローの1例を見てみる。

アプリケーション層においてHTTPプロトコルを利用して、メッセージが送信される。
トランスポート層において信頼の確立が行われる
ネットワーク層において送信先にパケットが送付される
物理層にて相手側に電信の形で一連の処理が伝送される

このような処理フローのことをRequestと呼んだりする。

ポート番号

通信の出入口、部屋番号とか郵便ボックスみたいなもの。
OSにおけるデータ通信のためのエンドポイント。
インターネット上の通信プロトコルで、同じコンピュータ内で動作する複数のソフトウェアのどれが通信するかを指定するための番号である。
例えば

HTTPポート(80)
HTTPSポート(443)
SSHポート(22)
SMTPポート(25)
POPポート(110,143)

などがある。

セキュリティグループとネットワークACL

AWSにおいてインスタンスへのトラフィックのアクセス可否(つまり、どの通信方式でどのIPアドレスを許可するのかなど)のルールを設定する機能。
いわゆるファイアウォール的な機能になる。
対してネットワークACLはサブネットへのトラフィック制御、つまり仮想ネットワーク自体へのトラフィックを設定する機能になる。
両者の違いとしては

サーバー単位(セキュリティグループ)かVPCまたはサブネット単位か(ACL)
ステートフル(セキュリティグループ)かステートレスか(ACL)
許可のみの設定(セキュリティグループ)か拒否も設定できるか(ACL)
デフォルトの場合、同じセキュリティグループ内通信のみの許可(セキュリティグループ)かすべての通信を許可するか(ACL)
すべてのルールを適用する(セキュリティグループ)か番号の順序通りに適用するか(ACL)

といったもの。
ステートフルとステートレスはこの場合は前者がインバウンド(通信の入口側)ルールだけ設定すれば自動的にアウトバウンドも許可されるが、後者の場合はインバウンドだけ許可しただけではアウトバウンドは許可されないという違いになる。

コンソールで確認してみる

ここまでの一連の流れを実際にVPC等々を作りながら確認してみる。

まずVPCウィザードからパブリックとプライベートのそれぞれのサブネットを持つVPCを作成する。
設定は上記の通り。
パブリックでもプライベートでもAZは必ず指定することに注意。(リージョンによって選択できるAZは当然変わる)
また、パブリックサブネットを作るという意味合い(プライベートサブネットにNATゲートウェイ経由でインターネットゲートウェイと接続させる)から考えて、パブリックサブネットを作る場合はプライベートサブネットも同じAZに作るのがベター。
そして、サブネットは作っただけではプライベートのままなのでルートテーブルを設定することでパブリックサブネットへと変化させる。
ルートテーブルの役割はその名の通りルーティングなので、インターネットゲートウェイに対し当該IPアドレスの場所を示すことでインターネットゲートウェイからのパケットの通路を作ってやれる。(上記の設定の場合は10.0.0/24への経路ということになる)
VPCを作ると以下のようになる。

インターネットゲートウェイも先程作ったVPCに関連付けられたものが新たに作られているのがわかる。

次はサブネットを新たにもう一つ作る。
V先程作ったVPCを選択して任意の設定を行っていく。
CIDRブロックは先程までの過程ですでに使用しているものと被らないように注意(10.0.1.0まで使っているので10.0.2.0にするなどする)。
AZも先程とは違うAZを指定して作成する。

さて、これで現状を整理すると10.0.0.0/16のVPCの中にAZが2つある状態が出来上がり仮にAZa、AZcとすると

AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート)
AZc → 10.0.2.0/24サブネット(プライベート)

というVPC構成が出来上がっていることになる。
ただし、10.0.2.0/24サブネットのルートテーブルを確認してみると以下の通りルーティングがNATゲートウェイに通ってしまっていることがわかる。

ここからサブネット自体はプライベートであり、デフォルトだとインターネットゲートウェイにはルーティングが通っていないということが確認できる。
なので、関連付けを編集してインターネットゲートウェイへ通してやる。
ルートテーブルIDを10.0.0.0/24サブネットのものと同じもので指定すると以下の通り切り替わってくれる

一応10.0.0.0/24サブネットのルートテーブルの詳細情報も確認してみる。

これで10.0.0.0/24サブネットと10.0.2.0/24サブネットで同じルーティングができたことが確認できた。
さて今度はプライベートなサブネットを新たに作ってみる。
ここでパブリック・プライベートサブネット及びNATゲートウェイを使った通信フローを整理してみる。

Webからのアクセスがインターネットゲートウェイを通してやってくる
パブリックサブネットへパスされる、パブリックサブネットへのアクセスならここでResponseを返す
プライベートサブネットへのアクセスであるならパブリックからパスされ、Responseが返す
Responseはパブリックサブネット内のNATゲートウェイへパスされる
NATゲートウェイからインターネットゲートウェイへパス
WebへResponseが到着する

つまりNATゲートウェイはプライベートサブネット下にあるインスタンスに対して、更新処理等のRequestが外部のネットワークから行われたという場合に、外部ネットワークから直接プライベート下のインスタンスへアクセスさせないようにパブリックサブネットへ迂回させつつ、トラフィック(Response)を返すためのゲートウェイであることがわかる。
ここまで確認した上で新しくサブネットを作る。
現状は

AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート)
AZc → 10.0.2.0/24サブネット(パブリック)

という構成なのでこれを

AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート)
AZc → 10.0.2.0/24サブネット(プライベート)、10.0.3.0/24サブネット(プライベート)

という構成にする。
サブネットの作り方は省略して、サブネットを作成したら以下のようにNATゲートウェイを作成する。
このときサブネットの指定に注意、必ず同じAZ内のパブリックサブネットを指定する。
ElasticIPはVPCを作る際に作ったものでOK。

さて、作ったサブネットのルーティングを確認してみる。
一見問題なさそうに見える。

ところがルートテーブルIDをクリックして以下の画面を見るとステータスがblackhole(存在しないルーティング)になってしまっている。

NATゲートウェイは実は最初ウィザードで作ったときに自動的に1つ出来上がっていて、以降サブネットを作ると自動的にそれが割り当てられてしまうという仕様になっている。
で、問題はNATゲートウェイは課金対象なので無闇に放置をしておくと要らぬコストになってしまうので適宜削除する必要があるが、そうすると今回のようにサブネット作ったはいいもののNATゲートウェイが通ってない……というトラブルにあたってしまうことがある。
なので、その場合はルートの編集でblackholeなルーティングを削除して、先程作ったNATゲートウェイへのルーティングを行ってやればいい。

これで作ったサブネットに同じく新しく作ったNATゲートウェイを設定することができた。

ここまでの注意ポイント

ここまでのフローでの気をつけておきたい課金対象は

Elastic ID
NATゲートウェイ

の2点なので必要なければ削除をしておく。

ネットワークACLの設定

ここまでがVPCを作ったときに自動的に作成されたネットワークACLになる。
現状だとすべてのプロトコル及びすべてのトラフィックが許可されている状態なので、これを変更していく。

まずは新しくネットワークACLを作成する。

作成したネットワークACLを確認してみる。
インもアウトも両方ともすべての通信が許可されていないのがわかる。

よってそれぞれルールを作っていく。
ルール番号の順に適用される優先順位が決まるのでそれを意識して作る。
作り方はセキュリティルールと同じだが、下記のようにインとアウトそれぞれ設定することが必要である。

ルールを作ったらあとは適用するだけ。
適用したいサブネットを選択するだけでいい。

すると以下のような状態になり、新しく作ったACLの方へデフォルトのACLからサブネットの関連付けが移行されたのがわかる。

しかし、このままだと実際に使うときにエラーになる場合があるので以下のようにカスタムTCPでポート番号を広く拾うように設定してやる必要があるらしい。

NATゲートウェイを使った通信をEC2インスタンスを用いて確認してみる

いよいよ実際のリソースと通信できるかの確認に入る。
まずはインスタンスを2つ作る。
細かいところは省略して注意するところは

ネットワークは作成したVPCを選択する
同じくサブネットも作成したパブリックサブネットを選択する
同様に2つ目のインスタンスも作る、ただしサブネットは作成したプライベートサブネットを選択し、自動割当パブリックIPは無効にする(パブリックサブネットじゃないから)
セキュリティグループはどちらのインスタンスも同じものを適用する

以下は設定例。

インスタンスを作成したらTerminal等でアクセスを試みる。
無事、インスタンスへアクセスできたらまず、インスタンスをアップグレードする。
以下は実行コマンド、sudo suで管理者権限へ切り替えてから実行している。

実行できたら下記のようにComplete！と表示される。
これでパブリックサブネットへのアクセスが通っていてかつリクエストを行って、レスポンスも返ってきていることがわかった。
次に、プライベートサブネットへアクセスを試みる。
その前にまずキーペアをリソース内へ作る必要があるのでnano ファイル名コマンドで作成する。
コマンドを実行するとエディタが開くので、既存のキーペア(今のインスタンスへアクセスする際に使っているもの)の中身をコピペしてCtrl+Xでエディタを終了しようとすると保存するか聞かれるのでYesと入力してEnterで完了。
あとは作ったキーペアへの権限をchmodコマンドで与えてやる。
今回はchmod 400なので対象のファイルへの読み取り権限を与えている。

ここまでいったらあとはsshコマンドでプライベートサブネットへアクセスする。
先ほどと違ってssh ec2-user@プライベートサブネットのIPv4アドレス -i 先程作ったキーペアでアクセスできる。
下記は-iなしでもコマンドを打っている。
どちらにしろ信頼の確立がてきないという旨のエラーメッセージが出て、このまま進めるかどうか聞かれる。
おそらく、-iなしではYesを選択しても下記のようなエラーになるのだろう。
なので、-iを使ってちゃんとキーペアを指定してやった上でyesを入力するとプライベートサブネットへアクセスができる。

しかしパブリックと同じようにインスタンスの更新を行おうとすると下記のようにエラーになってしまう。

理由は簡単で、都度触れてきたようにプライベートサブネット内へのアクセスやRequestのフローはパブリックを介して行えるが、ResponseのフローはNATゲートウェイがないとできないのでRequestをしてもResponseを返せないので正常にインスタンスの更新が行えずエラーが出てしまうという次第である。
なので、NATゲートウェイを作ってやる必要があるので以下のように作成する。
パブリックサブネットに作らないと意味がないので注意。

あとは作ったNATゲートウェイをサブネットへ適用する。
当該パブリックサブネットは以下のようになっている(さっきNATゲートウェイは削除してあるので)ので、ルートの編集から適用してやればOK。

NATゲートウェイの適用が終わったら再度コマンドを実行する。
問題なければ下記のようにインスタンスの更新が完了するはず。

Direct Connectとは

同一アカウントに所属する別リージョンの同士の接続でも使われるが、実態はAWS環境とオンプレ環境(自社サーバー等自社で物理リソース等用意して構築している環境)とをAWS Direct Connect のパートナーまたはネットワークプロバイダーと契約することで連携し、接続する際の仲立ちをしているのがDirect Connect。
競合するというか比較される仕組みとしてはVPN(Virtual Private Network)というものがある。
VPNは簡単に言うとプライベートネットワークを拡張するもので、大学生なんかだと例えば学外から学内サーバーのコンテンツを利用する(オンライン授業とか履修登録……etc)というときにこれを使わされたという人がいると思う。
VPNとDirect Connectの違いは

ベストエフォートなのでコストが安価か(VPN)かキャリアで契約する必要があり割高(DC)
クラウド上での接続であるので即時利用可能である(VPN)か物理対応が必要なので利用までに1ヶ月強かかるか(DC)
暗号化のオーバーヘッドにより帯域幅に制限がある(VPN)かポートあたり1/10Gbsと広く使えるか(DC)
ネットワークの状態によって品質に影響がある(VPN)か通信キャリアによってある程度品質が保証されているか(DC)
インターネットベースなので自社由来以外の障害の特定が難しい(VPN)か物理ベースなので障害の特定が比較的容易か(DC)

というものになる。

VPCエンドポイント

グローバルIPを持つAWSサービスに対して、VPC内から直接アクエスするための窓口(出口)。
つまり、VPC外にあるAWSリソース等にアクセスするにはこれを設定しないといけない。
このエンドポイントの接続方法は2種類ある。

Gateway型

サブネットに特殊なルーティングを設定することでVPC外のサービスへと直接接続する
エンドポイントポリシーを設定してアクセス制御を行う
無料
冗長性はAWS側が対応
これを利用して接続するサービスはS3かDynamoDBのみ

PrivateLink型

サブネットにエンドポイント用のプライベートIPアドレスを設定し、DNSに名前解決させてルーティングさせる
セキュリティグループを作成してアクセス制御を行う
有料
冗長性はマルチAZ設計

VPC Flow Logs

ネットワークトラフィックを取得して、CloudWatchでモニタリングできるようにする機能。
取得できるものは以下の通り。

ネットワークインターフェースを送信元/送信先とするトラフィック
セキュリティグループ及びネットワークACLのルールで許可/拒否されたトラフィックログ
RDS、Redshift、ElasticCache、WorkSpacesのネットワークインターフェーストラフィック

利用に追加料金はかからず、キャプチャウィンドウと呼ばれる時間枠(10分程度の枠)で収集・プロセッシング・保存を行う。

VPC Peering

異なる2つのVPC間で通信をしたい(連携させたい)場合にこれを使うことでトラフィックルーティングが可能になる。
特徴としては

異なるAWSアカウント間のVPC間を接続できる
一部リージョン(中国等)を除いて異なるリージョンに存在するVPC間の接続もできる
単一障害点・帯域幅のボトルネックは存在しない
接続は1対ずつになる(3つのVPCを接続するにはAB、BC、CAと3つのVPC Peeringを設定しないといけない)
上記の点からあまり多くのVPC間を繋げることは不得手

という点が挙げられる。
似たようなサービスとしてはTransit Gatewayがあるがこちらはより複数のVPC間接続で利用される。

ここまでをハンズオンで確認

まずはエンドポイントで通信するということを確認する。
そのためにはS3へのIAMロールを付与しないといけないのでいつか作ったものをプライベートインスタンスの方へ適用していく。

で、Terminal等でインスタンスへアクセスし、プライベートインスタンスの管理者権限へ入って試しにログ取得のコマンドを打つ。
すると下記のようにフリーズする。
これはNATゲートウェイがないためである。
VPCエンドポイントがない以上外からのアクセスはすべてNATゲートウェイがないとプライベートインスタンスにおいては正常に処理されないことは度々見てきた通り。
なので、VPCエンドポイントを作る。