プレイブック

請求とポリシー適用を一元化しつつ、ビジネスユニットには管理上の自律性を与える。

→各ビジネスユニット向けにフォルダーを持つOrganizationノードを使用する。フォルダー内にプロジェクトを作成し、全てのプロジェクトを単一の請求アカウントにリンクする。

理由: フォルダーは管理上の境界とポリシーの継承を提供する。単一の請求アカウントはコスト管理を一元化し、組織全体の割引を可能にする。

リファレンス↗

プロジェクトの支出が予算の特定の割合に達した際に財務部門に通知する。

→Cloud Billingでプロジェクトの予算を作成する。複数のアラートしきい値ルール（例：50%、90%、100%）を設定し、Pub/Subトピックまたはメールに通知を送信する。

理由: 予算はアラートのためのものであり、支出を停止するためのものではない。支出を自動的に上限設定するには、Pub/Sub通知がCloud Functionをトリガーして請求を無効にするか、リソースをシャットダウンする必要がある。

リファレンス↗

詳細なリソースレベルのクラウドコストを分析し、コストセンター別に支出を追跡する。

→BigQueryデータセットへの詳細な請求エクスポートを有効にする。リソースにラベル（例：`cost-center: "finance"`）を適用する。BigQueryテーブルをクエリし、ラベルでグループ化して分析する。

理由: BigQueryへの請求エクスポートは、ラベルを含む最も詳細なコストデータを提供し、カスタムのチャージバックおよびショーバックモデルに不可欠である。

リファレンス↗

組織内のすべてのプロジェクトでセキュリティと構成の標準を強制する（例：リソースの場所を制限する、一様なバケットアクセスを要求する、パブリックIPを無効にする）。

→OrganizationまたはFolderレベルで組織ポリシーの制約を適用する。例：データレジデンシーには`gcp.resourceLocations`、GCSセキュリティには`storage.uniformBucketLevelAccess`、パブリックIPを防ぐには`compute.vmExternalIpAccess`を使用する。

理由: 組織ポリシーは継承され、予防的な制御を提供し、準拠しないアクションが発生する前にブロックする。これは反応的な監査よりも効果的である。

リファレンス↗

重要な本番プロジェクトの偶発的な削除を防ぐ。

→`gcloud alpha resource-manager liens create`を使用してプロジェクトにLienを配置する。

理由: Lienはプロジェクトの削除をブロックするプロパティである。プロジェクトを削除する前に、`resourcemanager.lienModifier`ロールを持つユーザーによって明示的に削除される必要がある。

gcloud CLIを使用する際に、異なるプロジェクトとユーザーアカウント間を効率的に切り替える。

→`gcloud config configurations create`を使用して、各プロジェクト/アカウントの名前付き構成を作成する。`gcloud config configurations activate [CONFIG_NAME]`を使用してそれらを切り替える。

理由: 構成にはプロジェクト、アカウント、リージョン、ゾーンなどの設定が保存され、すべてのコマンドでそれらを指定する必要がなくなる。

運用オーバーヘッドとコストを最小限に抑えつつ、可変トラフィックを持つステートレスなコンテナ化されたHTTPマイクロサービスを実行する。

→コンテナをCloud Runにデプロイする。

理由: Cloud Runはフルマネージドであり、ゼロにスケール（アイドル期間のコストを排除）し、受信リクエストに基づいて自動的にスケールする。ステートレスなウェブサービスに最適である。

リファレンス↗

可能な限り低いコストで、フォールトトレラントで時間的に柔軟なバッチ処理ジョブを実行する。

→マネージドインスタンスグループでSpot VM（旧Preemptible VM）を使用する。

理由: Spot VMはオンデマンド料金と比較して最大91%の割引を提供する。多くのバッチ処理ジョブのように、停止および再開が可能なワークロードに適している。

高可用性（例：99.9%）とオートスケーリングを必要とするウェブアプリケーションをデプロイする。

→オートスケーリングポリシーを持つリージョンマネージドインスタンスグループ（MIG）を、グローバル外部HTTP(S)ロードバランサーの背後にデプロイして使用する。

理由: リージョンMIGは、フォールトトレランスのために複数のゾーンにインスタンスを自動的に分散する。オートスケーリングは需要に合わせて容量を調整し、ロードバランサーは単一のエントリポイントを提供する。

