【AWS】はじめてシリーズ第１回Amazon Virtual Private Cloud (VPC)環境を構築してみよう。

2024年7月24日 22:29

1. はじめに

こんにちは！なかぞです。皆様、充実した日々をお過ごしでしょうか。私は個人的にやりたいことはたくさんあるのですが、本業の仕事の関係で、記事の執筆時間がなかなか取れない日々を過ごしております。

さて、そんな中、今回からAWSはじめてシリーズとして何回かに分けて、AWSのサービスについて記事にしていきたいと思います。AWSに関する記事を書こうと思ってから、かなり日が経ってしまいましたが、執筆を続けていました。記事を書いていると、AWSの復習にもなりますし、自分が知らなかった新たな発見もあり、noteを始めてよかったなと感じています。

さて、今回は記念すべき第１回です。

noteでは、他の方が執筆したAWS認定資格の合格体験記やAWSのイベント参加レポートが数多くあります。一方で業務で必要となるAWSの知識、ノウハウはまだまだ記事が少ないと思いますので、AWSのサービスを１つ１つ丁寧に解説していきたいと思います。自分の経験に基づいて書いていますので間違いがあればご指摘いただけると助かります。

AWSを使ったシステムの基盤を構築したいけど、何から手をつければいいか分からない、ネットワークが難しくて環境作りが不安、サーバーレスってどうすればいいの？といったAWSを使ったシステムの基盤構築に必要なノウハウを放出していきたいと思います。

なお、AWSのサービスは、頻繁にアップデートが行われて、機能も増えたりします。記載の内容は2024年7月時点の情報です。記事内容はなるべく更新しますが、古くなっている場合は本家AWSのサイトも確認をお願いします。

2. VPCって何？

業務システムを構築する上で、最初に構築しなければならないもの、それはサーバーでもデータベースでもストレージでもありません。システムを稼働させるための仮想ネットワーク環境です。

そもそもネットワークとは何ぞや？という方は、このあたりにいい感じにまとめられたページがありますので、一読していただければと思います。仮想ネットワークとは、物理的なネットワーク構成の上に成り立つ論理的なネットワークを言います。従来のネットワークの仮想化技術には VLAN (Virtual LAN。仮想LANとも呼ばれる。) や SDN (Software Defined Network。ソフトウェアによって定義されるネットワークのこと。)、 NFV (Network Function Virtualization。汎用サーバー上でソフトウェアとして実装する方式。) といった技術がありますが、AWSにおいてはAmazon Virtual Private Cloud (Amazon VPC) が仮想ネットワーク環境を提供するサービスとなります。

Amazon VPCを構築すると、サーバーやデータベースなどAWSの多くのサービスをVPC内で動作させることができるようになるため、パブリッククラウドサービスであるAWSを、プライベートなネットワーク環境として、セキュリティを考慮して安全に使用する上で、なくてはならない非常に重要なサービスです。

ひと昔前（今でもありますが）は、ネットワーク環境を構築するために、ルーターやネットワークスイッチ（L2スイッチやL3スイッチなど）やロードバランサーといった非常に高価なハードのネットワーク機器を購入して、物理的なネットワークを「ネットワークエンジニア」と呼ばれるエンジニアの方々が構築していました。例えば、以下のようなネットワーク環境です。

このような物理的なネットワーク構成では機器を購入して揃えなければならず、構築に時間を要し、一度構築してしまうと物理的制約が発生します。また、機器の故障への対応やネットワークを拡張するために必要なネットワーク機器の増設、冗長化のための多重コストなど、非常に手間とコストと時間がかかってしまいます。
しかし、Amazon VPCで構築すると、以下のようなメリットがあります。

国内、国外といった構築場所の制約から解放され、災害に強い環境を構築できる。
構築時の自由度が格段に上がる（間違っても削除できる）。
構築にかかる時間、労力を大幅に削減できる。
必要なときだけ作成すればよいため、使い方次第で低コスト化が可能。
ネットワーク機器の設定に詳しくないエンジニアでもAWSマネージメントコンソールを使って構築できる。

これまではプライベートクラウド（オンプレミスなサーバー群を仮想化して利用）が主流で、パブリッククラウドのイメージは、インターネット上に構築するネットワーク環境というイメージでした。大事な個人情報を扱う民間企業、金融機関や官公庁では採用が進みませんでしたが、2018年6月に初版決定された「政府情報システムにおけるクラウドサービスの利用に係る基本方針」の決定以降、ISMAP（政府情報システムのためのセキュリティ評価制度）やクラウド・バイ・デフォルトの原則（政府情報システムではクラウドサービスの利用を第一候補として、検討を行う原則。デジタル社会推進標準ガイドライン DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針）が決定され、民間でも官公庁でも積極的にAWSやMicrosoft AzureなどのISMAP評価制度で登録された事業者のパブリッククラウドサービスを使ったシステム開発が検討され、今日では実際にシステムの稼働環境として利用されています。

話をVPCの話に戻しましょう。

Amazon VPCを用いて仮想ネットワーク環境を構築する場合は、そのネットワーク環境を使用するシステムの要件によって、さまざまなネットワーク構成が考えられます。ですので、何が正解というのはありませんが、AWSではVPCにもベストプラクティスというものを用意しています。VPCのベストプラクティスについては後述します。

では、VPCにはどのような機能があるか見ていきましょう！

その前に、VPCはどこに作成されるのかを理解しておくことは重要です。AWSにおいては、リージョンという地理的に離れた領域が定義されています。１つのVPCは１つのリージョンの中に作成します。1つのVPCを複数のリージョンにまたいで作成することはできません。

3. リージョン

