はじめに
AWS経験者が、GoogleCloudを活用する機会があるかもしれません。AWSとGoogleCloudはどちらもクラウドですが、考え方に違いがある部分もあります。今回は、GoogleCloudの初期設定における勘所を、AWSとの比較を通して説明します。

AWSとGoogleCloudにおける根本的な違い
AWS(Amazon Web Services)とGoogle Cloud(GCP)における根本的な違いは、主にリソースの階層構造、ID管理の基盤、および組織的な統制の適用方法に現れます。
AWSの経験者にとっては、GCPの初期設定や構造を理解する上で、特に以下の3点に注意が必要です。
1. リソース階層と分離の単位(アカウント vs プロジェクト)
AWSとGCPでは、リソースの隔離と管理の最小単位となる概念が異なります。

| GoogleCloudの概念 | AWSの対応する概念 | 違いと特徴 |
| プロジェクト (Project) | AWS アカウント (Account) | GoogleCloudにおけるプロジェクトは、仮想マシンやストレージバケットなどの個々のリソースを配置し、プロビジョニングする管理オブジェクトであり、AWSにおける「アカウント」に相当します,。課金情報やアクセス権限(IAMポリシー)もプロジェクト単位で設定できます。 |
| 組織 (Organization) | AWS Organizations のルート/マスターアカウント | GoogleCloudの組織リソースは、企業や団体を表す階層の最上位ノードであり、ドメインと1対1で存在します。組織を利用することで、プロジェクト管理、ポリシーの統一、権限管理といった組織的な統制を実現します。 |
| フォルダ (Folder) | OU (組織単位) | フォルダは、複数のプロジェクトをグループ化するための管理オブジェクトであり、リソース階層の中間に位置します。例えば、prod/やstaging/のように環境ごとにプロジェクトを分離するために使用されます。 |

AWSでは「アカウント」自体がリソースとセキュリティの強固な分離単位ですが、GoogleCloudでは「組織リソース」が最上位にあり、その下に「フォルダ」、そして具体的なリソースを配置する「プロジェクト」がぶら下がるという、明確な階層構造(Organization -> Folder -> Project)が推奨されます。
GoogleCloudプロジェクト作成の手順はこちら:

2. ユーザーID管理の仕組み(Cloud Identity/Workspace vs IAM)
GoogleCloudは、ユーザーアカウントの管理において、AWSとは異なり、GoogleのIDサービスを基盤として利用します。


根本的な違い:
AWSがIAMサービス内でユーザーを管理できるのに対し、GoogleCloudでは、まずドメインに紐づくCloud Identity(またはGoogle Workspace)を設定し、ユーザーIDを一元管理する必要があります,。このID基盤が確立されて初めて、GoogleCloudリソースへのアクセス権(IAMロール)を付与できるようになります。
3. 組織的な統制とセキュリティの適用
GoogleCloudは、階層の最上位からセキュリティとガバナンスを強制的に適用する強力な仕組みを備えています。

• 組織ポリシー (Organization Policy) の強制力: Googleの組織ポリシーは、組織レベルで適用される強制的なルール(ガードレール)であり、配下のフォルダやプロジェクトに継承されます。これにより、利用者が組織のセキュリティ体制から逸脱する操作(例:特定のリージョン以外でのリソース作成の制限、外部IPの無効化、デフォルトネットワークの無効化)を制限できます。
• 権限付与のベストプラクティス: GCPでは、最小権限の原則に従い、広範な権限を持つOwnerロールのような使用を避けることが強く推奨されており、カスタムロールやIAM Conditionを使用してアクセスを適切に制限することが重要です。また、個々のユーザーではなく、職務に応じて作成したグループにIAMロールを割り当てるロールベースアクセス制御(RBAC)がベストプラクティスとされています。
GoogleCloudの基本概念




実際のGoogleCloudセットアップ手順
STEP1:組織とID基盤を確立する







まとめ
GoogleCloudのセットアップを理解するには、AWSアカウントを賃貸住宅の各部屋に例えると分かりやすいかもしれません。AWSでは各部屋(AWSアカウント)を個別に契約・管理しますが、GoogleCloudでは、まずCloud Identityという「マンションの管理会社」を作り、次にその下に「マンション全体」(組織リソース)を所有します。そして、各部屋(プロジェクト)は、その管理会社を通じて借り、設定(リソース)を配置していくイメージです。これにより、組織ポリシーという「マンションの規約」を最上位で統一して適用できます。


コメント