Cloud Billing リソースの組織化とアクセス管理

この記事では、Google Cloud Platform(GCP)のお客様が一般的な問題を回避し、アクセス制御とコスト管理のベスト プラクティスを実現できるよう、さまざまな GCP リソースの設定方法を説明します。クラウド リソースの管理を成功させるための設計上の決定事項や構成オプションについて説明します。

このガイドの目的

  • 請求に関連するさまざまなリソースの概要について説明します。
  • Cloud Billing のリソースを効果的に設定して、簡単に管理できるようにする方法を説明します。また、戦略的な優先度に応じてクラウドを利用し、有効に機能するアカウントを維持する方法についても説明します。
  • GCP で発生する請求関連の一般的な問題を回避するのに役立つ情報を提供します。
  • 冗長性とセキュリティを維持するために、リソースのアクセス権限を構成する際のベスト プラクティスについて説明します。
  • 財務ガバナンス ツールを効果的に利用するための設定手順を説明します。

概要

このガイドは 2 つのセクションから構成されています。最初のセクションでは、GCP の請求管理に関連するさまざまなリソースと役割の概要について説明します。2 番目のセクションでは、課金要件に合わせて最適な GCP リソースを構成するために必要な手順を説明します。

セクション 1: コンセプト

  • リソースの概要と階層: 課金に影響するさまざまな GCP リソースの概要図を参照しながら、GCP リソース間の関係を説明します。
  • 役割の概要: 請求の設定に直接関連する役割をリソース別に説明します。

セクション 2: 設定ガイド

  • 課金設定に関連する GCP オンボーディング トピックの内容に合わせて構成手順を説明します。また、組織の要件に合わせてカスタマイズする方法についても説明します。

Cloud Billing のコンセプト

設定ガイドのセクションに進む前に、Cloud Billing のコンセプトを理解しておきましょう。主要なコンセプトを理解することで、クラウド環境の構成を決める際に的確な判断を行うことができます。追加情報が必要な場合は、Cloud Billing のコンセプトの概要をご覧ください。

リソースの概要

リソースとは

GCP のコンテキストでは、リソースはワークロードの処理に使用されるサービスレベルのリソース(VM、DB など)を意味することもあれば、サービスの上位にあるアカウント レベルのリソース(プロジェクト、フォルダ、組織など)を意味することもあります。

リソース管理とは

リソース管理では、会社 / チームで使用する各種の Cloud リソースの構成と、こうしたリソースへのアクセス許可を付与します。特に、サービスレベルのリソースの上位にあるアカウント レベルのリソースの設定と編成が重要です。アカウント レベルのリソースは、GCP アカウントの設定と管理に関連します。この記事では、アカウント レベルのリソースを構成する際の手引きとなるアドバイスと、有効に機能するアカウントを維持するためのリソース管理に必要な役割について説明します。

リソース階層

GCP のリソースは階層的に編成されます。これにより、組織の運用体制を GCP にマッピングし、関連リソースのグループに対するアクセスを制御できます。次の図に示すリソース階層の例は、GCP アカウントの管理に関連する主要なアカウント レベルのリソースを示しています。

リソース階層

  • public ドメインは、組織内のユーザーを管理するためのメカニズムです。これは、組織のリソースに直接関係します。

  • domain 組織リソースは組織全体(会社など)を表し、リソース階層のルートノードとなります。階層の下にあるすべての GCP リソースをここから集中管理できます。

  • 階層内で組織リソースの下にあるのは、folder フォルダです。フォルダを使用すると、親組織のさまざまな部門やチームの要件を分離できます。また、本番環境と開発環境のリソースを分けることもできます。

  • リソース階層の最下位にあるのは、プロジェクトです。プロジェクトには、ワークロードを処理するサービスレベルのリソース(コンピューティング リソース、ストレージ リソース、ネットワーク リソースなど)が含まれます。これらのリソースからアプリが構成されます。

  • リソースは、label ラベルを使用してさらに分類できます。サービスレベルのリソース(VM、DB など)にも、アカウント レベルのリソース(プロジェクト、フォルダなど)にも、ラベルを付けることができます。

  • monetization_on Cloud Billing アカウントはプロジェクトにリンクされており、プロジェクトの料金の請求先です。

  • Cloud Billing アカウントは、payment Google お支払いプロファイルに関連付けられています。お支払いプロファイルは Google レベルのリソースです。Google サービス(Google 広告、Google Cloud など)に対する料金のお支払いには、お支払いプロファイルに関連付けられている支払い方法を使用します。

リソース階層内のさまざまなレベルできめ細かい権限を適用し、組織内で適切な人物に権限を与えることができます。