AWSでは、世界中に複数のリージョンがあり、地理的に離れた領域として定義されており、１つのAWSアカウントで、複数のリージョンを使用することができます。（ただし、AWS GovCloudアカウントやAWS（中国）アカウントでは利用できるリージョンに制約があります）
AWSのリージョンは、2024年6月時点で、33のリージョン（AWS グローバルインフラストラクチャ）があり、AWSアカウントがあれば、どのリージョンに対してもVPCを作成することが可能です。（ただし、デフォルトで有効なリージョンは、17個で、それら以外は無効になっています。無効になっているリージョンでも自分で有効に変更することで利用することができます。また、デフォルトで有効な一部のリージョンは無効にすることはできません。）
どのリージョンを使用するかについては、要件として決まるかと思いますが、国内の業務システム、政府情報システムであれば、まず東京リージョンを選択しておけば間違いないでしょう。理由として、大阪リージョンではまだ対応していないサービスがあるためです。DR（Disaster Recovery。災害復旧。）目的や何のサービスを使用するか明確であれば大阪リージョンを選択することも可能です。東京リージョンと大阪リージョンで対応しているサービスについては2023年10月時点の一覧をこちらにまとめましたので参考にしてください。

4. VPCの概念

先ほど説明したリージョンごとにVPCを作成するわけですが、簡単にサービスを利用したい場合に便利な、デフォルトVPCというものが各リージョンに１つ用意されており、それを利用することも可能です。デフォルトVPCは、VPCのネットワークアドレス範囲（IPv4 CIDR ブロック）が172.31.0.0/16であり、パブリックサブネットが１つあり、インターネットへ繋がるネットワークのため、これを使用するのがネットワーク要件とあっているかは確認が必要です。また、リージョンごとに作成可能なVPCの数は、クォータとしてデフォルトでは、５つまでとなっています。業務のシステムによっては、例えば、本番環境、検証環境・・・のように環境をVPCで分離した場合に、5個では足りないということがあるかと思いますが、クォータ値を引き上げる申請はできますので、安心してください。

VPCの概念について、以下の項目に分けて説明します。

VPC
サブネット
アベイラビリティーゾーン
デフォルトVPC
DHCPオプションセット
ルートテーブル
ネットワークACL
インターネットへの通信
企業内のネットワークへの通信
VPC間接続
NATゲートウェイ
ゲートウェイエンドポイント
Elastic IPアドレス
AWS Transit Gateway
AWS Virtual Private Network
VPC Flow Logs
CloudWatch メトリクス
セキュリティグループ
VPCのベストプラクティス

4.1. VPC

VPCをどこに作るか、リージョンを決定したら、AWSマネジメントコンソールで、VPCを作成します。
VPCを作成するとき、現在は「作成するリソース」として、「VPCなど」を選択できます。これは、VPCだけではなく、その中のネットワーク分割に必要なサブネットやルートテーブル、インターネットゲートウェイなどをまとめて設定してくれる便利なものですが、最初のうちはVPCに対する理解を深めるために「VPCのみ」を選んで構築しましょう。
VPCを設定する際に必要な項目には以下のものがあります。

作成するリソース: 「VPCのみ」を選択すると、VPCだけを作成できます。「VPCなど」は、VPCとその中のサブネットなどのネットワークの設定をまとめて作成することができます。「VPCなど」を選択すれば簡単に仮想ネットワーク環境を準備できますが、サブネットのサイズの要件や、ルーティングの要件が構築するシステムによっては異なる場合がありますので、そのような場合は、「VPCのみ」を選択し、その後、サブネットやルートテーブルの設定を行います。
名前タグ: VPCの名前を設定します。プロジェクトで命名規約がある場合はその規約に沿った名前をつけましょう。
IPv4 CIDR ブロック: １つのVPCのネットワークアドレス範囲を設定します（CIDR（サイダー）については、AWSの「CIDR とは?」を参照してください）。
IPv6 CIDR ブロック: デフォルトは、「IPv6 CIDR ブロックなし」です。IPv6 CIDR ブロックを使用したネットワーク構築もできるようになっていますが、まだまだそのようなネットワーク要件があるシステムは少ないかと思います。
テナンシー: 「デフォルト」（VPC上のインスタンスをマルチテナントの共用ハードウェアで実行する）、「占有」（VPC上のインスタンスをシングルテナントの専用ハードウェアで実行する）から選択します。「占有」を選択すると、このVPC上ではハードウェア占有インスタンスとしてEC2が起動することになります。「占有」だと利用できないEC2のインスタンスタイプが出てきますので、AWSの各サービスを制限なく使用できるようにするため、通常は、「デフォルト」を選択します。

VPCは、仮想ネットワーク環境ですので、ここで重要な項目は「IPv4 CIDR ブロック」です。この項目は、このVPCのネットワークアドレス範囲を示し、それはつまり、利用できるネットワークの広さを意味します。
IPv4 CIDR ブロックに設定できるアドレス範囲については、AWSのユーザーガイドであるこちらに詳しく記載されていますが、簡単に言うと、RFC1918に指定されているプライベートIPv4アドレスの範囲がCIDRブロックとして設定が可能な範囲です。ただし、一部のAWSサービスは172.17.0.0/16を使用しているため、このアドレス範囲は使用できません。プライベート CIDR ブロックには、以下のような3種類のプライベートアドレス範囲があります。

VPCのIPv4 CIDRブロックで利用できるプライベートアドレスの範囲（RFC1918）
10.0.0.0	-	10.255.255.255 (10/8 prefix)
172.16.0.0	-	172.31.255.255 (172.16/12 prefix)
192.168.0.0	-	192.168.255.255 (192.168/16 prefix)

VPCのIPv4 CIDR ブロックで一度設定したCIDRブロックは作成後に変更することはできません。変更する必要がある場合は、VPCを作り直す必要がありますので、サイズはあまり小さくせず、大きめのCIDRブロックにしましょう。（大きすぎても、どんなネットワーク設計しているのだと発注者からツッコミを受ける場合もありますが。。。）

