Amazon VPCを「これでもか！」というくらい丁寧に解説

はじめに

AWS上で仮想ネットワークを構築できるAmazon VPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。

多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。

そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、

「VPC界の百科事典」 (あくまで例えですが…笑)

となるような記事を目指したいと思います。

【追記】 実践編の記事を追加しました

VPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい！」という方は、こちらもご一読いただけると嬉しいです。

VPCとは

「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。

例えば、オンプレ環境でWebアプリ(3層アーキテクチャ)と社内システムを運用するために、以下のようなネットワークを構築していたとします。

これをVPC上の仮想ネットワークで代用すると、以下のようになります（※こちらの公式ドキュメントの構成を参考にした一例です）

上図を見ての通り、オンプレでのネットワーク構築と設計思想が似ている部分 (例: DMZとパブリックサブネットが対応している)と異なる部分 (例: AWSにはS3やRoute53のようなVPCネットワーク外のサービスが存在)があり、セキュアかつ高性能なシステムを構築するためにはVPC独自の機能を広く理解する必要があります。

なお、VPC内に設置するサービスと、VPC外部に存在するサービスの一覧は、以下の記事が参考になります。

図を見るとLambdaやS3はVPCの外にあるように見えますが、Lambdaは設定次第でVPC内に設置することができますし、S3使用時も後述のVPCエンドポイント経由で他のサービスからアクセスする事が多いです。

また図には記載されていないFargateもVPC内に設置するサービスであり、AWSの主要サービスの多くがVPCと密接に関連している事が分かります。

VPCのメリット

多くのAWSサービスはネットワークを構築しなくとも個別に通信する事ができますが、この方式では成り行きで通信経路が決まってしまうため、セキュリティや性能面での制御が難しくなってしまいます。
これに対しVPCを利用することで、以下のようなメリットを得る事ができます。

• 通信経路を絞って監視・アクセス制御を行うことで、セキュリティを向上させる
• 通信経路を明示的に制御してロードバランサ等でスケールアウトすることで、性能を担保できる
• 通信経路を明示的に複数確保することで、可用性を向上させる事ができる
• システム内のサービスを整理して一括管理する事で、運用・保守性を向上させる事ができる
• IaCサービスと組み合わせることで、移行性を向上させる事ができる

これらの項目をまとめると、VPCの利用が「非機能要件」の担保 (後述)に大きく寄与することがわかります。

VPCの役割

システム・アプリ開発においてネットワーク設計は、以下の非機能要件 (※IPAの定義を参照)を満たす上で大きな役割を果たします。

1. 可用性 → 必要なときにいつでもサービスが提供されており、停止していない
2. 性能・拡張性 → 必要な速度が確保されている＆利用者が増えても対応できる
3. 運用・保守性 → 運用監視や問題発生時の対応を適切に行える
4. 移行性 → 新環境への移行の容易性
5. セキュリティ → 不正アクセスを防止する
6. システム環境・エコロジー → システムの設置環境や、自然環境に与える影響

オンプレにおけるネットワーク設計の難しさ

オンプレ環境においては、上記要件を満たすために高度なネットワーク機器の知識および機器を揃えるためのコストが必要となります。
例えば可用性を向上させるためには、サーバや回線を冗長化した上で、自動でバックアップに切り替えるための設定 (下図のリンクアグリゲーション等)を実施する必要があります。

上記の専門知識、コストが、一般エンジニアや小規模組織が適切な非機能要件を実現するためのハードルとなり、結果不十分な対策によりシステム障害やセキュリティ事故に繋がることも多々あります。

AWSのネットワーク設計上のメリット

一方でAWSでは、可用性やセキュリティ向上のための施策がデータセンタに組み込まれているため、デフォルト状態でもある程度高い非機能要件が確保されています。

加えて、さらに非機能要件を向上させるためのサービスが多数準備されており、これらを組み合わせるだけで高度な非機能要件を実現できてしまいます。

よって専用機器の購入や高度なハードの知識が不要となるため、小規模組織でも適切な非機能要件を実現しやすくなります。

VPCはこれらのサービス同士をネットワークで繋ぐ基盤となるため、可用性やセキュリティ向上のために正しい知識の会得は不可欠と言えます。

AWSにおけるネットワーク関連サービス一覧

参考までに、ネットワーク上で非機能要件を向上させるための主なAWSサービスを列挙します。

サービス名	該当する非機能要件	概要
ELB	1.可用性, 2.性能・拡張性	ロードバランサによる過負荷防止
Cloud Front	1.可用性, 2.性能・拡張性	CDNによるアクセス速度向上と過負荷防止
Route 53	1.可用性, 2.性能・拡張性, 5.セキュリティ	ヘルスチェックによる可用性向上、DNSラウンドロビンによる拡張性向上、DNSファイアウォールによるセキュリティ向上
Network Firewall	5. セキュリティ	サブネットに対するアクセスルールを設定する
WAF	5. セキュリティ	Webアプリに対する一般的な攻撃パターンをブロックする
Direct Connect	5. セキュリティ	専用線接続によるセキュリティ向上
(おまけ:AWSと環境負荷)	6. システム環境・エコロジー	AWS等の大規模クラウドプロバイダは世界平均よりも炭素強度が28%低い電源構成を使用しているとの事

これらのサービスは後述のVPC機能紹介で頻繁に登場する事から分かるように、基本的にVPCと連動した動作が前提となっています。

上記から、AWSのネットワーク構築および非機能要件担保において、VPCは基盤となる重要なサービスであることが分かります。

VPCの仕組みと主要機能

VPCの仕組みと主要機能について、以下の項目に分けて解説します。

• ネットワークの基礎知識
• VPCの構造
• ルートテーブル
• VPCと外部ネットワーク・サービスとの接続
• VPN
• VPCのセキュリティ機能
• IPアドレス管理用サービス
• VPCとログ

ネットワークの基礎知識

既にご存知の内容も多いかと思いますが、VPCを理解するためにはネットワークの知識が必要となるため、簡単に解説します。

IPアドレスとは

ネットワークの階層構造を表すOSI参照モデルにおいて、ネットワーク層で通信相手を識別する際に使用される番号です。

階層	名称	通信相手の識別に使用する情報
第7層	アプリケーション層	プロトコルにより異なる
第4層	トランスポート層	ポート番号
第3層	ネットワーク層	IPアドレス
第2層	データリンク層	MACアドレス
第1層	物理層	物理的な接続

※第5層(セッション層)、第6層(プレゼンテーション層)はTCP/IPではアプリケーション層と一体化されるため省略します

ネットワーク層は主に広域での通信で主要な役割を果たすため、IPアドレスをインターネットおよび組織ネットワーク上での住所とみなすと、理解しやすいかと思います。

IPアドレスの構造

IPアドレスには32ビットの数値で表される「IPv4」と、128ビットの数値で表される「IPv6」が存在しますが、2022年時点ではIPv4が主に使用されます

IPv4のIPアドレスは32ビットの数値で表され、10進数では以下のように8ビットごとにドットで区切られて表現されます。

	10進数での表記	2進数での表記
例1	192.168.1.2	11000000 10101000 00000001 00000010
例2	8.8.8.8	00001000 00001000 00001000 00001000

グローバルIPアドレスとプライベートIPアドレス

・グローバルIPアドレス

世界中で一意に定められるIPアドレスを「グローバルIPアドレス」と呼びます。

グローバルIPアドレスはインターネット経由でのアクセスに用いられ、文字通りインターネット上での「住所」に相当するアドレスとなります。

