GCP経験者向けのAWSメモ

概要

Google Cloud (以下GCP) の経験者の方が Amazon Web Service (以下AWS) を使い始めるときに混乱しやすいポイントや、GCP での各種機能の AWS での対応などの説明です。
過去に実際にGCPメインで使っていた私が AWS を使い始めるときにハマったポイントを追っています。

類似性、対応関係を説明しますが、異なるサービスなので基本的に正確な対応付けは行えず「こう対応付けして考えると理解しやすい」という記述になる旨をご了承ください。

前提など

前提として、GCP、AWS ともに基本的な(または素朴な)使い方を想定しています。
何をもって基本的というかは判断分かれるところではありますが、以下のような想定です:

• GCP ではサービスアカウントを JSON キーを使った認証で使用する。impersonate、Workload Identity などは考えない。
• AWS では IAM ユーザーで認証を行う。OIDC や SAML などでの認証は考えない。

GCPプロジェクト、Googleアカウント、AWSアカウント

用語の対応関係: 「アカウント」が指すものの違い

「アカウント」が指すものが GCP と AWS で異なっているというのが、GCP 経験者の方が AWS に入門する際の最大の障壁です。
本記事の目的の9割はこの1点の説明にあります。

GCP と AWS での「アカウント」に絡む用語の対応関係は以下のとおりです:

GCP	AWS	用途
GCP プロジェクト	AWS アカウント	クラウドリソースの管理単位
Google アカウント	IAM ユーザー	認証に使用するユーザー情報

AWS では「アカウント」は「ユーザーアカウント」の意味ではない ということを抑えておくと、AWS について他の人と話したり、AWS 関連の資料を読むときに理解しやすくなります。
AWS アカウントは請求の単位でもあるので、GCP での請求先アカウントと同じ意味の「アカウント」だと考えると理解しやすいかもしれません^[1]。

AWS で認証に使用するユーザーは「AWS ユーザー」とは言わず、「IAM ユーザー」という点もポイントです。「AWS ユーザー」という言葉もないわけではないようなのですが、「AWS の利用者」という意味合いの、認証とは関係のない文脈で使われます。

リソース管理単位と認証ユーザーの関係

リソースの管理単位(GCP プロジェクト/AWS アカウント)と、認証ユーザー(Google アカウント/IAM ユーザー)の対応関係が GCP と AWS では異なっています:

GCP では Google アカウントが GCP プロジェクト横断で利用できるのに対し、AWS では IAM ユーザーは各 AWS アカウント内に含まれる位置づけです。
このため複数の AWS アカウントを運用する場合、AWS アカウントごとに IAM ユーザーの作成をすることになります^[2]。

ここの相違は、Google アカウントが GCP 専用のものではなく Google のサービス全体で共通で利用するものであることも大きいと思います。

GCPプロジェクト、AWSアカウント関連

コンソール(WebUI)の違い

GCP ではクラウドコンソール、AWS では AWS コンソール、と呼び名が微妙に異なりますが、どちらのクラウドサービスでも Web ブラウザーでアクセスする管理画面が提供されます:

クラウドコンソール(GCP)	AWS コンソール(AWS)

2つのコンソールの大きな相違として、プロジェクト/アカウントの切り替えの挙動の違いがあります:

操作	GCP	AWS
コンソール上でのプロジェクト/アカウントの切り替え	可	不可(機能を提供しない)
別タブで複数プロジェクト/アカウントのコンソールを開く	可	不可(以前開いていたタブはサインアウトする)

AWS コンソールでは、同時に1つのアカウントのコンソールしか開けない仕様になっています。
別タブで別のアカウントのコンソールにサインインすると、以下のように元のコンソールはサインアウトさせられます。
「再ロード」を押すと、後からサインインしたアカウントのコンソールになります。

AWSコンソールが複数アカウントの同時操作をサポートしていないことは、コンソールの URL からも理解できます:

	クラウドコンソール(GCP)	AWSコンソール(AWS)
URL	https://console.cloud.google.com/welcome?project=PROJECT	https://REGION.console.aws.amazon.com/console/home?region=REGION
URL 内のパラメーター	プロジェクト名を含む	アカウント名を含ま ない

この仕様のため、AWS コンソールでは以下のようなことができません。これは運用の制約になりやすい点なので、注意が必要です:

• URL からコンソール内の特定の画面を直接開く
  • アカウントの選択 = サインイン操作を行ってからでないと開けない
• 異なるアカウントの同種のリソースの設定を並べて比較する。特に、費用詳細を比較するなどができない。
  • 異なるブラウザーを使う、プライベートタブを開く、といった対処が必要。