では、「VPCのみ」でVPCを作成した場合、たとえば、IPv4 CIDR ブロックを192.168.0.0/22で作成した場合、どれだけの数のIPアドレスを持った仮想ネットワーク環境を構築できるでしょうか。

答えは、以下の表のとおりです。

アドレス範囲の例（192.168.0.0/22の場合）

実際に、どのくらいの規模のVPCを構築する必要があるかは、そのVPCで稼働する業務システムによってさまざまかと思います。しかし、サイズを小さくしすぎると、後でVPCをサブネットで分割する際にサイズの制限が生じてしまうため、後でサイズを変更できないということも考慮し十分な検討が必要です。
なお、VPC CIDR ブロックとして設定できるブロックサイズは、/16サブネットマスク（65,536個のIPアドレス）から/28サブネットマスク（16個のIPアドレス）の間です。
余談ですが、サブネットマスクとは以下のように、ネットワーク・アドレスとホスト・アドレスの範囲を決定する数値です。

さて、東京リージョンに「VPCのみ」を作成した状態はどのような状態でしょう。以下のようにVPCの枠があるだけの状態ですね。
しかし、実際は、「VPCのみ」の場合であっても、DHCPオプションセット、メインルートテーブル、メインネットワークACLが設定されています。これらについては後述します。

4.2. サブネットとアベイラビリティーゾーン

VPCができたところで、このままでは、まだ、サーバーやデータベースをVPC内に構築していくことはできません。サブネットが必要です。サブネットは、VPC内のIPアドレスの範囲内で設けることができるIPアドレスの範囲です。サブネットを作成しておくことで、そのIPアドレス範囲に、EC2インスタンス等を構築することができるようになります。サブネットを作成する前に、もう１つ知っておいて頂きたいものがあります。それは、アベイラビリティーゾーンです。

AWSのアベイラビリティーゾーン（AZ（エーゼット））は、１つのAWSリージョン内でそれぞれ切り離され、冗長化された電力源とネットワーク、接続機能を備えた１つ以上のデータセンターを言います。これらのAZは、災害時に共に被災しないよう、数キロメートル離れてデータセンターが存在しておりかつ互いに100km以内に配置されています。
リージョンとアベイラビリティーゾーンについては、AWSのリージョンとアベイラビリティーゾーンのページに詳しく載っています。

1つのVPCは、1つのリージョン内に作成する必要があることは前述のとおりですが、1つのVPCを複数のアベイラビリティーゾーンにまたがって作成することは可能です。アベイラビリティーゾーンは、互いに数キロメートル離れているので、冗長化された環境を構築する際にメリットとなります。

1つのVPC内に、サブネットを作成する際、サブネット名、アベイラビリティーゾーン、サブネットのIPv4 CIDR ブロックを設定します。アベイラビリティーゾーンは、東京リージョンの場合、ap-northeast-1a、ap-northeast-1b、ap-northeast-1c、ap-northeast-1dの4つが使用できます。サブネットは複数作成できますが、IPアドレス範囲が重複しないように作成する必要があります。また、基本的にどのアベイラビリティーゾーンを使うかは自由ですが、冗長構成のために2つ以上の異なるアベイラビリティーゾーンを利用してサブネットを作成するということと、アベイラビリティーゾーンによって利用できるEC2のインスタンスタイプが違う場合がありますので、注意が必要です。具体的には、2023年10月時点では、AZ IDがapne1-az3の場所は、EC2インスタンスタイプが選択できませんので、AZ IDがapne1-az3であるアベイラビリティーゾーンは使用する明確な理由がない限り、サブネットに利用しないほうが無難です。
自分が使用したいEC2インスタンスタイプが、どのアベイラビリティーゾーンで使用できるかについては、EC2のインスタンスタイプの画面内の「ネットワーキング」にある「アベイラビリティーゾーン」から確認できます。
例えば、t3a.smallインスタンスタイプを選択した場合、私のAWSアカウントにおいては、利用できるのはap-northeast-1d, ap-northeast-1aの２つのアベイラビリティーゾーンで利用できることが分かります。

一方、AZ IDがapne1-az3であるap-northeast-1b上には、サブネットは作成できますが、そのサブネット上に作成できるEC2インスタンスタイプがありません。サブネットを作成するAZを決める際は注意しましょう。

では、ここでVPC上にサブネットを作る場合の例をいくつか載せておきます。

ご確認いただけたように、サブネットを作成することで、用途ごとにネットワークセグメントを分けて構築できます。また、複数のアベイラビリティーゾーンに分けて作成することで冗長構成のネットワーク環境を準備することができます。

4.3. デフォルトVPC

デフォルトVPCは、各リージョンにあらかじめ用意されているVPCです。デフォルトVPCは以下の内容を満たしたVPCとして作成されています。デフォルトVPCは削除することも可能ですし、他のVPC同様、サブネットを追加したり、ルートテーブルを変更したりするなど、設定を変更することが可能です。

VPC CIDRブロックが172.31.0.0/16である。
各アベイラビリティーゾーンに、サイズ /20 のデフォルトサブネットがある。
インターネットゲートウェイがデフォルトVPCに接続されている。
すべてのトラフィック（0.0.0.0/0）をインターネットゲートウェイにルーティングするルートをメインルートテーブルに持つ。
デフォルトのセキュリティグループをデフォルトVPCに関連付けている。
デフォルトのネットワークアクセスコントロールリスト(NACL)をデフォルトVPCに関連付けている。
デフォルトVPCに、デフォルトのDHCPオプションセットを関連付けている。

デフォルトVPCは、パブリックサブネットでインターネットに接続でき、DNSによる名前解決ができるVPCとして、すぐにEC2インスタンスを起動して利用したい場合など、手軽に環境を用意したい場合に便利です。