AWSにおいては、グローバルIPアドレスは「パブリックIPアドレス」と呼ばれる事も多いです。

・プライベートIPアドレス

限られた範囲内で用いられ、その範囲内のみ一意に定める必要がある(範囲外では重複が許される)IPアドレスを、「プライベートIPアドレス」と呼びます。

「限られた範囲」は、一般的に組織が相当することが多いため、組織内のネットワークをビルに例えた時の「部屋番号」とみなすと理解しやすいかと思います。

どのようなアドレスがプライベートIPアドレスとなり、どのようなアドレスがグローバルIPアドレスとなるかは、後述の「使用可能なIPアドレス」を参照ください

ネットワーク部とホスト部

IPアドレスは、ネットワーク部とホスト部に分けられます。

32ビットのIPv4アドレスであれば、上位xビットのネットワーク部と、下位32-xビットのホスト部に分かれ、例えばIPアドレス192.168.1.2においてネットワーク部が24ビットであれば、

	10進数表記	2進数表記
IPアドレス全体	192.168.1.2	11000000 10101000 00000001 00000010
ネットワーク部	192.168.1の部分	11000000 10101000 00000001
ホスト部	2の部分	00000010

となります。

また、ネットワーク部を1、ホスト部を0ビット表記したものをサブネットマスクと呼びます。
例えばネットワーク部が24ビットであれば、サブネットマスクは255.255.255.0(2進数では11111111 11111111 11111111 00000000)となります

ネットワーク部の長さは、サブネットマスク長またはプレフィックス長と呼ばれる事もあります。

またホスト部を全て0で埋めたアドレスはネットワークアドレスと呼ばれ、後述のサブネット自身を表すアドレスとして使用されます。

サブネット

ネットワーク部が等しいIPアドレス範囲のことをサブネットと呼び、サブネットを表すアドレスをネットワークアドレスと呼びます
(サブネットのことを単に「ネットワーク」と呼ぶこともあります)

サブネット外へのアクセスにはルーティングが必要となるため、ルーティングテーブル(後述)やファイアウォール(こちらも後述)によるアクセス制御は基本的にサブネット単位で行われ、ホストのグルーピングやセキュリティ向上のためにサブネットは重要な要素となります。

CIDR (Classless Inter-Domain Routing)

通常、プライベートIPアドレスのプレフィックス長は、後述のクラスA～Cの固定値(8ビット、16ビット、24ビット)が使用されます。
これだけでは3通りのプレフィックス長しか使用できないので、ホスト数によってはアドレス空間が大幅に余ってしまい、無駄の多いネットワークとなってしまいます。

そこで、上記3通り以外のプレフィックス長を動的に設定できるようにしたCIDR (Classless Inter-Domain Routing、「サイダー」と読みます)と呼ばれる機構が広く用いられています。

CIDRにおいてネットワークアドレスを表す記法をCIDR記法と呼び、例えば192.168.1.2においてネットワーク部が26ビットであれば、ネットワークアドレスは192.168.1.0/26のように表記します。

使用可能なIPアドレス

IPアドレスの指定にはICANNという組織がルールを定めており、用途に応じて使用できるアドレス範囲が決められています。

VPCでプライベートIPアドレスとして使用できるのは、以下太字のアドレス範囲のみです。
下記の範囲内から作成するサブネットのネットワークアドレスを決定してください。

IPアドレスの範囲	用途
127.0.0.0〜127.255.255.255	ループバックアドレス (自分自身を指すアドレス)
169.254.0.0〜169.254.255.255	リンクローカルアドレス (ルータを経由せずにアクセスするためのアドレス)
224.0.0.0〜239.255.255.255	マルチキャストアドレス (予め定められたルールで複数のアドレスに同時送信する際に使用)
255.255.255.255	制限ブロードキャストアドレス
10.0.0.0〜10.255.255.255	プライベートアドレス (クラスA=プレフィックス長8bit)
172.16.0.0〜172.31.255.255	プライベートアドレス (クラスB=プレフィックス長16bit)
192.168.0.0〜192.168.255.255	プライベートアドレス (クラスC=プレフィックス長24bit)
上記以外	グローバルアドレス等

また、AWSにおいて以下のホスト部はAWS側で利用されているため、ユーザ側が新たにホストに設定することはできません。

ホスト部	用途	ネットワークアドレスが10.0.1.0/28のときの例
0	ネットワークアドレスを表す	10.0.1.0
1	VPCルータ	10.0.1.1
2	Amazonが提供するDNSサービス	10.0.1.2
3	AWSで予約されているアドレス	10.0.1.3
全ビットが1	ブロードキャストアドレス	10.0.1.15

NAT

NATとNAPTについて解説します。

・NAT

グローバルIPアドレスとプライベートIPアドレスを変換する機構を、NAT (Network Address Translation)と呼びます。

・NATによる変換例

グローバルIPアドレス	プライベートIPアドレス
a.b.c.d	192.168.0.1
a.b.c.e	192.168.0.2

通常インターネット上からプライベートIPアドレスにアクセスする事は出来ませんが、NATを使用する事により、グローバルIPアドレス宛に届けられたパケットの宛先をプライベートIPアドレスに変換する事で、プライベートIPアドレスが設定されたホストにアクセスすることができます。

・NAPT

NATはIPアドレスのみを変換対象としますが、IPアドレスに加えてポートも変換対象とする機構を、NAPT (Network Address Port Translation)と呼びます。

多くの一般家庭ではグローバルIPアドレスは1個しか割り振られないため、NATでは1個のプライベートIPアドレスしかインターネットからアクセスできませんが、NAPTを使用する事で1個のグローバルIPアドレスに複数のプライベートIPアドレスを紐づけられるため、複数のプライベートIPアドレスにインターネットからアクセスする事ができます。

・NAPTによる変換例

グローバルIPアドレス	グローバル側ポート番号	プライベートIPアドレス	プライベート側ポート番号
a.b.c.d	80	192.168.0.1	80
a.b.c.d	81	192.168.0.2	80

なお、NATとNAPTを合わせて(広義の)NATと呼ぶことも広く行われています。

ルーティング

ルーティングとは、サブネットの結節点において他のサブネットとの通信経路を決定する制御を指します。
自サブネット以外との通信にはルーティングが必要となるため、複数のサブネットが存在するネットワークにおいて必須の技術と言えます。

ルーティングのルールを定めるテーブルをルーティングテーブルと呼び、宛先IPアドレスとルーティングテーブルに基づいてどのサブネットにパケットが送信されるかが決定されます。
ルールの決め方には、IPアドレスに基づいて毎回同じ経路が選択される「静的ルーティング」と、動的に経路が決定される「動的ルーティング」が存在しますが、VPCでは基本的に静的ルーティングを使用します (VPNやトランジットゲートウェイ使用時はBGPによる動的ルーティングでオンプレネットワークと連携することもできます)

・ルーティングテーブルの見方

ルーティングテーブルは、ロンゲストマッチアルゴリズムと呼ばれる方法に基づいてパケットの送信先を決めます。
ロンゲストマッチアルゴリズムとは、送信したい宛先IPアドレスとルーティングテーブルの宛先ルート(一般的に複数登録されている)を比較し、宛先アドレスをサブネット内に含む宛先ルートの中で、最もプレフィックス長が長いものを選択する手法です(詳細は後述)。