30日間は頻繁にアクセスされ、その後1年間はめったにアクセスされず、最終的にアーカイブされるデータを保存する。

→Cloud Storage Standardクラスバケットに保存する。30日後にオブジェクトをNearline/Coldlineに、365日後にArchiveに移行するライフサイクルルールを作成する。

理由: ライフサイクルルールは、手動介入なしに、経過時間やその他の条件に基づいてデータを安価なストレージクラスに移動することで、コスト最適化を自動化する。

リファレンス↗

グローバルに分散されたアプリケーションが、水平スケーラビリティと強い整合性を持つリレーショナルデータベースを必要とする。

→Cloud Spannerを使用する。

理由: Cloud Spannerは、グローバルに分散され、強力な整合性を持つSQLサポート付きのリレーショナルデータベースを提供する唯一のサービスである。Cloud SQLはリージョンサービスである。

アプリケーションが、99.95%の可用性SLAと自動フェイルオーバーを備えたマネージドPostgreSQLまたはMySQLデータベースを必要とする。

→高可用性（HA）構成を有効にしたCloud SQLを使用する。

理由: HA構成は、プライマリインスタンスと異なるゾーンのスタンバイインスタンスを作成する。データは同期的にレプリケートされ、フェイルオーバーは自動で行われる。

データベース層がインターネットからアクセスできないように、3層アプリケーション（ウェブ、アプリケーション、データベース）用のVPCを設計する。

→各層に個別のサブネットを持つカスタムモードVPCを作成する。データベースインスタンスは、専用サブネット内でプライベートIPアドレスのみでプロビジョニングする。

理由: 層を個別のサブネットに分離することで、詳細なファイアウォールルールが可能になる。データベースインスタンスに外部IPを含めないことが、インターネットアクセスを防ぐ最も直接的な方法である。

安定したネットワーク識別子と永続ストレージを必要とするステートフルなアプリケーション（例：データベース）をGKEにデプロイする。

→PersistentVolumeClaimテンプレートを持つStatefulSetを使用する。

理由: StatefulSetはステートフルなワークロード向けに設計されており、安定したホスト名（例：`pod-0`、`pod-1`）を提供し、各レプリカに固有のPersistentVolumeを自動的にプロビジョニングする。

レイテンシに敏感なCloud Runサービスは、トラフィックスパイク時のコールドスタートを回避する必要がある。

→`--min-instances`フラグを1以上に設定してサービスをデプロイする。

理由: 最小インスタンスを設定することで、指定された数のコンテナが「ウォーム」状態に保たれ、リクエストを処理する準備が整うため、新しいコンテナの起動に伴うレイテンシが排除される。

Cloud Storageバケットに新しいファイルがアップロードされるたびに、サーバーレス関数を自動的に実行する。

→指定されたバケットの`google.cloud.storage.object.v1.finalized`イベントに対するEventarcトリガーを持つCloud Function（第2世代）をデプロイする。

理由: Eventarcは統一されたイベント駆動型アーキテクチャを提供する。GCSトリガーは、ポーリングなしでストレージイベントをサーバーレスコンピューティングに接続する標準的なマネージドな方法である。

本番トラフィックをすぐに送信することなく、テスト用にApp Engineアプリケーションの新しいバージョンをデプロイする。

→`gcloud app deploy --no-promote`を使用して新しいバージョンをデプロイする。

理由: `--no-promote`フラグは新しいバージョンを作成するが、トラフィックをそれにシフトしない。その後、バージョン固有のURLを使用してテストし、準備ができたら手動でトラフィックを移行できる。

Compute Engineインスタンスで実行されているウェブアプリケーション用のグローバルHTTP(S)ロードバランサーを作成する。

→これらのコンポーネントを順番に作成する：インスタンスグループ（VMを含む）、ヘルスチェック、バックエンドサービス（IGとHCを指す）、URLマップ、ターゲットHTTP(S)プロキシ、およびグローバル転送ルール（パブリックIPを含む）。

理由: この順序により、バックエンド（インスタンス）からフロントエンド（転送ルール）までロードバランサーが正しく構築される。各コンポーネントは、ルーティングとヘルスチェックにおいて特定の目的を果たす。

チームがTerraformステートを共同で管理し、セキュリティを確保し、同時変更を防ぐ必要がある。