もし、デフォルトVPCを削除してしまった場合は、AWS管理コンソールから改めて作成することが可能です。

作成するとすぐに、以下のような構成のデフォルトVPCができあがります。設定の手間がなく、非常に便利ですね。

4.4. DHCPオプションセット

AWSのDHCPオプションセットは、Amazon Virtual Private Cloud（VPC）内のインスタンスに対して、ネットワーク構成情報を提供するための設定のグループです。DHCPオプションセットを使用することで、VPC内のインスタンスに自動的にIPアドレス、サブネットマスク、DNSサーバーのアドレス、NTPサーバーのアドレスなどのネットワーク構成情報を割り当てることができます。

DHCPオプションセットは、VPC内の任意のサブネットに関連付けることができます。サブネットごとに異なるネットワーク構成情報を提供する場合は、それぞれのサブネットに対して異なるDHCPオプションセットを作成し、関連付けることができます。

DHCPオプションセットには、以下のような情報を設定することができます：

ドメイン名: インスタンスが参加するドメインの名前を指定します。
DNSサーバー: インスタンスが使用するDNSサーバーのIPアドレスを指定します。デフォルトでは、AmazonProvidedDNSが使用されます。
NTPサーバー: インスタンスが使用するNTP（Network Time Protocol）サーバーのIPアドレスを指定します。
NetBIOS名: NetBIOS名を指定することで、Windowsインスタンスの名前解決をサポートします。
NetBIOSノードタイプ: NetBIOSノードタイプを指定することで、Windowsインスタンスのネットワーク名解決の方法を制御します。

これらの設定をDHCPオプションセットに含めることで、インスタンスが起動されると自動的にネットワーク構成情報を受け取ることができます。また、DHCPオプションセットは、VPC内のインスタンスに対して動的に変更することも可能です。

4.5. ルートテーブル

ルートテーブルとは、AWSでVPC内の通信のルーティング制御をするためのものです。ネットワーク設計を行う上で、とても大事な設定ですね。

ルートテーブルは、Subnetと関連付けられ、そのSubnet内からの通信は、ルートテーブルのルールに従ってルーティングされます。
ルートテーブルにはルートが登録されていて、各ルートは、宛先CIDRと、その通信の次ホップ（インスタンス、インターネットゲートウェイ、VGWなど）が定義されます。
VPCを作成したとき、初期のメインルートテーブルがデフォルトで作成されます。このルートテーブルはVPC内のすべてのSubnetと暗黙的に関連付けられます。
VPC内に追加でカスタムルートテーブルを作成し、特定のSubnetのみ関連付けることができます。これにより複雑なルーティングを制御できます。（例えば、すべての通信をいったん、Network Firewallにルーティングしてから、許可された通信のみNAT Gatewayやインターネットゲートウェイにルーティングするようなルーティング制御）。
ルートの優先順位はCIDRブロックの長さで決まります。長いCIDRブロックのルートが優先です。

インターネットへのアクセスのためには、0.0.0.0/0へのルートを設定する必要があります。

AWSのルートテーブルにおけるルートの優先順位は、宛先CIDRブロックの長さに基づいて決まります。一般的にネットワークのルーティングで、「ロンゲストマッチ」と呼ばれています。
具体的には、以下のようなルールが適用されます：

宛先CIDRブロックがより具体的（長い）ほど優先されます。

例えば、10.0.0.0/16と10.0.1.0/24の2つのルートがある場合、10.0.1.0/24の方が長いプレフィックスなので、そちらが優先されます。

では、ルートテーブルについてもう少し見ていきましょう。

ルートテーブルの主な概念や設定には、以下のものがあります。

メインルートテーブル: VPCに自動的に割り当てられます。サブネットが明示的に他のルートテーブルに関連付けられていない場合、このルートテーブルの内容でルーティングを制御します。上の画面では、メインが「はい」と表示されているため、このルートテーブルはメインルートテーブルを示しています。
カスタムルートテーブル: VPCに作成するメインとは異なるルートテーブル。メインルートテーブルとは異なるルーティング制御をサブネットに対して関連付けたい場合に作成します。
[送信先]: トラフィックを送信するIPアドレス範囲。以下のキャプチャの場合、172.31.0.0/16の宛先であれば、ローカルのルーティング、0.0.0.0/0（ここでは、172.31.0.0/16以外のIPアドレス範囲）の宛先であれば、インターネットゲートウェイへ向けることを指します。

[ターゲット]: 送信先トラフィックの送信に使用するゲートウェイ、ネットワークインターフェイス、または接続（インターネットゲートウェイなど）を設定します。
サブネットの関連付け: ルートテーブルとサブネット、インターネットゲートウェイ、または、仮想プライベートゲートウェイの間の関連付けを設定します。
サブネットルートテーブル: 明示的なサブネットの関連付けがされたルートテーブルを指します。
伝達: VPCに仮想プライベートゲートウェイをアタッチし、ルート伝達を有効にすると、サブネットルートテーブルへのVPN接続のルートが自動的に追加されます。便利なのですが、意図せずルーティング制御が変わってしまうことを避けるため、あえて伝達を使用しないこともあります。伝達を使用しない場合は、VPNルートを手動で追加または削除が必要となります。
ゲートウェイルートテーブル: インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けられたルートテーブルを指します。
Edgeの関連付け: インバウンドVPCトラフィックをアプライアンスにルーティングするために使用するルートテーブル。ルートテーブルをインターネットゲートウェイまたは仮想プライベートゲートウェイに関連付け、アプライアンスのネットワークインターフェイスをVPCトラフィックのターゲットとして指定する。

