COLUMN

2024.09.18 ｜ Writer：NTT東日本　白鳥翔太

AWSにおける最初のVPC構築時のネットワーク設計のポイントとは？

	こんにちは、白鳥です。

AWSを初めて利用する際に、どのようなネットワーク設計にするか悩まれている方が多いのではないでしょうか？Amazon VPCを利用することで、AWS内に仮想ネットワークを作ることができますが、今回はこのネットワーク設計に注目し、AWSへの移行や、初めてのシステム構築の際にAmazon VPCをどのように設計するかのポイントをおさらいしていきます。

AWSへのネットワーク設計・構築に関するご相談・お悩みなどNTT東日本のクラウドエンジニアがご相談にお応えします！お気軽にお問い合わせください。

1. Amazon VPCを利用するメリット
2. Amazon VPCの基本機能
3. Amazon VPCの設計: 3-1. 全体的な考慮ポイント; 3-2. リージョンの選択; 3-3. アベイラリティゾーンの選択; 3-4. テナンシーの選択; 3-5. ネットワークアドレス設計; 3-6. サブネット設計; 3-7. ルーティング設計; 3-8. DHCP/DNS/NTP設計; 3-9. ファイアウォール・通信制御設計; 3-10. VPC外部との接続設計; 3-11. AWSインターネットへの接続; 3-12. VPCエンドポイント接続; 3-13. VPC間接続; 3-14. VPCとオンプレミス環境の接続; 3-15. VPC運用設計
4. Amazon VPCおよびAWSのネットワーク利用にかかるコストの考慮
5. クラウドネットワーク接続サービスなどNTT東日本が提供するサービスの紹介: 5-1. クラウド側の設定にクラウド導入・運用サービス; 5-2. 拠点側にはギガらくVPN; 5-3. クラウド導入・運用サービスとギガらくVPNを利用した導入事例
6. 最後に

1. Amazon VPCを利用するメリット

Amazon VPCは、AWS上に独立した環境でリソースの配置、接続性、セキュリティなど、仮想ネットワーク環境をフルで制御できるサービスです。2009年にベータ版がリリースされ、以後ニーズに応じて機能が拡張されてきましたが、メリットとしては以下の要素でおおむね変わっておりません。

AWS上できめ細やかなネットワーク設定ができることで、セキュリティの向上、可用性の向上、モニタリング・スケーリングができる
インフラストラクチャーの設計はAWS側で行うため、物理ルータ・スイッチ等の設定を意識せず、自身の持つネットワークの拡張として利用できる
独自のIPアドレス範囲の選択や、IPv4/IPv6の選択、接続先の選択など大規模化にも対応できる

2. Amazon VPCの基本機能

Amazon VPCを利用することで、次のような機能が利用できるようになります。

仮想プライベートクラウド
サブネット
IPアドレスの指定
ルーティング
ゲートウェイとエンドポイント
ピアリング接続
トラフィックのミラーリング
VPC Flow logs
VPN接続

機能ベースで一つ一つ理解していくのもよいですが、初めての場合は基本的なネットワーク設計から入っていくのをおススメします。

3. Amazon VPCの設計

3-1. 全体的な考慮ポイント

ネットワーク設計の考慮ポイントとしては、オンプレミスの場合と同じくIPAに定められているような非機能要求グレードを検討します。オンプレミスと異なり、AWSの物理データセンタでの可用性や性能、セキュリティ、エコロジーといった非機能要件がデフォルトで組み込まれているため、可用性やセキュリティを向上させられるよう、以下の項目について検討していきます。

リージョンの選択（可用性/性能・拡張性）
アベイラリティゾーンの選択（可用性/性能・拡張性）
テナンシーの選択（性能・拡張性/システム環境）
ネットワークアドレス設計（可用性/性能・拡張性）
サブネット設計（可用性/性能・拡張性）
ルーティング設計（可用性/性能・拡張性）
DHCP/DNS/NTP設計（可用性/性能・拡張性/セキュリティ）
ファイアウォール・通信制御設計（セキュリティ）
VPC外部との接続設計（可用性/性能・拡張性/移行性）
VPC運用設計（可用性/保守・運用性）

3-2. リージョンの選択

AWSでは、リージョンという地理的に離れた領域で各サービスを展開しており、各リージョン間の論理的な分離を行っています。日本では東京リージョンと大阪リージョンがあります。複数のリージョンの中から構築する環境を選択できます。リージョンの選択基準としてはいくつかありますが、おおむねこのような基準の中から検討していきます。

