【解説】VPCとは何かを分かりやすく解説します

Table of Contents

はじめに

クラウドでシステムを構築するとき、まず最初に向き合うのがネットワークの設計です。その中心にあるのがVPCです。VPCはVirtual Private Cloudの略で、クラウド上に用意できる自分専用の仮想ネットワーク空間を指します。オンプレミスのデータセンターでいえば、建物と敷地を借りて自社のネットワークを引くのに相当します。awsではAmazon VPCというサービス名で提供されており、多くの設計判断がこの中で完結します。本記事では、はじめての方にも伝わるように、VPCの基本から実運用のポイントまで丁寧に解説します。

VPCを一枚の地図で捉える

土地と区画と道路の比喩で理解する

VPCは土地、サブネットは区画、ルートやゲートウェイは道路と出入口にたとえると理解しやすくなります。

最初に土地の広さを決めることで、あとからどれだけの区画を作れるか、どの方向に道路を伸ばせるかが決まります。実際には、CIDRブロックという表記でVPCのアドレス範囲を定義し、その範囲をサブネットに分割し、ルートテーブルで通信経路を定め、インターネットや社内ネットワークへの出入口を設けます。

VPCの役割

一言でいえば、VPCはクラウド上のリソースを安全に隔離し、必要な相手とだけ通信させるための器です。インスタンスやコンテナ、データベース、ロードバランサーといったコンピューティングと密接に結びつき、可用性、セキュリティ、コストに大きな影響を与えます。

主要コンポーネントを順に理解する

CIDRブロックとIPアドレス設計

VPCの最初の決断はIPアドレスの広さをどれにするかです。例として、10.0.0.0から10.0.255.255までを含む10.0.0.0/16の範囲をVPCに割り当てる、というように決めます。

あまりに狭いと後からサブネットが足りなくなり、広すぎると他のネットワークと重複しやすくなります。将来の拡張やマルチアカウント、マルチリージョンを見据えて、重複しない範囲をあらかじめ計画的に配ることが重要です。IPv6を併用すればアドレス枯渇の心配は緩和されますが、運用やセキュリティのポリシーを合わせておく必要があります。

サブネットの設計

サブネットはアベイラビリティーゾーンごとに作るのが基本です。可用性を高めるため、同じ役割のサブネットを複数ゾーンに展開します。サブネットには大きく公開系と非公開系の二種類があります。公開サブネットはインターネットへの直通ルートを持ち、ロードバランサーや踏み台サーバーなどの入口に向く一方、非公開サブネットは直接の外部公開を避けたいアプリケーションやデータベースに向きます。

アベイラビリティーゾーンをまたいだ冗長化

同一リージョン内で二つ以上のゾーンに同じ構成を展開し、どちらか一方が障害になってもサービスが継続するようにします。サブネット名やタグの付け方を標準化し、運用時にどの資産がどのゾーンにあるかを即座に把握できるようにしておくと効果的です。

ルートテーブル

ルートテーブルはサブネットの道路標識です。宛先のCIDRに対して、どのターゲットに転送するかを定義します。

よくあるエントリとして、デフォルトルートをインターネットゲートウェイへ向ける公開サブネットのルート、デフォルトルートをNATゲートウェイへ向ける非公開サブネットのルート、オンプレミスへの宛先を仮想プライベートゲートウェイやTransit Gatewayへ向けるルートなどがあります。

ルートの抜けや重複は通信不可や意図しない経路選択の原因になるため、変更時は影響範囲を丁寧に確認します。

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

インターネットゲートウェイはVPCの外のインターネットとやり取りするための出入口です。公開サブネットに置いたロードバランサーやプロキシからの受信に使います。

一方、NATゲートウェイは非公開サブネットにあるインスタンスからの送信を外に出すときに使います。外部からの着信はNATゲートウェイでは受けられないため、非公開リソースを直接公開したいときは設計の見直しが必要です。

ソフトウェア更新やパッケージ取得のために非公開サーバーが外へ出る必要がある場合、NATの配置数や規模はコストに直結するため、後述のエンドポイントの活用で外部転送量を減らすことがよく行われます。

セキュリティグループとネットワークACL

セキュリティグループはインスタンスやロードバランサーに付ける仮想ファイアウォールです。状態保持型で、許可した通信の戻りは自動的に許可されます。