Edgeの関連付けの説明をもう少し、分かりやすく説明します。
Edgeの関連付けは、インバウンド（入ってくる）ネットワークトラフィックをVPC内のAWSまたはサードパーティのアプライアンスにルーティングするための機能です。これにより、ネットワークセキュリティ、コンプライアンス、および運用の要件を満たすために、インバウンドネットワークトラフィックをより細かく制御できます。
以下に、VPC Ingress Routingの基本的な設定手順を示します：

まず、ネットワークアプライアンス（これはファイアウォール、侵入検知/防止システム、データロス防止システムなど、AWSまたはサードパーティ製のものである可能性があります）をVPC内のEC2インスタンスとしてセットアップします。
次に、VPCのルートテーブルを編集する画面でEdgeの関連づけを選択し、インバウンドトラフィックをこのアプライアンスのNICにルーティングするように設定します。これは通常、インターネットゲートウェイまたは仮想プライベートゲートウェイからのトラフィックを対象とします。
これにより、指定したアプライアンスに対する全てのインバウンドトラフィックは、そのアプライアンスを経由することになります。アプライアンスはトラフィックを検査し、適切なセキュリティポリシーを適用した後、トラフィックを適切な内部リソースに転送します。

VPC Ingress Routingを使用することで、ネットワークトラフィックのフローをより細かく制御し、セキュリティとコンプライアンスの要件を満たすことができます。また、これにより、アプライアンスの運用とスケーリングも容易になります。
ただし、VPC Ingress Routingを使用する際は、アプライアンスのパフォーマンスとスケーラビリティに注意を払い、ネットワークアプライアンスがトラフィックの量を処理できるように適切にスケーリングすることが重要です。
また、アプライアンスがEC2インスタンスの場合、以下の要件があります。

ルーティング先の仮想アプライアンスなどのインスタンスでは、IPフォワードされる設定が必要
ルーティング先のインスタンスでは「送信元／送信先チェック」が無効であることが必要

ゲートウェイルートテーブルの制限

ゲートウェイルートテーブルを作成する際、次のいずれかに該当する場合、ルートテーブルをゲートウェイに関連付けることはできません。

ルートテーブルに、すでにネットワークインターフェイス、Gateway Load Balancerエンドポイント、またはデフォルトのローカルルート以外のターゲットを持つ既存のルートが含まれている場合
ルートテーブルに、VPCの範囲外のCIDRブロックへの既存のルートが含まれている場合
ルートテーブルに対して、ルート伝達が有効な場合

これ以外にも細かなルールと考慮事項があります。AWSの以下のページも参照することをお勧めします。

4.6. ネットワークACL

AWSのネットワークアクセスコントロールリスト（Network Access Control List、通称 NACL）は、VPCにおける一種のファイアウォールで、VPC内のサブネットレベルでトラフィックを制御します。

NACLは次の特性を持ちます：

ステートレス: NACLはステートレスであり、インバウンドとアウトバウンドのルールはそれぞれ独立しています。つまり、特定のトラフィックがインバウンドルールを通過した場合でも、対応するアウトバウンドルールも通過しなければならないということです。
例えば、VPCのCIDRブロックが192.168.0.0/24で、EC2インスタンス（httpsを使用するWebサーバー）が192.168.0.0/25上のパブリックサブネットにて稼働していたとします。任意のユーザーから任意のIPアドレスでアクセスを許可する場合、NACLでは少なくともインバウンドルールで送信元0.0.0.0/0に対して、Port 443を許可し、Responseを返すためにアウトバウンドルールで、送信先0.0.0.0/0に対して、Port 443の許可を設定しておく必要があります。
なお、デフォルトのNACLでは、インバウンド、アウトバウンドとも、すべてのIPアドレスに対してすべてのPortでアクセス許可となっています。

NACLで設定する項目には以下の項目があります。

ルール番号: NACLルールは番号で指定され、低い番号のルールが先に評価されます。AWSは最初からデフォルトのNACLを提供しており、全てのトラフィックを許可するルール（ルール番号は最大値の32767）が設定されています。この番号は1から32766の間である必要があります。この番号はルールの評価順序を決定します。つまり、小さい番号のルールが先に評価され、大きい番号のルールが後に評価されます。
注意点として、AWSは自動的に番号32767のルールを設定し、これはすべてのトラフィックを拒否するデフォルトのルールです。これはユーザーが変更することはできません。したがって、カスタムルールを作成するときは、1から32766の間でルール番号を指定する必要があります。

タイプ: トラフィックのプロトコル（TCP、UDP、ICMP、またはALL）を指定します。

プロトコル番号: 使用するプロトコルの番号を指定します。

ポート範囲: トラフィックが使用するポート範囲を指定します。

ソースまたは宛先 CIDR ブロック: トラフィックのソース（インバウンドルールの場合）または宛先（アウトバウンドルールの場合）を指定します。

許可と拒否: NACLは「許可」ルールと「拒否」ルールの両方をサポートしています。特定のトラフィックを明示的に拒否することができます。

サブネットレベルの制御: NACLはサブネットレベルでの制御を提供します。つまり、同じVPC内の異なるサブネットに対して異なるアクセス制御を適用することができます。

NACLを使用して、特定のIPアドレス範囲からのトラフィック、特定のポートを使用するトラフィック、または特定のプロトコル（TCP、UDP、ICMP等）を使用するトラフィックなど、特定の種類のトラフィックを許可または拒否することができます。

なお、NACLはVPCのセキュリティを強化するための一部であり、セキュリティグループやVPCエンドポイントといった他の機能と組み合わせて使用されることが一般的です。

NACLは、サブネットレベルでのFW設定に相当する機能のため、サブネット内の特定のインスタンスやサービスに対して、IPアドレス、ポートの許可設定を行う場合は、セキュリティグループを使用します。また、逆にセキュリティグループでは、拒否の明示的な設定ができないので、特定のネットワーク、IPアドレスからの接続は拒否する場合、NACLを使用するという使い分けになります。

4.7. インターネットへの通信

