Google PCNE: ネットワーク自動化、ガバナンス、コスト オペレーション — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudにおけるネットワークの自動化、ガバナンス、コスト運用は、ネットワークを大規模に、いかに信頼性高く、セキュアに、そして経済的に運用するかを決定する、互いに不可分な規律です。効果的な実践は、よく構造化されたリソース階層と最小権限のIAMを、infrastructure as codeやイベント駆動のワークフローと融合させ、そのすべてが明確な予算、クォータ、監査可能性によって支えられています。最終的な状態は、予測可能なプロビジョニング、最小限の手動変更、防御可能なコンプライアンス証拠、そしてネットワークに関する透明なユニットエコノミクスです。

ガバナンスとアクセス制御

• リソース階層

  • 組織 → フォルダ → プロジェクトは、権限の継承とポリシーガードレールのためのコントロールプレーンです。本番環境と非本番環境を別々のフォルダに配置し、ポリシーとクォータを分離します。コスト配分とリソースのターゲティングのために、VPC、サブネット、ルーター、転送ルール、インスタンスにラベルを使用します。
  • Shared VPCは、ホストプロジェクトでルーティングと接続性を統合し、コンピューティングをサービスプロジェクトに委任します。ネットワークを明示的に公開し、意図しないルートの公開を減らすという原則に従うため、各サービスプロジェクトが必要とするサブネットのみを共有します。

• IAMと最小権限

  • ネットワーク管理とセキュリティ管理を分離します。Compute Network Adminはネットワーク構成要素に対する完全な制御とファイアウォールルールへの読み取り専用アクセスを許可し、Security AdminはファイアウォールルールとSSL証明書を管理します。この分離により、過剰な権限を持つオペレーターを避け、変更管理と整合性がとれます。
  • 対象を絞ったロールを付与します:
    • ファイアウォールルールを変更するには、Shared VPCでSecurity Adminを使用します。
    • VLANアタッチメントやその他の中核的なネットワークリソースを管理するには、Compute Network Adminが適切です。
    • 特定のリソースに対する自動化のためには、可能な場合はプロジェクト全体のロールではなくリソースレベルの権限を付与するか、必要な権限に限定したカスタムロールを作成します。
  • 永続的なキーよりもサービスアカウントの権限借用と短期的なトークンを優先します。可能であれば、組織のポリシーでサービスアカウントキーの作成を禁止します。オンプレミスやマルチクラウドの自動化では、Workload Identity Federationを使用してキーを完全に排除します。
  • データプレーンのタスクには最小権限のアクセスを適用します。例えば、Cloud Storageを読み取るジョブは、プロジェクトに対する広範な編集者権限ではなく、対象バケットに対するストレージオブジェクト閲覧者の権限のみを必要とします。

• 組織のポリシー

  • デフォルトでVMに「外部IPなし」を強制します。パブリックアドレスなしでGoogle APIにアクセスするには、Private Google AccessとCloud NATを使用します。
  • ピアリングや外部共有を承認されたパターンに制約します（例えば、VPCピアリングの構成を制限して、無秩序な増加を避けます）。
  • 認証情報の拡散を制限するために、サービスアカウントキーの作成とサービスアカウントの使用を制限します。
  • 障害モードとトレードオフ:
    • フォルダレベルで過度に広範な継承されたロールは、多くのプロジェクトに対して静かに書き込みアクセスを許可してしまう可能性があります。有効な権限の分析を用いてロールのバインディングを確認します。
    • Private Google AccessとNATの計画なしにVMが外部IPを持つことをブロックすると、Googleサービスを呼び出す際に障害が発生します。
    • 自動モードのサブネットを想定していたテンプレートをリファクタリングせずにVPCを自動モードからカスタムモードに変換すると、デプロイメントが失敗します。その後はカスタムサブネットを明示的に参照する必要があります。

自動化、IaC、イベント駆動の運用