リージョンの扱いの違い

GCP、AWS ともに、ホスティングの場所を指定する「リージョン」という項目があります。

GCP に比べて AWS はリージョンで完全にサービスが分割される作りになっています。
例えば VPC ネットワークだと、以下のように違いが生まれます:

• GCP: VPC ネットワークはリージョン横断で作成されてその中でリージョンごとのサブネットワークを作る
• AWS: 最初にリージョンを決めて VPC ネットワークを作る

このAWSでの、リージョンの指定が真っ先にくる挙動はリソースの識別子からも理解できます。
GCPプロジェクト/AWSアカウントと、リージョンの上下関係、リソースの識別子の例をまとめると以下のようになります:

	GCP	AWS
リソースの管理単位とリージョンの関係	GCP プロジェクト > リージョン	リージョン > AWS アカウント
リソースの識別子の例	projects/PROJECT/regions/REGION/subnetworks/NAME	arn:aws:ec2:REGION:ACCOUNT:vpc/VPCID

IAM関連

GCP、AWS ともに、権限管理の設定は Identity and Access Management (IAM) というサービス(または機能)として提供されます。
名前は同じだけれども仕様は異なります。

IAM 関連の用語の対応表

考え方自体が異なるため正確な対応は難しいのですが、以下のように対応づけて考えることができます:

GCP	AWS	用途/例
Google アカウント	IAM ユーザー	利用者に対応付けて認証につかうもの 例: A さんがログインに使用する
サービスアカウント	IAM ロール	非属人的に運用するシステム権限 例: サーバーで処理を行うときの権限を決めるのに使う
ロール	IAM ポリシー	権限の集合に意味をもたせたもの 例: A さんに「Storage オブジェクト管理者」ロールを設定する (GCP) 例: 「特定の S3 バケットに書き込める権限」の IAM ポリシーを作る (AWS)
IAM ポリシー	(対応なし)	プロジェクト/リソースのIAM設定 例:「ユーザーAとユーザーBにOwnerロールを設定する」プロジェクト全体の設定 例: 「ユーザーAとユーザーBにオブジェクト管理者ロールを設定する」というGCSバケットに対する設定

特記するべき点として、 「ロール」「IAM ポリシー」が指すものが全く異なる ことに注意が必要です^[3]。

ただし上記の表の対応が必ずしも成立しない状況もあります。例えば GCP のサービスアカウントについて「(JSON キーでの)認証を行える」という点に着目した場合、対応する AWS の概念は IAM ユーザー(システムユーザーにあたる IAM ユーザーを作る)になります。
上記の表はかなり便宜的に対応付けをしたものなので、理解の一助程度に御覧ください。

リソースごとの権限設定

権限を設定する際には、サービス全体に対する権限を設定する場合と、サービス内の特定のリソースだけに権限を設定する場合があります。
GCP と AWS では、特定のリソースに対して権限を設定する方法が異なります:

	GCP	AWS
特定リソースへの権限設定	サービス・リソースの IAM ポリシーで設定	IAM ポリシーの Resource 要素でリソースを指定

例として、Google Cloud Storage / AWS S3 の特定のバケットに対する権限を設定することを考えます。
使用するコンソール画面は以下のとおりです:

実施する設定	GCP	AWS
すべてのバケットに対する権限設定	IAM & Admin > IAM で設定	IAM で設定
特定のバケットに対する権限設定	Cloud Storage > Buckets で設定	IAM で設定

設定単位の相違がわかりやすいので、Terraform で設定する際に使用するリソースも記載します:

実施する設定	GCP	AWS
すべてのバケットに対する権限設定	google_project_iam_*	aws_iam_policy aws_iam_user_policy_attachment
特定のバケットに対する権限設定	google_storage_bucket_iam_*	aws_iam_policy aws_iam_user_policy_attachment

特定バケットへの Terraform テンプレートの例:

特定 GCS バケットに対する権限設定

resource "google_storage_bucket_iam_member" "jane_is_bucket_admin" {
  bucket = "BUCKETNAME"
  role = "roles/storage.admin"
  member = "user:[e-mail]"
}

特定 S3 バケットに対する権限設定