VPC内のEC2インスタンスなどがインターネットへ接続する際は、インターネットゲートウェイを使用します。インターネットゲートウェイは、VPCとインターネットの間の通信を可能にします。

インターネットゲートウェイ:Amazon VPCの重要なコンポーネントで、VPCとインターネットとの間で通信を可能にします。これにより、VPC内のリソース（例えば、EC2インスタンス）がインターネットに接続できます。また、インターネット上のリソースもVPC内のリソースに接続することが可能になります。インターネットゲートウェイは、冗長性と高可用性を提供し、水平スケーリングをサポートします。IPv4とIPv6の両方のトラフィックをサポートします。
インターネットアクセスの有効化: インターネットゲートウェイを使用してVPC内のインスタンスでインターネットアクセスを有効にするためには、次の手順が必要です。
- インターネットゲートウェイを作成し、VPCにアタッチします。
- サブネットのルートテーブルにインターネットバウンドトラフィックをインターネットゲートウェイに転送するルートを追加します。
- サブネット内のインスタンスがパブリックIPv4アドレスまたはIPv6アドレスを持つことを確認します。
- ネットワークアクセスコントロールリストとセキュリティグループルールがインスタンス間で目的のインターネットトラフィックを許可していることを確認します。
パブリックサブネットとプライベートサブネット: サブネットはルートテーブルによってパブリックまたはプライベートに分類されます。インターネットゲートウェイへのルートがある場合、サブネットはパブリックと呼ばれます。逆に、インターネットゲートウェイへのルートがない場合、サブネットはプライベートと呼ばれます。
IPv4とIPv6の通信: インターネット経由でIPv4を使用した通信を有効にするには、インスタンスにパブリックIPv4アドレスが必要です。これにより、インターネットゲートウェイが1対1のNATを実施します。一方、IPv6を使用した通信を有効にするには、VPCとサブネットにIPv6 CIDRブロックを関連付け、インスタンスにIPv6アドレスを割り当てる必要があります。IPv6アドレスはグローバルに一意であるため、デフォルトでパブリックアドレスとなります。

これらの機能と設定は、VPC内のリソースがインターネットと効果的に通信できるようにするための重要なステップです。それぞれの環境と要件に応じて適切に設定することが重要です。

4.8. 企業内のネットワークへの通信

AWS VPCは、企業のオンプレミスネットワーク（または他のリモートネットワーク）と通信するための2つの主要な方法を提供しています: それは、Site-to-Site VPNとAWS Direct Connectです。

Site-to-Site VPN: これは、インターネットを介してVPCとオンプレミスネットワーク間に暗号化されたセキュアな接続を作成します。Site-to-Site VPNは、AWSの仮想プライベートゲートウェイと企業のカスタマーゲートウェイ（通常はオンプレミスのファイアウォールまたはVPNデバイス）との間にIPSec VPNトンネルを作成します。これにより、AWS VPCとオンプレミスネットワーク間で安全な通信が可能になります。

AWS Direct Connect: Direct Connectは、AWSとオンプレミスネットワーク間の専用の物理的な接続を提供します。これは、公共インターネットを介さずにAWSと直接通信するためのものであり、ネットワークパフォーマンスを向上させ、帯域幅のコストを削減することができます。Direct Connectは、企業のネットワークからAWSのDirect Connectロケーション（通常はデータセンター）への専用のリンクを介してVPCと通信します。

これらの接続方法は、それぞれ異なるユースケースと要件に対して最適化されています。Site-to-Site VPNは、セットアップが容易で、コストが低い一方で、インターネットを介した接続のためネットワークパフォーマンスは一定しないことがあります。一方、Direct Connectは、より高いパフォーマンスと一貫性を提供する一方で、セットアップとメンテナンスがより複雑で、コストも高くなります。

4.9. VPCピアリング接続

AWSのVPCピアリング接続は、2つのAmazon VPC間でネットワーク接続を設定する機能です。VPCピアリングを使用すると、各VPCは他のVPCとまるで同じネットワーク内にあるかのように通信することができます。

以下に、AWSのVPCピアリング接続の詳細について説明します。

トラフィックのルーティング: VPCピアリング接続を介してルーティングされるトラフィックは、ネットワークインフラストラクチャのAmazon内部でプライベートにルーティングされます。つまり、公共インターネットを介してトラフィックがルーティングされることはありません。

スケーラビリティ: VPCピアリング接続は数多くのVPC間で設定することができます。これにより、大規模なネットワークトポロジを作成することが可能になります。

ステートフルな振る舞い: VPCピアリング接続はステートフルです。つまり、応答通信を追跡して、VPC間のすべてのTCP、UDP、そしてICMPフローを許可します。

ネットワークオーバーラップ: VPCピアリングを設定する場合、ピアリングを設定する各VPCは一意のCIDRブロックを持つ必要があります。つまり、重複するIPアドレス範囲を持つVPC間でピアリング接続を設定することはできません。

ピアリング接続の設定: VPCピアリング接続を設定するためには、ピアリングリクエストを作成し、そのリクエストを受け取った他のVPCオーナーがそれを受け入れる必要があります。これは、AWSマネージメントコンソール、AWS CLI、またはAWS SDKを使用して行うことができます。

トランジティブピアリング: AWS VPCピアリングはトランジティブではありません。つまり、VPC AがVPC Bとピアリング接続を持ち、VPC BがVPC Cとピアリング接続を持っていても、VPC AはVPC Cと直接通信することはできません。VPC AとVPC Cが直接通信するためには、それらの間に直接的なピアリング接続を設定する必要があります。

VPCピアリングは、AWSのリソース間でプライベートでセキュアな通信を実現するための強力なツールです。これは、同じアカウント内のVPC間、または異なるAWSアカウント間のVPC、さらには異なるAWSリージョン間のVPCで使用することができます。