性能重視：利用者からみて遅延の少ないリージョン（例：日本国内向けのシステムであれば、東京/大阪リージョン）を選択する
コスト重視：利用料の安いリージョンを選択する（XXXというサービスの検証のため、XXXの利用料が安いリージョンを選択する）
機能重視：利用したいサービスから選択する（例：XXXというLLMのAmazon Bedrock版がバージニア北部リージョンにしかないため、バージニア北部リージョンを利用する）
環境重視：Amazon の再生可能エネルギー・プロジェクト付近か、グリッドの炭素集約度（炭素強度）の低い場所を選択する（例：炭素集約度の高いストックホルムリージョンを選択する）

3-3. アベイラリティゾーンの選択

AWSのリージョンはアベイラリティゾーン（以下、AZ）という冗長性・信頼性・可用性を確保した1つ以上のデータセンタからなる群で構成されており、各AZでも電源の冗長化や通信経路の冗長化などが設計されています。リージョンは複数のAZからなり、VPCを構築する場合には以下が推奨となります。

単純な冗長性の確保：2AZ以上
ELBやAmazon Auroraを利用する場合：3AZ

リージョンによってはAZが1つ、2つの場合もありますので、その場合は注意が必要です。

また、後から追加することも可能なため、最初は2つのAZで始めて、後から追加することもできます。

3-4. テナンシーの選択

RFC1918の範囲	CIDRブロックの例
10.0.0.0 – 10.255.255.255	10.0.0.0/16
172.16.0.0 – 172.31.255.255	172.16.0.0/16
192.168.0.0 – 192.168.255.255	192.168.0.0/20

テナンシーとは、構築するリソースがほかの利用者と共有のハードウェアで実行されるか否かの選択になります。デフォルトではほかのお客さまと共有されます。コンプライアンスや利用するソフトウェアのライセンス上といった理由で、ハードウェア専有のリソースを利用したい場合はDedicatedを選択します。

3-5. ネットワークアドレス設計

初めてのVPCを設計する際に、今後VPCが複数になることを踏まえて、AWS全体で払い出すIPアドレスの範囲を決めておくことを推奨します。例えば、AWSで使用するアドレス帯を10.0.0.0/8で決めておき、各VPCはその範囲から払い出す、という形をとることができます。また、自身でグローバルIPアドレスをお持ちでない限りは、RFC1918で指定されているプライベートIPv4アドレス帯を指定することをお勧めします。

一つのVPCで利用可能なIPv4アドレスについては/16（65,536個のIPアドレス）~/28(16個のIPアドレス)の間で払い出すことができますが、VPC内のリソースやAWSマネージドサービスが自動的に利用することもあるため、一つのVPCでできるだけ多くのIPアドレスを利用できるようにすることをお勧めします。

VPCの設定において、注意点が2点あります。

デフォルトVPCが構築されている場合があります。こちらを本番環境や商用環境で利用することは推奨いたしません。意図していないルートテーブルやセキュリティグループ、サブネットが含まれている可能性があり、ネットワーク設計上不要な設定の削除を行うことになるためです。
VPCで172.17.0.0/16は使用しないでください。一部のAWSのサービスでこのアドレス帯を利用しており、IPアドレスの競合が発生する可能性があります。

IPv6アドレスを使ってVPCを作ることもできます。この場合は、/44から/60までの/4刻みで最大5つのIPv6 CIDRブロックを関連付けることができます。IPv6については本コラムでは省略します。

また、パブリックサブネットにおいて、パブリックIPv4アドレスを固定的に利用したい場合があります。この場合はElastic IPアドレスを利用して、グローバルIPv4アドレスを確保します。利用時間に応じてコストがかさむので、利用するパブリックIPv4アドレスは最小限にとどめることをお勧めします。

3-6. サブネット設計

VPCで10.0.0.0/16を払い出したとします。サブネットは、一つのAZ内で構成する必要があります。また、サブネットは大きく分けて二つあり、それぞれ以下のように機能します。

パブリックサブネット：サブネットには、インターネットゲートウェイへの直接ルートがあります。パブリックサブネット内のリソースは、インターネットにアクセスできます。
プライベートサブネット：サブネットには、インターネットゲートウェイへの直接ルートがありません。プライベートサブネット内のリソースには、インターネットへのアクセス用に NAT デバイスが必要です。

したがって、利用するAZの個数×2（2AZの場合は、パブリックサブネット2つ、プライベートサブネット2つの計4つのサブネット）を最低限作成します。

