VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャ

Last reviewed 2023-05-08 UTC

このガイドでは、Google Cloud を使用した Virtual Private Cloud(VPC)の設計に役立つベスト プラクティスと一般的なエンタープライズ アーキテクチャを紹介します。このガイドは、Google Cloud ネットワーキングのコンセプトに精通したクラウド ネットワーク アーキテクトとシステム アーキテクトを対象としています。

一般原則と最初のステップ

意思決定者、タイムライン、事前作業を特定する

VPC ネットワーク設計の第一歩として、関係者の要件を確実に満たすために必要な意思決定者、タイムライン、事前作業を特定します。

関係者には、アプリケーション所有者、セキュリティ アーキテクト、ソリューション アーキテクト、運用マネージャーなどがいます。プロジェクト、事業部門、組織全体の VPC ネットワークを計画するかどうかによって、関係者の顔触れが変わる可能性があります。

事前作業の一環として、VPC ネットワーク設計に関するコンセプトや用語をチームに周知してください。次のようなドキュメントが役に立ちます。

VPC ネットワーク設計を早期に検討する

Google Cloud での組織の設定を設計する初期段階で VPC ネットワーク設計を行います。ネットワークのセグメント化の方法やワークロードの場所などの基本事項を後で変更する必要がある場合、組織に影響を及ぼす可能性があります。

VPC ネットワーク構成が異なると、ルーティング、規模、セキュリティに大きく影響する可能性があります。慎重に計画し、具体的な考慮事項を十分に理解することが、ワークロードの増加に対応できる堅牢なアーキテクチャの土台の構築につながります。

簡潔さを心掛ける

管理が容易で信頼性が高く理解しやすいアーキテクチャを実現するには、VPC ネットワーク トポロジの設計を簡潔にすることが最善の方法です。

明確な命名規則を使用する

シンプルで直感的で一貫性のある命名規則を使用します。そうすれば、管理者とエンドユーザーは各リソースの用途と配置先を把握して、他のリソースと明確に区別できるようになります。

長い用語について、一般的に受け入れられている略語を使用すれば簡略化できます。使い慣れた用語を必要に応じて使用すれば、読みやすさが向上します。

命名規則の制定にあたっては、次に示す例を参考にしてください。

  • 会社名: Acme Company: acmeco
  • ビジネス ユニット: 人事部: hr
  • アプリケーション コード: 給与システム: comp
  • リージョン コード: northamerica-northeast1: na-ne1、europe-west1: eu-we1
  • 環境コード: devtestuatstageprod

この例では、人事部の給与システムの開発環境名は acmeco-hr-comp-eu-we1-dev です。