• TerraformによるInfrastructure as Code

  • モジュール設計を使用します。プリミティブ（VPC、サブネット、ファイアウォール、Cloud Router、Cloud NAT、インターコネクトアタッチメント）ごとに1つのモジュールを作成し、それらを組み合わせて環境スタックを構成します。モジュールをバージョン管理し、利用側のスタックでバージョンを固定してロールアウトを制御します。
  • 同時変更を防ぐために、ロック付きでステートをリモートに保存します（例：バックエンドパターンを介したDynamoスタイルのロックを持つCloud Storage）。ステートを暗号化してバックアップし、機密情報として扱います。
  • ドリフト管理:
    • CIでプルリクエストとterraform planを通じて変更を強制し、意図した状態と実際の状態を明らかにします。定期的なドリフト検出（plan -detailed-exitcode）を実行し、ドリフトが検出されたらアラートを発します。
    • 本番環境でのアドホックなgcloudの変更は避けます。緊急の修正が必要な場合は、それを記録し、コードですぐに調整します。
  • べき等性とガードレール: 常にplan、review、applyを実行します。影響範囲を最小化するために、対象を絞ったapplyを使用します。重複するCIDRやオープンなファイアウォールなどのアンチパターンをブロックするために、変数の検証やpolicy-as-code（例：SentinelやOPA）を使用します。

• gcloud、API、ワークフロー

  • 低レイテンシの運用タスクにはgcloudとRESTを使用しますが、それらを再利用可能なスクリプトでラップします。再試行と指数バックオフで、結果整合性とAPIレート制限を処理します。
  • イベント駆動の運用:
    • Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functionsを使用して、クォータチェック、NAT使用率の監査、ファイアウォールログのサンプリングなどの定型タスクを自動化します。
    • Admin ActivityログとData AccessログをPub/Subにストリーミングして、ガードレールワークフローをトリガーします（例：不正なファイアウォールルールの変更を自動的に元に戻す）。
  • コードスニペットの例

    • ロールを付与する:

undefined

- NGFWへのデフォルトルートをバイパスしてGoogle APIへのルートを作成する:
  -

undefined

• 運用の落とし穴
  • 複数のパイプラインが共有リソース（例：共通VPC内のファイアウォール）を管理する際の競合状態は、フラッピングを引き起こします。所有権の規約とフォルダスコープのパイプラインを使用します。
  • 高い並列処理下でのAPIの不安定さはクォータエラーを引き起こします。リージョンやリソースタイプごとに操作をスロットリングし、バッチ処理します。

コスト、割り当て、キャパシティ管理

• 割り当てとAPI制限

  • プロジェクトごと、リージョンごとの割り当て（アドレス、転送ルール、ファイアウォールルール、インターコネクトアタッチメント、ルーター）を追跡します。割り当ての監視を自動化し、新しい環境が展開される前に増加をリクエストします。CIに事前の割り当てチェックを組み込み、早期に失敗するようにします。
  • 大規模なプロビジョニングには以下を使用します:
    • リージョナルシャーディング（リージョンごとのリソースを作成して、リージョンの割り当ての競合を回避します）。
    • 事前割り当て（ピークイベントに先立ってアドレスを予約し、ルーターを設定します）。
    • 段階的なロールアウト（バックエンドを作成、検証してからアタッチします）。

• 下り（Egress）とトポロジーの経済性

  • VPC内のリージョン間トラフィックには、リージョン間の下り（Egress）コストが発生します。レイテンシとコストが重要な場合は、通信するワークロードを同じリージョンに配置するか、データをリージョンごとに複製します。
  • us-east1とeurope-west1の近くにいるユーザーの場合、リージョナルサブネットを持つ単一のVPCでプライベートなRFC1918通信が可能になり、NATやピアリングのオーバーヘッドを最小限に抑えつつ、シンプルなポリシーとルーティングを実現できます。
  • プロジェクトや部門間で低オーバーヘッドの接続を実現するには、VPC Network Peeringを使用します。NATはなく、推移的なルーティングもありません。CIDRは重複しないようにしてください。通信してはならない部門を隔離するには、別々のVPCを使用します。
  • Cloud CDNは、HTTP(S)トラフィックの下り（Egress）を削減し、レイテンシを改善します。グローバルHTTP(S)ロードバランサーはCDNのコントロールプレーンです。ネットワークロードバランサーは、エッジ配信とキャッシング機能がないため、Webアプリケーションのグローバルなレイテンシを改善しません。
  • インターコネクトは賢く選択します。ホストプロジェクト内のVLANアタッチメントを持つDedicated Interconnectは、管理を一元化し、大規模で共有されるオンプレミス接続のプロジェクトごとのコストを削減します。Cloud Routerを備えたCloud VPNは、組織間の迅速で暗号化された接続に適しており、後でインターコネクトに移行することも可能です。