サブネットのネットワーク設計は以下の点に注意します。

各サブネットの中にAWS側で利用するアドレスがあります。サブネットの先頭4つと、末尾の5つのアドレスは使用できません。10.0.0.0/24のサブネットの場合、下記のアドレスが使用できません

10.0.0.0	ネットワークアドレス
10.0.0.1	VPCルータ用のアドレス
10.0.0.2	DNSリゾルバ用（Route 53 Resolver）
10.0.0.3	将来のためにAWSが予約
10.0.0.255	ブロードキャストアドレス

ELBなどのマネージドサービスが自動的にIPアドレスを使用することがあるため、マネージドサービスやAutoScalingを利用する場合は/27(32個のIPアドレス)より大きなネットワークを推奨します。
ブロードドメインの分割のため、さらなるサブネットを追加する場合を踏まえて、最初にVPCで払い出したすべてのアドレスをサブネットに割り当てることは推奨しません。

3-7. ルーティング設計

ルートテーブルという機能で各サブネットにルーティングを設計します。オンプレミスではサブネットが異なるネットワークへの宛先を指定する必要がありますが、AWSではVPC内はデフォルトで通信できます。ターゲットはAWSの各リソースを指定します。ルートテーブルの例は次のようになります。

パブリックサブネットのルートテーブルの例

送信先ネットワーク	ターゲット
10.0.0.0/16	local
0.0.0.0/0	IGW-id

プライベートサブネットのルートテーブルの例

送信先ネットワーク	ターゲット
10.0.0.0/16	local
0.0.0.0/0	NAT-Gateway-id
192.168.0.0/16(VPN接続先)	VGW-id

ルートテーブルにおける経路優先度は次の通りになります。

最長プレフィックス（ロンゲストマッチ）
静的ルート
伝搬されたルート
- Direct Connectにより伝搬されたルート
- Site-to-Site VPNにより伝搬されたルート
- BGP AS-PATHを比較して短いほうのルート
- その他BGPの設定により優先度を決定

また、デフォルトでメインルートテーブルが設定されております。これはVPC内のlocalルートのみが設定されたものになりますが、これを設定変更することは推奨しません。理由としては、ルートテーブルが関連付けられていないサブネットはメインルートテーブルが参照されるため、意図しない経路（プライベートサブネットにしたかったが、メインルートテーブルのデフォルトルートをインターネットゲートウェイにしていたなど）により、インシデントが発生する可能性があるためです。そのため、メインルートテーブルはVPC内のみとしておき、各サブネットでルートテーブルを作成するようにしましょう。

3-8. DHCP/DNS/NTP設計

Amazon VPC内の各リソースは、DHCPを利用してIPv4/IPv6アドレスを取得します。このDHCPで払い出される情報には、マネージドのDNSサーバー（Amazon Route 53 resolver）や、NTP（Amazon Tim Sync Service）が含まれており、特段の指定がない場合はAWS上で追加のDNSサーバーやNTPサーバーを立てる必要はありません。

引用：DHCP オプションセットの概念

もし自前でDNSサーバーやNTPサーバーを持っていて、こちらとAWSリソースを連携したい場合には、DHCPオプションセットを使って、追加の設定を行います。

3-9. ファイアウォール・通信制御設計

オンプレミスと同様、通信制御は最小限に絞ることが大切です。VPCにおいてもファイアウォール・通信制御設計を行います。インバウンド方向（外部からリソースに向かう通信）、アウトバウンド方向（リソースから外部に）、ステートフル（要求パケットがインバウンドかアウトバウンドかを判断し、応答のパケットは要求パケットに従う）、ステートレス（単純に通信の方向のみを判断する）かによって、次の二つを使い分けます。

3-9-1. セキュリティグループ（ステートフル）

セキュリティグループは、関連付けられたリソースの通信制御を行います。通信元や宛先、ポートを指定します。また、ホワイトリスト型で、拒否ルールを設定することはできません。

引用：セキュリティグループを使用して AWS リソースへのトラフィックを制御する

複数のリソースを一つのセキュリティグループに関連付けることもできるので、役割ごとに（Webサーバー、ADサーバーなど）設定します。

SSHやRDPといった操作可能なプロトコルに0.0.0.0/0(IPv4)と::/(IPv6)の設定をせず、特定のIPアドレスに絞るようにしましょう。もしくは、サーバーの操作にこういったプロトコルを使用せず、Systems ManagerなどのAWSの機能を利用することをお勧めします。

