はじめに

AWSでマルチアカウント戦略を採用する際、避けては通れないのがネットワークアーキテクチャの選択かなと思います。特に、「ハブアンドスポーク」モデルと「共有VPC」モデルは、どっちを選べば良いのかと悩みどころです。

これらは、AWS Landing Zone Accelerator (LZA) でも中核的なネットワーキングパターンとして採用されており、それぞれの構成にはメリットとデメリットが存在します。
この記事では、AWS LZAのドキュメントを参考に、両者のアーキテクチャを徹底比較し、どのようなケースでどちらを選択するべきか、見ていこうと思います！

1.ハブアンドスポーク (Hub and Spoke) アーキテクチャ

構成の概要

このモデルでは、中央の「ハブ」となるネットワークVPCに、検査、ロギング、DNS、外部接続（Nat Gatewayやインターネットゲートウェイ）などの共有サービスを集約します。そして、個別のアプリケーションやワークロードが稼働するワークロードVPCを、AWS Transit Gateway (TGW) を介してハブVPCに接続します。

（参照：ハブアンドスポークモデルのネットワーク構成図)

主な特徴
  • 中央集権的な管理: トラフィックはすべてTGWを介してハブVPCを経由するため、一元的なトラフィック検査やガバナンスを強制できます。
  • 高い分離性: 各スポークVPCはデフォルトでは相互に通信できず、TGWのルーティング設定によって通信させるなら明示的に許可する必要があります。
メリット
  • 強力なガバナンスとセキュリティ: すべてのVPC間通信や外部への通信をハブVPCで一元的に監視・制御できるため、セキュリティポリシーの適用が容易です。
  • 高いネットワーク分離性: ワークロード間の分離が明確になり、意図しない通信を防ぐことで、障害の影響範囲を限定できます。
  • 柔軟なスケーラビリティ: 新しいワークロードVPCの追加や削除が容易で、アーキテクチャ全体への影響を最小限に抑えられます。
デメリット
  • コスト: Transit Gatewayの利用料金（アタッチメント数、データ処理量）が発生します。
  • CIDRの管理: 各VPCに個別のCIDRブロックを割り当てる必要があり、IPアドレス空間の計画がより重要になります。
  • 構成の複雑さ: TGWのルートテーブルなど、VPCや共有VPCと比較して管理すべきコンポーネントが増えます。

2. 共有VPC (Shared VPC) アーキテクチャ

構成の概要

共有VPCモデルでは、一つのVPCを複数のAWSアカウントで共有します。VPCの所有者（オーナーアカウント）がサブネットを作成し、それを他のアカウント（参加者アカウント）と共有します。参加者アカウントは、共有されたサブネット内にEC2インスタンスなどのリソースをデプロイできます。（AWS Resource Access Managerを使って共有します。）

(参照：共有VPCモデルのネットワーク構成図)

主な特徴
  • シンプルなリソース共有: NAT GatewayやVPCエンドポイントなどのリソースを、VPCを共有するすべてのアカウントで共同利用できます。
  • IPアドレス空間の効率化: 一つの大きなVPC内でIPアドレスを管理するため、CIDRの断片化が起こりにくいです。
メリット
  • コスト効率: NAT Gatewayなどの共有リソースを各アカウントで個別に持つ必要がなく、コストを削減できます。
  • IPアドレス管理の簡素化: 大規模なCIDRブロックを効率的に利用でき、IPアドレスの枯渇リスクを低減できます。
  • シンプルな構成: Transit Gatewayが不要なため、構成が比較的シンプルになります。
デメリット
  • 分離性の低下: 同じVPC内に複数のアカウントのリソースが混在するため、ネットワーク的な分離が弱くなります。セキュリティグループやNACLによる厳密なアクセス制御が不可欠です。
  • ガバナンスの複雑さ: 「誰がどのリソースにアクセスできるか」という権限管理が、ハブアンドスポークモデルに比べて複雑になりがちです。
  • オーナーアカウントへの依存: VPCの構成変更（サブネット追加など）はすべてオーナーアカウントで行う必要があり、運用上のボトルネックになる可能性があります。

まとめ：どちらのモデルを選択すべきか？

どちらのアーキテクチャが優れているか、という問いに唯一の正解はありません。要件に応じて適切なモデルを選択することが重要です！

ハブアンドスポークが適しているケース:
  • 高いセキュリティとガバナンスが求められる。
  • ワークロード間の通信を厳密に分離・制御したい。
  • 将来的に多数のVPCへスケールする可能性がある。
共有VPCが適しているケース:
  • コスト効率を最優先したい。
  • シンプルな構成で迅速に環境を構築したい。
  • アカウント間のリソースが相互に信頼できる、または通信要件が少ない。

最後に

AWS Landing Zone Acceleratorでは、デフォルトでハブアンドスポークアーキテクチャが採用されています。これは、エンタープライズ環境で求められる強力なガバナンスとスケーラビリティを重視した結果と言えるでしょう。
まずはハブアンドスポークを基本としつつ、小規模な環境やコスト要件が厳しい場合には共有VPCを検討するというアプローチが、失敗の少ないネットワーク設計への第一歩です!