• コスト配分、予算、予測

  • すべてのネットワークリソースに、部門、環境、コストセンターのラベルでタグ付けします。請求データをBigQueryにエクスポートし、単価（例：サービスごとの下りGBあたりのドル）を導き出します。
  • プロジェクト、フォルダ、またはラベルの粒度で予算を作成します。アラートをPub/Subに送信し、ChatOpsやCloud Runのレスポンダーに連携させます。超過時のアクション（例：ロギングのサンプリング率の削減、重要でないテスト環境のスケールダウン）を自動化します。
  • 下り（Egress）の最適化:
    • 下りパスを制御し、請求を一元化するために、外部IPの代わりにPrivate Google AccessとCloud NATを優先します。
    • 強制トンネリングトポロジーの場合、サードパーティのファイアウォールを介したヘアピンニングを避けるために、Google APIへのカスタムルートをデフォルトのインターネットゲートウェイに追加するか、オンプレミス向けにPrivate Google Accessを設定します。
    • VPCフローログとロードバランサーのログを分析してキャパシティを予測し、季節性と相関させます。ピークに先立って、NATゲートウェイとインターコネクトのキャパシティを適正なサイズにします。

監査能力とオペレーショナルエクセレンス

• ロギングと証跡

  • Cloud Audit Logs:
    • 管理アクティビティログは、VPC、ルート、ファイアウォール、ルーター、ロードバランサーへのコントロールプレーンの変更をキャプチャし、常に有効になっています。中央で保持し、必要に応じてCMEKを使用してセキュリティプロジェクトにルーティングします。
    • ネットワーキングAPIのデータアクセスログは大量になる可能性があります。選択的に有効にし、サンプリングやシンクを適用します。
  • VPCフローログとファイアウォールルールロギングは、インシデント対応とコンプライアンスのためのデータプレーンの証跡を提供します。必要な保持期間保存し、調査のためにBigQueryでインデックスを作成します。
  • 変更記録: すべてのネットワーク変更は、不変のプランアーティファクトとチケット参照を持つIaCから発生するように要求します。例外的な手動変更については、gcloudコマンド、オペレーター、タイムスタンプ、および正当な理由を中央のレジストリに記録します。

• 安全な認証情報と自動化リスクの制御

  • 有効期間の長いサービスアカウントキーを排除します。IAM Conditionsを使用して、リソース、時間、またはIPによって自動化のスコープを限定します。リスクの高い権限（例：compute.firewalls.update, compute.routers.updateBgpPeer）は、承認ワークフローで保護します。
  • CI/CDには最小権限を適用し、環境ごとのサービスアカウントを使用し、トークンを頻繁にローテーションします。データ漏洩のリスクが存在する場所では、VPC Service Controlsを使用してサービス境界を保護します。

• ランブック、ライフサイクル、継続的改善

  • 日常的な運用のためのランブックを維持します：プロジェクトの共有VPCへのオンボーディング、VPCピアリングの作成、IKEv2でのCloud VPNの確立、プレビュー中のCloud Armorルールを適用（enforce）に昇格させるなど。
  • ライフサイクルポリシーを定義します：
    • サンドボックス→ステージング→本番への昇格は、同一のTerraformモジュールとリージョン固有の変数を使用して行います。
    • ピアリング、NAT、ルートを安全に削除するための廃止プレイブック。
  • 継続的改善：
    • インシデント後のレビューは、モジュールにフィードバックされるべきです（例：明示的な許可リストを持つデフォルトの拒否エグレスの追加、またはデフォルトでのNATロギング）。
    • 組織のポリシー、ラベル、予算を定期的にレビューし、意図した状態からの逸脱（drift）がないか確認します。

実践的な問題シナリオ

Contoso Retailは北米とヨーロッパで事業を展開しています。ユーザーとサービスは主にus-east1とeurope-west1で実行されています。セキュリティ要件として、サードパーティのNGFWへのデフォルトルート、VMへの外部IPの不許可、およびオンプレミス接続の集中管理が求められています。また、部門ごとの明確なコスト配分と自動化されたガードレールも必要です。

1. ガバナンスとトポロジーの確立

