いまさら聞けないVPCのお話し　その①

投稿日: 2025/11/28

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。

いまさら聞けないシリーズの第2弾は「VPC」になります。

という訳で、前回同様、基本から応用（？）まで幅広く記載していくつもりです。

なお、公式資料としてはAWSさんからBlack Beltシリーズが詳しくサービス説明をしています。URLを載せておきます。
いつも通り、AWS Black Beltは見ずに園田がAWSのサービスについて紹介したいと思います。

　■AWS サービス別資料

https://aws.amazon.com/jp/events/aws-event-resource/archive/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc&awsf.tech-category=*all
※フィルターにてサービス名（今回だとVPC）を入力してください。

VPCって何？

お約束なので、まずはVPCって何？という所から始めましょう。
せっかくなので生成AIに聞いてみました。

googleに「VPC とは」と聞いた時の回答

完璧な回答ですね。もう私が補足するところはありません。

あまりに完璧すぎるので、ちょっと昔ばなしでもしましょう。
今となっては大変懐かしい話ですが、AWSがリリースされたのは2006年になります。

現在、2025年になるので、AWSが生まれてもうすぐ20年という事ですね。
（AWSがリリースされたときに生まれた子供がもう大学生になっている、という話です。びっくりするぐらい前ですね。常々思いますが、IT業界は進化が遅すぎてびっくりします。）

知っている方は知っていると思いますが、AWSで最初にリリースされたサービスはS3です。

今でこそ、全然シンプルじゃねーだろ、と言われるS3ですが、（Simple Storage Serviceの略です）昔は本当にシンプルなただ単にデータを置くだけのサービスでした。

この辺の細かい点については以下の資料が参考になるので、興味がある方はぜひ。（園田が大変好きな資料です）
https://d0.awsstatic.com/webinars/jp/pdf/services/20160406_AWS-BlackBelt-10years_of_AWS.pdf

その後、EC2がリリースされて、VPCが出来たのはなんと2009年になります。
今でこそ、「まずはVPC作って」となっていますが、2006年～2008年の3年間はインターネット上にEC2を立ち上げていました。

まぁ、こんな状態だったので、「クラウドはセキュリティが…」みたいな話があったわけですね。今考えると凄い話です。
ただ、当時はサーバといえばインターネットに公開するのが当たり前だったわけです。

ちなみにこのインターネット上にEC2を作成するサービスは「EC2 classic」と呼ばれ（VPCが出来て以降、後付けでそう呼ばれました）、2022年にサービス終了になりました。
実際には2015年ぐらいから作成したアカウントでは既にEC2 classicは作れなかったため、作ったことがあるよー、というユーザはほとんどいないと思われます。

話を戻しますが、2009年にVPCがリリースされたわけですが、当時は革新的な出来事として相当盛り上がったようです。

盛り上がりとしてはこんな感じ：

これでセキュリティ的な懸念が無くなったぞ。ブラボー！
的な感じの凄い出来後だったわけです。（あくまで2009年当時の話です）

今では当たり前のサービスであるVPCの凄さが分かって貰えたのではないでしょうか。

昔話はどうでもいいからVPCについて教えて

ずいぶん脱線してしまいました。
閑話休題ということで、VPCの話をするとしましょう。

いまさら説明するまでもありませんが、VPCはAWS上で仮想的なNW空間を作れるサービスとなります。
アカウント開設時、デフォルトで「172.31.0.0/16」のアドレスレンジを持つNW空間が作成されています。これをデフォルトVPCと呼びますが、不要なので削除してしまいましょう。（全リージョン、デフォルトVPCが作られているので、使うリージョン以外はそのままでも良いですが、可能であれば消しておきましょう。残しておくと勝手にサーバを作るなどセキュリティリスクが増えるので。）

基本的にVPCはお客様のオンプレミス環境、もしくは他のクラウド環境と接続することを前提としているため、きちんとNW設計を実施してIPアドレスの払い出しを実施してもらいましょう。

NW設計については以下のブログでもちょっとだけ記載しているので良ければ見てみてください。AWSのNW設計についてもきちんと記事を書きたいと思います。
https://www.ctc-g.co.jp/solutions/cloud/column/article/124.html