その他の一般的なネットワーキング リソースについては、次のようなパターンを検討してください。

  • VPC ネットワーク
    構文: {company name}-{description(App or BU)-label}-{environment-label}-{seq#}
    例: acmeco-hr-dev-vpc-1

  • サブネット
    構文: {company-name}-{description(App or BU)-label}-{region/zone-label}
    例: acmeco-hr-na-ne1-dev-subnet

  • ファイアウォール ルール
    構文: {company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
    例: acmeco-hr-internet-internal-tcp-80-allow-rule

  • IP ルート
    構文: {priority}-{VPC-label}-{tag}-{next hop}
    例: 1000-acmeco-hr-dev-vpc-1-int-gw

アドレスとサブネット

カスタムモードの VPC ネットワークを使用する

最初のプロジェクトはデフォルト ネットワークから始めます。これは、default という名前の自動モードの VPC ネットワークです。自動モードのネットワークは、予測可能な一連の RFC 1918 アドレス範囲を使用して、サブネットとそれに対応するサブネット ルートを自動的に作成します(それらのプライマリ IP 範囲は各 Google Cloud リージョンの /20 CIDR です)。default ネットワークには、いくつかの事前設定ファイアウォール ルールも自動的に含まれます。

自動モードのネットワークは初期の試験運用には役立ちますが、ほとんどの本番環境にはカスタムモードの VPC ネットワークが適しています。

以下の理由から、企業では最初からカスタムモードの VPC ネットワークを使用することをおすすめします。

  • カスタムモードの VPC ネットワークの方が既存の IP アドレス管理方式との統合に適しています。自動モードのネットワークはすべて同一の内部 IP 範囲のセットを使用するため、オンプレミスの企業ネットワークに接続すると、自動モードの IP 範囲は重複することがあります。
  • サブネットが同一のプライマリ IP 範囲を使用するため、VPC ネットワーク ピアリングを使用して 2 つの自動モードの VPC ネットワークを接続することはできません。
  • 自動モードのサブネットはすべてネットワークと同じ名前になります。カスタムモードのサブネット用に一意でわかりやすい名前を選択することで、VPC ネットワークの把握と保守が容易になります。
  • 新しい Google Cloud リージョンが導入されると、自動モード VPC ネットワークはそのリージョンで新しいサブネットを自動的に取得します。カスタムモードの VPC ネットワークは、指定した場合にのみ新しいサブネットを取得します。これは、主権と IP アドレス管理の両方の理由から重要となる場合があります。

リソースがない場合は、default ネットワークを削除できます。VPC ネットワークに依存するすべてのリソース(仮想マシン(VM)インスタンスを含む)を削除するまで、VPC ネットワークを削除することはできません。

自動モードとカスタムモードの VPC ネットワークの違いの詳細については、VPC ネットワークの概要をご覧ください。

アドレス範囲の大きい少数のサブネットにアプリケーションをグループ化する

エンタープライズ ネットワークは、従来よりさまざまな理由で多数の小さいアドレス範囲に分割されてきました。たとえば、アプリケーションを特定、分離するためや、ブロードキャスト ドメインを小さくするためなどです。

しかし Google では、運用するリージョン内で、同じ種類のアプリケーションをアドレス範囲が広く管理しやすい少数のサブネットにグループ化することをおすすめします。

サブネット マスクを使用する他のネットワーキング環境と異なり、Google Cloud はソフトウェア定義ネットワーキング(SDN)方式を使用して、グローバル VPC ネットワーク内のすべての VM 間でフルメッシュのネットワーク到達性を提供します。サブネットの数はルーティングの動作に影響しません。

サービス アカウントかネットワーク タグを使用すれば、特定のルーティング ポリシーやファイアウォール ルールを適用できます。Google Cloud の ID は、サブネット IP アドレスだけに基づくものではありません。

VPC 機能の中には、Cloud NAT限定公開の Google アクセスVPC フローログエイリアス IP 範囲などのように、サブネットごとに構成されるものもあります。これらの機能のきめ細かい制御が必要な場合は、追加のサブネットを使用してください。

単一 VPC ネットワークと共有 VPC

共通の要件を持つリソースは単一 VPC ネットワークから始める

多くの単純なユースケースでは、単一 VPC ネットワークによって必要な機能を提供できます。また、複雑な代替手段よりも作成、保守、把握が容易です。最初は、共通の要件と特性を持つリソースを単一の VPC ネットワークにグループ化することで、起こりうる問題の防衛線として VPC ネットワーク境界を設定できます。

この構成の例については、単一プロジェクト、単一 VPC ネットワークのリファレンス アーキテクチャをご覧ください。

スケーリング、ネットワーク セキュリティ、財政的な考慮事項、運用要件、Identity and Access Management(IAM)などの要因により、追加の VPC ネットワークの作成が必要になることもあります。

複数の作業グループの管理には共有 VPC を使用する

組織内に複数のチームがある場合、共有 VPC は、単一 VPC ネットワークのシンプルなアーキテクチャを複数の作業グループに拡張するための効果的なツールになります。最も単純なアプローチは、単一の共有 VPC ネットワークに単一の共有 VPC ホスト プロジェクトをデプロイしてから、チーム サービス プロジェクトをホスト プロジェクト ネットワークに接続することです。

この構成では、すべてのネットワーキング リソースに対するネットワーク ポリシーと制御が集中化され、管理が容易になります。サービス プロジェクト部門は、ネットワーク以外のリソースを構成および管理する一方で、組織内のさまざまなチームの責任を明確に分離できます。

プロジェクト内のリソースは、内部 IP アドレスにより、プロジェクト境界を越えて安全かつ効率的にやり取りできます。サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースをホスト プロジェクトから集中管理できるため、プロジェクト間で一貫したネットワーク ポリシーを適用できます。

この構成の例については、単一ホスト プロジェクト、複数サービス プロジェクト、単一共有 VPC のリファレンス アーキテクチャをご覧ください。

サブネット レベルでネットワーク ユーザーロールを付与する

集中化された共有 VPC の管理者は、サブネット レベル(きめ細かいサービス プロジェクト承認用)またはホスト プロジェクト レベル(すべてのサブネット用)で、IAM メンバーにネットワーク ユーザー(networkUser)ロールを付与できます。

最小特権の原則に従って、サブネット レベルでネットワーク ユーザーロールを関連ユーザー、サービス アカウント、またはグループに付与することをおすすめします。

サブネットはリージョン単位であるため、このきめ細かい制御を使用して、各サービス プロジェクトがリソースのデプロイに使用できるリージョンを指定できます。

共有 VPC アーキテクチャでは、組織内で複数の共有 VPC ホスト プロジェクトを柔軟にデプロイできます。各共有 VPC ホスト プロジェクトは、単一または複数の共有 VPC ネットワークに対応できます。この構成では、異なる環境で異なるポリシー項目を容易に適用できます。

詳細については、ネットワーキングにおける IAM 役割をご覧ください。