構造は柔軟に定義できます。変化する要件にも対応できます。まだ GCP に慣れていない場合は、初期の要件を満たす最も単純な構造を採用できます。詳細については、Resource Manager の概要をご覧ください。

役割の概要

役割とは

役割は、一般的なビジネス ファンクションを実行するための権限をユーザーに付与するものです。

GCP での役割の機能

Google Cloud Platform では、Cloud Identity and Access Management(Cloud IAM)を使用して GCP リソースに対するアクセス制御を管理できます。Cloud IAM ポリシーを設定して、誰(どのユーザー)に、どのリソースに対するどのアクセス権(役割)を付与するかを制御できます。ユーザーに権限を割り当てるには、Cloud IAM ポリシーを使用して特定の役割をユーザーに付与します。役割には 1 つ以上の権限が割り当てられています。これにより、リソースに対するユーザー アクセスを制御します。

Cloud IAM ポリシー(役割)は、組織レベルフォルダレベルプロジェクト レベルで設定できます。場合によっては、サービスレベルのリソースに対して設定することもできます。リソースでは親ノードのポリシーが継承されます。組織レベルでポリシーを設定すると、そのすべての子フォルダとプロジェクトにポリシーが継承されます。プロジェクト レベルでポリシーを設定すると、そのすべての子リソースにポリシーが継承されます。

下の図は GCP リソース階層を表しています。各レベルで重要な役割について説明します。

public ドメイン
ドメインレベルの G Suite または Cloud Identity の特権管理者は、作成時に組織にアクセスする最初のユーザーとなります。
ドメインの特権管理者
特権管理者は、組織管理者の役割(またはその他の役割)を付与できます。また、ドメインレベルでアカウントを復元できます。
推奨される割り当て先
特権管理者は通常、上位レベルでのアクセスを管理できる人物です(ドメイン管理者など)。
詳しくは、G Suite 管理者役割Cloud Identity 管理者役割をご覧ください。
domain 組織
組織(たとえば、会社)は GCP リソース階層のルートノードになります。組織リソースは、階層上、プロジェクト リソースとフォルダの祖先になります。組織リソースに適用される Cloud IAM アクセス制御ポリシーは、組織のすべてのリソースの階層全体に適用されます。
役割: 組織管理者
組織管理者は、任意のリソースを管理し、組織内のあらゆる役割を付与できます。
推奨される割り当て先
組織管理者は通常、アクセス制御を管理できる人物です(IT 管理者など)。
詳しくは、組織の役割をご覧ください。
folder フォルダ
フォルダ リソースを使用すると、プロジェクトをさらに細かくグループ化してプロジェクトを分離できます。組織内ではサブ組織としてみることができます。フォルダは、異なる法人、部門、社内チームのモデル化に使用できます。フォルダには、サブフォルダとプロジェクトを含めることができます。
役割: フォルダ管理者
フォルダ管理者は、フォルダの Cloud IAM ポリシーを作成および編集できます。フォルダ内のプロジェクトによって継承される役割を決めます。
推奨される割り当て先
フォルダ管理者は、細かいアクセス制御を管理します。通常は部門長やチーム マネージャです。
詳しくは、フォルダの役割をご覧ください。
プロジェクト
プロジェクト リソースは、基本レベルの構成エンティティです。組織とフォルダには複数のプロジェクトを含めることができます。Google Cloud Platform プロジェクトを使用するにはプロジェクトが必要で、すべての GCP サービスの作成、有効化、使用、API の管理、課金の有効化、共同編集者の追加と削除、権限の管理などの基礎となります。
役割: プロジェクト作成者
プロジェクト作成者の役割は、プロジェクトを作成できます。GCP でのリソースの起動や使用料金の請求を許可できます。
推奨される割り当て先
この役割は、チームリードやサービス アカウント(自動化用)に割り当てることができます。
役割: プロジェクト オーナーとユーザー
プロジェクト オーナーとユーザーの役割では、プロジェクトの費用と使用状況を確認したり、リソースにラベルを付けたりできます。
推奨される割り当て先
この役割は、チームリードやデベロッパーに割り当てることができます。
詳しくは、プロジェクトの役割をご覧ください。
monetization_on 請求先アカウント
Cloud Billing アカウントはプロジェクトにリンクされており、プロジェクトの料金の請求先です。Cloud Billing アカウントは、Google お支払いプロファイルに関連付けられています。
役割: 請求先アカウント管理者
請求先アカウント管理者は、課金データのエクスポートを有効にして、費用 / 支出の確認、予算とアラートの設定、プロジェクトのリンク / リンク解除を行うことができます。
推奨される割り当て先
組織の請求管理者は、財務関連の担当者がなるケースが多いようです。
役割: 課金ユーザー
課金ユーザーは、プロジェクトを請求先アカウントにリンクできますが、リンクの解除はできません。これは通常、プロジェクト作成者の役割と連携して広く使用されています。
推奨される割り当て先
通常、組織で信頼できるプロジェクト作成者はこの役割を必要とします。
詳しくは、請求役割をご覧ください。
payment お支払いプロファイル
お支払いプロファイルは、Google お支払いセンターで管理されます。つまり、Cloud 組織の外部で管理されるということです。Google お支払いセンターでは、Google 広告、Google Cloud、Fi 電話サービスなど、すべての Google プロダクトとサービスに対する料金のお支払い方法を一元管理できます。お支払いプロファイルは Cloud Billing アカウントに関連付けられています。
お支払いプロファイル管理者
お支払いプロファイル管理者は、支払い方法を表示して管理できます。また、支払い、請求書やお支払いアカウントの確認を行うことができます。
推奨される割り当て先
組織のお支払いプロファイル管理者は通常、財務や会計部門の担当者に割り当てます。
詳しくは、お支払いプロファイルのユーザー権限をご覧ください。