選択された宛先ルートと同一行を参照し、主にインターフェイス(パケットが送出されるルーターのポート)とネクストホップ(次に転送されるルータ)からパケットの送信先が決定されます。

例として以下のようなオンプレネットワークを考えます。

ルータ1のルーティングテーブルが以下のように設定された場合を考えると

宛先ルート	インターフェイス (パケットが送出されるルーターのポート)	ルーティング方法	ネクストホップ (次に転送されるルータ)
172.31.1.0/24	0	直接接続	-
172.31.2.0/24	1	直接接続	-
172.31.3.0/24	1	静的ルーティング	172.31.2.2
0.0.0.0/0	1	動的ルーティング(OSPF)	動的ルーティングで決定

例えば宛先アドレスが172.31.3.4の場合、このアドレスがサブネット内に含まれる宛先ルートには172.31.3.0/24と0.0.0.0/0の2つの候補が存在しますが、よりプレフィックス長の長い前者が選択され、静的ルーティングに基づいてインターフェイス(IF)1からパケットが送出され、ネクストホップに基づいて172.31.2.2のルータ2に転送されます（これ以降の経路はルータ2のルーティングテーブルに基づいて決定されます）

また、もう一例として宛先アドレスが8.8.8.8の場合を考えると、このアドレスがサブネット内に含まれる宛先ルートは0.0.0.0/0に絞られ、IF1からパケットが送出されます。この行では動的ルーティングが選択されているため、ネクストホップをルータ3にするかルート4にするかは、ルーティング方法(OSPF,RIP,BGP等)や経路内の障害情報に基づいて動的に選択されます。

難しいですね。実際、オンプレネットワークにおいてルーティングの設定は高度なスキルが必要とされる分野の一つであり、VPCではよりシンプルなルーティング設定が実現できることも、クラウドを使用するメリットの一つとなります。

・オンプレとVPCのルーティングの違い

オンプレネットワークにおいては、サブネット間の結節点である「ルータ」がルーティングを実施します。
一方でVPCにおいては、「ルートテーブル」というサービスを使用する事でサブネット (後述)ごとにルーティングを制御できます。

VPCではルータ同士の物理的な位置関係や、動的ルーティングを考慮しなくとも良いので、オンプレよりもシンプルなルーティングを実現できます

DHCP

DHCP(Dynamic Host Configuration Protocol)とは、ホストにネットワーク関係の情報を渡すためのプロトコルです。

一般的に、ホストにプライベートIPアドレスを動的に割り振る際に使用されますが、それ以外にもDNSサーバのIPアドレスやデフォルトゲートウェイ(ルーター)のIPアドレス等の情報がホストに渡されます。

業務向けシステムではDHCP機能を実現するDHCPサーバが置かれる事が一般的ですが、一般家庭で使用されるルータにもこのDHCP機能が標準装備されていることが多く、これによりユーザが特別な設定をしなくとも、プライベートIPアドレスが割り振られてネットワーク通信ができたり、DNSによる名前解決でドメイン名(URL)からホームページにアクセスする事が出来ます。

VPCにおいても、後述のElastic IPを使用しない限りはこのDHCP機能が働き、VPC内部のインスタンスのIPアドレスは動的に割り振られます (再起動するとIPアドレスが変わる)

なお、名前が似ているDHCPオプションセットは本来のDHCPの主機能であるIPアドレスの振り分けには使用されれず、DNSサーバやNTPサーバ等の情報をホストに渡す機能のみを持つ事にご注意ください。

外向き通信と内向き通信

本記事では「外向き」と「内向き」という言葉が頻繁に登場しますが、

外向き：内部ネットワーク(VPC等)からインターネット方向への通信
内向き：インターネットから内部ネットワーク(VPC等)方向への通信

を表しています。

注意すべきが、インターネットで最も一般的に用いられるTCP通信では、下図のように基本的に要求と応答のセットで通信が行われるため、基本的に片方向のみで通信が完結する事はないということです。

※画像はWikipediaより

このような双方向の通信を扱う際に、「ステートレス」と「ステートフル」の2種類の考え方が存在します。

・ステートレス

パケットが要求であるか応答であるかは考慮せず、通信の方向のみで外向きか内向きかを判定する方法をステートレスと呼びます。

・ステートフル

通信の起点となる要求パケット(SYNパケット)の方向が外向きなら、それに付随する応答パケットも全て外向きとして扱う方法を、ステートフルと呼びます

ステートフルは最初の要求パケットの方向のみを考慮すれば良いため、後述のファイアウォールの設定をシンプルにすることができます。よって多くのファイアウォールではステートフルな設定を採用しています。

ファイアウォールとACL

ファイアウォールは、特定のルールに基づいてネットワーク上の通信を制限するための機構で、通信を制限するためのルールを記述したリストをACL(Access Control List)と呼びます。

ACLではIPアドレスとポート番号に基づき通信を制限する事が一般的で、特定の条件のみ通信を許可し、それ以外を全て拒否する「ホワイトリスト(Allow)」式と、特定の条件のみ通信を拒否し、それ以外を全て許可する「ブラックリスト(Deny)」式が存在します。

また前述のように通信方向の評価には、行きの通信と戻りの通信を別々に評価するステートレス方式と、行きと戻りをまとめて評価するステートフル方式が存在します。

一般的にはセキュリティ強度の高いホワイトリスト式、かつ設定が容易でミスを防ぎやすいステートフル方式がよく用いられており、VPCでもこの方式を採用した「セキュリティグループ」の使用が推奨されています。

この方式でのACLの例を下記します。

・ACLの例

許可するIPアドレスの範囲	許可するポート	許可する方向	(想定する通信)
0.0.0.0/0	443	内向き	(HTTPS)
192.168.0.0/24	22	内向き	(SSH)
0.0.0.0/0	80	外向き	(HTTP)
0.0.0.0/0	443	外向き	(HTTPS)

上例では任意のIPアドレスからポート443番への内向きアクセス、サブネット192.168.0.0/24内のホストからポート22番への内向きアクセス、任意のIPアドレスへのポート80番、443番への外向きアクセスを許可し、それ以外の通信を遮断しています。
(一般的には外向きアクセスの方が許可を緩めに設定し、外向きは全ての通信を許可しているケースも多いですが、近年は外向き通信を使用したサイバー攻撃用サーバ(C&Cサーバ)との通信による被害が増えているため、外向き通信にも制限を設けるケースが増えています)

また、ファイアウォールが前述のNATを兼ねている事も多く、この場合両者をまとめてインターネットとプライベートネットワークとの結節点に設置されます。

VPCの構造

VPCの基本的な構造を解説します

リージョンとAZ

AWSのデータセンターは、東京、バージニア州、シンガポール等の広域的な位置を表す「リージョン」と、リージョン内で地理的に一定距離(数km前後)離れた複数のデータセンターを表す「AZ」(アベイラビリティゾーン)から構成されます。

VPCで非機能要件を向上させるためには、このリージョンとAZによる物理的位置の考慮が非常に重要となるため、それぞれ解説します。

・リージョン

データが実際に保存される地理的な位置を表します。
全世界に数十個のリージョンが存在しますが、日本からの使用頻度が高いリージョンは以下となります。

・主なリージョン