→TerraformバックエンドとしてCloud Storageバケットを使用する。履歴とリカバリのためにオブジェクトバージョニングを有効にする。ステートロッキングはGCSバックエンドによって自動的に処理される。

理由: リモートGCSバックエンドは、GCPでのチームコラボレーションの標準である。ステートの破損を防ぐためのロッキングと、ロールバック機能のためのバージョニングを提供する。

グループ内の任意のVMのCPU使用率が、一定期間（例：5分間）80%を超えた場合に通知を受け取る。

→Cloud Monitoringでアラートポリシーを作成する。条件を`Metric: CPU utilization > 80%`、`Duration: 5 minutes`に設定する。通知チャネル（例：メール、PagerDuty）を構成する。

理由: Cloud Monitoringは、メトリックベースのアラートを作成するためのネイティブサービスである。期間条件は、短時間の正常な利用率スパイクによる「フラッピング」アラートを回避するために重要である。

特定の監査ログをコンプライアンスのために7年間保持し、他のログは30日間保持する。

→監査ログのフィルタを持つログシンクを作成する。シンクをCloud Storageバケットにエクスポートするように構成する。バケットに7年間の保持ポリシーを適用する。

理由: Cloud Loggingには保持期間の制限がある（Admin Activityは最大400日）。シンクは、GCSのような長期で安価なストレージへのログルーティングやBigQueryでの分析のためのメカニズムである。

GKEポッドが`CrashLoopBackOff`状態にある。クラッシュ直前のコンテナからのログを表示する必要がある。

→`kubectl logs [POD_NAME] --previous`コマンドを使用する。

理由: コンテナがクラッシュして再起動すると、`kubectl logs`は*新しい*コンテナのログを表示する。クラッシュを診断するために、終了したインスタンスのログを表示するには`--previous`フラグが不可欠である。

マネージドインスタンスグループは、応答しなくなったインスタンスを自動的に置き換える必要がある。

→ヘルスチェック（例：HTTP、TCP）を構成し、マネージドインスタンスグループの自動修復ポリシーに適用する。

理由: MIGはヘルスチェックに基づいて定期的にインスタンスをプローブする。インスタンスが連続してチェックに失敗した場合、MIGはテンプレートからインスタンスを自動的に削除して再作成し、アプリケーションの可用性を確保する。

Cloud SQLデータベースでデータ破損イベントが発生した。イベント発生の5分前の状態にデータベースを復元する必要がある。

→事前にインスタンスでPoint-in-Time Recovery（PITR）が有効になっていることを確認する。復元する正確なタイムスタンプを指定して復元操作を実行する。

理由: PITRはバイナリロギングが有効になっていることに依存する。保持期間内の任意の時点への詳細な復元が可能であり、データ損失を最小限に抑える（低いRPO）ために重要である。

Compute Engine永続ディスクの毎日バックアップを自動化し、14日間保持する。

→ディスクスナップショット用のリソースポリシーを作成する。毎日スケジュールと14日間の保持ポリシーを構成する。このポリシーをターゲットの永続ディスクにアタッチする。

理由: スナップショットスケジュールは、GCEバックアップを自動化するためのマネージドな「設定したらあとは忘れる」方法である。これは、cronジョブやカスタムスクリプトを使用するよりも信頼性が高く、保守が容易である。

Compute EngineインスタンスがCloud Storageバケットから読み取り、BigQueryテーブルに書き込む必要がある。最小限必要な権限を付与する。

→カスタムサービスアカウントを作成する。それに`roles/storage.objectViewer`と`roles/bigquery.dataEditor`のロールを付与する。このサービスアカウントをインスタンスにアタッチする。

理由: 特定の事前定義されたロールを持つカスタムサービスアカウントを使用することで、デフォルトのCompute Engineサービスアカウントの過度に寛容な性質を避け、最小権限の原則に準拠する。

ユーザーにGCEインスタンスを管理する権限を付与するが、削除する権限は与えない。

→カスタムIAMロールを作成する。`roles/compute.instanceAdmin.v1`ロールの権限から開始し、`compute.instances.delete`権限を削除する。

理由: カスタムロールは、事前定義されたロールが特定の職務に対して広すぎるか、または制限的すぎる場合に、正確な権限セットを付与する柔軟性を提供する。