resource "aws_iam_policy" "bucket_admin" {
  name        = "bucket_admin"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "s3:*",
        ]
        Effect   = "Allow"
        Resource = [
          # バケットと中のオブジェクト双方への権限を設定
          arn:aws:s3:::BUCKETNAME",
          arn:aws:s3:::BUCKETNAME/*",
        ]
      },
    ]
  })
}

resource "aws_iam_user_policy_attachment" "jane_is_bucket_admin" {
  user       = "jane"
  policy_arn = aws_iam_policy.bucket_admin.arn
}

これらの表の通り、GCP ではサービス全体の設定と特定リソースの設定で設定場所が異なるのに対し、AWS では常に同じ場所で設定を行います。これは以下のようにまとめられます:

• GCP ではサービスごとに IAM の機能を持つ。
  • あるユーザーがプロジェクトで持つ権限を追跡するには全サービスの IAM を参照する必要がある。
• AWS では権限設定はすべて「IAM」という単一のサービスに集約されている。
  • あるユーザーがアカウントで持つ権限を追跡するには IAM の設定を見るだけで十分。

IAMロールとassumeRole

GCP では以下のような場面でサービスアカウントを使用します:

• 複数人で共有管理する機能、例えばCI/CDなどの自動処理で非属人的に権限を管理して処理を実行したい。
• GCE インスタンスなどサービス提供目的で起動するリソースでの処理実行の権限を管理したい。

AWS ではこれに対応する設定は IAM ロールです。

GCP で サービスアカウントの権限を利用する際には JSON キーを発行して認証に使用します。
それに対し、AWS で IAM ロールの権限を利用する際には assumeRole と呼ばれる操作を使用します。
IAM ロールの権限で API を実行する際の手順は以下のようになります:

1. アクセスキーID / シークレットアクセスキー (AWS で発行される認証情報) を使用して IAM ユーザーの権限を得る。
2. IAM ユーザーの権限で sts:assumeRole API を実行し、 IAM ロールの権限を得る。
3. IAM ロールの権限で API を実行する。

assumeRole の実行ができるように設定するには、2箇所での設定が必要で、この部分がサービスアカウントよりも設定が複雑になります:

1. 「assumeRole を実行する側」で、 sts:assumeRole の実行を許可する。
2. 「assumeRole によって権限を移譲する側」で、 sts:assumeRole の実行元を許可する。 (信頼ポリシー)

IAM ロールを使用する背景として、IAM ユーザーでは認証に必要なアクセスキーID / アクセスキーシークレットを2つまでしか発行できないという点もあります。
複数の利用者で IAM ユーザー自体を共有しようとすると認証情報の共有が必要となるため、各利用者の IAM ユーザー から IAM ロールを経由することで、認証情報の共有を行うことなく権限管理を共有できるメリットを得られます。

また、IAMロールを用途によって使い分けることで、誤った操作を行うリスクを下げるメリットを得ることもできます。

比較まとめ表

項目	GCP	AWS	備考・ポイント
クラウドリソースの管理単位	GCP プロジェクト	AWS アカウント	「アカウント」が意味するものが違う
認証に使用するユーザー情報	Google アカウント	IAM ユーザー	「アカウント」が意味するものが違う
リソース管理単位と認証ユーザーの関係	Google アカウントは GCP プロジェクト横断	IAM ユーザーは AWS アカウントに所属する
コンソール(WebUI)	異なるプロジェクトのコンソールを同時に開ける	異なるアカウントのコンソールを同時に開けない
リージョンの扱い	GCP プロジェクト > リージョン	リージョン > AWS アカウント
非属人的な権限主体	サービスアカウント	IAM ロール	「ロール」が意味するものが違う
権限の集合	ロール	IAM ポリシー	「ロール」が意味するものが違う/「IAM ポリシー」が意味するものが違う
権限設定	IAM ポリシー	(対応なし)	「IAM ポリシー」が意味するものが違う
特定リソースへの権限設定	リソースのIAMポリシーで設定	IAMポリシーのResource要素でリソースを指定
権限の管理場所	プロジェクト単位とサービス単位	アカウント単位
非属人的な権限主体の利用方法	JSON キーによる認証	assumeRoleによる認証

脚注

1. 複数の AWS アカウントの請求を AWS Organizations でまとめられるので、その意味では GCP の請求先アカウントに対応するのは AWS Organizations になる。

2. それではあまりにも大変なので、実際にはスイッチロールによるクロスアカウントのコンソール切り替えや、SAML2.0 フェデレーションによる外部 IdP による認証 を使用して運用する…けれどややこしいので割愛

3. ただ GCP の運用で「IAM ポリシー」って言うことが少ない気がするので、IAM ポリシーについてはあまり混乱の原因にはならない気がする。この対応表を作って「あ、そういえば GCP でも IAM ポリシーって言葉あるわ」って思ったくらいなので。