リージョン名	英名	場所	特徴
アジアパシフィック (東京)	ap-northeast-1	日本 東京都	日本国内からの利用では第一の選択肢となる
アジアパシフィック (大阪)	ap-northeast-3	日本 大阪府	西日本からの通信遅延（レイテンシ）が少ないが、機能が限定されている（例：Transfer Accelerationが使用不可）
アジアパシフィック (シンガポール)	ap-southeast-1	シンガポール	アジアで最初のリージョン
米国東部 (バージニア北部)	us-east-1	米国 バージニア州	世界で最初のリージョン、費用が安めでサービスが豊富。日本からは通信遅延大

当然ながら、異なるリージョン間での通信では遅延(RTT)が大きくなり、またデータ転送コストも増えるため、基本的には需要地と近いリージョンを選択する事が両者の利便性向上に繋がります。

・ アベイラビリティゾーン（AZ）

1つのリージョンは、実は地理的に離れた複数のデータセンターから構成されています。
実際の位置は公開されていませんが、例えば品川区と江東区にサーバが分散されているようなイメージです。

この個々のデータセンターのことをアベイラビリティゾーンを呼び、複数のアベイラビリティゾーンを跨いだ構成（マルチAZ）とすることで、リージョンを跨いだ場合と同様に可用性向上およびデータの消失対策に繋げられます。

VPCのベストプラクティスでもマルチAZ構成による可用性向上が推奨されており、冒頭のVPC構成例でもマルチAZによる並列なネットワーク構築を実施しています。具体的な構築法は別記事(作成中)で解説します。

VPCとその上限個数

1つのAWSアカウントには複数のVPCを作成する事ができ、それぞれのVPCは以下の条件を満たす必要があります

• VPCはリージョンをまたげない (VPCを作成するリージョンを一意に指定する必要あり)
• VPCはAZをまたげる (AZをまたぐ事でマルチAZ構成を実現できる)
• 1アカウントで1リージョンあたり最大5個までVPCを作成可能(申請すれば6個以上も可能)

VPCには、以下のように16～28ビットのプレフィックス長を用いることができます

• 最小サイズ → /28 (11ホスト)
• 最大サイズ → /16 (65531ホスト)

また、以下の「デフォルトVPC」がアカウント作成時にデフォルトで作成されます。

・デフォルトVPC

AWSアカウント作成時には、リージョンごとにVPCが1個自動的に作成されます。
これを「デフォルトVPC」と呼び、ネットワークアドレス172.31.0.0/16が割り当てられています。
デフォルトVPC内には

• AZごとに1個 (バージニア北部リージョンは計6個、それ以外は計3個)のパブリックサブネット
• 1個のセキュリティグループ
• 1個のルートテーブル
• 1個のインターネットゲートウェイ
• 1個のネットワークACL
• 1個のDHCPオプションセット

が予め作成されています

VPCとサブネット

VPC内部には、以下のように複数のサブネットを作成する事ができます。

このVPCとサブネットの階層構造が、VPCにおける基本的なグルーピング単位となります。

サブネットにはVPCに設定したプレフィックス長よりも長いプレフィックス長を設定することで、VPC内に複数のサブネットを格納することができます

このサブネット内に、EC2やRDS、Fargateのような各種サービス (インスタンス)を設置することで、最終的なVPCのネットワークを構築します。

パブリックサブネットとプライベートサブネット

セキュリティの観点からは、インターネットと直接通信できるホストは最小限に絞ることが望ましいです。
これを実現する方法として、ネットワークを「インターネットと直接通信できるサブネット」と「インターネットと直接通信できないサブネット」に分ける方法が一般的に用いられます。

・パブリックサブネット

インターネットと直接通信できるサブネットを「パブリックサブネット」と呼びます。
パブリックサブネットは外部から(へ)のアクセスが必要なWebサーバやプロキシサーバを設置するという特性上、前述のオンプレネットワークにおけるDMZと近い役割を果たします。

VPCからインターネットに接続するには後述のインターネットゲートウェイへの接続が必要なので、「パブリックサブネット」=「インターネットゲートウェイにルーティングされるサブネット」と言い換えることもできます。

・プライベートサブネット

インターネットと直接通信できないサブネットを「プライベートサブネット」と呼びます。
前述のオンプレネットワークにおける内部ネットワークと近い役割を果たします。

インターネットとの通信が必要ないインスタンスをプライベートサブネットに設置する事で、外部からのアクセスを最小限に抑え、システム全体のセキュリティを高めることができます。

プライベートサブネット内のインスタンスは基本的に同一VPC内のみと通信を行いますが、以下のように踏み台サーバをパブリックサブネットに作成して経由することで、VPC外部からアクセスすることができます。
(外部へのアクセスが必要な場合は後述のNATゲートウェイ等を使用します)

ルートテーブル

前述のように、VPCにおいてルーティングによるサブネット外への通信経路制御を実現するのが「ルートテーブル」です

ルートテーブルにおける宛先指定方法

VPCのルートテーブルは、ロンゲストマッチアルゴリズムに基づき宛先ルート (VPC画面では「送信先」と表記)を選択するという点では、オンプレのルーティングテーブルと共通しています。

一方でオンプレのルーティングテーブルでは「インターフェイス」と「ネクストホップ」に基づきパケットの送信先を定めていたのに対し、VPCのルートテーブルでは送信先のサービスを指定します。
送信先のサービス（以下の実画面における「ターゲット」）には、インターネットゲートウェイやEC2のインスタンス、Gateway Load Balancer エンドポイント等を指定する事ができ、柔軟な経路制御を実現できます。

サブネットごとのルートテーブル指定方法

ルートテーブルはサブネットごとに作成する事が可能ですが、この際に重要となる概念が「メインルートテーブル」と「サブネットルートテーブル」です

• メインルートテーブル：VPCごとに自動で作成されるルートテーブル(編集も可能)。サブネットルートテーブルが設定されていないサブネットに適用される
• サブネットルートテーブル：ユーザが自分で作成し、サブネットと紐づけるルートテーブル

デフォルト状態で設定したいルートテーブルをメインルートテーブルに記述し、このルールから外れたサブネット独自のルートテーブルを作成したい場合、サブネットルートテーブルを使用するのが良いかと思います（以下参照）

また前述のようにインターネットゲートウェイがターゲットに設定されているサブネットが、パブリックサブネットとなります。

VPCと外部ネットワーク・サービスとの接続

VPCとVPC外部のネットワークやサービスとを接続するために、以下のような機能が準備されています
(よく使われる機能は太字にしています)

※有料サービスが多いので、料金にご注意ください

名称	VPC内部の接続対象	外部の接続対象	料金 (リンク先に料金表)
インターネットゲートウェイ	パブリックサブネット	インターネット	外向き通信量に課金
NATゲートウェイ	プライベートサブネット	インターネット(外向き通信のみ)	利用時間＋通信量に応じ課金
Egress Only インターネットゲートウェイ	プライベートサブネット	インターネット(IPv6の外向き通信のみ)
キャリアゲートウェイ	AWS Wavelength内のサブネット	インターネット(5Gネットワークのみ)	外向き通信量に課金
エンドポイント	VPC全体	他のAWSサービス	インターフェース型のみ有料 (ゲートウェイ型は無料)
エンドポイントサービス	VPC全体	他アカウントのAWSサービス	後述
VPCピアリング	VPC全体	他のVPC	AZをまたぐ場合、通信量に応じ課金
トランジットゲートウェイ	VPC全体	他のVPCやオンプレネットワーク	利用時間＋通信量に応じ課金

種類が多いですが、基本的には「内部の接続対象」と「外部の接続対象」を決めれば、使用すべきサービスは絞られるかと思います。

以下、詳細を解説します。