設定ガイド

設定ガイドの各セクションでは、決定ポイントに関する情報とベスト プラクティスの推奨事項を提供します。重要な役割について説明し、構成チェックリストを示します。潜在的な問題に関する情報も提供します。このガイドの最終的な目標は、課金要件に合わせて GCP リソースを構成することです。このガイドラインでは、アクセスと課金に関連して GCP でよく見られる問題の回避に役立つ情報を提供します。

始める前に

設定ガイドを読み進める前に、Cloud Billing のコンセプトを十分に理解してください。主要なコンセプトを理解することで、クラウド環境の構成を決める際に的確な判断を行うことができます。

詳細については、このウェブセミナーをご覧ください。

Cloud OnAir: ベスト プラクティス: GCP リソースとアクセス制御を構成してコスト管理に対応する

Google Cloud Platform でリソースを編成してアクセス制御を設定するには、さまざまな方法があります。こうした設計決定を行う際は、自分の選択が、効果的なコスト管理(ショーバック、チャージバック、費用分析など)にどのような影響を与えるかを理解しておく必要があります。このウェブセミナーでは、課金とコスト管理に関して直面しがちな問題を回避できるよう、お客様の事例を取り上げながら、重要な設計上の決定、構成オプション、ベスト プラクティスについて説明します。

この設定ガイドは次のセクションから構成されています。


ドメインと組織

ドメインと組織は、リソース階層の最上位に位置します。Cloud ドメインと組織を組み合わせて使用することで、すべてのユーザーと Cloud リソースを一元管理できます。

  • ドメインを使用して、組織内のユーザーを管理できます。

  • 組織を使用して、GCP リソースと、それに対するユーザーのアクセス権限を管理できます。

リソース階層におけるドメインと組織

ドメインと ID

会社のドメインは組織の主要な ID です。Google Cloud Platform を含む Google サービスでは、ドメインによって会社の ID を確立します。ドメインは G Suite アカウントまたは Cloud Identity アカウントのいずれかにリンクされます。

ID は、GCP リソースに対するユーザーの認証とアクセス管理で使用されます。ユーザー認証と ID の管理方法は、Google Cloud Platform の使用を開始するときに決めます。これは重要な決定事項です。アクセス管理は G Suite と Cloud Identity を使用して柔軟に行うことができます。

stars 重要な決定: Cloud Identity と G Suite

ユーザー認証と識別で Cloud Identity または G Suite を使用する必要があるか。

組織リソースは、G Suite アカウントまたは Cloud Identity アカウントと密接に関連しています。G Suite または Cloud Identity のユーザーでなければ、組織リソースを取得できません。1 つの G Suite または Cloud Identity アカウントに 1 つの組織がプロビジョニングされます。ドメインに組織リソースを作成すると、アカウント ドメインのメンバーが作成するすべての GCP プロジェクトはデフォルトで組織リソースに属します。

Cloud Identity
Cloud Identity には無料の管理対象 Google アカウントが含まれています。このアカウントを使用して、Google Cloud Platform などの Google サービスを利用できます。各ユーザーに Cloud Identity アカウントを使用することで、Google 管理コンソールからドメイン全体にわたって、すべてのユーザーを管理できます。

利用方法: ドライブや Gmail などの G Suite 機能は必要ありません。ドメインの統合で提供されるアカウント管理機能が必要です。

推奨事項: Cloud Identity を使用して無料の組織を取得します。

G Suite
G Suite 管理者は、G Suite 管理コンソールからすべてのユーザーと設定を管理できます。デフォルトでは、すべての新規ユーザーに G Suite ライセンスが割り当てられます。G Suite ライセンスが不要な開発者のサブセットがある場合、代わりに、Cloud Identity アカウントを追加できます。

