はじめに
PCA(Professional Cloud Architect)の勉強を始めたので、その過程のメモです。普段はAWSを使っていて、Google Cloudはほぼ初めてという状態でドキュメントを読み始めました。
読み進めてみて感じたのは、「AWSの知識があればほとんどのサービスは読み替えられるが、思想レベルで違う部分が2つだけある」ということです。
- 違い①：アカウント管理 vs リソース階層
- 違い②：IAMユーザー・ロール vs サービスアカウント
この2つは対応表の丸暗記では乗り切れず、考え方ごと入れ替える必要がありました。逆に言うと、この2つさえ押さえれば残りは記事末尾の対応表で足ります。同じようにAWSからGoogle Cloudに入る人と、未来の自分のために整理しておきます。
違い①：アカウント管理 vs リソース階層
AWS：1システム=1アカウントで分離する世界
まずAWS側の復習です。AWSで環境を分離するとき、最も強い境界は「アカウント」です。1つのアカウントの中にVPCや命名規則でSTG/PRODを同居させる運用も見かけますが、ベストプラクティスは環境ごと・システムごとにアカウント自体を分けることとされています。
- アカウントを複数作り、AWS Organizationsで束ねる
- OU(組織単位)でアカウントをグルーピングする
- SCP(サービスコントロールポリシー)で「このOU配下ではこの操作を禁止」というガードレールを敷く
請求もアカウント単位が基本で、Organizationsの一括請求でまとめる、という世界観です。
Google Cloud：組織 > フォルダ > プロジェクトの階層構造
Google Cloudは最初から木構造です。ドキュメントでは「リソース階層」と呼ばれています。
組織 (example.com)
├── フォルダ: 本番
│ ├── プロジェクト: myapp-prod
│ └── プロジェクト: batch-prod
└── フォルダ: 開発
├── プロジェクト: myapp-stg
└── プロジェクト: sandbox
それぞれの役割はこう理解しました。
- プロジェクト：課金・APIの有効化・IAMのスコープの単位。AWSアカウントに一番近い分離境界
- フォルダ：プロジェクトをまとめる箱。OUに相当する
- 組織：木のルート。1つの会社(ドメイン)に1つ
感覚としては「1つの契約(組織)の中に、プロジェクトを何個も生やす」イメージです。プロジェクトの作成はAWSアカウントの開設と違って数十秒で終わるので、検証用に作ってすぐ捨てる、という使い方が普通にされています。この軽さがAWSアカウントとの一番の肌感の違いでした。
脳内変換表と、自分がハマった勘違い
対応表にするとこうなります。
| AWS | Google Cloud |
|---|---|
| AWS Organizations(全体のルート) | 組織(Organization) |
| OU | フォルダ |
| AWSアカウント | プロジェクト |
| SCP | 組織ポリシー |
ここで自分は「フォルダごとに環境(STG/PROD)を分けるのかな」と勘違いしていました。正しくは、環境の分離はプロジェクトの単位で行います。myapp-prod と myapp-stg のようにプロジェクトを分けるのが基本形です。
ではフォルダは何のためにあるかというと、プロジェクト群を束ねて権限をまとめて当てるための箱です。たとえば本番フォルダに「本番は管理者以外アクセス不可」というIAMを付けると、配下の全プロジェクトに継承されます。OUに本番アカウント群を入れてSCPを当てるのと同じ発想です。
この「継承」がリソース階層の肝で、組織やフォルダに付けたIAMポリシーは下の階層すべてに自動で流れ落ちます。しかも基本はAllowの足し算で、上の階層で付与した権限を下の階層で剥がすことはできません。Deny優先の評価に慣れたAWS脳だとここで一度つまずくので、PCAの試験対策としても要注意ポイントだと思います。
違い②：IAMユーザー・ロール vs サービスアカウント
AWS：IAMユーザーとIAMロールの世界
こちらもAWS側の復習から。AWSのアイデンティティはアカウントの「中に」作ります。
- 人間にはIAMユーザーを作り、ポリシードキュメント(JSON)でAllow/Denyを細かく書く
- プログラムやEC2にはIAMロールをアタッチし、STSの一時クレデンシャルで動かす
アイデンティティもポリシーも、すべてアカウントの内側で完結する世界です。
Google Cloud：Googleアカウントに直接権限を振る世界
Google Cloudには、IAMユーザーという概念そのものがありません。最初ドキュメントを読んでいて「ユーザー作成の手順はどこ?」と探し回りました。
権限を付与する対象(プリンシパル)は、GmailやGoogle Workspaceのアカウント、つまりGoogleアカウントそのものです。アイデンティティはクラウドの外(Google)にあり、Google Cloud側のIAMがやるのは「誰に・どのロールを・どのリソースで」という紐づけ(バインディング)の管理だけです。
もう1つの違いは、ポリシーを自分でJSONで書かないことです。roles/storage.objectViewer のような事前定義ロールをプリンシパルに割り当てるのが基本形で、評価も原則Allowの積み上げです。拒否ポリシーという仕組みも後から追加されていますが、例外的な位置づけと理解しています。
サービスアカウント：リソースでありアイデンティティでもある
プログラム用のアイデンティティがサービスアカウントです。Compute EngineやCloud Runにアタッチして動かす使い方は、EC2にIAMロールをアタッチする感覚とそっくりで、ここは素直に読み替えられます。
ただし決定的に違う点が1つあります。サービスアカウントは、アイデンティティであると同時に、それ自体がプロジェクトに属するリソースだということです。
- アイデンティティとしての顔：ロールを付与されて、Cloud StorageやBigQueryにアクセスする
- リソースとしての顔：サービスアカウント自体にIAMポリシーが付き、「誰がこのサービスアカウントを使えるか」を
roles/iam.serviceAccountUserなどで制御される
AWSのIAMロールにも信頼ポリシー(誰がAssumeRoleできるか)があるので発想は近いのですが、Google Cloudでは「サービスアカウントの権限借用(impersonation)」として、人間が一時的にサービスアカウントの権限で操作する使い方まで含めた、より一般的な仕組みになっています。
なお、サービスアカウントはキー(JSONファイル)を発行してローカルに置くこともできますが、これはアンチパターンとされています。漏洩したら終わりの長期クレデンシャルなので、GitHub ActionsなどからはWorkload Identity Federationを使ったキーレス認証が推奨です。IAMユーザーのアクセスキーを撲滅してIAMロールに寄せる、というAWSでの流れと同じ空気を感じました。
IAMまわりの脳内変換表
| AWS | Google Cloud |
|---|---|
| IAMユーザー | Googleアカウント |
| IAMグループ | Googleグループ |
| IAMロール(EC2などにアタッチ) | サービスアカウント |
| ポリシードキュメント(JSON) | 事前定義ロール+バインディング |
| STS AssumeRole | サービスアカウントの権限借用(impersonation) |
| アクセスキーの撲滅 | サービスアカウントキーの撲滅 |
どれも「近い概念」であって完全一致ではないので、あくまで最初のとっかかり用です。
クイック脳内対応表：定番サービス編
思想が違うのは上の2つだけで、個々のサービスは対応表でだいたい読み替えられます。
| AWS | Google Cloud |
|---|---|
| Amazon S3 | Cloud Storage |
| Amazon EC2 | Compute Engine |
| AWS Lambda | Cloud Run functions(旧Cloud Functions) |
| Amazon ECS / Fargate | Cloud Run |
| Amazon RDS | Cloud SQL |
| Amazon DynamoDB | Firestore / Bigtable |
| Amazon VPC | VPC |
| Amazon CloudWatch | Cloud Monitoring / Cloud Logging |
| Amazon Route 53 | Cloud DNS |
| Amazon CloudFront | Cloud CDN |
| AWS CloudFormation | 該当なし(Terraformが事実上の標準) |
同じ名前でも中身が違って罠になりやすいものを2つメモしておきます。
- VPC：AWSのVPCはリージョンに閉じますが、Google CloudのVPCはグローバルリソースで、1つのVPCの中に複数リージョンのサブネットを作れます。リージョン間をまたぐ設計の前提が変わります
- IAM：前述のとおり、Google CloudのIAMは原則Allowの積み上げで、階層を下に継承します。「Denyで上書きして絞る」というAWSの発想は基本的に持ち込めません
まとめ
自分なりの結論は「変換できる部分と、思想ごと入れ替える部分を分けて覚える」です。
- サービス対応(S3⇄Cloud Storageなど)は対応表の読み替えで十分
- リソース階層とIAMだけは、AWSの概念を当てはめようとせず、木構造と継承・Googleアカウント直付け・サービスアカウントの二面性、として新しく覚える
手を動かすなら、無料枠でプロジェクトを2つ作って、片方だけにIAMでロールを付与し、スコープが分かれることを体感するのが手っ取り早いと思います。なお組織とフォルダは個人のGmailアカウントだけでは作れず、Cloud Identity(またはGoogle Workspace)が必要なので、個人検証ではプロジェクトの分離とIAMの挙動に絞るのが現実的です。
PCAの試験対策としては、リソース階層・IAMの継承・サービスアカウントの二面性のあたりが繰り返し問われる印象なので、このメモをベースに公式ドキュメントを読み込んでいきます。
参考