半年前に勉強会で話したAWS VPCルーティングについて改めて整理してみた

本記事は初夏のAWSアワードエンジニア祭り 10日目の記事です。
🍦 9日目 ▶▶ 本記事 ▶▶ 最終日 💻

2023 Japan AWS All Certifications Engineers発表時の裏話

NRIネットコムの望月です。初夏のAWSアワードエンジニア祭りもいよいよ明日で終わりです。
昨年に続き、2023 Japan AWS All Certifications Engineersに選出されました。

この認定は、

APN(AWS Partner Network)企業に所属している
AWSの認定資格を全て持っている

の2つの条件を満たしていれば、申請すると誰でも貰えるものです。

ところが、2023年4月20日に認定者の発表があった時点では、私の名前はありませんでした。
4回くらいはページリロードしましたね。
しかしながら、残酷なことに表示結果は変わらず「何故だ！！まぼろしか？？」と思いました。

おそらくは申請が正しくできていなかったのだろうと、救いのない自暴自棄に陥りかけました。チャンスは1年に1回ですし。
しばらく荒れた後に「こういう認定には縁がない人間なのだろう」と自分に言い聞かせ、大好きなスコッチウィスキーで落ち着かせたのを覚えてます。
むしろ、スコッチのおかげで絶好調になりました。

ところがその4日後の2023年4月24日。こんな記述とともにページが更新されていました。

2023 年 4 月 24 日：集計結果に誤りがあり、記載が漏れていた受賞者の方を掲載致しました。また、合計人数についても 578 名 → 580 名へ訂正しております。

こうして、晴れて私も2023 Japan AWS All Certifications Engineersに選出されたのです。
AWSさんのフェイントにはまったのは全国でたったの2名のみ。
中学・高校時代はSBもしくはCBを主戦場としていた私のディフェンス力を試されたのだと思います（まぁ見事に引っかかってますがw）。

580名中の2名ですよ？大変光栄に思います！

勉強会の復習をしてみます

さて、こうして私もAWSアワードエンジニア祭りを担当することになったのですが、昨年に登壇した勉強会の内容を記事にしてなかったので、この機会に書いてみます。
実は、NRIネットコムが開催する勉強会：TECH & DESIGN STUDYの初回登壇者は望月だったのです。

techplay.jp

私は元々、OSI参照モデルで言うところの第1層-第5層を住処としていたので、ネットワーク系のサービスは好きです。
勉強会では"初級~中級編"ということで、ネットワークの超初歩からVPCルーティングの話までしました。
前半と後半でかなりのレベル差があったために驚かれた方も多かったようですが、後半に関してはそれなりに為になったというコメントもいただいております。

というわけで勉強会の後半でお話した内容を中心に要約してみます。

1. 大忙しのVPC Router

VPC内の通信は、VPC Routerが繋いでくれます。
必ずVPC Routerを経由すると考えて、ほぼほぼ間違いありません。

EC2：1台 + RDS：1台構成でも、

EC2：2台 + RDS：1台構成でも、

同じサブネット内でも、

リソース間の通信はVPC Routerを経由します。
これは、各リソース（正確にはENI）のデフォルトルートがVPC Routerを向いているからです。
ちなみに、VPC RouterのIPアドレスは各サブネットのホスト部の2つ目のアドレスです。
各サブネットで使用できるホスト部のうち、3つはAWSで予約されています。
これにネットワークアドレスとブロードキャストアドレスを加えた計5つは使用できません。

2. ルートテーブルの役割

ルートテーブルの役割は、VPC Routerにルーティング情報を書き込むことです。
デフォルトで作成される"local"をターゲットとするルートはVPC内の通信を意味しており、これがVPC内のリソース間の通信を可能にしている正体です。
ルートテーブルでは、通常のルーティングと同じく宛先とネクストホップを指定します。