インターネットゲートウェイとNATゲートウェイ

インターネットゲートウェイ、NATゲートウェイは共にVPC内からインターネットに接続するために使用されますが、以下のような差があります

名称	インターネット接続対象のサブネット	IPアドレスの変換方法	許可される通信方向
インターネットゲートウェイ	パブリックサブネット	NAT	外向き、内向き
NATゲートウェイ	プライベートサブネット	NAPT	外向きのみ

・インターネットゲートウェイ

インターネットゲートウェイはパブリックサブネットを作成する際に必ず必要となるサービスであり、インターネットとの外向き、内向き双方向の通信を許可します。

インターネットゲートウェイではグローバルIPアドレスとプライベートIPアドレスが1対1で変換されるため、NATとしての機能を果たします。

・NATゲートウェイ

プライベートサブネットからは通常インターネットにアクセスできません(後述のエンドポイント経由のyumコマンドを除く)が、セキュリティパッチ更新等のためにインターネットにアクセスしたい場面も度々生じます。このような用途のためにプライベートサブネットから外向きの通信のみを許可する(内向きは許可しない)サービスが、NATゲートウェイです

NATゲートウェイはプライベートサブネットのインターネット接続を実現するサービスですが、NATゲートウェイ自身はパブリックサブネット上に設置されます。

なお名前が紛らわしいですが、NATゲートウェイは前述した狭義のNATではなく、ポートを含めて1対多でグローバルIPとプライベートIPを変換するNAPTとしての機能を果たします。
グローバルIPとプライベートIPを1対1変換する狭義のNATの役割を果たすのは「インターネットゲートウェイ」ですので、ご注意ください
詳細は以下の記事が分かりやすいです。

また、NATゲートウェイは比較的料金お高めのサービスのため、多くの場合後述のエンドポイント等の他サービスを使用した方がコストを節減できる場合が多いです。NATゲートウェイの使用頻度を減らしてコストダウンする方法については、以下の記事が分かりやすいです。

上記記事に記載されているように、構成によっては「NATインスタンス」を使った方がコストを節減できることもあります。NATインスタンスはNATゲートウェイと同様の機能をインスタンスとして実現する古いサービスですが、ユーザ側の管理の手間が増えるため、大きな価格差がないのであればNATゲートウェイを使用することが推奨されています。

Egress Only インターネットゲートウェイ

IPv6専用のインターネットゲートウェイで、外向きの通信のみを許可する(内向きは許可しない)という意味で、IPv4におけるNATゲートウェイと同様の役割を果たします("Egress"とは「出力」を表します)

詳細は以下の記事をご参照ください

キャリアゲートウェイ

AWS Wavelengthと呼ばれる、5Gモバイルネットワーク専用のAZと5Gネットワーク網との間に設置されるゲートウェイです。

こちらも新しいサービスのため情報が少ないですが、以下の方が記事にされています。

なお、この機能は大阪リージョンでは使用できません。

エンドポイント (VPCエンドポイント)

エンドポイントは、VPC内のインスタンスとVPC外のAWSサービスとをインターネットを経由しない接続(プライベート接続)で通信できるようにする機能です。

VPCと他のAWSサービスとの接続はインターネットゲートウェイやNATゲートウェイ経由でも実現できますが、コスト面でエンドポイントを使用した方がメリットが大きいです。

エンドポイントは大きく以下の2種類に分けられます

• インターフェイスエンドポイント ：AWSサービスにVPC内のIPアドレスが割り振られる(仮想NICとして機能する)方式。見かけ上はVPC内での通信で完結しているように見えるため、設定がシンプルで管理しやすいが、アクセスに料金が発生する (下図のEndpoint network interfaceが相当)

• ゲートウェイエンドポイント ：グローバルIPを持ったAWSサービスへのルーティング設定が追加される方式。VPC外の機器という扱いとなるため、ACL等の設定がやや複雑となるが、アクセスは無料。S3とDynamoDBのみ使用可能 (下図のVPC endpointが相当)

図を見ると分かりますが、接続先のAWSサービスはインターフェイスエンドポイントではVPC内のホスト(サブネット内にIPアドレスが存在する)、ゲートウェイエンドポイントではVPC外のホスト (VPC外のグローバルIPアドレスが割り振られ、ルーター経由でルーティングされる)として認識されていることが分かります
詳細は以下をご参照ください

なお、2021年以降のAWSサービス間の通信は基本的にエンドポイントを利用しなくともインターネットを経由しないようです。
よって、よくテック記事等で見かける「エンドポイントを利用しないと通信がインターネットを経由するが、利用するとインターネットを経由せずセキュアになる」というメリットは成立しなくなっていますが、以下のようにセキュリティ面、コスト面で多数のメリットが存在するため、VPCと他のAWSサービスとの接続時には、エンドポイントをインターネットゲートウェイやNATゲートウェイよりも優先的に採用して良いかと思います。

※ゲートウェイエンドポイント経由でプライベートサブネットからyumコマンド実行

通常、プライベートサブネットからインターネットへアクセスするにはNATゲートウェイが必要となります。
これはyumコマンドで各種パッケージをアップデートする際も同様です。

一方で、OSにAmazon Linuxを使用している場合のみ、NATゲートウェイなしでもS3用のゲートウェイエンドポイント経由でyumコマンドを実行する事ができます。

これにより、コストが増大しがちなNATゲートウェイなしでパッケージのアップデートを実現できるので、コスト削減にぜひご活用下さい

エンドポイントサービス

エンドポイントサービスは、他のAWSアカウントにVPC内のサービスへのインターネットを経由しないアクセスを提供する機能です。

エンドポイントサービスは大きく以下の2種類に分けられます

名称	概要	料金
インターフェイスVPCエンドポイント	Network Load Balancer(NLB)経由でVPC内のサービスへアクセスする。最近まで唯一の選択肢だった	インターフェイスエンドポイントのコスト＋NLBのコスト
Gateway Load Balancerエンドポイント	Gateway Load Balancer(GWLB)経由でVPC内のサービスへアクセスする。2020年に追加された新しいサービスで、スケーリングやサードパーティのセキュリティ製品との連携に優れるとのこと	Gateway Load Balancerエンドポイント＋GWLBのコスト

なお、「エンドポイントサービス」は前述の「エンドポイント」とAWS内のサービス間でインターネットを経由しないセキュアな通信を提供するという意味で共通しており、まとめて"PrivateLink"と呼ばれる事もあります。

VPCピアリング

VPCピアリングとは、VPC同士を接続し、お互いに通信できるようにするための機能です。
VPC同士を接続するケーブルの役割を果たします。

VPCピアリングではルーティングテーブルに相手のVPCへのルーティングが追加されるため、オンプレネットワークにおけるルーターのようにふるまいます。

※画像はAWS公式より

接続対象のVPCは異なるアカウントのものでもよく、異なるリージョンにあってもよいですが、異なるリージョンにある場合IPv6での通信ができないことにご注意ください。

なお、CIDRブロックの重複が許されない、ピアリングを経由したインターネットやVPNへの接続ができない等、ピアリング経由の通信にはいくつか制約があります。詳細は以下の記事が分かりやすいです。

トランジットゲートウェイ

トランジットゲートウェイは、VPCピアリングと同様にVPC同士を接続できるサービスですが、VPCピアリングが2個のVPCを接続するケーブルの役割を果たすのに対して、トランジットゲートウェイは3個以上のVPCを放射状に接続する事ができます。