このVPCに割り当てるIPアドレスですが、最大「/16」となっていますが、利用できるIPアドレスについては特に制限がありません。

何が言いたいかというと、プライベートアドレスでもグローバルアドレスでも特殊アドレスでも何でも利用可能です。

ただし、グローバルのIPアドレスを付与した場合、IPが重複する特定のサイトにアクセスできない、などの事象が発生します。
そのため、基本的にはプライベートアドレス、もしくはそれに準ずるアドレスが良いでしょう。

ちなみに便宜上、クラスA、クラスB、クラスCという書き方をしましたが、現状クラスという考え方は存在しません。

かつて、「サブネット」という概念が無かった時代に

当時の名残ですが、ややこしいだけなので、クラスの概念自体を無くして欲しいものです。

なお、どうしてもプライベートIPを使いたくないけど、グローバルIPも嫌だという場合は、「100.64.0.0/10」のShared Address Spaceを使うという手もあります。
まぁ、基本はプライベートアドレスを使うよう説得してください。

IPアドレスですが、現状はIPv4だけでなく、IPv6のデュアルスタックにすることも可能です。とはいえ、きちんとIPv6の利用設計があるよ。というユーザ以外はIPv6は無効にしておきましょう。（使わない機能は無効にしておくほうが分かり易いです。運用において分かり易さは何よりも優先されると思っています。）

VPCはVPCサービスから「お使いのVPC」→「VPCを作成」ボタンをクリックすることで作成が可能です。ただ、VPCを作っただけではEC2等のサービスを作成することはできません。

実際にEC2を設置するのはサブネットになります。
そのため、VPC作成→サブネットという手順となります。

一点注意点としては、VPCはリージョン（東京リージョン、など）に所属しますが、サブネットはリージョンのアベイラビリティゾーン（以下、AZ）に所属します。
要するにサブネットを作成する際に、AZを指定するという事です。

AZは東京リージョンの場合、3つ利用が可能です（2025年10月現在）。
AZを選択する際は、東京の場合、「ap-northeast-1a」、「ap-northeast-1c」、「ap-northeast-1d」から選択可能ですが、この1a、1c、1dというのは実態を表すものではありません。

実態は1a、1c、1dに紐つく、apne1-az1、apne1-az2、apne1-az4になります。
大体みんな、1aをサブネットのA系に、1cをサブネットのB系にという形で割り当てを実施しますが、その際、アカウントによって1aと1cに紐つくaz1、az2、az4がそれぞれバラバラになっていることにより、AWSとして利用されるAZが集中しない設計となっています。

なので、基本的は全てのアカウントで「az1」をA系に、「az2」をB系にみたいな設計はやめましょう。
障害時に全てのアカウントで影響が一緒なので分かり易いと言えば分かり易いですが、そうではなく「Design For Failure」(故障を前提とした設計)にて障害に備える設計にしましょう

VPCに外部接続を持たせる

VPCを作成しましたが、VPCは「Virtual Private Cloud」なので閉じた空間になります。
作っただけではどこからもアクセスできません。これはこれで非常に安心ですが、全くテストも出来ないので、このままでは（実質）利用できません。

という訳でこのVPCに対してリーチャビリティを確保する必要があります。
VPCにはXX gatewayというのを接続（アタッチ）することで接続が可能となります。

どのような物があるか見ていきましょう。

意外とありますね。1つずつ説明していきましょう。

1．インターネットゲートウェイ（igw）

インターネットに接続するためのゲートウェイです。
VPCにigwをアタッチ、ルートテーブルで、0.0.0.0/0（デフォルトルート）をigwに向けてあげることでインターネットからの接続、ならびにインターネットへの接続が可能となります。

igwをデフォルトルートにしているサブネットを便宜上publicサブネット。それ以外をprivateサブネットと呼称します。（AWSのマネジメントコンソール上でpublicサブネット、privateサブネットというものは存在しません。）

2．仮想プライベートゲートウェイ (vgw)

仮想プライベートゲートウェイ（vgw）ってAWSのアイコンが無いんですよね…。