4.10. NATゲートウェイ

AWSのNATゲートウェイ（Network Address Translationゲートウェイ）は、プライベートなAWS Virtual Private Cloud（VPC）内のインスタンス等がインターネットや他のAWSサービスにアクセスするための手段を提供します。NATゲートウェイは、インターネットに接続するためにプライベートIPアドレスをパブリックIPアドレスに変換します。

以下に、NATゲートウェイの重要な特性と利点をいくつか挙げます:

インターネット接続: NATゲートウェイを使用すると、プライベートなサブネット内のインスタンス等はインターネットにアクセスできますが、NAT変換しているため、インターネット側を起点として直接内部のインスタンス等へアクセスされることはありません。これにより、セキュリティが強化されます。
自動スケーリング: NATゲートウェイは、トラフィック要求の増減に応じて自動的にスケーリングします。これにより、パフォーマンスが一貫して高く維持され、管理の手間が減ります。
高耐久性と可用性: NATゲートウェイは、それが配置されるAvailability Zone内で高い耐久性と可用性を持っています。また、冗長性を提供するために、各Availability Zoneに一つ以上のNATゲートウェイを設定することが推奨されます。
帯域幅: NATゲートウェイは最大45Gbpsまでの帯域幅をサポートします。

NATゲートウェイを設定する際、それが配置されるサブネットと、それを使用するすべてのルートテーブルを適切に設定することが重要です。また、一般に、プレイベートサブネットからインターネットへ到達するために、NATゲートウェイはパブリックIPアドレス（具体的にはElastic IPアドレス）を必要とします。

NATゲートウェイはAWSのマネージドサービスであり、自分でNATインスタンスを管理・スケーリングする手間を省くことができます。

4.11.ゲートウェイエンドポイント

AWSのゲートウェイエンドポイントは、S3やDynamoDBへのプライベートなアクセスを可能とするゲートウェイエンドポイントをVPCに提供します。つまり、VPCから、パブリックなインターネット経由でS3やDynamoDBのサービスエンドポイントへアクセスする場合NAT GatewayやInternet Gatewayを通す必要がありますが、ゲートウェイエンドポイントを用意するとS3やDynamoDBにVPCから直接アクセスすることができるようになります。ただし、制約があり他のオンプレミスネットワークや他のリージョンのピアリングしたVPCやTransit Gatewayを介してゲートウェイエンドポイントにアクセスすることはできません。

ゲートウェイエンドポイントを使うことで以下のようなメリットがあります。

セキュリティの向上
- ゲートウェイエンドポイントを使用すると、VPC内からAWSサービスに直接アクセスできます。インターネット経由ではなくAWS内の経路を使用するので、セキュリティ面でのリスクが下がります。
パフォーマンスの向上
- ゲートウェイエンドポイント経由ではインターネットを経由しないため、データ通信におけるレイテンシ、スループットが向上します。
可用性の向上
- ゲートウェイエンドポイントはAWS内部ネットワーク経由のため、インターネット障害時でもAWSサービスへのアクセスを維持できます。
管理性の向上
- アクセス制御はゲートウェイエンドポイント単位で細かく管理できます。インターネット経由のACLより柔軟な管理が可能です。
コスト削減
- S3やDynamoDBにインターネット経由でアクセスする場合は、Internetへのアウトバウンド転送費用が発生しますが、ゲートウェイエンドポイントを介したアクセスの場合は、VPC内のデータ転送料のみで、アウトバウンドへの追加費用は発生しません。

では、実際にS3のゲートウェイエンドポイントを作ってみましょう。

AWSマネジメントコンソールからVPCを選択し、メニュー上の「エンドポイント」を選択します。

2.今回は、S3のゲートウェイエンドポイントを作成するので、「AWSのサービス」を選択し、その中の「com.amazonaws.ap-northeast-1.s3」を選びます。タイプでソートすると探しやすいです。また、御覧のとおり、ゲートウェイエンドポイントは、DynamodbとS3の2種類のみ提供されます。

3.次にどのVPCでこれから作成するゲートウェイエンドポイントを利用するのかを選択します。また、ゲートウェイエンドポイントのエントリを追加するルートテーブルを選びます。複数選択も可能です。ここでは、プライベートサブネットに関連付けているルートテーブルを選択しています。

S3のゲートウェイエンドポイントを使いたいVPCとエントリを追加したいルートテーブルを選択

4.サービスへのポリシーを設定します。特定のアカウントのみ許可する場合やアクセス可能なS3バケットを限定したい場合など、必要に応じてポリシーを設定してください。ここでは、特に制限せずフルアクセスで設定します。

5.ゲートウェイエンドポイントを作成したところ。時間はさほどかからずすぐできます。

6.ゲートウェイエンドポイントを作成すると同時に、選択したルートテーブルに対して、S3を宛先とする場合のターゲットにゲートウェイエンドポイントが追加されていることが分かります。

S3を宛先とする場合にゲートウェイエンドポイントを宛先とするエントリが追加されている

7.実際に、NAT Gatewayへのルーティングもしない、インターネットにつながらないプライベートサブネット上にEC2インスタンスを立てて、S3へアクセスできるか試してみました。確かに、S3バケットの中を見ることができています。ここで気を付ける必要があることは、ゲートウェイエンドポイントを作成したリージョンと同じリージョン上のS3バケットにしかアクセスできないということです。今回の場合、東京リージョン上のVPCにゲートウェイエンドポイントを作成しましたので、東京リージョンにあるS3バケットにはゲートウェイエンドポイント経由でアクセスできますが、大阪リージョン上のS3バケットにはアクセスできません。

4.12.Elastic IPアドレス