ルートテーブルはサブネットにアタッチして使用します。
パブリックサブネットとプライベートサブネットの違いは、デフォルトルートがInternet Gatewayを向いているかどうかの違いだけです。
"全ての通信はVPC Routerを経由する"ことを理解しておくと、VPC内のルーティングの見え方が変わってくることでしょう。

3. パターンで見るVPCルーティング

全ての通信はVPC Routerを経由する、ルートテーブルはVPC Routerにルーティング情報を書き込む。
この2点を理解しておけば、もうAWSのネットワークは怖くありません。
一般的なVPCルーティングのパターンをいくつか書いていきますので、理解の補足になれば幸いです。

・インターネットからのアクセス
VPC内のリソースに対してインターネット越しにアクセスする際には、リソースはパブリックサブネットに配置されている必要があります。
プライベートサブネットは、インターネットからのアクセスに対する戻りのルートを持ちません。

また、グローバルIP ⇔ プライベートIPの変換はInternet Gatewayで行われます。ElasticIPによる予約と動的割り当てがありますが、詳細は割愛します。
当然、NAT Gateway経由でのグローバルIP変換についても同様です。

・拠点間接続
拠点間接続はサイト間VPNもしくは専用線接続（DirectConnect）を使用します。
ルーティングは行きと帰りの両方があって初めて成立します。そのため、VPC Routerにはオンプレ向けのルートを、オンプレからはVPC向けのルートをそれぞれに設定する必要があります。
下図の例では、仮想プライベートゲートウェイを使用してサイト間接続を行っていますが、Transit Gatewayを経由しても基本的な考え方は同じです。詳細については割愛します。

・VPC間接続
VPCを跨ぐリソース間の通信を実現する方法はいくつかあります。
VPC peering、Transit Gateway、プライベートリンク、インターネットアクセス、etc..
ここではTransit Gatewayを例にルーティングを整理してみます。
なお、Transit Gateway経由でVPC間を接続する際には、各VPCのCIDRに重複は許されないので注意が必要です。
Transit Gatewayアタッチメントを作成するサブネットは、いくつかの理由で専用のサブネットを用意することが推奨されています。その理由と詳細については、いつか記事にしようと思います。
VPC内のリソースがTransit Gatewayを使用する場合には、VPC Router、Transit Gatewayアタッチメントを経由してからTransit Gatewayに抜けていくという点がポイントです。

・VPC Endpoint
VPC Endpointは、ものすごく平たく言うとAWSサービス間のプライベート通信を実現するものです。
VPC内のリソースがVPC外のサービスを使用する際、通常はInternet Gatewayを経由したインターネットアクセスとなりますが（※）、各サービスエンドポイントを使用することでAWS外に出ない経路でのセキュアな通信が可能です。
VPC Endpointにはゲートウェイ型とインターフェース型があり、それぞれの違いについてはいろんな記事があるので参考にしてください。

下図はゲートウェイ型エンドポイントのルーティング例です。
ゲートウェイ型のエンドポイントは、関連付けるルートテーブルを作成時に指定します。
ルートテーブルにはpl-xxxxxという宛先のエントリーが追加されますが、plはプレフィックスリストの略で、対象のAWSサービスのIPをリストとしてまとめたものです。
つまり、ゲートウェイ型エンドポイントの正体は、インターネットゲートウェイを経由する代わりに、特定のサービスに対する出口を提供しているだけなのです。

上記はゲートウェイ型の例でしたが、インターフェース型の一例としてプライベートリンクの有用性について昨年記事にしていたので、紹介しておきます。

tech.nri-net.com

（※）AWSサービス間の通信はプライベートなのか？
これは、結論を出すのが難しい問題です。
以下は、我らが佐々木さんのつぶやき。

これがプライベートネットワークの通信と明示された意味は大きい

『Q:2つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスが AWS のサービスのパブリックエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?』https://t.co/uy26KyCZKn
— Takuro SASAKI (@dkfj) 2021年4月22日