利用方法: G Suite のアカウント管理機能に加えて、ドライブや Gmail などの G Suite 機能も利用できます。

推奨事項: G Suite に登録して組織を取得します。

詳細については、組織リソースを取得するCloud Identity の利用を開始するをご覧ください。

重要な役割

public ドメイン特権管理者
特権管理者は、組織管理者の役割(またはその他の役割)を付与できます。また、ドメインレベルでアカウントを復元できます。
推奨される割り当て先
特権管理者は通常、上位レベルでのアクセスを管理できる人物です(ドメイン管理者など)。
詳しくは、G Suite 管理者役割Cloud Identity 管理者役割をご覧ください。

チェックリスト

1. リソースの作成
star Cloud Identity または G Suite を選択する。
2. アクセスの構成
ユーザーとグループの追加 / 同期に関するベスト プラクティスを確認する。
管理コンソールGoogle Cloud Directory Sync または Admin SDK API を使用して、ユーザーとグループを追加します。
複数の特権管理者を設定します。アカウントへのアクセスで問題が発生したり、他の組織管理者に権限を委任する必要が生じたりした場合に連絡先がわかるよう、これらの特権関係者を他のプロジェクト オーナー、管理者、従業員に伝えます。
3. リソースの構成
提供されているライセンス数を確認する。Google では、デフォルトで固定数の無料ライセンスを提供しています。追加ライセンスが必要な場合は、お問い合わせください
Cloud Identity は、さまざまなセキュリティ機能とユーザー管理機能を提供します。詳細については、機能とエディションの比較表をご覧ください。

組織

組織は、Google Cloud Platform リソース階層のルートノードです。組織には 1 つのドメインが関連付けられます。組織に属するすべてのリソースは組織ノード下でグループ化されます。このグループ化に基づいて、組織内のすべてのリソースに対する分析情報やアクセス制御が提供されます。

stars ベスト プラクティス: 組織の構成

GCP ユーザーに組織リソースが必要なわけではありません。ただし、複数のユーザー アカウントを管理する必要がある場合は、組織を構成することを強くおすすめしますCloud IAM ポリシーの継承リソース アクセスの復旧など、組織リソースには多くのメリットがあります

詳しくは、組織の作成と管理をご覧ください。

重要な役割

domain 役割: 組織管理者
組織管理者は、任意のリソースを管理し、組織内のあらゆる役割を付与できます。
推奨される割り当て先
組織管理者は通常、アクセス制御を管理できる人物です(IT 管理者など)。
詳しくは、組織のアクセス制御をご覧ください。

チェックリスト

1. リソースの作成
組織リソースを取得するドメインと ID の手順を行っている場合は、すでに組織が作成されています。
2. アクセスの構成
Cloud IAM ポリシーを定義し、組織全体のリソース(Cloud Billing やプロジェクト管理など)に対する責任を委譲する複数の組織管理者を設定する。
最小限の権限というセキュリティ原則を考慮しながら、組織レベルで Cloud IAM 役割を付与する
3. リソースの構成
プロジェクトと請求先アカウントを組織に移行する

移行後に、プロジェクトまたは請求先アカウントのオーナーがアカウントにアクセスできなくなったり、退職したりした場合、組織管理者がプロジェクトまたは請求先アカウントの所有権を復旧できます。


Cloud Billing アカウント

プロジェクトの料金は、請求先アカウントが支払います。各プロジェクトとそのサービスレベルのリソースに対する料金の請求先アカウントは、常に 1 つだけです。請求先アカウントは単一の通貨で運用され、Google お支払いプロファイルに関連付けられます。

リソース階層における Cloud Billing アカウント

請求先アカウントは、1 つ以上のプロジェクトにリンクできます。プロジェクトの利用料金は、リンクされた請求先アカウントに請求されます。請求先アカウントにリンクされていないプロジェクトでは、有料の GCP サービスを使用することはできません。

stars 重要な決定: 1 つの請求先アカウントか複数の請求先アカウントか

組織内にメインの Cloud Billing アカウントを 1 つ作成することをおすすめします。多くの場合、請求先アカウントを追加すると余分なオーバーヘッドが発生し、追跡や管理が難しくなります。また、複数の請求先アカウントが存在すると、確約利用割引が適切に機能しなかったり、プロモーション クレジットで問題が発生したりする可能性があります

次のいずれかの要件を満たしている場合、複数の Cloud Billing アカウントが必要になることがあります。

  • 法的または会計上の理由から、料金を分割する必要がある。
  • 複数の通貨で支払う必要がある。