多数のVPC同士を接続したい際に構成がシンプルになるのみならず、オンプレネットワークとのVPN接続(後述)を追加することもできます。

但し、VPCピアリングよりも若干通信料金がお高めのため、どちらを選択するかはコストと利便性のバランスを見て判断してください。

トランジットゲートウェイにも異なるリージョン間のVPCを直接接続できない等の制約があります。詳細は以下の記事が参考になります。

VPN (仮想プライベートネットワーク)

仮想プライベートネットワークは、VPCとオンプレネットワーク間に仮想的なプライベートネットワークを作成するサービスです。

VPNの通信路は実際にはインターネット内に作成されるのですが、トンネリングと呼ばれる技術を用いる事によって、遠く離れた2点 (AWSの場合、VPCとオンプレネットワークそれぞれのゲートウェイ)をあたかも同一点であるかのように扱えます。
これによりセキュアな通信路を確保できるため、社内ネットワーク等によく利用されています。

AWSでは、以下の2種類のVPNを使用できます。

名称	オンプレ側のVPN接続地点	トンネリングプロトコル	料金 (リンク先に料金表)
Site-to-Site VPN	オンプレネットワーク上のルーター (カスタマーゲートウェイ)	IPsec	利用時間※＋通信量に応じ課金
クライアントVPN	クライアントPC	SSL-VPN	利用時間に応じ課金

※Acceleratedサイト間VPNで高速化すると時間料金に追加料金が上乗せされます

また、VPN以外にもVPCとオンプレを専用線で繋ぐDirect Connectというサービスも存在します

Site-to-Site VPN (サイト間のVPN接続)

Site-to-Site VPNは、VPCの仮想プライベートゲートウェイと、オンプレネットワーク上のルーター(カスタマーゲートウェイ)との間にトンネリング通信路を作成します。

・Site-to-Site VPNの概要図

上図のように、VPNで接続されたプライベートネットワーク内はインターネットから直接アクセスできないため、オンプレネットワークとVPC間にセキュアな通信路を確保できます。

VPNにはいくつかの種類がありますが、Site-to-Site VPNではIPsecと呼ばれる方式が用いられています。

以下、各種ゲートウェイとこれらを繋ぐトンネリング (Site-to-Site VPN)について解説します

・仮想プライベートゲートウェイ

トンネリングのAWS側の出口となるゲートウェイです。

・カスタマーゲートウェイ

トンネリングのオンプレ側の出口となるゲートウェイです。

利用にはゲートウェイとして設定するオンプレミス環境のルーターのIPアドレスやAS番号、認証のための証明書が必要となります。

・サイト間のVPN接続 (Site-to-Site VPN)

上記のゲートウェイ間を接続するトンネリング通信路を作成します。

通常のVPNに加えて、追加料金を払って「Acceleratedサイト間VPN」を有効化すると、高速なVPN接続を実現できます。

各種ゲートウェイとSite-to-Site VPNの接続パターンは、以下の記事が参考になります。
(前述のトランジットゲートウェイと組み合わせることもできます)

クライアントVPN

Site-to-Site VPNではVPCとオンプレネットワーク上のルータを接続していました。
一方でクライアントVPNでは、VPC上に設置したクライアントVPNエンドポイントとクライアントPC間に直接トンネリング通信路を作成することができます。

ルータを介する必要がないので、ノートPC等でVPNを使用したいときに非常に便利です。

VPN接続はクライアントPCにOpenVPNというオープンソースのVPNソフトウェアをインストールする事で実現し、SSL-VPNと呼ばれる方式 (HTTPS通信で使われるSSL/TLSと同様の暗号化方式)が用いられています。

またVPC側にはクライアントVPNエンドポイントを設置する必要があります。
設定方法は以下の記事が分かりやすいです。

VPCのセキュリティ機能

VPCにはセキュリティを高めるためのファイアウォールに相当する機能として、以下の3サービスが準備されています。

名称	外部側フィルタ対象	フィルタ方式	戻り通信の扱い	内部側フィルタ対象
ネットワークACL	外部側IPアドレス + ポート番号 + プロトコル	ホワイトリスト + ブラックリスト	ステートレス	サブネットごと
セキュリティグループ	外部側IPアドレス (セキュリティグループID, プレフィックスリストも指定可) + ポート番号 + プロトコル	ホワイトリスト	ステートフル	インスタンスごと (セキュリティグループIDでグルーピング)
ネットワークファイアウォール	外部側IPアドレス (ドメインリストも指定可) + ポート番号 + プロトコル	ホワイトリスト + ブラックリスト	ステートフル + ステートレス	サブネットごと (ドメインリストも指定可)

※「プロトコル」とは？

フィルタ対象として前述のIPアドレスとポート番号に加え、「プロトコル」と呼ばれる要素が加わっていますが、何を表すのでしょうか？

この「プロトコル」は、IANAが定義するトランスポート層のプロトコル番号を指しており、UDPとTCP等、IPアドレスとポート番号だけでは見分けられれないプロトコルを特定するために使用されます。
UDPやTCP等のトランスポート層プロトコルと、ICMP等のネットワーク層プロトコルが混在しているため、混乱しやすいのでご注意ください。

とはいえ、実際に選択する際には該当するアプリケーション層プロトコルの名称が併記されているので、それほど迷う事はないと思います。

どれを使う？

前者2つの違いは以下の記事で分かりやすくまとめられております

AWS公式では触れられていませんが、以下のような多くのサードパーティーの記事では、ネットワークACLよりもセキュリティグループを優先して使用する事が推奨されています。

主な理由として、ステートレスかつホワイトリストとブラックリスト両方を指定可能なネットワークACLは設定が煩雑で、ステートフルかつホワイトリストのみで指定するセキュリティグループは設定がシンプルであり、ミス等を防ぎやすい事が挙げられます (他にも、サブネット単位でしかルール設定できないネットワークACLと比べ、セキュリティグループはインスタンス単位でより細かいアクセス制御ができることも挙げられます)

以下で各機能について詳説します。

ネットワークACL

ネットワークACLは、サブネットごとにIPアドレスやポート番号(通信プロトコル)に基づきアクセス制限を設定する機能で、その名の通りACLを使用します。

前述の「ファイアウォールとACL」の定義と照らし合わせると、ネットワークACLは

• ホワイトリスト(許可)とブラックリスト(拒否)両方を設定可
• 行きと戻りを別々に評価するステートレス方式
  の評価方法となります。

前述のように、多くのファイアウォールでは設定をシンプルにするために「ステートフル」なACLを採用している事が多いですが、ネットワークACLは「ステートレス」のため、設定が煩雑となりがちです。

そのため、多くの記事ではネットワークACLよりもステートフルなセキュリティグループ (後述)を優先して使用することを推奨しています。

セキュリティグループの使用が推奨される理由は他にもいくつかあり、以下の記事で分かりやすく解説されております。

なお、VPC作成時にはデフォルトのネットワークACLが作成され、VPC内の全サブネットに必ず適用されます。
デフォルトのネットワークACLは全ての通信を許可する設定となっている(＝一切のアクセス制限を実施しない)ため、ここから追加でセキュリティグループやネットワークACLを編集・作成することで、アクセス制限を適用する事ができます。

セキュリティグループ

セキュリティグループも、ネットワークACLと同様にルールに基づくVPCへのアクセス制限を実現する機能ですが、インスタンス単位、あるいはインスタンスのグループ単位でアクセス制御可能 (ネットワークACLはサブネット単位)であることが特徴です。