図を記載する時、非常に困ります。

こちらはVPCが外部環境（お客様のオンプレミス環境）と接続する際のゲートウェイとなります。

このvgwに対し、

を接続することが可能です。

逆に言うと、この2つのサービスを使う時はかならずvgwが必要という事ですね。

3．VPC peering

別のVPCと接続する際に利用します。
VPC Peeringは必ず1対1となりますので、複数のVPCと接続する際は、VPC分のPeeringが必要となります。

また、全てのVPCとリーチャビリティを持たすためには、「N（N-1）/ 2」のVPC Peeringが必要となります。管理が大変になることが予想されるので、そのような場合は、Transit Gatewayを利用することを推奨します。

なお、この「1」～「3」のサービスについては接続そのものには費用が掛かりません。

全てのサービスは通信費用のみとなります。
そのため、費用を安価に抑えることが出来ます。

逆に言うと「4」～「6」のサービスについては利用料が発生します。

4．Transit gateway

Transit gatewayを作成し、それに対し以下のサービスを接続させることで外部への接続が可能となります。
「1」～「3」のサービスとは異なり、VPCに所属しない別サービスとなります。

Transit gatewayには以下が接続可能となります。

VPCに接続する際は、アタッチメントの作成が必要となります。
アタッチメントの作成には0.07ドル/月の費用が掛かるので、1カ月だとそれなりの金額になります。（50.4ドル/30日）

5．VPCエンドポイント

インターネットを経由せずAWSのサービスに接続するためのエンドポイント（接続点）になります。

こちらもエンドポイントが利用するIFを作成する必要があり、「10.08ドル（30日/シングルAZ）」、「20.16ドル（30日/マルチAZ）」の費用が発生します。（gateway型のS3、およびDynamoDBのみは無料です。それ以外は上記費用が発生します。）

インターネットに接続できない、またセキュリティを強化したいという場合は、このVPCエンドポイントを利用しましょう。

6．Private Link

Private Linkはちょっと特殊な接続になります。
構成としてはこんな感じです。（AWSの公式サイトより抜粋）

上記の図でいうと、Customer VPC　→　Service Provider VPCに対し「一方通行」の接続が可能となります。

基本的にVPC間はIPアドレスが重複しては接続が出来ませんが、Private Linkを使うと、利用者は自身のVPC内にある「PrivateLink Endpoint」に通信すると、いつの間にか別のVPCのEC2に接続が出来る。というものとなります。

画像の通り、通常はSerive Providerが顧客に対し、サービスを提供する際の経路して利用されます。まぁ、なので一般的には忘れて貰っても問題ないかと思います。

ケースとしては、

みたいな時に利用しますね。

というわけで、VPCについてはこんな感じのXX gatewayを接続することで、初めて外部との接続が可能となります。

要件と整理して、きちんと外部とのリーチャビリティを設計しましょう。

VPCに関するセキュリティ

VPCに関してはセキュリティを確保する手段として、「ネットワーク ACL」と「セキュリティグループ」が存在します。
今更の説明になりますが、「いまさら聞けない」シリーズなので簡単に説明しておきましょう。

まずは簡単に、「ネットワーク ACL」と「セキュリティグループ」の違いを見ていきましょう。こんな感じになります。

正直言ってこれ以上でも以下でもありません。
とはいえ、一応、ちょっとだけ説明しましょう。

「ネットワーク ACL」について

図の通りですが、「ネットワーク ACL」は「サブネット」に対して適用されています。
ネットワーク ACLなんて使ったことないよー。という方もおられると思いますが、そんなことはありません。

かならず使ってます。

サブネットを作成すると必ずデフォルトのネットワーク ACLが紐付けられています。

で、どのようなルールになっているかというと、

となっています（IN、OUT共通）。
何が言いたいかというと、デフォルトでオールパーミットになっているという事です。
そのため、特に意識しなくても気が付かない状態となっています。

基本ネットワーク ACLのメリットは無いのですが、強いて言うのであれば不要な通信を

