Google Cloudのbillingにおいての組織構造について

こんにちは、はじめまして。grasys 社内SEの浦野です。
私は自身で何かを開発したりということはあまりないのですが、社内の請求関連のシステムに携わっていることもあって、Google Cloudでのリソースと請求がどの様に紐づいているかについて書いてみようと思います。

まずProjectについて

Google Cloudでは、Projectリソースが基本単位として存在します。
Google Cloudのサービスのリソース(VMやCloud Storage バケット、Pub/Sub トピック、App Engine インスタンスなど)は全てProjectに紐づきます。
そのため、課金・請求もProjectに紐づく形になります。
ProjectはAWSでいうところのAWSアカウントに似ています。
主体にするものが違うので厳密には同じとは言えないですが、サービスのリソースが紐づく、課金・請求の単位という点では同じと言えます。

組織について

Google WorkspaceやGoogle Cloud Identifyとドメインを紐づけることで、組織という単位で一括管理を行うことができます。
組織という単位を利用した場合は、Cloud請求先アカウントも組織に紐づく形になり、組織に紐づくProject全ての請求が組織のCloud請求先アカウントで管理されることになります。
また、組織を利用することで、Projectをフォルダという単位でグループ分けしたり、フォルダ単位や一括でのアクセス制御と権限を管理できるようになります。
組織を使用しない場合には組織なしとして扱われ、どこを一括とするかの基準が存在しないので、上記のフォルダ管理、一括でのアクセス制御などを行うことはできません。
これはAWSでいうところのOrganizationsに似ています。
これもどこを主体にするかが違うので厳密には違うのですけれど、一括管理するための仕組みという観点では同じと言えます。

Google Cloud のリソース階層

上記までの情報を踏まえて、Google Cloudのリソース階層をまとめると以下の形になります。

ドメイン = 組織 -> (フォルダ) -> Project -> 各種サービス等のリソース
組織 -> Cloud請求先アカウント

上位から下位は、1対多の関係です。
アクセス制御などのポリシーは、基本上位から継承される形になります。
Cloud請求先アカウントはProjectの課金情報を取得するように紐づいていますが、直接階層がつながっているわけではないので、ポリシーが継承されることはありません。

Cloud請求先アカウントとお支払いプロファイルについて

Cloud請求先アカウントは上記にも書いたようにGoogle Cloudのリソースの一つです。
紐づいたProjectの課金情報の把握を行なっています。
また、リソースであるため、アクセス権限の設定も可能です。
例えば、請求の設定、請求情報の閲覧、または新規・既存のProjectをCloud請求先アカウントに紐づけるなどです。

Cloud請求先アカウントにはお支払いプロファイルが紐付きます。
これは、Google Cloudを含めたすべてのGoogleのサービスの支払いを処理するGoogleレベル(Google Cloudとは別)のリソースです。
お支払いプロファイルには管理者び住所や支払い方法(口座、クレジットカードなど)、支払い履歴などが含まれます。

請求サブアカウントについて

請求サブアカウントとはリセラーの時に使用されるアカウントです。
請求サブアカウントは親となるCloud請求先アカウントを持ち、サブアカウントの請求は親アカウントにまとめられ、親アカウントによって支払いが行われます。
請求サブアカウントは基本的にはCloud請求先アカウントと同じ機能を持ち、Projectを紐付け、アクセス制御を行うことができます。
アクセス制御に関しては親アカウントとは切り離され、独立して設定が行えます。
grasysもGoogle Cloudのリセールパートナーであるので、grasys組織に紐づいたサブアカウントがいくつもあることになります。

終わり

あんまりまとまりがない状態になりましたが、請求として考えておく組織についてはこんな感じになります。
次は請求の機能そのものに関して書ければと考えています。