Google Cloud Professional Cloud Network Engineer
最終確認：2026年5月
PCNE 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
大規模またはハイブリッドクラウドのデプロイメント向けにIPアドレス指定を計画する。
カスタムモードVPCを使用する。オンプレミス（多くの場合 10.0.0.0/8）との競合を避けるため、重複しないRFC 1918 CIDRブロック（例：172.16.0.0/12）を割り当てる。GKE Podのセカンダリレンジには100.64.0.0/10を使用する。
理由: 将来のハイブリッド接続におけるオンプレミスとのIP競合を回避し、アドレス空間を完全に制御できる。これは、規模の拡大や高コストな再IPアドレス設定を避けるために不可欠である。
ネットワーク管理と共有サービスを集中化しつつ、複数のテナント/環境（開発、本番）にネットワーク分離を提供する。
Shared VPCを使用する。ホストプロジェクトにはVPC、サブネット、ファイアウォール、インターコネクトが含まれる。テナント/環境は、ホストプロジェクトにアタッチされたサービスプロジェクトである。
理由: ホストプロジェクトでネットワーク管理を集中化し、リソース管理はサービスプロジェクトに委任する。組織内の多数のプロジェクトに対してVPC Peeringよりもスケーラブルで統制しやすい。
VPCネイティブネットワーキングを使用する大規模GKEクラスタ向けにIPアドレス指定を計画する。
カスタムモードVPCで、ノード用のプライマリレンジ、Pod用のセカンダリレンジ、サービス用のもう一つのレンジという3つのCIDRレンジを計画する。拡張のためには、不連続なマルチPod CIDRを使用する。
理由: VPCネイティブネットワーキングでは、Podとサービスに専用の重複しないセカンダリレンジが必要となる。適切なサイジングは、大規模クラスタで一般的かつ破壊的な問題であるIP枯渇を防ぐ。
外部IPを持たないVMがGoogle Cloud API（例：Cloud Storage, BigQuery）にアクセスする必要がある。
サブネットでPrivate Google Accessを有効にする。オプションで、VPC-SCを強制するために、DNSを設定して`*.googleapis.com`を`restricted.googleapis.com`（199.36.153.4/30）に解決させる。
理由: VMにパブリックIPを必要とせずに、Googleの内部ネットワーク経由でGoogle APIへのトラフィックをルーティングする。`restricted.googleapis.com`を使用することで、データ流出保護の層が追加される。
IPレンジが重複するVPCを持つコンシューマー（パートナー、他の事業部門）のために、自身のVPC内のサービスへのプライベートアクセスを提供する。
Private Service Connect (PSC) サービスアタッチメントを使用して、サービス（Internal Load Balancer経由）を公開する。コンシューマーは、自身のレンジのIPを持つPSCエンドポイントを自身のVPC内に作成する。
理由: PSCはプロデューサーとコンシューマーのネットワークを分離し、NATを使用して重複するIPを処理する。VPC Peeringのような完全なネットワーク接続ではなく、セキュアなサービスレベルのアクセスを提供する。
集中管理と接続性のために、多数（50以上）のVPCおよび/またはオンプレミスサイトをハブアンドスポークトポロジで接続する。
Network Connectivity Centerを使用する。ハブを設定し、VPCをVPCスポークとして、オンプレミス接続（VPN/Interconnect）をハイブリッドスポークとしてアタッチする。
理由: NCCは、大規模なハブアンドスポークトポロジ向けのGoogleのマネージドソリューションであり、ルート管理を簡素化し、VPC Peeringの25ピア制限を超えてスケールできる。
セキュリティ強化のため、ノードとコントロールプレーンがパブリックIPアドレスを持たないGKEクラスタをデプロイする。
Private GKEクラスタを作成する。これにより、ノードには内部IPのみが割り当てられ、コントロールプレーンにはプライベートエンドポイントが作成される。認可済みネットワークを設定して、コントロールプレーンへのアクセスを制限する。
理由: プライベートクラスタは、コントロールプレーンとノードをパブリックインターネットから削除し、攻撃対象領域を大幅に削減する。すべての管理トラフィックとワークロードトラフィックはプライベートネットワーク上に留まる。
サーバーレスワークロード（Cloud Run, Functions）がVPC内のリソース（例：Cloud SQL, Memorystore）にアクセスする必要がある。
ターゲットVPC内にServerless VPC Accessコネクタを作成する。このコネクタをエグレス（送信）トラフィックに使用するようにサーバーレスサービスを設定する。
理由: コネクタはプロキシとして機能し、サーバーレスサービス（Google管理環境で実行される）が内部IPを使用して顧客管理のVPCにトラフィックを送信することを可能にする。
アプリケーション（例：HPC、金融取引）が、VMグループ間で絶対的に最も低いネットワークレイテンシを必要とする。
コンパクト配置ポリシーを作成し、VMに適用する。Tier_1ネットワーキングを持つマシンタイプを使用する。
理由: VMを同じネットワークラック内に併置することで、ネットワークホップと物理距離が最小限に抑えられ、標準的なVM配置と比較してレイテンシが大幅に削減される。
マイクロサービス向けにゼロトラストセキュリティモデルを実装し、強力なID、暗号化された通信（mTLS）、およびきめ細かい承認を要求する。
Anthos Service Meshをデプロイする。すべてのサービス間通信で自動mTLSを有効にする。`AuthorizationPolicy`リソースを使用して許可される通信を定義する。
理由: サービスメッシュは、セキュリティを基盤となるネットワークから分離し、ワークロードID、透過的なmTLS、およびL7承認を提供する。これらはゼロトラストアーキテクチャの核となる要素である。
パブリックIPを持たないワークロード（VM、GKE Pod）が、許可リストを使用する外部APIへのアウトバウンド接続のために、安定した予測可能な送信元IPを必要とする。
Cloud NATをデプロイする。「手動NAT IP割り当て」オプションを使用し、予約済みの静的外部IPアドレスをNATゲートウェイに割り当てる。
理由: 手動割り当てによるCloud NATは、静的エグレスIPの共有プールを提供する。これにより、ワークロードとIPが分離され、外部の許可リストを更新することなくスケールできる。
VPC Peeringは確立されているが、ピアリングされたVPC間でVMが通信できない。
*両方の* VPCのファイアウォールルールが、相手のVPCのIPレンジからのイングレストラフィックを許可していることを確認する。ピアリング接続はルーティングを確立するだけであり、暗黙的にファイアウォールの許可を作成するわけではない。
理由: ピアリングがファイアウォールポートを開放すると仮定するのは一般的な間違いである。明示的な許可ルールが作成されるまで、暗黙的なイングレスのすべて拒否ルールがトラフィックをブロックする。
Shared VPCで、チーム/サービスプロジェクトに、VPC全体ではなく特定のサブネットのみを使用する権限を付与する。
ホストプロジェクトで、サブネットレベルのリソースに対し、サービスプロジェクトのID（例：サービスアカウント、グループ）に`compute.networkUser` IAMロールを付与する。
理由: IAMロールは特定のりソースにスコープ設定できる。`compute.networkUser`をサブネットレベルで適用することで、最小権限を強制し、そのサブネットのみの使用を許可する。
Compute Engine上で、多層アプリケーション（例：Web、アプリケーション、DB）向けにマイクロセグメンテーションを実装する。
VMにそのティアに基づいてネットワークタグ（例：`web-server`）を割り当てる。これらのタグを送信元およびターゲット指定子として使用するファイアウォールルールを作成する。
理由: タグは、IPベースのルールに代わる柔軟でスケーラブルな方法を提供する。ファイアウォールポリシーは、ティア内のVMの数やIPアドレスとは独立している。
コンプライアンス/監査のためにトラフィックメタデータをキャプチャしつつ、ログボリュームとストレージコストを最小限に抑える。
より長い集計間隔（例：10分）、削減されたサンプリングレート（例：0.5）、および不要なフィールドを除外するためのメタデータフィルタリングを使用して、VPCフローログを有効にする。
理由: デフォルト設定では大量のデータが生成される。これらのパラメータを調整することでコストが大幅に削減され、ほとんどの監査ユースケースで十分な可視性が維持される。
低レイテンシでグローバルなアプリケーションを提供し、自動フェイルオーバーでユーザーを最も近い正常なバックエンドにルーティングする。
Global External Application Load Balancer（HTTP以外の場合はTCP/SSL Proxy LB）を使用する。複数のリージョンにバックエンドサービス/NEGを設定する。Premium Tierネットワーキングを使用する。
理由: ロードバランサーのAnycast IPは、ユーザーを最も近いGoogleのエッジPoPに誘導する。その後、トラフィックはGoogleのプライベートバックボーンを経由して、最適なパフォーマンスのために最も近い正常なバックエンドに到達する。
URLパスまたはホスト名に基づいて内部トラフィックをルーティングし、SSL終端を行い、VPC内またはオンプレミスからのみアクセス可能にする。
Regional Internal Application Load Balancerを使用する。ホスト/パスルールに基づいてトラフィックを指示するようにURLマップを設定する。プロキシ専用サブネットが必要となる。
理由: これはGoogleのマネージドL7内部ロードバランサーである。L4 Internal Passthrough Network LBでは利用できない高度なルーティング機能を提供する。
Cloud CDNを使用して、プライベートまたはユーザー固有のコンテンツを公開せずにキャッシュして配信する。
プライベートバックエンド（例：GCSバケット）でCloud CDNを有効にする。アプリケーションでCloud CDN Signed URLまたはSigned Cookieを生成し、ユーザーに一時的な認証済みアクセスを許可する。
理由: Signed URL/Cookieは、Cloud CDNがキャッシュされたオブジェクトを配信する前に検証するセキュアなトークンを提供し、厳密なアクセス制御を維持しながらエッジキャッシングを活用する。
オンプレミスネットワークとGCP VPC間の双方向DNS解決を有効にする。
1) オンプレミスがGCPを解決する場合：Cloud DNSインバウンドサーバーポリシーを作成する。オンプレミスDNSをインバウンドフォワーダーIPに転送するように設定する。 2) GCPがオンプレミスを解決する場合：オンプレミスDNSサーバーを指すCloud DNS転送ゾーンを作成する。
理由: この標準的な2部構成の構成は、ハイブリッド環境向けにシームレスでプライベートな名前解決を提供し、アプリケーションの相互運用性にとって不可欠なコンポーネントである。
不要なURLバリエーション（例：トラッキングパラメータ）により、Cloud CDNのキャッシュヒット率が低い。
バックエンドサービスにカスタムキャッシュキーポリシーを設定する。不要なクエリパラメータ、Cookie、ヘッダーをキャッシュキーから除外する。
理由: デフォルトでは、完全なURLがキャッシュキーとなる。関連性のないパラメータを除外してキーを正規化することで、キャッシュの断片化を防ぎ、ヒット率を劇的に向上させる。
内部クライアントにはDNS名を内部IPに、外部クライアントにはパブリックIPに解決する。
ドメイン用に内部IPレコードを持つCloud DNSプライベートゾーン（VPCから見える）を作成する。一致するパブリックIPレコードを持つCloud DNSパブリックゾーンを作成する。
理由: Cloud DNSは、認可されたVPC内のクライアントにはプライベートゾーンからの応答を、それ以外のすべてにはパブリックゾーンからの応答を自動的に提供する。
あるリージョン内の内部アプリケーションが、他のリージョン内のクライアント（VM、オンプレミス）からアクセス可能である必要がある。
Internal TCP/UDP Load BalancerまたはInternal Application Load Balancerの転送ルールで「Global Access」オプションを有効にする。
理由: デフォルトでは、内部LBはリージョン単位である。グローバルアクセスを有効にすることで、VPCネットワーク内のどのリージョンからもアクセス可能になり、多リージョン内部サービスアーキテクチャが簡素化される。
オンプレミスとGCP間で、高可用性（99.99% SLA）、高帯域幅（10G以上）の接続を確立する。
少なくとも4つのDedicated Interconnect接続をプロビジョニングする。1つのメトロに2つ、別のメトロに2つ配置し、各メトロペアが異なるエッジアベイラビリティドメインにあるようにする。BGPを設定する。
理由: 99.99%のSLAには、別々のメトロポリタンエリアおよび障害ドメイン（エッジアベイラビリティドメイン）にわたる冗長性が必要である。
中程度の帯域幅（< 6 Gbps）で、暗号化され、信頼性があり（99.9%または99.99% SLA）、迅速にデプロイ可能なハイブリッド接続が必要である。
動的ルーティングにはBGPを使用したHA VPNを使用する。99.99% SLAには2つのHA VPNゲートウェイを使用する。99.9% SLAには2つのトンネルを持つ単一のゲートウェイを使用する。
理由: HA VPNはInterconnectよりもセットアップが迅速で、強力なSLAを提供し、多くのユースケースに十分な帯域幅を提供する。これにより、物理接続以外のデフォルトの選択肢となる。
コンプライアンスのために、DedicatedまたはPartner Interconnectリンクを通過するすべてのトラフィックを暗号化する。
Interconnect経由でHA VPNを設定する。InterconnectのVLANアタッチメントを基盤トランスポートとして使用するHA VPNトンネルを作成する。
理由: このパターンは、Interconnectの高速帯域幅と低レイテンシをHA VPNのIPsec暗号化と組み合わせ、両者の利点を提供する。
GCPと他の主要なクラウドプロバイダー（AWS, Azure, OCI）との間に、専用のプライベートな高帯域幅接続を確立する。
Cross-Cloud Interconnectを使用する。Googleのネットワークと他のクラウドプロバイダーのネットワーク間に専用の物理接続をプロビジョニングする。Cloud RouterでBGPを設定する。
理由: クラウド間で、パブリックインターネットとVPNの変動するパフォーマンスを回避し、SLAに裏打ちされた直接的で低レイテンシのパスを提供する。
Interconnect経由で1つのGCPリージョンに接続されたオンプレミスネットワークが、他のすべてのGCPリージョンのリソースにアクセスする必要がある。
VPCで「グローバル」動的ルーティングモードを有効にする。これにより、Cloud Routerはローカルリージョンのサブネットだけでなく、VPC内のすべてのサブネットのルートをアドバタイズするようになる。
理由: グローバルルーティングにより、単一のハイブリッド接続ポイントがGoogleのグローバルネットワーク全体へのオンランプとして機能し、複数リージョンへのアクセスが簡素化される。
BGPを使用して、冗長なハイブリッド接続（VPN/Interconnect）上のトラフィックパス選択に影響を与える。
GCPからオンプレミスへのトラフィックに影響を与えるには、オンプレミスでより具体的なルートをアドバタイズするか、優先パスに短いAS_PATHを使用する。オンプレミスからGCPへのトラフィックに影響を与えるには、Cloud Routerから優先パスに低いMED値でアドバタイズする。
理由: BGPのパス選択は明確なアルゴリズムに従う。アウトバウンドトラフィックには最長プレフィックスマッチが重要であり、MEDはインバウンドトラフィックの決定に影響を与える。
プライマリDedicated InterconnectとバックアップHA VPN間で、アクティブ/パッシブフェイルオーバーを設定する。
両方でBGPを使用する。Cloud Router上で、Interconnect経由のルートは低い基本優先度（例：100）で、VPN経由のルートは高い基本優先度（例：200）でアドバタイズする。
理由: GCPはより低い優先度値（より高い優先順位）を持つBGPルートを優先する。トラフィックはプライマリInterconnectを使用する。障害発生時には、そのルートが取り消され、バックアップVPNルートがアクティブになる。
機密性の高いGoogle Cloudサービス（例：BigQuery, GCS）からのデータ流出を防止し、認可されたネットワークからのみアクセスを保証する。
VPC Service Controlsを実装する。機密データを持つプロジェクトの周囲にサービス境界を作成する。認可された送信元（IPレンジ、デバイスの状態、ID）を定義するためにアクセスレベルを設定する。
理由: VPC-SCは、Google管理サービス周辺に仮想ネットワーク境界を作成し、有効な認証情報があっても境界外からのアクセスをブロックする。これは重要なデータガバナンス制御である。
組織全体で一貫性のある、上書き不可能なベースラインファイアウォールルールを強制しつつ、プロジェクトレベルのカスタマイズを許可する。
組織またはフォルダレベルで階層型ファイアウォールポリシーを実装する。ここに重要なルールを配置する。`goto_next`アクションを使用して、下位レベルのポリシーへの評価を委任する。
理由: 階層型ポリシーはVPCレベルのルールよりも先に評価され、プロジェクトオーナーによって変更できないため、集中管理が保証される。`goto_next`は柔軟性を提供する。
WebアプリケーションをOWASP Top 10の脆弱性から保護し、クライアントIPごとのレート制限を適用する。
Cloud ArmorセキュリティポリシーをGlobal External Application LBにアタッチする。事前に構成されたWAFルール（例：`sqli-v3.3-stable`）を適用し、レートベースのルールを追加する。
理由: Cloud Armorはエッジセキュリティを提供する。事前構成されたWAFルールはマネージド保護を提供し、レートベースのルールはDoS攻撃やブルートフォース攻撃を軽減する。
ラベルに基づいて、GKEクラスタ内できめ細かなPodレベルのネットワークセキュリティを実装する。
GKEクラスタでネットワークポリシーの適用を有効にする。ラベルセレクタを使用してPodのイングレス/エグレスルールを定義するKubernetes `NetworkPolicy`リソースを作成する。
理由: Kubernetes NetworkPolicyは、Podレベルでマイクロセグメンテーションを実装するネイティブな方法であり、ノードレベルで動作するVPCファイアウォールルールよりもきめ細かい粒度を提供する。
集中管理されたサードパーティのファイアウォール/NVAを使用して、すべてのVPC間またはVPCからインターネットへのトラフィックを検査する。
ハブアンドスポークトポロジを作成する。ハブVPCにNVAをデプロイする。スポークにカスタムルートを設定し、トラフィックをハブ内のInternal Load Balancerにネクストホップとして指示する。
理由: このパターンは、トラフィックを中央検査ポイントに強制的に通過させる。ILBはNVAに安定した高可用性のネクストホップIPを提供する。
VPNを使用せずに、ユーザーが内部WebアプリケーションまたはVMにセキュアなIDベースのゼロトラストアクセスを提供する。
Webアプリケーションの場合は、External HTTPS LBのバックエンドサービスでIAPを有効にする。SSH/RDPの場合は、TCP転送にIAPを使用する。ユーザーに適切なIAP IAMロールを付与する。
理由: IAPは、アクセス制御をネットワーク境界からユーザーのIDに移し、すべてのリクエストを認証および承認する。これはGoogleのBeyondCorpゼロトラストモデルの核となるコンポーネントである。
マルウェア検出とTLS検査を含む、VPC間またはVPCからインターネットへのトラフィックに対する脅威防止（IDS/IPS）を実装する。
Cloud NGFWを使用する。ファイアウォールポリシーをVPCに関連付け、脅威防止のためのセキュリティプロファイルを持つルールを作成し、必要に応じてTLS検査を有効にする。
理由: Cloud NGFWはGoogleの分散型マネージドファイアウォールサービスであり、Palo Alto Networksの高度なL7検査機能をVPCに直接統合して提供する。
セキュリティとコンプライアンスのために、VPCからのすべてのインターネット向けエグレス（送信）トラフィックを一元的に検査、ログ記録、制御する。
Secure Web Proxyをデプロイする。URLフィルタリングとTLS検査のためのセキュリティポリシーを設定する。カスタムルートを使用して、サブネットからのトラフィックをプロキシにルーティングする。
理由: これはGoogleのセキュアなエグレス向けマネージドソリューションであり、自己管理型プロキシフリートを必要とせずにL7の可視性と制御を提供する。
GCP内の2つのエンドポイント間（例：VM-to-VM、VM-to-Cloud SQL）の接続障害を迅速に診断する。
Network Intelligence CenterのConnectivity Testsを使用する。送信元と宛先を指定すると、構成されたパス全体を分析して問題を特定する。
理由: この非侵襲的ツールは、パスの決定的な分析を提供し、手動検査よりもはるかに迅速に正確な障害点（ファイアウォール、ルートなど）を特定する。
ハイブリッド接続を介したBGPセッションが断続的にリセットされる（「フラッピング」）。
BGPキープアライブ/ホールドタイマーの不一致を確認する。負荷時にタイマーが期限切れになる場合は、それらを増やす（例：キープアライブ60秒、ホールド180秒）。また、MTU設定を確認し、BFDを有効にする。
理由: タイマーの不一致や過度に積極的な設定は、BGPフラップの一般的な原因である。一時的なネットワーク輻輳がキープアライブパケットをホールド時間以上に遅延させる可能性があるため。
GCPリージョン間のトラフィックでレイテンシが増加したという報告を調査する。
Network Intelligence CenterのPerformance Dashboardを使用して、すべてのGCPゾーンペア間の履歴およびリアルタイムのレイテンシとパケットロス指標を表示する。
理由: このツールは、Googleのバックボーンネットワークパフォーマンスを直接可視化し、アプリケーションの問題とネットワークインフラストラクチャの問題を区別するのに役立つ。
Cloud NATを使用するVMが断続的なアウトバウンド接続障害を経験し、NATログに`OUT_OF_RESOURCES`ドロップが表示される。
これはNATポート枯渇の可能性が高い。割り当てられたNAT IPの数を増やすか、「VMインスタンスあたりの最小ポート数」を増やすか、および/または動的ポート割り当てを有効にする。
理由: 多数のVMからの高接続レートは、NAT IPごとの割り当てられた送信元ポートプールを枯渇させる可能性がある。より多くのリソースを割り当てることが必要な解決策である。