ネットワークACLはサブネット単位のルールで、より低い層でのガードレールとして機能します。基本はセキュリティグループで制御し、ACLは広い拒否や一律の制限に使う、という役割分担にすると運用が安定します。

接続手段の選択肢

エンドポイントの基礎と使いどころ

エンドポイントは、VPCの中から特定のクラウドサービスに対して、インターネットを経由せずに私設の回線でアクセスする仕組みです。大きく二種類あります。

ゲートウェイ型はS3やDynamoDB向けに提供され、ルートテーブルに経路を追加するだけで利用できます。

インターフェイス型は多くのサービスに対応し、VPC内にネットワークインターフェイスを作ってそこへプライベートに接続します。いずれの場合も、外部に出ずに通信できるためセキュリティとコストの両面で有利です。例えばソフトウェアの配布をS3で行い、非公開サブネットのサーバーからはS3のゲートウェイ型エンドポイント経由で取得させれば、NATゲートウェイの転送量を削減できます。インターフェイス型はサービスごとにエンドポイントポリシーでアクセス制御ができ、統制にも役立ちます。

ピアリングでVPC同士を直結する

ピアリングは二つのVPCを直接つなぐ方式です。同一リージョン間はもちろん、クロスリージョンでも可能です。特徴はシンプルさで、両VPCのルートテーブルに相互経路を追加するだけで直接通信できます。ただし、ピアリングは一対一の関係であり、経路は非推移的です。

AとB、BとCがつながっていても、AからCへはB経由で届きません。また、CIDRが重複していると接続できない点にも注意が必要です。複数VPCをハブアンドスポークでつなぐ必要がある場合は、Transit Gatewayなどのハブ型サービスを検討すると運用が楽になります。

オンプレミスとの接続

企業ネットワークからVPCへは、暗号化トンネルのVPN、専用線のDirect Connect、あるいは両者の併用が一般的です。

重要度や帯域、コスト、冗長性の要件に応じて組み合わせを選びます。オンプレミス側の経路とVPC側のルートテーブル、さらにセキュリティグループやACLの整合性を取ることが成功の鍵です。

監視とトラブルシューティング

フローログで通信の実態を記録する

フローログはVPC、サブネット、またはネットワークインターフェイス単位で、どのIPがどのポートへいつ通信し、それが許可か拒否かを記録する機能です。

出力先はCloudWatch LogsやS3を選べます。通信不能時にセキュリティグループの許可漏れなのか、ルートの欠落なのか、あるいは相手側の拒否なのかを切り分けるのに有効です。

例えばアプリケーションサーバーからデータベースへの接続が断続的に失敗する場合、フローログを期間指定で検索して、特定のポート宛ての拒否が増えていないか、スパイクがいつ発生しているかを可視化できます。ログの保持期間や出力粒度はコストに影響するため、重要な区画から段階的に有効化するのが現実的です。

よくある落とし穴と確認順序

一つ目はCIDRの重複です。将来のピアリングやハブ接続を見据え、アカウントやリージョンをまたいでも重ならない計画を立ててください。

二つ目は非公開サブネットからの外向き通信で、NAT経由かエンドポイントかの設計が中途半端になりがちです。

三つ目はセキュリティグループの双方向の許可漏れで、片方だけ開けても意図通りに動かないことがあります。切り分けの際は順に、名前解決、ルート、ゲートウェイ、セキュリティグループ、ACL、アプリケーションの順で確認すると迷いにくくなります。

典型アーキテクチャで学ぶ

小さく始めて大きく育てる三層構成

公開サブネットにアプリケーションの入口となるロードバランサーを置き、非公開サブネットにアプリケーションサーバー、さらに別の非公開サブネットにデータベースを配置します。

運用管理のための踏み台は公開サブネットに置きますが、実運用では踏み台すら公開せず、セキュアな踏み台サービスやSession Managerのような方式に寄せるのが主流です。

非公開サブネットからの外部取得は、S3やコードリポジトリに向けてエンドポイントを作ることでNATの負荷を下げます。ログはCloudWatchやS3に集約し、重要なサブネットからフローログを有効化して、異常検知と監査証跡の両方を満たします。

マルチアカウントやマルチVPCへの発展

