このドキュメントでは、一般的な問題を回避し、アクセス制御とコスト管理のベスト プラクティスを実現するために、さまざまな Google Cloud リソースを設定する方法について説明します。クラウド リソースの管理を成功させるための設計上の決定事項や構成オプションについて説明します。
このガイドの目的
- 請求に関連するさまざまなリソースの概要について説明します。
- Cloud Billing のリソースを効果的に設定して、簡単に管理できるようにする方法を説明します。また、戦略的な優先度に応じてクラウドを利用し、有効に機能するアカウントを維持する方法についても説明します。
- Google Cloud で発生する請求関連の一般的な問題を回避する際に役立つ情報を提供します。
- 冗長性とセキュリティを維持するために、リソースのアクセス権限を構成する際のベスト プラクティスについて説明します。
- 財務ガバナンス ツールを効果的に利用するための設定手順を説明します。
概要
このガイドは 2 つのセクションから構成されています。最初のセクションでは、Google Cloud の請求管理に関連するさまざまなリソースとロールの概要について説明します。2 番目のセクションでは、課金要件に合わせて最適な Google Cloud リソースを構成するために必要な手順を説明します。
セクション 1: コンセプト
- リソースの概要と階層: 課金に影響するさまざまな Google Cloud リソースの概要図を参照しながら、GCP リソース間の関係を説明します。
- ロールの概要: 請求の設定に直接関連するアクセス ロールを、リソース別に説明します。
セクション 2: 設定ガイド
- 課金設定に関連する Google Cloud オンボーディング トピックの内容に合わせた構成チュートリアル。また、組織の要件に合わせてカスタマイズする方法についても説明します。
Cloud Billing のコンセプト
設定ガイドのセクションに進む前に、Cloud Billing のコンセプトを理解しておきましょう。主要なコンセプトを理解することで、クラウド環境の構成を決める際に的確な判断を行うことができます。追加情報が必要な場合は、Cloud Billing のコンセプトの概要をご覧ください。
リソースの概要
リソースとは
Google Cloud のコンテキストでは、リソースはワークロードの処理に使用されるサービスレベルのリソース（仮想マシンなど）を意味することもあれば、サービスの上位にあるアカウント レベルのリソース（プロジェクト、フォルダ、組織など）を意味することもあります。
リソース管理とは
リソース管理では、会社またはチームで使用する各種の Google Cloud リソースの構成と、こうしたリソースへのアクセス許可を付与します。特に、サービスレベルのリソースの上位にあるアカウント レベルのリソースの設定と編成が重要です。アカウント レベルのリソースは、Google Cloud アカウントの設定と管理に関連します。このドキュメントでは、アカウント レベルのリソースを構成する際の手引きとなるアドバイスと、有効に機能するアカウントを維持するためのリソース管理に必要なロールについて説明します。
リソース階層
Google Cloud のリソースは階層的に編成されます。この階層により、組織の運用体制を Google Cloud にマッピングし、関連リソースのグループのアクセス制御と権限を管理できます。次の図に示すリソース階層の例は、Google Cloud アカウントの管理に関連する主要なアカウント レベルのリソースを示しています。
ドメインは、組織内のユーザーを管理するためのメカニズムです。これは、組織のリソースに直接関係します。
組織リソースは組織全体（会社など）を表し、リソース階層のルートノードとなります。階層の下にあるすべての Google Cloud リソースをここから集中管理できます。
階層の次のノードは フォルダです。フォルダを使用すると、親組織のさまざまな部門やチームの要件を分離できます。また、本番環境と開発環境のリソースを分けることもできます。
階層の一番下にあるのが プロジェクトです。プロジェクトには、ワークロードを処理するサービスレベルのリソース（コンピューティング リソース、ストレージ リソース、ネットワーク リソースなど）が含まれます。これらのリソースからアプリが構成されます。
リソースは、 ラベルを使用してさらに分類できます。サービスレベルのリソース（仮想マシンなど）にも、アカウント レベルのリソース（プロジェクトなど）にも、ラベルを付けることができます。
Cloud 請求先アカウントはプロジェクトにリンクされており、プロジェクトの料金の請求先です。
Cloud 請求先アカウントは、 Google お支払いプロファイルに関連付けられています。お支払いプロファイルは Google レベルのリソースです。Google サービス（Google 広告、Google Cloud など）に対する料金のお支払いには、お支払いプロファイルに関連付けられている支払い方法を使用します。
リソース階層内のさまざまなレベルできめ細かい権限を適用し、組織内で適切な人物に権限を与えることができます。
構造は柔軟に定義できます。変化する要件にも対応できます。まだ Google Cloud に慣れていない場合は、初期の要件を満たす最も単純な構造を採用できます。詳細については、Resource Manager の概要をご覧ください。
ロールの概要
ロールとは
ロールは、一般的なビジネス機能を実行するための権限をユーザーに付与するものです。
Google Cloud でのロールの仕組み
Google Cloud では、Google Cloud リソースに対するアクセス制御を管理するために Identity and Access Management（IAM）を使用できます。IAM ポリシーを設定することで、誰（どのユーザー）に、どのリソースに対するどのアクセス権（ロール）を付与するかを制御できます。ユーザーに権限を割り当てるには、IAM ポリシーを使用して特定のロールをユーザーに付与します。ロールには 1 つ以上の権限が割り当てられています。これにより、リソースに対するユーザー アクセスを制御します。
IAM ポリシー（ロール）は、組織レベル、フォルダレベル、プロジェクト レベルで設定できます。場合によっては、サービスレベルのリソースに設定することもできます。リソースでは親ノードのポリシーが継承されます。組織レベルでポリシーを設定すると、そのすべての子フォルダとプロジェクトにポリシーが継承されます。プロジェクト レベルでポリシーを設定すると、そのすべての子リソースにポリシーが継承されます。
下の図は Google Cloud リソース階層を表しています。各レベルで重要なロールについて説明します。
| ドメイン | ||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||
| Google お支払いプロファイル | ||||||
|---|---|---|---|---|---|---|
|
||||||
設定ガイド
設定ガイドの各セクションには、決定ポイントに関する情報と、ベスト プラクティスの推奨事項が記載されています。重要なロールについて説明し、構成チェックリストを示します。潜在的な問題に関する情報も提供します。このガイドの最終的な目標は、課金要件に合わせて Google Cloud リソースを構成することです。このガイドラインでは、アクセスと課金に関連して Google Cloud でよく見られる問題の回避に役立つ情報を提供します。
始める前に
設定ガイドを読み進める前に、Cloud Billing のコンセプトを十分に理解してください。主要なコンセプトを理解することで、クラウド環境の構成を決める際に的確な判断を行うことができます。詳しくは、次の動画をご覧ください。
ベスト プラクティス: Google Cloud リソースの編成とアクセス管理（Cloud Next '19）
Google Cloud でリソースを編成してアクセス制御を設定するには、さまざまな方法があります。チームがリソースに継続してアクセスし、効率よく管理できるようにするには、次のベスト プラクティスを実践する必要があります。このセッションでは、利用可能な Google Cloud のリソースについて説明します。また、アカウントの構成でよく発生する問題を回避できるように、ベスト プラクティスのチェックリストを提供します。
この設定ガイドは次のセクションから構成されています。
ドメインと組織
ドメインと組織は、リソース階層の最上位に位置します。Google Cloud ドメインと Google Cloud 組織を組み合わせて使用することで、すべてのユーザーと Google Cloud リソースを一元管理できます。
ドメインを使用して、組織内のユーザーを管理できます。
組織を使用すると、Google Cloud リソースと、それに対するユーザーのアクセス権限を管理できます。
ドメインと ID
会社のドメインは組織の主要な ID です。Google Cloud などの Google サービスでは、ドメインによって会社の ID を確立します。ドメインは、Google Workspace アカウントまたは Cloud Identity アカウントのいずれかにリンクされます。
ID は、Google Cloud リソースに対するユーザーの認証とアクセス管理で使用されます。ユーザー認証と ID の管理方法は、Google Cloud の使用を開始するときに決めることが重要です。アクセス管理は、Google Workspace と Cloud Identity を使用して柔軟に行うことができます。
重要な決定: Cloud Identity と Google Workspace
ユーザー認証と ID に Cloud Identity と Google Workspace のどちらを使用するか
組織リソースは、Google Workspace のアカウントまたは Cloud Identity のアカウントと密接に関連しています。組織リソースを取得するのは、Google Workspace または Cloud Identity ユーザーだけです。Google Workspace アカウントまたは Cloud Identity アカウントには、それぞれ 1 つの組織のみをプロビジョニングできます。ドメインの組織リソースを作成すると、アカウント ドメインのメンバーが作成する Google Cloud プロジェクトはすべて、デフォルトで組織リソースに属するようになります。
Google Cloud では、認証とアクセス管理に Google アカウントが使用されます。Google Cloud リソースの可視性、監査、アクセス制御を強化するため、フルマネージドの企業用 Google アカウントを使用することをおすすめします。
|
|
||||
| 詳細については、組織リソースの取得と Cloud Identity の設定をご覧ください。 | |||||
重要なロール
|
ドメインの特権管理者 特権管理者は、組織管理者のロール（またはその他のロール）を付与できます。また、ドメインレベルでアカウントを復元できます。 |
推奨される割り当て先 特権管理者は通常、上位レベルでのアクセスを管理できる担当者（ドメイン管理者など）です。 |
| 詳細については、Google Workspace 管理者ロールと Cloud Identity 管理者ロールをご覧ください。 | |
チェックリスト
| 1. リソースの作成 | |
|---|---|
| ❑ |
Cloud Identity または Google Workspace を選択する。
|
| 2. アクセスの構成 | |
| ❑ | ユーザーとグループの追加または同期に関するパターンを確認する。 |
| ❑ | 管理コンソール、 Google Cloud Directory Sync、または Admin SDK API を使用して、ユーザーとグループを追加します。 |
| ❑ | 複数の 特権管理者を設定します。アカウントへのアクセスで問題が発生した場合や、他の組織管理者に権限を委任する必要が生じた場合に連絡先がわかるよう、これらの特権関係者を他のプロジェクト オーナー、管理者、従業員に伝えます。 |
| 3. リソースの構成 | |
| ❑ | 提供されているライセンス数を確認する。Google では、デフォルトで固定数の無料ライセンスを提供しています。追加ライセンスが必要な場合は、お問い合わせください。 |
| ❑ | Cloud Identity は、さまざまなセキュリティ機能とユーザー管理機能を提供します。詳細については、 機能とエディションの比較表をご覧ください。 |
組織
組織は、Google Cloud リソース階層のルートノードです。組織には 1 つのドメインが関連付けられます。組織に属するすべてのリソースは組織ノード下でグループ化されます。このグループ化に基づいて、組織内のすべてのリソースに対する分析情報やアクセス制御が提供されます。
ベスト プラクティス: 組織を構成する
Google Cloud ユーザーは 組織リソースを持っている必要はありません。ただし、複数のユーザー アカウントを管理する必要がある場合は、 組織を構成することを強くおすすめします。 IAM ポリシーの継承やリソース アクセスの復旧など、 組織リソースには多くのメリットがあります。
詳細については、 組織の作成と管理をご覧ください。
重要なロール
|
ロール: 組織管理者 組織管理者は、組織内の任意のリソースを管理し、任意のロールを付与できます。 |
推奨される割り当て先 組織管理者は通常、アクセス制御を管理できる担当者（IT 管理者など）です。 |
| 詳しくは、組織のロールをご覧ください。 | |
チェックリスト
| 1. リソースの作成 | |
|---|---|
| ❑ | 組織リソースを取得します。ドメインと ID の手順を行っている場合は、すでに組織が作成されています。 |
| 2. アクセスの構成 | |
| ❑ | IAM ポリシーを定義し、組織全体のリソース（Cloud Billing やプロジェクト管理など）に対する責任を委譲する 組織管理者を複数設定します。 |
| ❑ | 最小権限のセキュリティ原則を考慮しながら、組織レベルですべてのユーザーが使用する IAM ロールを付与します。 |
| 3. リソースの構成 | |
| ❑ |
プロジェクトと請求先アカウントを組織に移行する。 移行後に、プロジェクトまたは請求先アカウントのオーナーがアカウントにアクセスできなくなった場合や退職した場合、組織管理者がプロジェクトまたは請求先アカウントの所有権を復旧できます。 |
Cloud 請求先アカウント
プロジェクトの料金は、請求先アカウントが支払います。各プロジェクトとそのサービスレベルのリソースに対する料金の請求先アカウントは、常に 1 つだけです。請求先アカウントは単一の通貨で運用され、Google お支払いプロファイルに関連付けられます。
請求先アカウントは、1 つ以上のプロジェクトにリンクできます。プロジェクトの使用量が追跡され、リンクされた請求先アカウントに請求されます。請求先アカウントにリンクされていないプロジェクトは、Google Cloud または Google Maps Platform サービスを使用できません。これは、無料のサービスのみを使用している場合もあてはまります。
重要な決定: 請求先アカウントを 1 つにするか複数にするか
組織内にメインの Cloud 請求先アカウントを 1 つ作成することをおすすめします。多くの場合、請求先アカウントを追加すると余分なオーバーヘッドが発生し、追跡や管理が難しくなります。また、複数の請求先アカウントが存在すると、 確約利用割引が適切に機能しない可能性があります。また、プロモーション クレジットで問題が発生する可能性もあります。
次のいずれかの要件を満たしている場合、複数の Cloud 請求先アカウントが必要になることがあります。
- 法的または会計上の理由から、料金を分割する必要がある。
- 複数の通貨で支払う必要がある。
重要な決定: クレジット カード / デビッドカードで支払うか、請求書による請求を利用するか
Google Cloud コンソールを使用して Cloud 請求先アカウントを最初に設定するときに、デフォルトでは、セルフサービスの請求先アカウントを作成し、支払い方法としてクレジット カードまたはデビットカードを関連付けます。
財務または経理部門がある場合や、Google Cloud を最初に開始する際に多額の費用がかかると予想される場合は、 請求書による請求を使用する方がよいことがあります。貴社が請求書発行の対象かどうかについては、Cloud Billing サポートまでお問い合わせください。お申し込みは組織の現在の請求先アカウントの課金管理者が行う必要があります。
重要なロール
|
ロール: 請求先アカウント管理者 請求先アカウント管理者は次のことができます。
|
推奨される割り当て先 通常、このロールを担うのは、会社の財務担当者（損益計算（P&L）を担当するビジネスリード、予算管理を担当する技術チームのメンバーなど）です。 重要な点として、課金サポートに連絡するユーザーには、このロールが割り当てられていることが必須であるため、サービス アカウントまたはメーリング リストを課金管理者として使用しないでください。 |
|
ロール: 課金ユーザー 課金ユーザーは次のことができます。
|
推奨される割り当て先 このロールは一般にプロジェクト作成者のロールと一緒に付与されます。通常、組織内の信頼できるプロジェクト作成者にはこのロールを付与して、作成したプロジェクトを請求先アカウントにリンクできるようにする必要があります。 |
| 詳しくは、請求のロールをご覧ください。 | |
チェックリスト
| 1. リソースの作成 | |
|---|---|
| ❑ | 使用するメインの請求先アカウントを作成または特定します。請求先アカウントがすでに存在する場合、この手順は完了しています。 |
| 2. アクセスの構成 | |
| ❑ | 財務部門などの担当者や、経費の確認 / 超過費用の確認を行うユーザーの役割に 請求レポートへのアクセスを許可する。 |
| ❑ | 複数の 請求先アカウント管理者を各請求先アカウントに割り当てます。組織レベルの権限を使用することも検討してください。 |
| 3. リソースの構成 | |
| ❑ |
複数の請求先アカウントをメインの請求先アカウントに統合します。
|
| ❑ |
潜在的な問題の発生を防ぐため、不要になった請求先アカウントを精算して閉鎖します。
|
| ❑ | 費用のモニタリングと分析に使用する課金データの自動エクスポートを設定します。課金データを BigQuery にエクスポートする方法を学習する。 |
課金データのエクスポート、請求レポート、請求書に関する重要なコンセプト
使用状況はプロジェクトから請求先アカウントに報告されます。使用状況のデータはさまざまな方法で利用できます。これにより、費用の全体像を把握できます。
- 請求書には請求額が記載されています。
- 請求レポートには、請求額の根拠と費用が発生した場所が記載されています。
費用に関する質問に回答するには、まず請求レポートを確認することをおすすめします。
課金データのエクスポートを行うと、毎日の使用量の概算がデータセットまたは特定のファイルに出力されます。これにより、使用データの分析ができます。
課金データを BigQuery にエクスポートすると、invoice.month フィールドが追加されます。これにより、エクスポートされたデータと請求書を比較できます。
- 請求書に反映されていない、後から報告された使用量が含まれている場合があります。たとえば、一部の月末のプロダクト使用料は、翌月の請求書で請求される場合があります。
- エクスポートされた課金データには、課金された税金や請求先アカウントに発行されたクレジットは含まれません。
- Looker Studio を使用すると、 一定期間の費用を可視化できます。
請求レポートは、課金データのエクスポートで出力されたものと同じデータを使用し、請求先アカウントに関連するすべてのプロジェクトの使用料金を表すグラフを表示します。 請求レポートを使用して、使用料金の概要を把握し、傾向を分析できます。
- Google Cloud コンソールで請求レポートにアクセスします。
- 請求先アカウントが複数ある場合、請求レポートには、一度に 1 つの請求先アカウントの使用料金が表示されます。すべての請求先アカウントが集計されることはありません。
- アクセスレベルによっては、請求先アカウントに関連するすべてのプロジェクトではなく、特定のプロジェクトの料金が表示されます。
請求書には、毎月の正式な請求額が示されます。また、請求対象の使用状況の内訳も示されます。毎月、請求書の PDF または CSV ファイルで明細を確認します。クレジットメモと請求書の支払い履歴は Google お支払いセンターで確認できます。
Google お支払いプロファイルとアカウント
ビジネスは Google お支払いプロファイルによって表されます。Google サービスに対する料金のお支払いには、お支払いプロファイルに関連付けられている支払い方法を使用します。お支払いプロファイルは payments.google.com で管理される Google レベルのリソースであり、Cloud 請求先アカウントにリンクされます。
警告: お支払いプロファイルは Google Cloud リソースではありません。お支払いプロファイルは、 別個のロールと権限で管理されます。これは Google Cloud 組織の管理対象ではないため、IAM ロールは適用されません。Google お支払いプロファイルの ユーザーの追加や削除、権限の変更は、Google お支払いセンターで行います。
重要な決定: 使用する Google お支払いプロファイルは 1 つか複数か
Cloud 請求先アカウントと同様に、管理上の理由からお支払いプロファイルの数は少なくすることをおすすめします。多くの場合、お支払いプロファイルを追加すると余分なオーバーヘッドが発生し、問題が発生する可能性があります。
次のような場合は、複数のお支払いプロファイルを作成することをおすすめします。
- Google アカウントに関連付ける支払いを個人用とビジネス用で別々にしたい
- 複数の企業や組織のお支払いプロファイルを管理したい
- 複数の国でお支払いプロファイルを設定したい国を変更するときに、新しいプロファイルの作成が必要になることがあります。
Cloud 請求先アカウントは、適切な Google お支払いプロファイルに関連付けられている必要があります。
重要なロール
|
Google お支払いプロファイル管理者 お支払いプロファイル管理者は次のことができます。
|
推奨される割り当て先 組織の Google お支払いプロファイル管理者は通常、財務や会計部門の担当者に割り当てます。 |
|
Google お支払いプロファイルの読み取りアクセス お支払いプロファイルの読み取りアクセスが付与されたユーザーは次の操作を行うことができます。
|
推奨される割り当て先 読み取りアクセスは、請求書に関するメール通知の受信のみが必要なユーザーに割り当てます。 |
| 詳しくは、Google お支払いプロファイルのユーザー権限をご覧ください。 | |
チェックリスト
| 1. リソースの作成 | |
|---|---|
| ❑ | Google Cloud で使用するビジネスタイプのお支払いプロファイルを作成する。請求書発行先の Cloud 請求先アカウントがすでに作成されている場合、この手順はすでに完了しています。オンラインで Cloud 請求先アカウントを設定する場合は、請求先アカウントの作成プロセスで Google お支払いプロファイルを作成（または選択）します。 |
| 2. アクセスの構成 | |
| ❑ | 住所、お支い払方法、税務情報などのアカウント情報を編集する複数の Google お支払いプロファイル管理者を割り当てる。 |
| ❑ | 請求書発行の場合は、複数の 請求書送付先を割り当てる。請求書はメールで送信することも郵送で送付することもできます。新しい請求書が送信されたことを常に確認できるようにする必要があります。 |
| ❑ | 電子通知と毎月の課金明細書の場合は、ユーザーを追加し、文書と通知を受信するメールアドレスの設定を行う。 |
| 3. リソースの構成 | |
| ❑ | Google お支払いプロファイルの情報が最新の状態かどうか定期的に確認する。特に、住所、メールアドレス、お支払いサービスのユーザー、お支払い方法を確認します。 |
| ❑ | 請求書発行でない場合:
|
| ❑ | 請求書発行の場合:
|
プロジェクト、フォルダ、ラベル
プロジェクト、フォルダ、ラベルを使用すると、管理要件や原価配分要件に基づいてリソースを論理的にまとめることができます。
概要
プロジェクト:
- リソース（Compute Engine 仮想マシン、Pub/Sub トピック、Cloud Storage バケットなど）を使用する場合に必要
- Google Cloud での基本レベルの構成エンティティです。すべてのサービスレベルのリソースの親になります。
- サービス、API、IAM 権限を有効にする場合の基準となります。
フォルダ:
- プロジェクトのグループ化メカニズムです。プロジェクトと他のフォルダの両方を含めることができます。
- 共通の IAM ポリシーを共有するリソースをグループ化するために使用
- 組織ノードにマッピングされます（フォルダを使用するには組織ノードが必要です）
ラベル:
- Google Cloud リソース（Compute Engine インスタンスなど）の分類に使用されます。
- リソースに関連付ける Key-Value ペアです。ラベルに基づいてリソースをフィルタリングできます。
- 課金システムに転送されるため、ラベル別に料金を分析でき、よりきめ細かなレベルで費用を追跡するのに最適です。
重要な決定: フォルダとプロジェクトに関する戦略
プロジェクトは必須です。フォルダは省略可能ですが、使用することを推奨します。
プロジェクトを使うメリット:プロジェクトは、Google Cloud での基本的な構成エンティティです。Compute Engine や Cloud Storage などのサービスレベルのリソースを使用するには、プロジェクトが必要です。サービスレベルのリソースは、プロジェクトの設定と権限を継承します。Google Cloud で実行しているプロダクトやサービスの数に応じて、複数のプロジェクトを作成する必要があります。プロジェクトを簡単に識別できるように、意味のある命名規則を定義する必要があります。プロジェクトの詳細については、 プロジェクトの作成と管理をご覧ください。
フォルダを使うメリット:フォルダでプロジェクトをグループ化すると、フォルダを単位として複数のプロジェクトに一貫してポリシーと権限を適用できます。Google Cloud を使用するユーザーやチームの数、Google Cloud で実行するプロダクトやサービスの数に応じて、フォルダを使用して論理的にリソースをグループ化できます。たとえば、サービスの開発用、ステージング用、本番環境用プロジェクトごとに異なるフォルダを設定できます。また、異なる環境を反映して複数のフォルダにプロジェクトやサービスを分散することも可能です。社内の部門ごとにフォルダを使用してプロジェクトを整理することもできます。フォルダを使用するメリットの 1 つは、フォルダごとに異なる IAM ポリシーを適用できるという点です。フォルダの使い方については、 フォルダの作成と管理をご覧ください。
ラベルを使うメリット:ラベルは、プロジェクト内のリソースや複数のプロジェクトにまたがるリソースにアノテーションを付けます。費用の追跡の要件に応じて、その内容、機能、関連するチームを識別するラベルをリソースに適用できます。たとえば、HTTP サーバーのすべての Compute Engine インスタンスにラベルを付けたり、データベース サービスに関連するすべてのコンポーネントにラベルを付けたりできます。ラベルの使用方法について詳しくは、ラベルの作成と管理をご覧ください。
重要なロール
|
ロール: プロジェクト作成者 プロジェクト作成者のロールでは、プロジェクトを作成できます。また、Google Cloud でリソースを起動して使用料金を発生させることができます。 |
推奨される割り当て先 組織のプロジェクト作成者は、チームリードやサービス アカウント（自動化用）に割り当てることができます。 |
|
ロール: プロジェクト オーナーとユーザー プロジェクト オーナーとユーザーのロールでは、プロジェクトの費用と使用状況を確認できます。また、リソースにラベルを付けることもできます。 |
推奨される割り当て先 組織のプロジェクト オーナーとユーザーは、チームリードやデベロッパーなどに割り当てます。 |
| 詳しくは、プロジェクトのロールをご覧ください。 | |
|
ロール: フォルダ管理者 フォルダ管理者は、フォルダの IAM ポリシーを作成、編集できます。フォルダ内のプロジェクトによってロールが継承される方法を決定します。 |
推奨される割り当て先 フォルダ管理者は、細かいアクセス制御を管理します。通常は部門長やチーム マネージャーです。 |
| 詳しくは、フォルダのロールをご覧ください。 | |
チェックリスト
| 1. リソースの作成 | |
|---|---|
| ❑ | プロジェクトを作成して、共通の目標、テーマ、目的を共有するリソースをグループにまとめる。プロダクトやサービスで、コンピューティングやストレージなどの複数の Google Cloud リソースを必要とする場合は、プロジェクトでこれらのリソースをグループ化します。 |
| ❑ | プロジェクトに意味のある名前を付ける。プロジェクトの名前規則を決めます。たとえば、サービスやそのリソースのコレクションを反映する名前（productname-prod など）をプロジェクトに付けることができます。プロジェクト名を使用することで、人が判読可能な方法でプロジェクトを識別できます。プロジェクト ID は、プロジェクトの作成時に Google Cloud コンソールで入力したプロジェクト名から生成されます。 |
| ❑ | 組織やインフラストラクチャでの使用方法に合わせて フォルダを設定する。 |
| 2. アクセスの構成 | |
| ❑ | チーム、プロダクト、サービス、環境の IAM 権限を指定するには、 フォルダを使用します。 |
| ❑ | 必要に応じて、 プロジェクト レベルで IAM 権限を設定する（フォルダを使用しない場合や、さらに細かいレベルでの設定が必要な場合）。 |
| 3. リソースの構成 | |
| ❑ | 重要なプロジェクトにリーエンを適用する。誤ってプロジェクトが削除されないよう、リーエンを適用してプロジェクトの削除を防止します。プロジェクトにリーエンを適用すると、リーエンを削除するまでプロジェクトを削除できなくなります。これは、重要なプロジェクトを保護する場合に役立ちます。 |
| ❑ | ラベルを使用して、リソースをさらに分類する。ラベルを使用して、プロジェクトやフォルダにまたがるリソースにタグを設定できます。1 つのリソースに複数のラベルを付けることができます。ラベルに関する情報は課金システムに転送され、課金データのエクスポートで取得されます。この情報は、費用のレポートや分析で役に立ちます。 |
| ❑ | プロジェクトで 確約利用割引（CUD）を使用するかどうかを決定し、Compute Engine リソースと請求に 継続利用割引（SUD）が適用される仕組みを確認する。 |
| ❑ | 必要に応じて、割り当ての仕組みを確認し、割り当ての増加をリクエストします。 |
| ❑ | 必要に応じて、 プロジェクトで API を有効にする。API を有効にすると、その API が現在のプロジェクトに関連付けられ、モニタリング ページが追加されます。さらに、プロジェクトで課金が有効になっている場合はその API の課金が有効になります。 |
詳細
動画ライブラリ: Google Cloud のコスト管理。コストのモニタリングと管理を行う際のベスト プラクティスをご覧ください。
Cloud OnAir: Google Cloud コスト管理のスタートガイド
Google Cloud への移行を最大限にするには、組織が Google Cloud の費用を明確に把握する必要があります。このウェブセミナーでは、Google Cloud の費用と使用量の管理を始めるためのベスト プラクティスを紹介します。請求先アカウント、組織、プロジェクト、基本的な権限、および予算を設定する方法をご覧ください。また、予算の超過を防ぐために現在の費用傾向を把握し、月末に支出を予測するために利用できる請求レポートについても紹介します。
Google Cloud でコスト管理を行うためのリソース編成（Cloud Next '19）
フロントエンド サーバーの費用や、ステージング環境で使用されるリソースの数はどのくらいでしょうか。各部門の支出を把握し、最適化するにはどうすればよいでしょうか。組織、フォルダ、プロジェクト、ラベルなどの Google Cloud ツールを使用すると、管理要件や原価配分要件に基づいてリソースを論理的にまとめることができます。このセッションでは、これらのツールを使用してコスト管理を行う方法を説明します。デベロッパーの方にも多国籍企業の方にも役立つ情報を提供します。
Google Cloud での財務ガバナンス統制の確立（Cloud Next '19）
クラウドで発生する費用をコントロールできているかどうかを把握するには、クラウドの費用計画を大なう必要があります。このセッションでは、予算、割り当て、権限など、事前あるいは事後に財務ガバナンスをコントロールする方法について説明します。また、プログラムで予算通知を行い、クラウドの使用量と費用を自動的に制限する方法についても紹介します。
費用および KPI を把握するために BigQuery でインタラクティブ ダッシュボードを作成する方法（Cloud Next '19）
クラウドの費用、使用量、全体的な費用を KPI 別に評価することで、より詳細な分析を行うことができます。このセッションでは、BigQuery を使用した課金データのエクスポート、請求または KPI 関連の高度なクエリの作成、内部関係者でのカスタムビューの共有について説明します。また、コストドライバを簡単に把握できるように、Looker Studio と Elastic でダッシュボードを作成する方法について紹介します。この機能をユーザーとして利用している PerimeterX が、Google Cloud のコストと主要なビジネス指標とどのように結び付けているのかを説明します。
Google Cloud の費用のモニタリングと管理（Cloud Next '19）
Google Cloud の使用量とコストの傾向を管理するのは、それほど難しいことではありません。このセッションでは、Google Cloud のコストを表示して月末の請求額を予測する方法について説明します。また、予算超過を防ぐための管理機能をいくつか紹介します。さらに、課金データを詳しく分析できるようにカスタム ダッシュボードを設定する方法についても紹介します。
Compute Engine の費用を削減する（Cloud Next '19）
Next '18 の「Compute Engine の費用を削減する」以降、多くの変更が行われましたが、適切なコスト管理の方法や経費節減の方法を探している方も少なくありません。この講演では、使用量を最適化し、コスト効率の優れた方法で最新のプロダクトと技術を利用する方法について説明します。