セキュリティポリシーに従い、外部IPアドレスを持たないCompute Engineインスタンスに開発者がSSHする必要がある。

→開発者に`roles/iap.tunnelResourceAccessor`ロールを付与する。その後、`gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`を使用して接続できる。

理由: Identity-Aware Proxy（IAP）TCP転送は、踏み台ホスト、VPN、またはパブリックIPなしで内部インスタンスにアクセスするための安全な、IDベースの方法を提供する。

リファレンス↗

特定のVMへのインバウンドSSH（ポート22）トラフィックを、企業オフィスIP範囲からのみ許可する。

→`direction: INGRESS`、`action: ALLOW`、`protocol/ports: tcp:22`、`source ranges: [CORPORATE_IP_CIDR]`、`target tags: [例： "allow-ssh"]`を持つVPCファイアウォールルールを作成する。そのタグを意図するVMに適用する。

理由: ソース範囲とターゲットタグを組み合わせることで、トラフィックを制御するための正確でスケーラブルな方法が提供される。これにより、接続できる*人*と接続できる*もの*の両方が制限される。

機密性の高いBigQueryプロジェクトのデータが、有効な認証情報がある場合でも、信頼できるネットワーク境界外からコピーされたりアクセスされたりするのを防ぐ。

→VPC Service Controlsを構成する。機密プロジェクトを含み、BigQuery APIを制限するサービス境界を作成する。

理由: VPC Service Controlsは、APIレベルのアクセスを制御する仮想的な「データ境界」を作成し、ファイアウォールルールでは防ぐことができないデータ持ち出しに対する強力な防御を提供する。

サードパーティアプリケーションに、Cloud Storageバケット内の特定のプライベートオブジェクトへの一時的かつ時間制限付きの読み取りアクセスを提供する。

→読み取り権限を持つサービスアカウントを使用して、短い有効期限（例：15分）を持つオブジェクトの署名付きURLを生成する。

理由: 署名付きURLは、サードパーティがGoogleアカウントやIAM権限を持つ必要なく、一時的なオブジェクトごとのアクセスを許可する。これはこのユースケースで最も安全な方法である。

GKEポッドが、Kubernetesシークレットとしてサービスアカウントキーを保存することなく、Google Cloud API（例：Pub/Sub）に安全にアクセスする必要がある。

→GKEクラスターでWorkload Identityを有効にする。Googleサービスアカウント（GSA）とKubernetesサービスアカウント（KSA）を作成する。IAMポリシーを使用してKSAをGSAにバインドする。ポッドがKSAを使用するように構成する。

理由: Workload Identityは、GKEアプリケーションがGoogle Cloudサービスに認証するための推奨されるキーレスな方法である。これはKSAのIDをGSAのIDにマッピングし、キーファイルを管理およびローテーションするよりも安全である。

リファレンス↗

組織のポリシーにより、Cloud Storageバケット内のすべてのデータが組織が管理する暗号化キーを使用して暗号化される必要がある。

→Cloud KMSで暗号化キーを作成する。Cloud Storageバケットを作成する際に、このキーを顧客管理の暗号化キー（CMEK）として指定する。

理由: CMEKは、暗号化に使用されるキー（ローテーションと失効を含む）を制御できるようにする一方で、Googleのマネージド暗号化インフラストラクチャを依然として活用できる。

従業員が既存のオンプレミスActive Directory認証情報を使用してGoogle Cloudリソースにアクセスできるようにする。

→SAML 2.0を使用してCloud IdentityをActive Directoryとフェデレーションするように構成する。ユーザーはADで認証し、その後ADがGoogle CloudにIDをアサートしてアクセスを許可する。

理由: フェデレーションによりシングルサインオン（SSO）が可能になり、既存のIdP（Active Directory）でID管理を一元化できるため、Google Cloudで別途パスワードセットを管理する必要がなくなる。

外部の請負業者にプロジェクトへ一時的なアクセスを許可し、そのアクセスが30日後に自動的に期限切れになるようにする。

→請負業者を必要なロールを持つIAMメンバーとして追加する。ロールバインディングに有効期限タイムスタンプ（`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`）を持つ条件を追加する。

理由: IAM条件は属性ベースのアクセス制御を提供する。時間ベースの条件は一時的なアクセスに最適であり、手動でのクリーンアップなしに自動的に権限を取り消す。