stars 重要な決定: クレジット カード / デビッドカードで支払うか、請求書による請求を利用するか

Google Cloud Platform Console で Cloud Billing アカウントを最初に設定するときに、デフォルトでは、セルフサービスの請求先アカウントを作成し、支払い方法としてクレジット カードまたはデビッドカードを関連付けます。

財務 / 経理部門がある場合や、GCP を最初に開始する際に多額の費用がかかると予想される場合は、請求書による請求を使用する方がよいことがあります。貴社が請求書発行の対象かどうかについては、Cloud 課金サポートまでお問い合わせください。お申し込みは組織の現在の請求先アカウントの課金管理者が行う必要があります。

重要な役割

monetization_on 役割: 請求先アカウント管理者
請求先アカウント管理者は次の操作を行うことができます。
  • 支払い方法を管理する
  • 課金データのエクスポートを有効にする
  • 費用 / 利用額を表示し、予算アラートを設定する
  • プロジェクトをリンクまたはリンク解除する
  • 請求先アカウントに関連付けられている他のユーザーの役割を管理する
推奨される割り当て先
通常、この役割を担うのは、会社の財務担当者(損益計算(P&L)を担当するビジネスリード、予算管理を担当する技術チームのメンバーなど)です。

重要: 課金サポートに連絡するユーザーにはこの役割が割り当てられていることが必須です。

monetization_on 役割: 課金ユーザー
課金ユーザーは次の操作を行うことができます。
  • プロジェクトを請求先アカウントにリンクする(ただし、リンクを解除することはできません)
  • 費用を表示する
推奨される割り当て先
この役割は一般にプロジェクト作成者の役割と一緒に付与されます。通常、組織内の信頼できるプロジェクト作成者にはこの役割を付与して、作成したプロジェクトを請求先アカウントにリンクできるようにする必要があります。
詳しくは、請求役割をご覧ください。

チェックリスト

1. リソースの作成
star 使用するメインの請求先アカウントを作成または特定する請求先アカウントがすでに存在する場合、この手順は完了しています。
2. アクセスの構成
財務部門などの担当者や、経費の確認 / 超過費用の確認を行うユーザーの役割に請求レポートへのアクセスを許可する
複数の請求先アカウント管理者を各請求先アカウントに割り当てる。組織レベルの権限を使用することも検討してください。
3. リソースの構成
star 複数の請求先アカウントをメインの請求先アカウントに統合する
  1. 最初に、メインの請求先アカウントと、これらの請求先アカウントにリンクするプロジェクトを特定します。詳しくは、リンクされているプロジェクトの確認をご覧ください。
  2. 既存のプロジェクトをメインの請求先アカウントにリンクまたは移動します
star 潜在的な問題の発生を防ぐため、不要になった請求先アカウントを精算して閉鎖する
  1. 古い請求先アカウントを表示して、リンクされたプロジェクトがないことを確認します。
  2. すべてのプロジェクトをメインの請求先アカウントに移動した後、古い請求先アカウントへの課金が停止するまで 2 日間お待ちください
  3. 2 日後、古い請求先アカウントの残高を精算し、古い請求先アカウントを閉鎖します
attach_money 課金と原価配分のベスト プラクティスをよく理解する。
  • 複数のアラートしきい値を使用して予算アラートを設定し、過度な支出や予期しない予算超過を防ぐ。
attach_money 費用のモニタリングと分析に使用する課金データの自動エクスポートを設定する。データのエクスポートには 2 つのオプションがあります。

stars 重要なコンセプト: 課金データのエクスポート、請求レポート、請求書

使用状況はプロジェクトから請求先アカウントに報告されます。使用状況のデータはさまざまな方法で利用できます。これにより、費用の全体像を把握できます。

  • 請求書には請求額が記載されています。
  • 請求レポートには、請求額の根拠と費用が発生した場所が記載されています。

推奨事項: 費用の確認を行う際は、請求レポートを先にご覧ください。

課金データのエクスポートを行うと、毎日の使用量の概算がデータセットまたは特定のファイルに出力されます。これにより、使用データの分析ができます。 課金データを BigQuery にエクスポートすると、invoice.month フィールドが追加されます。これにより、エクスポートされたデータと請求書を比較できます。

  • 請求書に反映されていない、後から報告された使用量が含まれている場合があります。たとえば、一部の月末のプロダクト使用料は、翌月の請求書で請求される場合があります。
  • エクスポートされた課金データには、課金された税金や請求先アカウントに発行されたクレジットは含まれません。
  • ヒント: データポータルを使用すると、一定期間の費用を視覚的に表示できます