ネットワークACLはフィルタリングのルールにサブネット(CIDR)を指定しますが、セキュリティグループはCIDRに加えセキュリティグループID、マネージドプレフィックスリストも指定する事ができるため、より柔軟で細かいアクセス制御が可能となります。

他にも

• ホワイトリスト (ネットワークACLはブラックリスト＋ホワイトリスト)
• ステートフル (ネットワークACLはステートレス)

という特徴を持ち、ネットワークACLと比べてシンプルでミスを防止しやすい設定が可能と言えます。

なお、セキュリティグループに設定可能なインスタンスはEC2に限らず、RDS(データベース)やELB(ロードバランサ)
等も設定できます。

また詳細は別記事(作成中)で紹介しますが、同一セキュリティグループ内の通信も明示的に許可しないとアクセス不可である事にご注意ください (内部間のアクセスは遮断しないオンプレのファイアウォールと挙動が異なる)

ネットワークファイアウォール

セキュリティグループはホワイトリスト形式のため「特定のターゲットをブロックしたい」といった用途で使用する事は出来ません。また、ブラックリスト形式のネットワークACLはステートレスなため、前述のように設定が複雑となりミスを引き起こしやすいというデメリットが存在します。

そこで、両者の欠点を補えるよう2020年に登場したサービスが、ネットワークファイアウォールです。
ネットワークファイアウォールはホワイトリスト・ブラックリスト両者、かつステートレス・ステートフル両者を設定可能で、柔軟なアクセス制御を実現できます。

また、ネットワークACLやセキュリティグループはVPC上に「ルール」を設定するだけで動作しましたが、ネットワークファイアウォールは以下のようにVPCのサブネット上に「ファイアウォールエンドポイント」というオブジェクトを設置する必要があります
（ファイアウォールエンドポイントはルートテーブル上ではGateway Load Balancer エンドポイントとして認識されます。またエンドポイントはAZごとに設置する必要があります）

注意点として、ネットワークファイアウォール使用時はルートテーブルを編集して、インターネットとの通信が必ずファイアウォールエンドポイントを経由するよう設定する必要があります。
例えばWebアプリにおけるネットワークファイアウォールの設置方法や、WAF・サードパーティのファイアウォールとの使い分けに関しては、以下の公式ドキュメントで詳細に解説されています。

ネットワークファイアウォールにより通信の流れを上記のような図で可視化する事ができるため、オンプレのネットワークに慣れている人には直感的に理解しやすい構成となります。一方でルートテーブル等の設定すべき項目が複雑となってしまう事や、料金が高めであること(かつAZごとに必要なため、冗長化するとさらに高額となる)がデメリットとなります。
よって比較的上級者向けのサービスと言え、初心者はなるべくセキュリティグループを使用する事が望ましいでしょう。

IPアドレス管理用サービス

デフォルト設定では、サブネット内部に作成したインスタンスのIPアドレスは成り行きで動的に作成されます。

成り行きでは管理が難しいため、IPアドレスを固定したり、複数のIPアドレスをグルーピングすることで、より制御された管理を実現するために以下のようなサービスが準備されています。

名称	概要
Elastic IP	インスタンスに固定のグローバルIPアドレスを割り振る
マネージドプレフィックスリスト	複数のIPアドレスをグルーピングし、セキュリティグループやルーティングの設定を一括管理する

Elastic IP

通常、VPC内部のインスタンスのグローバルIPアドレスは、DHCP機能により動的に付与されるため、インスタンスを停止 ⇨ 再起動するたびにIPアドレスが変わってしまいます。
このIPアドレスの変化を防ぐために固定のグローバルIPアドレスを割り振る機能が、Elastic IP (EIP)です。
Elastic IPにより、インスタンスを再起動しても同一のIPアドレスでアクセスできるようになります。

Elastic IPは稼働中のEC2インスタンスに付与した場合は無料ですが、休止中のEC2インスタンスに使用する場合やインスタンスと紐づいていない場合は$0.005/hの料金が掛かるのでご注意ください。

Elastic IPは、EC2インスタンス以外にもNATゲートウェイ、Network Load Balancer(NLB)でも用いる事ができ、この場合1つのElastic IPアドレスを複数のインスタンスやサービスで共有する事ができます。

マネージドプレフィックスリスト

マネージドプレフィックスリストは、複数のプレフィックス(CIDRブロック、サブネット)をグルーピングするための機能です。

マネージドプレフィックスリストを利用することで、セキュリティグループやルートテーブルの設定を一括管理できるため、管理の手間を減らす事ができます。

マネージドプレフィックスリストには、次の2つのタイプがあります。

• カスタマー管理プレフィクスリスト ：ユーザ側で独自に作成したプレフィックスリスト

• AWSマネージドプレフィクスリスト ：AWS側で予め準備されているプレフィックスリスト。カスタマー管理プレフィックスリストと同様にセキュリティグループやルートテーブルを設定できるが、ユーザ側でプレフィックスリスト自体を変更、削除することはできない

詳細は以下の記事が参考になります。

また2022/5現在、AWSマネージドプレフィクスリストには以下の3種類 (CloudFront, S3, DynamoDB用)が準備されています。

このうちS3, DynamoDB用は前述のゲートウェイエンドポイント使用時にルートテーブルの送信先に設定するため、VPC内からS3, DynamoDBにアクセスする際は重要な役割を果たします (S3での設定法に関しては別記事で紹介(記事作成中)します)

VPCとログ

VPCには、内部のENI (EC2インスタンス, ELBなどに紐づけられたネットワークインターフェイス)に出入りするIPトラフィックを記録するフローログと呼ばれる機能が存在します

公式ドキュメントでは、フローログのユースケースとして以下が挙げられています

• 制限が厳しすぎるセキュリティグループルールを診断する (想定外の通信拒否の有無を確認できる)
• インスタンスに到達するトラフィックをモニタリングする
• ネットワークインターフェイスに出入りするトラフィックの方向を特定する

以下で、実際に記録される内容と保存場所について解説します

フローログの構造

フローログは、以下のような構造となっています。　　

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

上記だけでは分かりづらいですが、以下のようなフィールドから構成されています(公式ドキュメントでの解説)

フィールド名	上例での値	内容
version	2	フローログのバージョン
account-id	123456789010	VPCが所属するAWSアカウントID
interface-id	eni-1235b8ca123456789	トラフィックが記録されるENIのID (送受信元のインスタンスやELB等と紐づく)
srcaddr	172.31.16.139	送信元のIPアドレス
dstaddr	172.31.16.21	受信先のIPアドレス
srcport	20641	送信元ポート
dstport	22	受信先ポート
protocol	6	トラフィックのIANAプロトコル番号
packets	20	フロー中に転送されたパケットの数
bytes	4249	フロー中に転送されたバイト数
start	1418530010	フローの最初のパケットが受信された時間 (UNIX秒)
end	1418530070	フローの最後のパケットが受信された時間 (UNIX秒)
action	ACCEPT	トラフィックの許可状況 (ACCEPT: 承認、 REJECT: セキュリティグループやネットワークACL等により拒否)
log-status	OK	ログのステータス (OK: データは選択された送信先に正常に記録、 NODATA: 集約間隔内に対象ENIへのトラフィックなし、 SKIPDATA: 集約間隔内に一部のフローログレコードがスキップ (内部的なキャパシティー制限、または内部エラーが原因の可能性あり))

