AWSでVPCを分割する理由と設計のベストプラクティス

VPCを分割する必要性

2025年現在、AWS Well-Architected Frameworkでもワークロードを論理的に分離し、ネットワークレイヤーを構築することが推奨されています。

AWS Well-Architected Frameworkの記載例

SEC05-BP01 ネットワークレイヤーを作成する

ワークロードコンポーネントをそのデータの機密度とアクセス要件に応じて論理的にグループ化し、そのグループに基づいてネットワークトポロジをさまざまなレイヤーに分割します。インターネットからのインバウンドアクセスを必要とするコンポーネント (公開ウェブエンドポイントなど) と、内部アクセスのみを必要とするコンポーネント (データベースなど) は区別します。

期待される成果: ネットワークのレイヤーは、ワークロードにおける ID の認証と認可の戦略を補完する多層防御セキュリティアプローチに不可欠な部分です。データの機密度とアクセス要件に応じてレイヤーが配置され、トラフィックフローと統制のメカニズムが適切に機能しています。

一般的なアンチパターン:

• 単一の VPC またはサブネットですべてのリソースを作成する。
• データの機密度の要件、コンポーネントの動作、機能を考慮せずにネットワークレイヤーを構築する。
• ネットワークレイヤーのすべての考慮事項について、デフォルトとして VPC とサブネットを使用し、AWS マネージドサービスがトポロジに与える影響を考慮していない。

引用：SEC05-BP01 ネットワークレイヤーを作成する - AWS Well-Architected フレームワーク

本項は情報セキュリティ観点でのVPCの分割によるネットワークレイヤーの作成と、データの機密度とアクセス要件の統制に関してのベストプラクティスとなっていますが、単一のVPCで運用することで、一般的にこのようなデメリットが発生します。

VPCを分割しないことによるデメリット

• ネットワークの到達性があることで、一つのサブネットで発生したセキュリティインシデントが別のサブネットへ波及する可能性があります
  セキュリティグループやNACLで管理することも可能ですが、これらの管理が煩雑化することと、VPCを分割したほうがシンプルにネットワークの到達性を分割させることができます
• 検証用のリソースと本番用のリソースを混在させることでネットワーク設定に差分が出るため、本番環境への適用時に環境差分を埋める必要が出てきます
• 複数組織で同一のVPCを利用している場合、AWS利用料の按分の際にネットワークトラフィックの利用料をどうするかを決めておく必要があります
• 単一VPCで複数システムを運用している場合、ネットワーク変更やセキュリティ設定の影響範囲が広く、変更管理が複雑になります
• 障害発生時に影響範囲を限定できず、復旧対応が長期化するリスクがあります

（余談）単一のVPCが良いとされた時代も

余談ですが、単一のVPCで構成するのが良いとされた時代もありました。例えば、VPCがリリースされた当初は単一のVPCで構成することが基本となっていました。これはVPCがセキュリティ機能を持たず、企業の内部ネットワークの拡張としてリリースされたことに起因すると考えています。

この根拠の一つとして、re:Invent 2023のNetworking分野のInnovation TalkでスピーカーのDave Brown氏が「当初、VPCは一つでよいと考えていた」という発言もあり、VPC間を接続するVPCピアリングが2014年リリースということを考えると、当時は単一のVPCを利用することがよしとされていました。

Dave氏の当時を振り返る発言やセッションに関するコラムはこちら

【AWS re:Invent 2023】[NET208]The power of cloud network Innovation参加レポート

AWSのネットワークに関するお悩みや課題などNTT東日本のクラウドエンジニアがお応えします。お気軽にご相談ください！

VPCを分割する際の考慮ポイント

では、どのようにVPCを分割していくことが良いでしょうか？いくつかの視点で分けて考えていきたいと思います。

信頼境界での分割

情報セキュリティにおける信頼境界の考え方で分割するのが一つの考え方です。信頼境界とは、「信頼できるものと、信頼できないものとの境界」と呼ばれるものです。ネットワークの信頼境界でよく言われるのは、インターネットに直接通信可能なネットワーク、プライベートネットワークおよびその中間のDMZとなります。この3つでVPCおよびサブネットを分割していきます。具体的には、Webレイヤー、アプリケーションレイヤー、データベースレイヤーで分ける、といった選択肢がこの分割方法になります。

