こんにちは、ふくちです。
普段AWSを使っているんですが、最近Google Cloudを使う機会が増えてきました。
ただAWSとは似ているようで違う部分も出てくるので、それを少しずつ整理していこうと思います。
OrganizaitonとProject
ほとんど似ているんですが、一部用語が違うのと、1点明確に違う部分があるという理解をしています。
まず同じ部分としては、クラウドリソースの管理・統制をする一番上の単位というところ。
その組織内部でのルールを設定したり、使えるリソースを管理したり、アカウントの作成・管理を担ったり。そしてこれらが階層構造で管理されているのもほぼ同じです。
AWSではOrganizations→OU→Member Account→各種AWSリソースという感じで階層構造になっていきます。
Google Cloudにおいてはリソース階層という形で記載されています。
これの一番上がOrganizationで、その配下にFolders・Projects・Resourcesというのが階層構造で見えてくるという感じです。
これのFoldersというのがAWSで言うOU、ProjectsというのがMember Accountです。Resourcesは各クラウドのリソースですね、Project/Account単位で作られて管理されます。
ただ完璧に一緒というわけではなく、特にProjectとAccountを比較するとProjectの方が軽いと言うか比較的気軽に作成・削除ができるものになっているようです。
AWSはAccountごとにメールアドレスとか変えないとダメですし各ルートユーザーが一応存在したりと割と重いですよね。
ちなみにGoogle Cloudには、Organizationに所属していないと使えないリソースがあります。これ多分SCPとかと同じ感じで、会社などの本格的な組織で利用することを想定されたものです。
会社アカウントが最初組織に所属して無くて辛い思いをしたのは内緒
違うところ
Organizationにおける権限の継承がなんか違うらしいです。
Google Cloudにおいては、Organization → Folder → Project → Resource へ、権限が下に継承されます。例えば上でEditor権限を付けると下にもそれが適用されるらしいです。
アクセス制御ポリシーと組織ポリシーのアタッチメント ポイントを提供し、階層の下部まで継承できるようにします。上位レベル（組織やフォルダなど）でロールを付与できます。これらのロールはすべての子リソースに継承されるため、個々のプロジェクトごとに権限を手動で構成する必要がなくなります。
一方AWSのIAMは原則アカウントの中で完結します。Organization / OUから設定するのは主にSCPで、これは権限というよりガードレールのようなものです。
なので上で権限を付けても下のアカウントには引き継がれません。