3-9-2. ネットワークACL（ステートレス）

ネットワークACLはサブネットで指定されます。サブネットに割り当てられたすべてのインスタンスに適用されます。セキュリティグループと違い、拒否ルールを作ることもできます。また、ステートレスのため、あて先・送信元で使うIPアドレス、ポート、プロトコルについて許可・拒否を設定する必要があります。

参照：デフォルトのネットワーク ACL

セキュリティグループとネットワークACLの機能をまとめると、次のようになります。

セキュリティグループ	ネットワークACL
リソースレベルで動作	サブネットレベルで動作
リソースと関連付けられている場合に適用	関連付けられているサブネットにあるすべてのリソースに適用
許可ルールのみ動作	許可・拒否ルール両方で動作
すべてのルールを評価して、トラフィックを許可	低い番号のルールから順に評価
ステートフル	ステートレス

3-10. VPC外部との接続設計

VPCと外部の接続については、次の要素を検討します。

AWSからインターネットへの接続
VPC外にあるマネージドサービスへの接続
VPC間の接続
VPCとオンプレミス環境の接続

利用しない要素については、現段階では省略してかまいません。

3-11. AWSインターネットへの接続

インターネットゲートウェイ（以下IGW）を使用します。IGWは冗長性と高い可用性を備えており、水平スケーリングが可能なためユーザーでの帯域幅や可用性の設計は不要です。VPCにIGWを関連付けることで、インターネット接続が可能になります。ただし、プライベートサブネットを利用する場合には、インターネットからの到達性を排除させるため、IPv4の場合はNATゲートウェイをパブリックサブネットに配置し、IPv6の場合はEgress-Onlyゲートウェイを関連付けます。これら二つのゲートウェイも冗長性を備えており、水平スケーリングが可能です。

そしてルートテーブルのデフォルトルートを、IPv4/IPv6パブリックサブネットはIGWに、IPv4プライベートサブネットはNATゲートウェイに、IPv6プライベートサブネットはEgress-Onlyゲートウェイに設定します。

コストのところでも触れますが、NATゲートウェイはNATゲートウェイそのものに加えて、パブリックIPv4アドレスを利用しますので、追加のコストが発生します。一つのVPCの時は各AZに配置しますが、VPCが二つ以上になった際に各VPCでNATゲートウェイを作成するとその分コストが追加されるので、VPCが増えてきた際にNATゲートウェイの集約の検討をおススメします。

3-12. VPCエンドポイント接続

通常、AWSのVPC外にあるマネージドサービスについては、インターネットゲートウェイを通じてパブリックサービスエンドポイントに接続します。

引用：AWS サービスを介したアクセス AWS PrivateLink

しかしながら、制約上パブリックIPアドレスを使用できないということがある場合は、VPCエンドポイントを利用します。VPCエンドポイントには2種類あり、ゲートウェイエンドポイント型と、インターフェースエンドポイント型の二つがあり、利用するサービスに応じて使い分けます。主な使い分けは次の通りになります。

	ゲートウェイエンドポイント型	インターフェースエンドポイント型
利用できるサービス	Amazon S3 Amazon DynamoDB	多くのサービス
料金	無料	ENIによる時間単位の課金
VPC外（オンプレミス等）からの通信	不可	可 ※IPアドレスの到達性を確保

ゲートウェイエンドポイント型のイメージ

引用：ゲートウェイエンドポイント

インターフェースエンドポイント型のイメージ

引用：AWS サービスを介したアクセス AWS PrivateLink

3-13. VPC間接続

少し大規模になってきたときにはVPC間接続を使用しますが、本コラムでは最初のVPCを構築することとしたいので、サービス紹介だけとさせていただきます。

VPCピアリング：1対1のVPC間接続
Privatelink：1対NのVPC間接続（対向先VPCがSaaSアプリケーションなど）
Transit Gateway：多対多のVPC間接続や、オンプレミスとの接続を統合
Cloud WAN：マルチリージョン・マルチアカウント・ハイブリッド環境等の大規模環境での接続を統合

3-14. VPCとオンプレミス環境の接続

VPCとオンプレミスの接続には、インターネットを使用して接続するほか、仮想プライベートゲートウェイを使用して使用する方法があります。インターネットVPNやIP-VPN、専用線接続などの接続方法があります。既存のオンプレミスとのネットワーク要件を踏まえて決定することをおススメします。

接続方法の比較については、当社のコラムやホワイトペーパーでも紹介されておりますので、ぜひこちらも併せてご覧ください。