• 単一のVPCとus-east1およびeurope-west1に2つのリージョンサブネットを持つ共有VPCホストプロジェクトを作成します。理由：リージョンサブネットを持つ単一のVPCにより、シンプルなルーティングとポリシーでリージョン間の直接的なRFC1918通信が可能になり、プロジェクトごとのオーバーヘッドを最小限に抑えられます。
• 必要なサブネットのみを3つのサービスプロジェクト（マーケティング、サプライ、財務）に共有します。理由：サブネットレベルの共有は、中央集権的な制御を維持しつつ、ルートとファイアウォールの公開範囲を制限します。
• 分離が必要なレガシーの財務システム用に別のVPCを作成し、必要な場合にのみマーケティングとサプライをピアリングします。理由：VPCピアリングは、財務からの分離を維持しつつ、2つの部門に低レイテンシのプライベート接続を提供します。

2. パブリックIPなしでGoogleサービスへの安全なアクセスを構成

• すべての共有サブネットで限定公開のGoogleアクセス（Private Google Access）を有効にします。理由：外部IPを持たないインスタンスが、プライベートにGoogle APIに到達できます。
• デフォルトルートがNGFWに向かうため、199.36.153.8/30へのカスタム静的ルートをデフォルトのインターネットゲートウェイに追加します。理由：Google APIへの呼び出しがファイアウォールを経由してヘアピン状態になるのを防ぎ、レイテンシを削減し、単一のボトルネックを回避します。

3. オンプレミス接続の集中管理

• 共有VPCホストプロジェクトにDedicated InterconnectとVLANアタッチメントをデプロイし、リージョンごとにCloud Routerに接続します。理由：相互接続を集中管理することで、コストと運用の重複を削減します。Cloud Routerは、成長に対応するための動的ルーティングを提供します。
• ネットワークオペレーターにはCompute Network Adminを、セキュリティチームにはSecurity Adminを付与します。理由：最小権限と職務の分離を徹底します。これにより、ネットワーク管理者はセキュリティの承認なしにファイアウォールを変更できなくなります。

4. プロビジョニングとガードレールの自動化

• VPC、サブネット、ルーター、NAT、ピアリング、ファイアウォールポリシー用のTerraformモジュールを実装します。ステートはロック機能付きでリモートに保存し、CIでterraform planを含むプルリクエストレビューを強制します。理由：再現可能でバージョン管理された変更とドリフト制御により、障害を最小限に抑えます。
• 重複するCIDRや内部サブネットへの0.0.0.0/0イングレスをブロックするOPAポリシーを追加します。理由：レビュー時に一般的な設定ミスを防ぎます。
• Cloud Schedulerを使用して毎日の割り当てチェックをPub/Subにパブリッシュします。Cloud RunサービスがService Usage APIを呼び出して、アドレス、転送ルール、相互接続アタッチメントのヘッドルーム（余裕）を確認します。理由：割り当ての枯渇によるデプロイの失敗を回避します。

5. コストの最適化と正確な配分

• Terraformを介して、すべてのネットワークリソースにenv、dept、serviceのラベルを適用します。請求をBigQueryにエクスポートし、部門ごとに予算を定義して、アラートをPub/Subに送信します。理由：透明性のあるコスト配分と急増に対する早期警告により、プロアクティブな対応が可能になります。
• パブリックなWebプロパティの前面にグローバルHTTP(S)ロードバランサーを配置し、Cloud CDNを有効にします。理由：グローバルユーザーのレイテンシを改善し、エッジでキャッシュされたコンテンツを提供することでエグレスを削減します。

6. 監査能力とインシデント対応の強化

• 管理アクティビティログとファイアウォールルールロギングを、CMEKを備えた中央のロギングプロジェクトにルーティングします。理由：改ざん防止の変更記録とデータプレーンの証跡がコンプライアンス要件を満たします。
• 不正が疑われるクライアントに対しては、HTTP(S)ロードバランサーにCloud Armorルールをプレビューモードでデプロイし、適用する前にログを確認します。理由：緩和策を検証しつつ、ユーザーへの影響を最小限に抑えます。

7. 文書化とイテレーション

• プロジェクトを共有VPCにオンボーディングする、マーケティングとサプライ間でVPCピアリングを作成する、BGPを持たないパートナー向けにポリシーベースのCloud VPNを構築するためのランブックを公開します。理由：標準化された実行により、MTTRとばらつきを削減します。
• 各変更ウィンドウの後、メトリクス（デプロイ時間、エラー、エグレス$/GB、キャッシュヒット率）を収集し、改善点をモジュールとポリシーにフィードバックします。理由：継続的な改善により、信頼性とコスト管理が日々の運用に組み込まれます。

← ネットワーク オブザーバビリティ、信頼性、トラブルシューティング · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →