Google Cloud Platform（GCP）では、ニーズに合わせて請求をさまざまな方法で構成できます。このセクションでは、組織と課金の基本的なコンセプトと効果的な使用方法について説明します。
リソースの概要
リソースとは
GCP のコンテキストでは、リソースはワークロードの処理に使用されるサービスレベルのリソース（VM、DB など）を意味することもあれば、サービスの上位にあるアカウント レベルのリソース（プロジェクト、フォルダ、組織など）を意味することもあります。
リソース管理とは
リソース管理では、会社 / チームで使用する各種の Cloud リソースの構成と、こうしたリソースへのアクセス許可を付与します。特に、サービスレベルのリソースの上位にあるアカウント レベルのリソースの設定と編成が重要です。アカウント レベルのリソースは、GCP アカウントの設定と管理に関連します。
リソース階層
GCP のリソースは階層的に編成されます。これにより、組織の運用体制を GCP にマッピングし、関連リソースのグループに対するアクセスを制御できます。リソース階層は、アクセス管理ポリシー（Cloud Identity and Access Management）と組織ポリシーの論理的な接点となります。
Cloud IAM と組織ポリシーはともに階層から継承されます。階層の各ノードで有効なポリシーは、ノードに直接適用されるポリシーで、祖先から継承されます。
次の図に示すリソース階層の例は、GCP アカウントの管理に関連する主要なアカウント レベルのリソースを示しています。
ドメイン
- 会社のドメインは組織の主要な ID です。Google Cloud Platform を含む Google サービスでは、ドメインによって会社の ID を確立します。
- ドメインを使用して、組織内のユーザーを管理します。
- Google Cloud Platform の使用時に組織に関連付けるユーザーは、ドメインレベルで定義します。
- ドメインは、ユーザーとデバイスに関する全体的なポリシーを管理できる場所でもあります（たとえば、2 要素認証を有効化したり、組織内の任意のユーザーのパスワードをリセットしたりできます）。
- ドメインは G Suite アカウントまたは Cloud Identity アカウントのいずれかにリンクされます。
- G Suite アカウントや Cloud Identity アカウントには、それぞれ 1 つの組織が関連付けられます。
- ドメインレベルの機能を管理するには、Google 管理コンソール（admin.google.com）を使用します。
リソース階層の詳細については、Cloud Resource Manager のドキュメントをご覧ください。
組織
- 組織は、Google Cloud Platform リソース階層のルートノードです。
- 組織に属するすべての GCP リソースは組織ノード下でグループ化されます。このグループ化に基づいて、組織ノードの下位にあるすべてのプロジェクト、フォルダ、リソース、請求先アカウントに対して設定、権限、ポリシーを定義できます。
- 組織は 1 つのドメイン（G Suite アカウントまたは Cloud Identity アカウントのいずれかで設定されたドメイン）に関連付けられます。Google Cloud でドメインを設定すると、自動的に組織が作成されます。
- 組織を使用して、GCP リソースと、それに対するユーザーのアクセス権限を管理できます。これには、次のタイプの管理が含まれます。
- プロアクティブ管理: 必要に応じてリソースを再編成します（たとえば、部門を再編成したり新しく立ち上げたりする場合、新しいプロジェクトとフォルダが必要になることがあります）。
- リアクティブ管理: リソースに対するアクセスを失った場合（たとえば、チームメンバーの 1 人がリソースにアクセスできなくなった場合や、退職した場合など）、そのリソースへのアクセスを再度取得するには、組織リソースがセーフティ ネットとして機能します。
- GCP に関連するさまざまな役割とリソース（組織、プロジェクト、フォルダ、リソース、請求先アカウントを含む）は、Google Cloud Platform Console 内で管理します。
組織の詳細については、組織の作成と管理をご覧ください。
フォルダ
- フォルダはグループ化メカニズムです。フォルダにはプロジェクト、他のフォルダ、またはその両方を格納できます。
- フォルダを使用するには、組織ノードが必要です。
- フォルダとプロジェクトはすべて組織ノード下でマッピングされます。
- フォルダを使用すると、共通の Cloud IAM ポリシーを共有するリソースをグループ化できます。
- 1 つのフォルダに複数のフォルダやリソースを格納できますが、個々のフォルダまたはリソースの親は 1 つだけです。
フォルダの使い方については、フォルダの作成と管理をご覧ください。
プロジェクト
- サービスレベルのリソース（Compute Engine 仮想マシン（VM）、Cloud Pub/Sub トピック、Cloud Storage バケットなど）を使用するには、プロジェクトが必須です。
- サービスレベルのリソースは例外なく、GCP での基本レベルの構成エンティティであるプロジェクトを親として持ちます。
- プロジェクトを使用すると、論理プロジェクト、チーム、環境、またはビジネス ファンクションや構造にマップされるその他のコレクションを表すことができます。
- プロジェクトは、サービス、API、Cloud IAM 権限を有効化するための基本単位となります。
- どのリソースも、1 つのプロジェクト内にしか存在することができません。
プロジェクトの詳細については、プロジェクトの作成と管理をご覧ください。
リソース
- すべての GCP サービスは、GCP のサービスレベルのリソース（Compute Engine 仮想マシン（VM）、Cloud Pub/Sub トピック、Cloud Storage バケットなど）を基本コンポーネントとして構成されます。
- 請求およびアクセスを制御する目的で、リソースは、階層（プロジェクトや組織も含む）の最下位に存在します。
ラベル
- ラベルを利用して、Google Cloud Platform リソース（Compute Engine インスタンスなど）を分類できます。
- ラベルは Key-Value ペアです。
- 各リソースにラベルを設定し、そのラベルに基づいてリソースをフィルタリングできます。
- ラベルは、よりきめ細かなレベルで費用を追跡するのに役立ちます。ラベルに関する情報は課金システムに転送されるため、ラベル別に料金を分析できます。
ラベルの使用方法については、ラベルの作成と管理をご覧ください。
請求先アカウントとお支払いプロファイル
概要
請求先アカウントは GCP で設定されます。特定の GCP リソースセットに対する料金の支払い者は、請求先アカウントを使用して定義します。 請求先アカウントのアクセス制御は、Cloud Identity and Access Management（IAM）役割で行います。請求先アカウントには、費用の支払い方法が記録された Google お支払いプロファイルが関連付けられます。
| 請求先アカウント | お支払いプロファイル |
|---|---|
Cloud Billing アカウント:
|
Google お支払いプロファイル:
|
請求先アカウントのタイプ
請求先アカウントには次の 2 つのタイプがあります。
セルフサービス
- 支払い方法は、各国またはリージョンの状況に応じて、クレジット カード、デビットカードまたは ACH 口座振替になります。
- 費用は自動的に請求されます。
- セルフサービス アカウントはオンラインで登録できます。
請求書発行
- 支払い方法は、小切手または銀行振込みです。
- 請求書は郵送またはメールで送られます。
- 請求先として適格である必要があります。 請求先の適格性については、こちらをご覧ください。
お支払いプロファイルのタイプ
お支払いプロファイルを作成するときに、プロファイルのタイプを指定するよう求められます。課税条件と本人確認のために、ここでは正確な情報を提供してください。この設定を後から変更することはできません。お支払いプロファイルを設定する際は、そのプロファイルの用途に最適なタイプを選択してください。
お支払いプロファイルには次の 2 つのタイプがあります。
個人
- 個人のお支払いアカウントとして、自分のアカウントを使用します。
- お支払いプロファイルを個人として登録すると、そのプロファイルを自分で管理できます。この場合、ユーザーの追加や削除、プロファイルに対する権限の変更を行うことはできません。
ビジネス
- ビジネス、組織、パートナーシップ、教育機関の代理として料金を支払います。
- Play アプリ、Play ゲーム、Google サービス（Google 広告、Google Cloud、Fi 電話サービスなど）のお支払いには、Google お支払いセンターをご利用いただけます。
- ビジネス プロファイルを使用する場合、複数のユーザーがお支払いプロファイルにアクセスして管理できるよう、管理対象の Google お支払いプロファイルに他のユーザーを追加できます。
- ビジネス プロファイルに追加されたすべてのユーザーが、そのプロファイルでお支払い情報を確認できます。
請求サイクル
費用は、次のいずれかの方法で自動的に請求先アカウントに請求されます。
- 毎月の請求: 月単位で定期的に費用が請求されます。
- 限度額請求: 特定の金額に達すると、費用が請求されます。
請求がある請求先アカウントには、毎月請求されます。セルフサービス請求先アカウントは、毎月の請求と限度額請求のどちらかを選ぶことができます。 限度額請求について詳しくは、こちらをご覧ください。
請求に関する連絡先
請求先アカウントには、そのアカウントに関連付けられている Google お支払いプロファイルで定義された一連の連絡先が設定されます。これらの連絡先は、登録されたお支払い方法に固有のお支払い情報を受け取ることができるユーザーです（たとえばクレジット カードの更新が必要なときに、その情報を受け取れます）。連絡先を管理するには、Google Cloud Platform Console またはお支払いコンソールを使用します。
サブアカウント
請求先サブカウントを利用すると、プロジェクトからの請求を請求書の別のセクションにまとめることができます。請求先サブカウントは、請求金額が表示される販売パートナーのマスター請求先アカウントへの請求先リンクが付いた請求先アカウントです。マスター請求先アカウントは請求書発行に記載されている必要があります。
サブアカウントは、多くの点で請求先アカウントと同様に動作します。つまり、リンクされたプロジェクトを設定し、請求関連のエクスポートの構成や Cloud IAM 役割の定義を行うことができます。サブアカウントにリンクしているプロジェクトで発生した料金は請求書にまとめられ、小計されます。リソース管理に対する影響として、アクセス制御ポリシーがサブアカウントで完全に分離され、お客様を分離して管理できるようになります。
サブアカウントは、通常、チャージバックの目的で販売パートナーのお客様を表すために使用されます。
Cloud Billing API には、API を経由してサブアカウントを作成し、管理する機能があります。この機能によって既存のシステムに接続し、新しい顧客またはチャージバック グループをプログラムでプロビジョニングできます。
組織、プロジェクト、請求先アカウント、お支払いプロファイルの関係
組織、請求先アカウント、プロジェクト間の相互作用は、所有権と支払いリンクという 2 つのタイプの関係によって管理されます。
- 所有権とは、Cloud IAM 権限の継承を指します。
- 支払いリンクは、特定のプロジェクトの支払いを行う請求先アカウントを定義します。
次の図は、ある組織の所有権と支払いリンクの関係を示しています。
この図では、組織はプロジェクト 1、2、3 の所有権を持ちます。つまり、この組織は 3 つのプロジェクトの Cloud IAM 権限の親となっています。
請求先アカウントは、プロジェクト 1、2、3 にリンクされています。これは、この請求先アカウントが 3 つのプロジェクトで発生した料金を支払うことを意味します。
請求先アカウントには Google お支払いプロファイルもリンクされています。このプロファイルには、氏名、住所、お支払い方法などの情報が記録されています。
この例では、組織の Cloud IAM 請求役割が付与されているユーザーには、請求先アカウントまたはプロジェクトの請求役割も割り当てられます。
Cloud IAM 請求役割の付与方法については、請求アクセス制御の概要をご覧ください。
役割の概要
役割とは
役割は、一般的なビジネス ファンクションを実行するための権限をユーザーに付与するものです。
GCP での役割の機能
Google Cloud Platform では、Cloud Identity and Access Management（Cloud IAM）を使用して GCP リソースに対するアクセス制御を管理できます。Cloud IAM ポリシーを設定して、誰（どのユーザー）に、どのリソースに対するどのアクセス権（役割）を付与するかを制御できます。ユーザーに権限を割り当てるには、Cloud IAM ポリシーを使用して特定の役割をユーザーに付与します。役割には 1 つ以上の権限が割り当てられています。これにより、リソースに対するユーザー アクセスを制御します。
Cloud IAM ポリシー（役割）は、組織レベル、フォルダレベル、プロジェクト レベルで設定できます。場合によっては、サービスレベルのリソースに対して設定することもできます。
ポリシーは階層から継承されます。階層の各ノードで有効なポリシーは、ノードに直接適用されるポリシーで、祖先から継承されます。組織レベルでポリシーを設定すると、そのすべての子フォルダとプロジェクトにポリシーが継承されます。プロジェクト レベルでポリシーを設定すると、そのすべての子リソースにポリシーが継承されます。リソース階層内のさまざまなレベルで権限を細かく適用し、GCP 内で適切な人物が機能を利用できるように設定できます。
役割に関するベスト プラクティス
- 重要な役割は複数のユーザーに割り当てます（ある程度の冗長性を確保するため）。
- 管理者が誰であるかを記録して、管理者の名前を組織内のユーザーに伝えます。
- 役割の割り当てを最新の状態に保ちます。
重要な役割
下の図は GCP リソース階層を表しています。各レベルで重要な役割について説明します。
| ドメイン | ||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||
| お支払いプロファイル | ||||||
|---|---|---|---|---|---|---|
|
||||||