用途での分割

次に用途での分割を考えます。ワークロードの種類や機能、利用対象者で分割を行います。VPCが大量になりますが、機能ごとに分割できれば単一の機能の障害だけにとどまり、他の機能は無事に機能する、といったことも可能になります。

また、社内向けのプライベートネットワークで使うアプリケーションを分割しておくことで、インターネットへの公開を行わない、アウトバウンドの通信を集約するといった設計を実行することができるようになります。こうした入出力の処理をデータの機密度に合わせてネットワークレイヤーを定めることも大切になってきます。

環境での分割

同じアプリケーションでも、検証環境・ステージング環境・本番環境といった環境での分割も検討します。環境での分割を行うことで、検証環境のデータが本番環境に影響を及ぼさない、検証環境の設定と本番環境の設定の差分が出ないようにすることができるようになります。

運用・管理組織での分割

一つのVPCに複数の運用・管理組織がいると、責任分界点があいまいとなります。サブネットで運用・管理組織を分けることもできますが、ネットワークの設計追加やとあるサブネットでのトラブルが他の運用・管理組織のリソースに影響を与えることもあります。

予算での分割

運用・管理組織と似ていますが、AWS利用料やアプリケーションの利用料の予算をもつ管理組織で分割することも考えます。タグを使うことで一つのVPCでもコスト配分を行うことはできますが、利用組織が増えてくるとタグ付けの稼働が煩雑になることと、請求書から按分を行う稼働が発生しますので、その担当者を決めていく必要があります。

AWSのネットワークに関するお悩みや課題などNTT東日本のクラウドエンジニアがお応えします。お気軽にご相談ください！

VPCの分割とアカウントの分割はどう考える？

上記の話は、ネットワークの分割だけではなく、アクセス権限の分割やアプリケーションの分割といった部分もセットで考える必要があります。一つの環境やワークロードを小さく保つことで、敏速性や他の環境やワークロードへの影響度を最小化することもできますので、ネットワークの分割が必要になった場合は、アカウントの分割もセットで検討しましょう。

とある企業では、1アカウントあたり1VPCをルール化して、厳格に分割を行っているところもあるようです。

実践のヒント

では、単一のVPCで運用している方が、VPCの分割を行っていくにはどうしたらよいか、簡単な実践のヒントをステップでご紹介したいと思います。一気に行うのではなく、段階的な移行をおススメします。

• ① 現状の棚卸しを行う
  • 現在のVPC構成や利用中のサービスを整理する
  • 特に複数の環境やシステムが混在していないかを確認する
• ② セキュリティリスク・運用課題の洗い出し
  • セキュリティ境界やアクセス管理（セキュリティグループ・NACLなど）を確認する
  • リソースがセキュリティ侵害を受けた場合の障害の影響範囲を検討する
  • リソース追加や設定変更時の手順や複雑さを確認する
• ③ 分割の優先度を検討する
  • 信頼境界（インターネット公開・内部利用の分離）による分割
  • 環境（検証・ステージング・本番）による分割
  • 責任分界点やコスト配分による分割
• ④ AWSのベストプラクティスを確認し、他のリスクがないかを確認する
  • AWS Well-Architected レビューなどを行う
• ⑤ 小さく始める
  • 検証環境と本番環境の分離など、影響度の少ないものから始める
  • 将来の拡張性に備えて、マルチアカウント戦略や効率的なVPC間接続を検討する

まとめ

VPCのネットワーク要件を適切に設定し、権限や境界の分割を行うためにVPCの分割の方針や実践のポイントを検討してみました。様々な角度から最適な形を生み出して、より効率的なAWSの効果的な利用方法を確立できればと思います。

NTT東日本では、AWSの構築保守だけではなく、オンプレミスのネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

AWSのネットワークに関するお悩みや課題などNTT東日本のクラウドエンジニアがお応えします。お気軽にご相談ください！