請求レポートは、課金データのエクスポートで出力されたものと同じデータを使用し、請求先アカウントに関連するすべてのプロジェクトの使用料金を表すグラフを表示します。請求レポートを使用して、使用料金の概要を把握し、傾向を分析できます。

  • Google Cloud Platform Console で請求レポートにアクセスします。
  • 請求先アカウントが複数ある場合、請求レポートには、一度に 1 つの請求先アカウントの使用料金が表示されます。すべての請求先アカウントが集計されることはありません。
  • アクセスレベルによっては、請求先アカウントに関連するすべてのプロジェクトではなく、特定のプロジェクトの料金が表示されます。

請求書には、毎月の正式な請求額が示されます。また、請求対象の使用状況の内訳も示されます。毎月、請求書の PDF または CSV ファイルで明細を確認します。クレジットメモと請求書の支払い履歴はお支払いセンターで確認できます。


お支払いプロファイルとアカウント

ビジネスは Google お支払いプロファイルによって表されます。Google サービスに対する料金のお支払いには、お支払いプロファイルに関連付けられている支払い方法を使用します。お支払いプロファイルは payments.google.com で管理される Google レベルのリソースであり、Cloud Billing アカウントにリンクされます。

リソース階層における Google お支払いプロファイル

warning 重要: お支払いプロファイルは Google Cloud Platform のリソースではありません。お支払いプロファイルは、別個の役割 / 権限で管理されます。これは Cloud 組織の管理対象ではないため、Cloud IAM の役割は適用されません。お支払いプロファイルのユーザーの追加や削除、権限の変更は、Google お支払いセンターで行います。

stars 重要な決定: 1 つのお支払いプロファイルか、複数のプロファイルか

請求先アカウントと同様に、管理上の理由からお支払いプロファイルの数は少なくすることをおすすめします。多くの場合、お支払いプロファイルを追加すると余分なオーバーヘッドが発生し、問題が発生する可能性があります。

次のような場合は、複数のお支払いプロファイルを作成することをおすすめします。

  • Google アカウントに関連付けるプロファイルを個人用とビジネス用で別々にしたい
  • 複数の企業や組織のプロファイルを管理したい
  • 複数の国でプロファイルを設定したい(国を変更するときは、新しいプロファイルの作成が必要になる場合があります)

Cloud Billing アカウントは、適切な Google お支払いプロファイルに関連付けられている必要があります。

重要な役割

payment お支払いプロファイル管理者
お支払いプロファイル管理者は次の操作を行うことができます。
  • プロファイル全体のお支払い方法を表示および管理する
  • 料金を支払う
  • お支払いアカウントと請求書を表示する
  • アカウントの設定を変更する
  • お支払いプロファイルに関連付けられている他の Google サービスを確認する
推奨される割り当て先
組織のお支払いプロファイル管理者は通常、財務や会計部門の担当者に割り当てます。
payment お支払いプロファイルに対する読み取り専用の権限
お支払いプロファイルに対する読み取り専用の権限を持つユーザーは、次の操作を行うことができます。
  • お支払いプロファイルを表示する
  • サブスクリプションとサービスを表示する
  • 請求書を表示する
推奨される割り当て先
請求書に関するメール通知の受信のみが必要なユーザー。
詳しくは、お支払いプロファイルのユーザー権限をご覧ください。

チェックリスト

1. リソースの作成
star GCP で使用するビジネス用のお支払いプロファイルを作成する。請求書発行アカウントを作成している場合、この手順はすでに完了しています。請求先アカウントをオンラインで設定している場合は、お支払いプロファイルはこのプロセスで作成されます。
2. アクセスの構成
住所、お支い払方法、税務情報などのアカウント情報を編集する複数のお支払いプロファイル管理者を割り当てる。
請求書発行の場合は、複数の請求書送付先を割り当てます。請求書はメールで送信することも郵送で送付することもできます。新しい請求書が送信されたことを常に確認できるようにする必要があります。
電子通知と毎月の課金明細書の場合は、ユーザーを追加し、文書と通知を受信するメールアドレスの設定を行います。
3. リソースの構成
お支払いプロファイルの情報が最新の状態かどうか定期的に確認する。特に、住所、メールアドレス、お支払いサービスのユーザー、お支払い方法を確認します。
請求書発行でない場合:
請求書発行の場合:
  • 毎月、請求書を確認し、異常や予期しない変化があるかどうか調べる。
  • 未適用のクレジットと支払いを定期的に確認し、毎月の支払いとクレジットが請求書に正しく反映されていることを確認する。ヘルプが必要な場合は、Google の Collections チームに連絡して、一致しないクレジットを申請してください。

プロジェクト、フォルダ、ラベル

プロジェクト、フォルダ、ラベルを使用すると、管理要件や原価配分要件に基づいてリソースを論理的にまとめることができます。