例えばactionフィールドから想定外のREJECTとなっているトラフィックがないかを確認することで、前述の「制限が厳しすぎるセキュリティグループルールの診断」を実施する事ができます。

見ての通り生のログを目視で確認するのは大変ですが、他の多くのログと同様にCloudWatch Logsで要約や各種検知を実施したり、Amazon Athenaを利用して分析すると効率よく活用できるかと思います

フローログの保存場所

フローログの保存場所は、以下から選択する事ができます。

• CloudWatch Logs
• S3

こちらのサイトをみる限り、2つの保存場所は以下のように使い分けるとよさそうです。

フローログの保存場所	用途
CloudWatch Logs	ネットワークトラフィックの特定のアクセス傾向を検知してアラームを発する場合
S3	フローログを蓄積してAthenaで分析する場合

具体的なフローログの取得方法は、以下の記事で解説します

記事作成中

フローログの料金

フローログの料金は、以下のページから参照する事ができます。

保存場所にCloudWatch Logsを使用する場合は「例4. CloudWatch Logsに配信されたVPCフローログのモニタリング」を、
S3を使用する場合は「例3. S3に配信されたVPCフローログのモニタリング」を参照下さい

VPCとコスト

VPCの料金については、以下のサイトが大変分かりやすいので、こちらをご参照ください。

要点としては、以下に特に気をつける必要があるかと思います。

• NATゲートウェイにコストが掛かりがちなので、むやみに大量使用しない
• NATゲートウェイのコスト削減のため、S3やDynamoDBアクセス時はエンドポイントを使用すると良い
• AWS外部からの受信は無料だが、外部への送信はデータ転送量がかかる
• AWS内部でも、リージョンを跨ぐとデータ転送量が増大する

また、フローログの料金に関しては前述の「フローログの料金」を参照ください

VPCコンソール画面の見方

AWSコンソールにログインしてVPCのサービスに入ると、以下のような画面が表示されます。

「VPCダッシュボード」は、現在のアカウントが保持しているVPCリソースが一覧表示されています。

「左側のタブ」（ナビゲーションペイン）からはVPC各リソースの設定画面に飛べるので、それぞれ簡単に解説します

EC2 Global View

全リージョンのVPCリソースおよびEC2インスタンスの数が一覧表示されます。
他のリージョンの情報も含め簡易的に確認したい場合に便利です

VIRTUAL PRIVATE CLOUD

VPC

前述のVPCの作成、一覧表示、設定を行います。

サブネット

前述のサブネットの作成、一覧表示、設定を行います。

ルートテーブル

前述のルートテーブルの作成、一覧表示、設定を行います。

インターネットゲートウェイ

前述のインターネットゲートウェイの作成、一覧表示、設定を行います。

Egress Only インターネットゲートウェイ

前述のEgress Only インターネットゲートウェイの作成、一覧表示、設定を行います。

キャリアゲートウェイ

前述のキャリアゲートウェイの作成、一覧表示、設定を行います。

DHCPオプションセット

DHCPと名前が付いていますが、DHCPサーバの主機能として解説した動的なIPアドレスの振り分けでなく、VPC内部のインスタンスから使用するDNSサーバやNTCサーバを指定するために使用されます。
(Elastic IPの項で解説したようにVPC内部のIPアドレスはデフォルトで動的に振り分けられます)

内部のEC2インスタンス等からDNSサーバやNTCサーバを使用したい場合、一括で指定ができて便利です。

詳細は以下の記事が分かりやすいです。

Elastic IP

前述のElastic IPの作成、一覧表示、設定を行います。

マネージドプレフィックスリスト

前述のマネージドプレフィックスリストの作成、一覧表示、設定を行います。

エンドポイント

前述のエンドポイントの作成、一覧表示、設定を行います。

エンドポイントのサービス

前述のエンドポイントサービスの作成、一覧表示、設定を行います。

NATゲートウェイ

前述のNATゲートウェイの作成、一覧表示、設定を行います。

ピアリング接続

前述のVPCピアリングの作成、一覧表示、設定を行います。

セキュリティ

ネットワーク ACL

前述のネットワークACLの作成、一覧表示、設定を行います。

セキュリティグループ

前述のセキュリティグループの作成、一覧表示、設定を行います。

Reachability Analyzer

VPC内の任意の2つのサービス(リソース)間において、お互いが通信できるかを分析するツールです。
VPCやサービス作成後の動作確認、トラブル時の疎通確認等に使用できます (有料サービスなのでご注意ください)

詳細は以下の記事が分かりやすいです

※2022/6現在、大阪リージョンでは使用できません

NETWORK ANALYSIS

Network Access Analyzer

ネットワークがネットワークアクセス要件を満たしているかを分析するツールです (有料サービスなのでご注意ください)

「ネットワークアクセス要件」だけでは何のことだか分かりませんが、主にVPCと外部ネットワーク・サービスとの接続で紹介した外部との接続サービスへの経路を可視化し、想定外の経路=セキュリティリスクが存在しないかを分析する事ができます。

使用法等は以下の記事が分かりやすいです

※2022/6現在、大阪リージョンでは使用できません

DNS Firewall

通常のファイアウォール (前述のセキュリティグループやネットワークACL,ネットワークファイアウォール)はIPアドレスとポート番号に基づき通信を制限しますが、DNS Firewallはドメイン名(ホスト名)の名前解決に制限を加える機能となります。

これにより、サイバー攻撃(DNSキャッシュ汚染,マルウェア感染等)の第2段階として行われる不正なサーバ (C&Cサーバ)との通信を防ぐ事ができます

厳密にはRoute53の機能となるため詳細解説は割愛しますが、以下の記事が参考になります

ネットワークファイアウォール

前述のネットワークファイアウォールの作成、一覧表示、設定を行います。

仮想プライベートネットワーク (VPN)

前述のVPNを構成するカスタマーゲートウェイ、仮想プライベートゲートウェイ、Site-to-Site VPN、クライアントVPNエンドポイントの作成、一覧表示、設定を行います。

AWS CLOUD WAN

VPCとオンプレミス間を接続する方法には、前述のSite-to-Site VPN、クライアントVPN、トランジットゲートウェイ、Direct Conntect等多くのサービスが存在し、これらの個別に管理すると多大な手間が掛かってしまいます。

そこで、これら複数のオンプレネットワークやVPC間の接続を統合的に管理できるようにした2021年リリースの新機能が、AWS クラウド WANです。

詳細は以下の記事が分かりやすいです

※2022/6現在、大阪リージョンでは使用できません

TRANSIT GATEWAY

前述のトランジットゲートウェイおよび付随したTransit Gatewayアタッチメント、Transit Gatewayルートテーブルの作成、一覧表示、設定を行います。

トラフィックのミラーリング

ミラーリングとは、ネットワーク上を流れているデータ (トラフィック)を他の場所にコピーした上で、各種検査を行う事を指します (有料サービスなのでご注意ください)

検査の目的としては、異常なトラフィックの判別による攻撃検出や、監査等に使用するログを残すための法令対応等が挙げられます。

詳細は以下の記事が分かりやすいです

※2022/7現在、大阪リージョンでは使用できません

VPCの構築方法

下図のVPC構成 (冒頭で紹介した構成)の構築を通じ、VPCの実際の構築方法を解説します。

指針として、以下のベストプラクティスに極力従うよう構築を進めていきます

長くなったので、以下の別記事でまとめました。
VPC構築を実践する上で役立つ記事を目指したので、ぜひご一読いただけると嬉しいです！