サブネット内に流さないという事でしょうか。
正直、影響が出るほど不正な通信が行われている時点でかなりやばい状態なので普通に考えてメリットは無いです。

ネットワーク ACLはciscoのACLと一緒ですね。
ステートレスなので片方向の通信しか考慮されていません。
具体的には、

ユーザ　→　「ネットワーク ACL」→　Webサーバ

という通信をする場合、

という設定が必要なります。

要するに「ステートレスなので戻りとなるアウトバウンドの設定が必要」という事になります。（いまどきステートレスって…。というレベルの話ですね。ウェルノウンポートという単語久しぶりに使いました。）

アウトバウンドの設定ですが、きちんと書こうと思うと管理が少なくとも2倍以上になってしまうので結果的に「がばがば」 or 「ちゃんとやろうとしすぎて通信がちゃんとできない」というパターンになりがちです。

正直手間がかかることはやってはいけません。コスパを考えましょう。

一応擁護すると、ネットワーク ACLは途中にDenyを記載することが可能です。

どういうことかというと、

という事が可能です。（実際にはDenyをルール番号の上位に記載する必要があります。（ACLは順番毎の適用なので））

そのため、どうしても「XXXはDenyしたいんだー」という時はネットワーク ACLを使う必要があります。
昔はこの特定の通信のみDenyするという機能がネットワーク ACLしかなかったため利用していましたが、現在ではAWS WAFのIP setで特定のIPからの通信をDenyするという機能があるので、やっぱりネットワーク ACLは使いません。（AWS WAFはログも出ますしね…）

こんな状況の時は「ネットワーク ACL」を利用するよー、という方は是非教えてください。

「セキュリティグループ」について

続けてセキュリティグループですね。
こちらは普通のFWになります。要するにステートフルインスペクションに対応しているという事です。

ステートフルインスペクションは「INの通信が許可されている場合、OUTの通信については自動的に許可」（要するにステートフル（システムが状態を記憶している）という事です。）してくれるという機能です。

そのため、基本はINの通信のみ記載すればOKとなります。
セキュリティグループについてはACLと異なり、基本はDeny’（通信を拒否）となっており、必要な通信を許可するという形式になっています。

また、ネットワークACLとは異なり、インスタンスに適用します。
そのため、同サブネット内でも通信可否を定義できます。（所謂「ゼロトラスト」になります。この言葉も懐かしいですね。）

基本機能として、きめ細やかなセキュリティ制御が出来るというのがクラウドのいいところですね。

インスタンスに適用と説明するとOSまで通信が来るのはちょっと、という方もいますが、通信はAWSレイヤにて制御されていますのでOSまで届きません。
（VPCフローログで通信を確認すると、セキュリティグループで許可されていないものはきちんとDenyされていることが分かります。）

なお、セキュリティグループはVPCに所属します。
そのため、同じアカウント内のVPCであってもVPCが異なると、同じセキュリティグループを利用することが出来ません。

このセキュリティグループについては、同アカウント内のみ共有可能な機能がリリースされています。　（セキュリティグループを選択、上タブの「共有中 - 新規」にて共有可能）

複数VPCがあってセキュリティグループの管理を楽にしたいという方は共有機能を使ってみましょう。

セキュリティグループの共有機能はアカウントを跨いで使えるといいのですが、残念ながらそれは出来ません。
一応、共有VPCの機能を使う場合、アカウントを跨いでもセキュリティグループの利用が可能ですが、まぁ特例と思っていただいて問題ありません。通常だとアカウントを跨いでセキュリティグループは利用できないです。（共有VPC好きなんですけどね）

IAMと同様、だいぶ長くなってしまったので続きは
「いまさら聞けないVPCのお話し　その②」でお話ししようと思います。

正直VPCは1つの記事で説明できるかなと思いましたが、無理でした。説明することが多くて大変です。
その②では、その他VPCで利用するオプションについてお話ししたいと思います。

ではまたー。

お問い合わせ

【著者プロフィール】

園田　一史（そのだ　かずし）

伊藤忠テクノソリューションズ株式会社　クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS（キュービック オン エーダブリューエス）」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年～2025年APN Ambassadorに選任。