リソース階層におけるプロジェクト、フォルダ、ラベル

概要

プロジェクト:

  • Compute Engine 仮想マシン(VM)、Cloud Pub/Sub トピック、Cloud Storage バケットなどのリソースを使用する場合に必要です。
  • GCP での基本レベルの構成エンティティです。すべてのサービスレベルのリソースの親になります。
  • サービス、API、Cloud IAM 権限を有効にする場合の基準となります。

フォルダ:

  • プロジェクトのグループ化メカニズムです。プロジェクトと他のフォルダの両方を含めることができます。
  • 一般的な Cloud IAM ポリシーを共有するリソースをグループ化する場合に使用されます。
  • 組織ノードにマッピングされます。フォルダを使用するには組織ノードが必要です。

ラベル:

  • Google Cloud Platform リソース(Compute Engine インスタンスなど)の分類に使用されます。
  • リソースに関連付ける Key-Value ペアです。ラベルに基づいてリソースをフィルタリングできます。
  • よりきめ細かなレベルで費用を追跡するのに最適です。ラベルに関する課金システムに転送されるため、ラベル別に料金を分析できます。

stars 重要な決定: フォルダとプロジェクトに関する戦略

プロジェクトは必須です。フォルダは省略可能ですが、使用することを推奨します。

プロジェクトを使うメリット: プロジェクトは GCP での基本的な構成エンティティです。Compute Engine、Cloud Storage などのサービスレベルのリソースを使用するには、プロジェクトが必須となります。サービスレベルのリソースは、プロジェクトの設定と権限を継承します。GCP で実行しているプロダクトやサービスの数に応じて、複数のプロジェクトを作成する必要があります。プロジェクトを簡単に識別できるように、意味のある命名規則を定義する必要があります。プロジェクトの詳細については、プロジェクトの作成と管理をご覧ください。

フォルダを使うメリット: フォルダでプロジェクトをグループ化すると、フォルダを単位として複数のプロジェクトに一貫してポリシーと権限を適用できます。GCP を使用するユーザーやチームの数、GCP で実行するプロダクトやサービスの数に応じて、フォルダを使用して論理的にリソースをグループ化できます。たとえば、サービスの開発用、ステージング用、本番環境用プロジェクトごとに異なるフォルダを設定できます。また、異なる環境を反映して複数のフォルダにプロジェクトやサービスを分散することも可能です。社内の部門ごとにフォルダを使用してプロジェクトを整理することもできます。フォルダを使用するメリットの 1 つは、フォルダごとに異なる Cloud IAM ポリシーを適用できるという点です。フォルダの使い方について詳しくは、フォルダの作成と管理をご覧ください。

ラベルを使うメリット: ラベルは、プロジェクト内のリソースや複数のプロジェクトにまたがるリソースにアノテーションを付けます。費用の追跡の要件に応じて、その内容、機能、関連するチームを識別するラベルをリソースに適用できます。たとえば、HTTP サーバーのすべての Compute Engine インスタンスにラベルを付けたり、データベース サービスに関連するすべてのコンポーネントにラベルを付けたりできます。ラベルの使用方法について詳しくは、ラベルの作成と管理をご覧ください。

重要な役割

役割: プロジェクト作成者
プロジェクト作成者の役割は、プロジェクトを作成できます。GCP でのリソースの起動や使用料金の請求を許可できます。
推奨される割り当て先
この役割は、チームリードやサービス アカウント(自動化用)に割り当てることができます。
役割: プロジェクト オーナーとユーザー
プロジェクト オーナーとユーザーの役割では、プロジェクトの費用と使用状況を確認したり、リソースにラベルを付けたりできます。
推奨される割り当て先
この役割は、チームリードやデベロッパーに割り当てることができます。
詳しくは、プロジェクトの役割をご覧ください。
folder 役割: フォルダ管理者
フォルダ管理者は、フォルダの Cloud IAM ポリシーを作成および編集できます。フォルダ内のプロジェクトによって継承される役割を決めます。
推奨される割り当て先
フォルダ管理者は、細かいアクセス制御を管理します。通常は部門長やチーム マネージャです。
詳しくは、フォルダの役割をご覧ください。

チェックリスト