3-15. VPC運用設計

VPCの運用設計については、ネットワーク機器の保守・運用についてはAWS側で行いますのでこちらは意識する必要はありませんが、Network Address Usage (NAU)というメトリクスでVPCごとに定められた最大値があります。NAUが最大値に達すると新しいEC2インスタンスやVPCのリソースを構築できなくなるため、アラートを設定しておくことをおススメします。デフォルトのNAUは2024年9月現在で64,000NAUユニットとなり、256,000NAUユニットまで上限緩和できます。

アラートを受領したら、クォータの引き上げをリクエストするか、新たなVPCを作成します。

リソースごとのNAUユニットは、次の通りになります。

リソース	NAU ユニット
VPC 内にある EC2 インスタンスのネットワークインターフェイスに割り当てられた IPv4 および IPv6 の各プライベートアドレスまたはパブリックアドレス	1
EC2 インスタンスにアタッチされた追加のネットワークインターフェイス	1
ネットワークインターフェイスに割り当てられたプレフィックス	1
AZ (アベイラビリティーゾーン) あたりの Network Load Balancer	6
AZ (アベイラビリティーゾーン) あたりのゲートウェイロードバランサ―	6
AZ (アベイラビリティーゾーン) あたりの VPC エンドポイント	6
Transit Gateway アタッチメント	6
Lambda 関数	6
NAT ゲートウェイ	6
EFS マウントターゲット	6

NAUのメトリクスを利用するには、VPCごとに[Network mapping units metrics settings]を有効化します。

また、トラブルシューティングの際にはVPCのネットワークインターフェイスの間で行き来するIPトラフィックに関する情報をキャプチャできる、VPC Flow logsや、パケットキャプチャを行い、専用のソフトウェアで解析を行えるようにするVPC Traffic Mirroringもございます。詳細なネットワークのログ解析を行いたい

4. Amazon VPCおよびAWSのネットワーク利用にかかるコストの考慮

VPCを利用する際のコストについての考慮です。VPC自体を利用する際には料金はかかりませんが、オプション機能を利用する際に費用が掛かります。

VPCのオプションでかかる費用

NATゲートウェイ
パブリックIPv4アドレス
VPC Traffic Mirroring
IPAM(AWS ワークロードの IP アドレスの計画、追跡、モニタリングサービス)

これ以外にも、ネットワーク全体としてみた場合には、以下のような転送量がかかってきます。

EC2のネットワーク転送量
インターネットやVPNなどのAWSから外部へのネットワーク転送量

これらの料金は正確に算出してから利用を開始するのではなく、少しずつ利用開始して早めにネットワークやサーバーの運用負担を下げていくことをおススメします。

5. クラウドネットワーク接続サービスなどNTT東日本が提供するサービスの紹介

5-1. クラウド側の設定にクラウド導入・運用サービス

NTT東日本のクラウド導入・運用サービスは、AWSの認定を受けた担当者が提案から設計・構築・運用・保守までワンストップで対応し、専門スキルがなくお悩みの方や、最適な設計が分からない方に最適なサービスです。

Amazon VPCのネットワーク設定からファイルサーバーやADサーバーなどの構築まで対応いたします。

クラウド導入・運用 for AWS/ Microsoft Azure

5-2. 拠点側にはギガらくVPN

ギガらくVPNは、インターネットVPNの構築ご利用いただけるVPN対応ルーターサービスです。

NTT東日本のヘルプデスクがルータの設定やインターネットVPN設定を遠隔で代行するためネットワークの構築・管理を簡単に行うことができ、AWSとのSite-to-Site VPNに対応します。

ギガらくVPN

5-3. クラウド導入・運用サービスとギガらくVPNを利用した導入事例

オンプレミス型RPAのクラウド移行に成功した事例

～医療法人社団ときわさま～

医療法人社団ときわさまでは、医療事務における単純作業の一部をオンプレミスのRPAで自動化していましたが、サーバーの更新期限を機にクラウドへ移行されました。クラウド側の設定にはクラウド導入・運用サービスをご利用いただき、またクラウドと拠点との接続には費用を抑えつつVPNでネットワークのセキュリティを確保したいとのことから、ギガらくVPNを採用いただきました。

詳しい内容はこちらよりご確認ください。

「課題探し」からの伴走、粘り強い提案、円滑なコミュニケーションを高く評価。情報システム部門が0名でも、オンプレミス型RPAのクラウド移行に成功した事例