いまさら聞けないVPCのお話し その②
投稿日: 2025/11/28
はじめに
こんにちは、園田です。
今回は「いまさら聞けないVPCのお話し その②」になります。
途中からになりますのでその①を読んでない方は、まずは「いまさら聞けないVPCのお話し その①」を見てみてください。
前回の続きという事でお話の振り返りをしたいと思います。
前回はこんな感じでした。
- VPCって何？
→ VPCについての昔話でした。昔はVPC無かったんだよ。 - VPCについて
→ VPCに関するリージョンとサブネットのお話し - VPCに外部接続を持たせる
→ 閉じたNW空間であるVPCに対し、外部接続を持たせる場合の方法と種類についてお話ししました。 - VPCに関するセキュリティ
→ 定番のセキュリティグループとネットワークACLのお話でした。
今回VPCに関連するオプションのお話ですね。
VPCってオプションがむっちゃ増えましたからね。頑張って説明していきたいと思います。
DHCP オプションセット
はい、出ました。DHCPオプションセットです。
多分、ほとんど使う事のないオプションだと思います。
AWSではDNSサーバ（フルサービスリゾルバ）についてはDHCPにより配布されます。
その際、デフォルトではサブネット +2のIPアドレスとなります。（192.168.0.0/24のサブネットの場合、192.168.0.2のIPとなります）
で、この配布されるDNSサーバ（フルサービスリゾルバ）のアドレスを配布するのがDHCPオプションセットです。
デフォルトでは、ドメインネームサーバーが「AmazonProvidedDNS」になっています。
これを変更したい場合、
ドメインネームサーバーに、「192.168.1.10 , 192.168.2.10 , AmazonProvidedDNS」みたいな感じで記載すると
EC2側で、DNSサーバが
- 192.168.1.10
- 192.168.2.10
- サブネット + 2のIP
という形になります。
このDHCPオプションセットは、AWSのDNSではなく、オンプレミスのDNSサーバにて名前解決をさせたいという場合に利用されるものです。
特定のゾーンについてはグローバルから名前解決する場合と、プライベートで名前解決する際は同じドメインでもIPアドレスが違うよー。といった場合など、どうしてもオンプレミスのDNSにて名前解決をさせたい場合に利用します。
昔はオンプレミスのDNSを利用したい場合はDHCPオプションセットしか無かったのですが、現状ではroute53 アウトバウンドリゾルバでよりオンプレミスのDNSを選択させることが可能であるため利用される機会は激減しました。
Route53だと特定のドメインだけをオンプレミスのサーバに問い合わせに行かせることが可能です。
具体的には「ctc-sonoda.com」というドメインがあって、そのドメインへの問い合わせだけは192.168.100.100のDNSを確認するという感じです。それ以外はAWSのDNSを使うため、仮にオンプレミスまでの経路に障害があった場合も影響が最小限で抑えられます。
ということでroute53 アウトバウンドリゾルバは便利なんですが、利用に180ドル/30日の費用が発生します。一方、DHCPオプションセットは無料で利用が出来ます。
そのため、費用を節約したいという場合、DHCPオプションセットを利用する方がいいかもしれませんね。ただし、DHCPオプションセットは複数アカウントで共有できません。アカウントが増えてきた場合はroute53 アウトバウンドリゾルバを共有することを推奨します。
先程、費用が掛かると話をしましたが、複数のアカウントで共有すると値段は相対的に安くなります。
route53 アウトバウンドリゾルバの共有については、以下の記事を参照ください。
大規模なAWS NWを管理する
（VPCエンドポイント、Route53の共有）（2）
https://www.ctc-g.co.jp/solutions/cloud/column/article/126.html
NATゲートウェイ
いまさら説明はいらないような気がするNAT ゲートウェイです。
インターネットに接続したーい、でもサーバから直接インターネットに接続させたくないー。といった場合に利用します。
というか、VPCを利用するにあたって、ほぼmustで利用される機能ですね。
NAT ゲートウェイ利用時のインターネット接続はこんな感じになりますね。
通常、プライベートサブネットに存在するEC2はインターネットに接続は出来ませんが（グローバルIPを持たないので当たり前です）、NAT ゲートウェイを経由することにより、NAT ゲートウェイが持つグローバルIPでNAT（NAPT、IPマスカレード、PAT）し、インターネットに接続することが出来ます。
NATと言いながら、実際にはNATP（IPマスカレード、PAT）となります。そのため、外部からNAT ゲートウェイ経由で接続することはできません。
なお、NAT ゲートウェイは上記の図の通り、AZ障害に備えるため、各AZに1つずつ作っておきましょう。
NAT ゲートウェイで利用されるグローバルIPはEIPとなるため、1度NAT ゲートウェイを作成すると変更はされません。
これも複数AWSアカウントがある場合、各VPCでNAT ゲートウェイを作ってしまうと
外部に接続する際のIPアドレスがバラバラになってしまい、統制を取り辛くなるので、可能な限り同じNAT ゲートウェイを使ったほうがいいですね。
（NATゲートウェイを持つのは1つのアカウントに限定して、Transit Gateway等でアカウント間をつなぐと実現可能です。大規模でAWSを利用する場合、各アカウントに明確な役割を与えたほうが分かり易いです）
ネットワークファイアウォール
はい、出ました。ネットワークファイアウォールです。
「ネットワークファイアウォールだけで記事が書けるのでは…。」とも思いますが、今回は簡単にサクッと行きましょう。
ネットワークファイアウォールは大きく分けて、以下の2つの機能を持ちます。
- ステートレスなパケットフィルタリング
→ 要するに普通のFWの機能です。 - 送信先ドメイン名を基にしたHTTP/HTTPSのアクセス制御
→ 要するにプロキシ機能です。
大体プロキシとして利用されているケースが多いのではないでしょうか。
送信元ドメインに対し、通信可、不可を設定が出来ます。
通信全てネットワークファイアウォールを通るルーティングとすることで、ネットワークファイアウォールで全てのパケットの精査が可能です。あくまでルーティング上そのように設定すればという話なので、ネットワークファイアウォールをいれれば全ての通信をフィルタリングできるという訳ではありません。
なお、同サブネット内にある通信は検査できないため、ネットワークファイアウォールについては専用のサブネットに置くことが推奨されます。
なお、プロキシとして利用する際は、
- 特定のドメイン名に対し、拒否を設定する（ブラックリスト式）
- 特定ドメイン名へのアクセスのみ許可してそれ以外は拒否（ホワイトリスト式）
の選択は可能です。
とはいえ手動で設定が必要なので運用が面倒です。
そのため、実際には「ステートレスなパケットフィルタリング」はセキュリティグループで分散して管理する。「送信先ドメイン名を基にしたHTTP/HTTPSのアクセス制御」に関してはクラウドプロキシを利用する、またはオンプレミス環境で利用しているプロキシを利用する方が、きめ細かな制御が出来るため、良いと思います。
あくまでAWSの標準ツールでプロキシも出来るよ。ぐらいで留めておくことを推奨します。
トラフィックミラーリング
OS上でwiresharkとか、dumpコマンドを実行しなくてもトラフィックが取れる機能です。
もちろん取得したデータはwiresharkで閲覧可能です。
NWエンジニアが大好きな機能ですね。
基本通信については、VPCフローログで見れるのですが、VPCフローログでは、「どこからどの通信が来た」（TCPであれば、スリーウェイハンドシェイクが正しくできた）という事しか分かりません。
別にそれでイイじゃん。とも思いますが、具体的にはこんな時に困ります。
- 正しく通信が出来ない
→ 送信側のサーバがデータを正しく投げているか知りたい
→ 受信側のサーバがデータを受け取った際、どのようなデータを受け取っているか知りたい
こんな時、オンプレミスあれば、
「OSにログインして通信データを取得」とか「スイッチにポートミラーリング設定をして通信データを取得」とかを実施するのですがAWSではトラフィックミラーリングという機能を使って、EC2に送信されるデータを別のEC2で取得することが可能です。
具体的にはこんな感じ
上記の例では、
- サーバA→サーバBの通信がうまくいかない。
- サーバB側で通信をキャプチャしたい
という時にサーバBに届く通信をミラーして、サーバCに転送する機能ですね。
サーバCは全く関係ないサーバで切り分けの為、新規に作成するのが一般的です。
一応、このミラーリングは制限があって「Nitro世代のインスタンス」である必要があります。（Nitro世代は、t3、m5以上のインスタンスです。今ではほぼ全部使えるといっても良いでしょう）
まぁ、AWSでもtcp dump取れるよ。と覚えておきましょう。
VPCの共有
最後はVPCの共有ですね。
マネジメントコンソールから確認できるVPCサービスの左タブの画面にはVPC共有というものはありませんが、実はVPCを他のアカウントと共有することが出来ます。
この機能はRAM（AWS Resource Access Manager）から利用が可能です。
ただ、この共有VPCについては一部制限があって、同じOrganizationのアカウントに所属している必要があります。
AWSアカウントを直接契約している場合、この機能を利用したい場合は1つのOrganizationに頑張ってまとめましょう。リセラーからAWSを提供してもらっている場合は、Organizationの機能が利用できるかどうか、の確認が必要です。
なお、VPCの共有（英語だと、「VPC Sharing」）という記載なのに、実際に共有するのはサブネットになります。
名前はおいて置いて、正直この機能無茶苦茶便利で使える機能です。
複数のアカウントがあった場合、NWで統制を取るのが結構大変になりますが、このVPC共有を利用することで、
共有するアカウントから見たメリット
- 事前に作成したサブネットを共有することで、エンドポイントなどを各アカウントで共有できる
- NWルールを各アカウントで統一できる
共有されるアカウントから見たメリット
- NW設定を実施しなくて良い
というメリットがあります。
実際には、共有される側から共有していない側のVPCを勝手に変更できるので、統制の為制限をかける、みたいなことをする必要があるかと思いますが、その際もSCPでNW関連は全部Denyしてしまって全く問題ありません。
実際に利用するのは共有する側のAWSアカウントのVPCになるため、共有される側は権限無くても何の問題もありません。
先程記載した通り、共有VPCを利用する場合は同一Organizationに所属している必要があります。
とはいえ、統制を取ろうとすると、むしろ同じOrganizationに所属して欲しいところです。
同じOrganizationに所属されることが基本は前提になりますので、積極的に共有VPCをつかってもよいのでは？と思います。
とはいえ、この辺はお客様にきちんと説明して、ちゃんと了承を貰ったうえで進める必要があります。この説明が一番難しそうですね。
アーキテクチャを理解いただいた上で、将来像をきちんと共有するというのが大事ですが、なかなか骨が折れる仕事になります。
という訳で、「いまさら聞けないVPCのお話し」となります。
IAMに比べるとVPCはそこまで難しくないですね。
とりあえず設定というレベルだとVPCはかなり簡単だと思います。
ただ、きちんと設計するとなると途端にレベルが上がってしまうのがVPC（というか、NW）の宿命ですね。
クラウドが一般的になってNWの知識は不要になったかと思わせておきながら、実際にはより深いレベルのNWの知識が必要になるというのは面白いところです。
今後クラウドがどんな風になっていくのかは良く分かりませんが、今年より1年後、1年後より3年後、3年後より10年後は、より高度な知識が求められることだけは間違いありません。
常に新しい知識と高度な知識を取得していきましょう。
ではまた、別の記事でお会いしましょう。
- 関連コラム