1. リソースの作成
star プロジェクトを作成して、共通の目標、テーマ、目的を共有するリソースをグループにまとめる。プロダクトやサービスで、コンピューティングやストレージなどの複数の GCP リソースを必要とする場合は、プロジェクトでこれらのリソースをグループ化します。
star プロジェクトに意味のある名前を付ける。プロジェクトの名前規則を決めます。たとえば、サービスやそのリソースのコレクションを反映する名前(productname-prod など)をプロジェクトに付けることができます。プロジェクト名を使用することで、人が判読可能な方法でプロジェクトを識別できます。プロジェクト ID は、プロジェクトの作成時に GCP Console で入力したプロジェクト名から生成されます。
組織やインフラストラクチャでの使用方法に合わせてフォルダを設定する
2. アクセスの構成
チーム、プロダクト、サービス、環境ごとにフォルダを使用して Cloud IAM 権限をサイロ化する
必要に応じて、プロジェクト レベルで Cloud IAM 権限を設定する(フォルダを使用しない場合や、さらに細かいレベルでの設定が必要な場合)。
3. リソースの構成
star 極めて重要なプロジェクトにリーエンを適用する。誤ってプロジェクトが削除されないよう、リーエンを適用してプロジェクトの削除を防止します。プロジェクトにリーエンを適用すると、リーエンを削除するまでプロジェクトを削除できなくなります。これは、重要なプロジェクトを保護する場合に役立ちます。
attach_money ラベルを使用して、リソースをさらに分類する。ラベルを使用して、プロジェクトやフォルダにまたがるリソースにタグを設定できます。1 つのリソースに複数のラベルを付けることができます。ラベルに関する情報は課金システムに転送され、課金データのエクスポートで取得されます。この情報は、費用のレポートや分析で役に立ちます。
プロジェクトで確約利用割引(CUD)を使用するかどうかを決定し、Compute Engine リソースと請求に継続利用割引(SUD)が適用される仕組みを確認する。
必要に応じて、割り当ての仕組みを確認し、割り当ての増加をリクエストする。
必要に応じて、プロジェクトで API を有効にするAPI を有効にすると、その API が現在のプロジェクトに関連付けられ、モニタリング ページが追加されます。さらに、プロジェクトで課金が有効になっている場合はその API の課金が有効になります。

詳細

Cloud OnAir: GCP コスト管理のスタートガイド

クラウドへの移行を最大限にするには、組織がクラウドコストを明確に理解する必要があります。このウェブセミナーでは、GCP の費用と使用量の管理を始めるためのおすすめの方法を紹介します。請求先アカウント、組織、プロジェクト、基本的な権限、および予算を設定する方法をご覧ください。また、予算の超過を防ぐために現在の費用傾向を把握し、月末に支出を予測するために利用できる請求レポートについても紹介します。

GCP でのコスト管理: リソースの構成方法(Cloud Next '18)

フロントエンド サーバーの費用や、ステージング環境で使用されるリソースの数はどのくらいでしょうか。各部門の支出を把握し、最適化するにはどうすればよいでしょうか。組織、フォルダ、プロジェクト、ラベルなどの GCP ツールを使用すると、管理要件や原価配分要件に基づいてリソースを論理的にまとめることができます。このセッションでは、これらのツールを使用してコスト管理を行う方法を説明します。開発者の方にも多国籍企業の方にも役立つ情報を提供します。

GCP 財務ガバナンスによるクラウドコストのコントロール(Cloud Next '18)

オンプレミスからクラウドに移行する企業が増えています。クラウドコストを管理するために財務ガバナンス ポリシーの導入はこれまで以上に重要になっています。このセッションでは、財務ガバナンスのコントロールについて説明します。割り当て、権限、予算を管理することで、予期しないコスト超過を防ぐことができます。また、Broad Institute によるデモでは、プログラムによる通知でアクションを自動的に実行し、クラウドの使用量とコストを制御する方法を紹介します。

BigQuery とデータポータルで課金データを処理する方法(Cloud Next '18)

多くの大企業は、チームやアプリケーション全体のクラウドの使用状況を追跡し、コスト要因を把握するため、カスタム ダッシュボードとレポートを作成しています。このセッションでは、課金チームと Vendasta が詳細な課金データを BigQuery にエクスポートし、そのデータに対する便利なクエリを作成する方法を説明します。また、これらのクエリに基づいて、データポータルに表示されるカスタム ダッシュボードを作成する方法も紹介します。

GCP コストのモニタリングと予測(Cloud Next '18)

GCP の使用量とコストの傾向を管理するのは、それほど難しいことではありません。このセッションでは、GCP コストのグラフの表示、カスタム レポートと予算の設定、月末請求額の予測、予算超過の可能性を通知するアラートの設定方法について説明します。

Google Compute Engine の費用を削減する(Cloud Next '18)

Next '17 の「Compute Engine の費用を削減する」以降、多くの変更が行われましたが、適切なコスト管理の方法や経費節減の方法を探している方も少なくありません。この講演では、使用量を最適化し、コスト効率の優れた方法で最新のプロダクトと技術を利用する方法を説明します。