組織が大きくなると、開発、検証、本番でVPCを分け、アカウントも分離するのが一般的です。このとき、ピアリングを多数張ると運用が複雑になりやすいため、ハブとしてTransit Gatewayを導入し、各VPCをスポークとして接続すると見通しがよくなります。

サービス間の個別公開にはインターフェイス型エンドポイントを介したPrivateLinkのパターンが有効で、相手VPCに直接ルートを広げずに特定サービスだけを提供できます。

コストの考え方

VPCそのものに大きな固定費はありませんが、周辺のコンポーネントがコストの主役です。

NATゲートウェイは時間課金とデータ転送量が発生するため、ソフトウェア取得やストレージアクセスをエンドポイントへ切り替えると顕著な削減につながります。

インターフェイス型エンドポイントは時間課金とデータ処理量があるため、必要なサービスに絞り、共有サブネットで使い回す設計も検討余地があります。

ピアリングやTransit Gatewayをまたぐデータ転送は方向やリージョンの違いで単価が変わるため、アプリケーションの会話の多い部分を同一VPCや同一ゾーンに寄せるとコストと遅延を同時に抑えられます。

フローログやロードバランサーのアクセスログは保持期間と出力先を設計し、保管コストと分析の利便性のバランスを取りましょう。

セキュリティとガバナンス

最小権限の原則はネットワークでも有効です。セキュリティグループは用途ごとに小さく分け、相互参照の関係を整理します。エンドポイントにはポリシーで利用可能なプリンシパルや操作を制限し、不要なリージョン外通信を抑えます。

監査の観点では、重要サブネットのフローログ、ロードバランサーのアクセスログ、DNSクエリのログなどを一元的に収集し、検知ルールを継続的に磨き上げることが効果的です。

変更管理の面では、ネットワーク構成をコード化し、レビューと段階的デプロイを通じてリスクを減らします。awsの各種サービスと連携し、タグやアカウントガードレールを活用すると、運用の見通しが格段に良くなります。

設計チェックリスト

一つ、VPCとサブネットのCIDRは将来の拡張と外部接続を想定して重複を避けていますか。
二つ、公開と非公開の役割分担は明確で、インターネットへの入口は限定されていますか。
三つ、非公開からの外向き通信はエンドポイントで極力閉じ、NATは最小限ですか。
四つ、セキュリティグループとACLの役割を分け、レビューしやすい命名と粒度になっていますか。
五つ、監視と記録はフローログやアクセスログを含めて一元化され、保持と可視化の方針が明文化されていますか。
六つ、将来のピアリングやハブ接続に備えて、経路設計と命名規則が統一されていますか。

具体シナリオでの判断軸

パッケージ更新が多い非公開サーバー群

毎日多くの更新を行うサーバー群がある場合、NAT経由の外向き通信はコストとボトルネックになりがちです。S3やコード配布の仕組みを見直し、対応するエンドポイントを活用することで、転送コストと遅延を減らせます。さらにミラーサーバーをVPC内に用意して、更新の爆発を内部に吸収する方法もあります。

サービス間連携を最小限の公開で行いたい

別チームのVPCにあるAPIだけを安全に呼びたい場合、ピアリングで広範囲に経路を開くのではなく、相手側にインターフェイス型エンドポイントサービスを用意してもらい、こちらのVPCに対応するエンドポイントを作ると、公開範囲を最小限にできます。監査や課金の分離もしやすくなります。

段階的移行のためにオンプレと併用する

初期はVPNでつなぎ、帯域や安定性の要件が固まってきたらDirect Connectへ段階的に切り替える、といったステップを踏むと、リスクとコストをコントロールしやすくなります。いずれの段階でも、ルートの優先順位とフェイルオーバーの方針を明確にし、定期的に切替試験を行うことが肝要です。

運用のコツ

日常運用では、変更履歴の可視化と自動テストが効果を発揮します。ネットワークをコードとして管理し、レビューで四つの観点を確認すると安心です。宛先と経路に矛盾がないか、セキュリティ境界が緩んでいないか、ログ収集に抜けがないか、コストに影響する変更になっていないか。定期的にフローログを集計して、普段使われていないポートや想定外の宛先を洗い出し、ルールや経路を整理していくと、シンプルさが保てます。