Elastic IPアドレスは、インターネットからアクセス可能なパブリックIPv4アドレスです。かつては無料でしたが、有料になりましたね。
Elastic IPアドレスは、インターネットからアクセス可能な静的なパブリックIPv4アドレスで、AWSアカウントに対して割り当てられ、通常、EC2インスタンスやNAT Gatewayに紐づけて利用することで、IPアドレスを固定化するために使用します。EC2インスタンスを実行している際は、Elastic IPアドレス１つに対する料金は発生しませんが、関連付けていない場合はElastic IPアドレスをAWSアカウントから解放しないと、保持し続けている間は課金が発生します。また、2024年2月1日からは、実行中のEC2インスタンスに関連付けられているものに対しても、Elastic IPアドレスの課金が発生します。

4.13.AWS Transit Gateway

これを簡潔に説明するのは意外と難しいです。AWSのページでは、「クラウドルーター」と表現されていますが、「クラウドルーター」って今までほとんど聞いたことがありません。AWSのページの説明では、Amazon Virtual Private Cloud(VPC)とVPNの間の動的および静的レイヤー3ルーティングをサポートしたサービスとされています。つまり、VPCとVPCの間のL3ルーティングやVPCとオンプレミスゲートウェイ間のVPN接続を作成でき、複数のVPN接続によるEqual Cost Multipath)(ECMP　等価コストマルチパス)を有効にすることができます。ECMPにより、帯域幅を広げることができます。

4.14.AWS Virtual Private Network

AWS Virtual Private Network (AWS VPN)には、2種類のVPNサービスがあります。１つは、AWS Client VPNでユーザーの需要に応じて自動的にスケールアップまたはスケールダウンするフルマネージド型VPNサービスです。クラウドVPNソリューションのため、ソリューションをインストールして管理したり、一度にサポートするリモートユーザーの数を見積もったりする必要はありません。Client VPNは構築も容易で、OpenVPNクライアントというVPN接続ソフトを使用して安全なTLS接続を実現できるので、接続人数が少ない環境においてはお勧めです。ただし、利用料金はそれなりにかかりますので注意が必要です。
例えば、アジアパシフィック（東京）の場合、
2024年7月現在
　AWS Client VPNエンドポイントアソシエーション　$0.15/時間
　AWS Client VPN接続 $0.05/時間
です。

4.15.VPC Flow Logs

VPCフローログは、VPCのネットワーク内を行き来するIPトラフィックデータをキャプチャできる機能です。フローログデータは、Amazon CloudWatch LogsやAmazon S3、Amazon Data Firehoseに出力できます。
フローログの取得にあたっては、VPC内のネットワークのスループットやレイテンシーに影響を与えず取得することができる点が利点です。
フローログを取得する場合は、以下3点の内容を指定します。

フローログを作成する対象のリソース（EC2インスタンスのネットワークインターフェイスやVPC全体）
ログするトラフィック種類（許可、拒否、全て）
フローログの保管先

フローログ取得にあたって一点注意が必要なことは、ネットワーク内を行き来するIPトラフィックをキャプチャするといっても、パケットデータをすべてキャプチャして保管するわけではない点です。パケットキャプチャツール「Wireshark」のようにネットワーク上を流れるデータをキャプチャして保管することができるわけではなく、どのような種類のデータが流れているか、インタフェース間におけるセキュリティグループやNACLにより許可されたフローか拒否されたフローかなどトラフィックを分析するために使用します。フローログレコードの項目は以下のURLを参照してください。

フローログでは、IPトラフィックをキャプチャしますが、制限事項があり、以下のトラフィックは記録しませんので、注意が必要です。

Amazon DNS サーバーに接続したときにインスタンスにより生成されたトラフィック。
Amazon Windows ライセンスのアクティベーション用に Windows インスタンスによって生成されたトラフィック。
インスタンスメタデータ用に 169.254.169.254 との間を行き来するトラフィック。
Amazon Time Sync Service の 169.254.169.123 との間でやり取りされるトラフィック。
DHCP トラフィック。
ミラートラフィック。
デフォルト VPC ルーターの予約済み IP アドレスへのトラフィック。
エンドポイントのネットワークインターフェイスと Network Load Balancer のネットワークインターフェイスの間のトラフィック。

4.16.セキュリティグループ

VPCにおけるネットワークアクセスを制御する方法はいくつかありますが、セキュリティグループはその中でも最も主要な方法です。VPCにおいては、先述のネットワークACLと、このセキュリティグループを組み合わせて、パケットフィルター処理を行い、ネットワークを保護します。ネットワークACLとセキュリティグループには以下のような違いがあります。

セキュリティグループは、インスタンスに対して割当ができるので、仮想の簡易なファイアウォールのような機能だと言えます。また、インバウンドルールとアウンとバウンドルールのそれぞれに許可の設定を行いますが、ステートフルであるため、リターントラフィックは自動的に許可となります。例えば、Webサーバーのインスタンスやロードバランサーが使用するセキュリティグループに対して、HTTP:80番ポートとHTTPS:443番ポートを許可する場合は、以下のようになります。

セキュリティグループのポイントとして、ソースをネットワークアドレスの範囲だけではなく、他のセキュリティグループ（ID）を設定し、そのセキュリティグループを使用しているインスタンスからのアクセスを許可するといった設定も可能です。
セキュリティグループの設定に関する詳細については、以下を参照していただければと思います。

ここまでの内容で、VPCを構築する上で必要な基本的な考え方や機能をご説明してきました。ネットワークの基本的な知識があると理解が早いかと思います。また、様々なAWSのVPCに関わる機能がありますが、ひととおり設定するとそれなりのコストが毎月発生することになります。こんなはずではなかった！と後で後悔しないよう、事前にhttps://calculator.aws/ で費用を試算しておくことを忘れないようにしましょう。

次回、【AWS】はじめてシリーズ第２回は、「サーバーレスで生成AIを使ってみよう」です。お楽しみに！

この記事が気に入ったらサポートをしてみませんか？