【AWS初学者向け】IAMとは何か分かりやすく徹底解説

AWS認定試験の合格に必要な知識を確認します。

はじめに

AWSを活用する上で，最初の難関となるのが「IAM」です。非常に詳しいドキュメントが用意されている一方で，様々な概念が複雑に絡み合っているため，多くの人にとってはIAMを理解することがストレスになると思います。カタカナ語がたくさん登場するため，用語の表層的なイメージから誤解を生みやすい構造にあることが，IAMの理解が進みにくいことの原因の一つだと筆者は考えています。

そこで，本項ではAWS初学者を対象として，難解なIAMの概念を一つずつ紐解いていこうと思います。筆者は難解な概念を理解するときには，最初のうちは多少の間違いを許容してでも概念の大枠やお気持ちを把握することに努めるべきだと考えています。最初から細かい部分まで詰めようとすると，精神的にもかなりしんどいですし，往々にして途中で挫折してしまうケースもあるでしょう。大きな山を登るとき，がむしゃらに目の前の道を全力で駆け上がるのではなく，まずは地図を読んで山の形状を把握するイメージです。

所々で語弊を恐れずに表現してしまう箇所がtありますが，何卒ご理解いただけますと幸いです。致命的な誤解がありましたら，記事最下部のコメント欄よりご指摘ください。

概念・用語のざっくり理解

本章では，IAMにまつわり概念・および関係性をざっくりと理解することを目指します。概念の関係性を図に表すと，以下のようになります。

上図からは「セッション」の概念をスコープアウトしています。セッションは，AssumeRoleの概念を語る際に欠かせない概念なのですが，全体像を掴む上では必須ではないと筆者は考えています。

上図で登場する概念を語弊を恐れずに一言でまとめると，下記のようになります。

本稿では，ユーザーを「ユーザ」と表記しますが，深い意図はありません。

用語解説

各概念のイメージが掴めたところで，それぞれの概念をもう少し詳しめに確認しましょう。

IAM

IAMを使用すると，AWSのサービスやリソースにアクセスできるユーザーやグループを指定し，きめ細かいアクセス許可を一元管理し，AWS全体でアクセス許可を改善することができます

AWS Identity and Access Management (IAM) より一部抜粋

後ほど「IAMとは何か」については確認します。

ルートユーザ

すべてのAWSサービスとリソースに対して完全なアクセス権限を持つアイデンティティ

AWS アカウントのルートユーザー より一部抜粋

ルートユーザは，AWSのアカウントを作成した人間のことを指します。AWSを使うためには，他の一般的なサービスと同様に，まずはアカウントを作成する必要がありますが，はじめに作成したこのアイデンティティをルートユーザとよびます。

パワーユーザ

パワーユーザーはアプリケーション開発タスクを実行し，AWS 対応アプリケーションの開発をサポートするリソースとサービスを作成および設定できます。

AWSジョブ機能の管理ポリシー より一部抜粋

ざっくりと，パワーユーザはIAMとアカウント管理以外の全ての操作を行うことができるIAMユーザのことを指します。

IAMユーザ

AWS Identity and Access Management (IAM) のユーザーとは，AWSで作成したエンティティのことです。IAMユーザーは，AWSとやり取りするためにIAMユーザーを使用する人間のユーザーまたはワークロードを表します。

IAM ユーザー より一部抜粋

日本語が難しいですが，IAMユーザ=エンティティではないことに注意です。

IAMグループ

IAMユーザーグループとは，IAMユーザーの集合です。

IAMユーザーグループ より一部抜粋

IAMグループの正式名称はIAMユーザグループです。

IAMポリシー

IAMポリシーは，アイデンティティやリソースにアタッチしてそのアクセス許可を定義する，AWSの JSONポリシードキュメントです。

AWSリソースのアクセス管理 より一部抜粋

アクセス許可を定義するJSONという部分が特に大切です。

IAMロール

IAMロールは，特定の許可があり，アカウントで作成できるもう1つのIAMアイデンティティです。

IAMロール より一部抜粋

「もう1つの」というのは，IAMユーザに加えてもう1つという意味です。

アイデンティティ

識別とグループ化に使用されるIAMリソースオブジェクトで，ユーザー，グループ，およびロールが含まれます。

IAMの仕組み より抜粋

IAMアイデンティティというのは，IAMユーザ・グループ・ロールを指していると理解すればOKです。

リソース

IAMに保存されているユーザー，グループ，ロール，ポリシー，および ID プロバイダー。

IAMの仕組み より抜粋

IAMリソースは，IAMで管理するAWSリソースのことを指します。

プリンシパル

AWSアカウントのIAMユーザー，IAMロールを使用してサインインしAWSへのリクエストを行う人またはアプリケーション，フェデレーションユーザーと引き受けたロールが含まれます。

IAMの仕組み より抜粋

プリンシパルは，エンティティ＋AWSリソースと捉えればOKです。

AssumeRole

Returns a set of temporary security credentials that you can use to access AWS resources.

AssumeRole より一部抜粋

AssumeRoleは，IAMロールに対して一時的なセキュリティトークンを取得し，そのロールが持つアクセス権限を一時的に継承する操作を指します。

PassRole

ユーザーがAWSサービスにロールを渡すには，IAM ユーザー，ロール，またはグループにPassRoleアクセス許可を付与する必要があります。PassRoleはAPI呼び出しではありません。PassRoleはアクセス許可です。

AWSのサービスにロールを渡すアクセス権限をユーザーに付与する より一部抜粋

PassRoleはアイデンティティがAWSリソースにロールを渡すためのアクセス許可を指します。RoleのARNを渡すためのアクセス許可と捉えてもよいでしょう。AssumeRoleとは異なり，PassRoleというAPIが存在する訳ではありません。

SwitchRole

ロールを切り替えると，元のユーザーアクセス権限が一時的に無効になり，そのロールに割り当てられたアクセス権限が代わりに付与されます。常に元の認証情報を使用して切り替えを認証します。

ロールの切り替え (コンソール) より一部抜粋

SwitchRoleは単にロールを切り替えるという操作を指します。AssumeRoleとは異なり，SwitchRoleというAPIが存在する訳ではありません。

信頼ポリシー

信頼ポリシーでは，ロールを引き受けることができるプリンシパルを定義します。

IAMでのポリシーとアクセス許可 より一部抜粋

信頼ポリシーは，IAMポリシーの一種です。特に，ロールを引き受けることができるプリンシパルを定義するポリシーを指します。

IAMとは

各用語のイメージと詳細が把握できたところで，改めて「IAMとは何か」を考えていきたいと思います。AWSでは，あるプリンシパルが特定のAWSリソースに対してアクセスするプロセスを，IAMという仕組みを用いて体系的に制御しています。IAMとは何かを一言でまとめると，「プリンシパルが認証・認可を通じてAWSリソースに適切なアクションを行う仕組み」となります。各フェーズを一つずつ見ていきましょう。

プリンシパル

上でも述べた通り，プリンシパルはIAMユーザ・IAMロール・AWSリソースのことを指します。

プリンシパルと混同しやすい概念に，アイデンティティがあります。IAMアイデンティティというのは，IAMユーザ・IAMグループ・IAMロールのことを指します。IAMグループはプリンシパルに属さずに，アイデンティティに属することに注意してください。

認証

プリンシパルはAWSリソースにリクエストを送出する主体となる訳ですが，その正当性を確認する必要があります。この行為を「認証」とよびます。AWSでは，プリンシパルの認証を行うために，以下二つのいずれかが利用されます。

固定されたアクセスキーID/シークレットアクセスキーのペアを用いると，ID/シークレットが漏洩するリスクが高まるだけでなく，仮に漏洩してしまった場合にも不正利用のリスクが高まります。そこで，AWSではSTSによる一時的なセッション情報に基づいたアクセス制御をベストプラクティスとして推奨しています。

STSというのは，AWSによる一時的なセキュリティ認証基盤のことを指します。STSを利用すれば，一時的なアクセスキーID/シークレットアクセスキーを発行することができるのです。実際には，ID/シークレットのペアは有効期限の情報が付け加えられたセッションとして提供され，IAMロールによってプリンシパルと紐づけられます。

セキュリティを強化させるプラスアルファの要素として，MFA tokenがあります。MFAは多要素認証のことを指し，Multi Factor Authenticationの頭文字を取った略称です。MFAでは，スマホなどの物理的なデバイスに基づいて認証を行うため，プリンシパルの正当性をより厳密に確認することができます。

認可

プリンシパルの認証が完了すると，次はそのプリンシパルが行おうとしているアクションの正当性を確認する必要があります。この行為を「認可」とよびます。AWSでは，プリンシパルが行おうとしているアクションの認可を行うために，IAMポリシーが用いられます。認可に関しては，後ほどIAMポリシーの種類と評価ロジックに関して詳しくみていきます。

AWSリソース

認証・認可されたプリンシパルは，最終的にAWSリソースへのアクセスが可能になります。AWSのIAMでは，このような流れで正当なプリンシパルに適切なアクセス権限を付与しています。プリンシパルにはAWSリソースも含まれますので，IAMではAWSリソースからAWSリソースへのアクセス制御も行います。

IAMポリシー

IAMポリシーは，認可のフェーズにおいて具体的なアクセス許可を定義するJSONのことを指します。

AWSのドキュメントでは，「アクセス許可」という用語と「権限」という用語が混用されています。両者には明確な定義の違いがある訳ではないため，差し当たりは同じ概念を指すと捉えて問題ありません。権限という用語はアクセス許可という用語を内包しているとも考えられますが，権限には許可と拒否しかないことを踏まえると，許可が拒否の裏返しであると捉えればアクセス許可という用語で権限自体を表現できてしまっているのです。

IAMアイデンティティやIAMリソースに関連付けてアクセス許可を実現しますが，IAMポリシーはIAMロールにアタッチされることが多いです。初学者は，まずはこの「IAMポリシーはIAMロールやIAMユーザにアタッチされる」という部分をおさえてください。ただし，IAMポリシーはIAMグループにもアタッチすることができ，IAMグループに属するIAMユーザには同じIAMポリシーが適用されます。

本当にざっくりと理解するならば，IAMロールはIAMポリシーの集合だと捉えてもらって最初のうちは問題ないと思います。冒頭のイラストでいうと，王冠がIAMロールを表し，王冠にはめるバッジがIAMロールを表しています。

繰り返しますが，IAMポリシーはIAMロールだけでなく，IAMユーザやIAMグループにもアタッチできます。あくまでも，ここではIAMポリシーでアクセス許可の詳細を定義し，IAMポリシーを他の概念に紐づけることでアクセス許可の制御を実現するという部分を理解してください。IAMポリシーをバッジと捉え，王冠であるIAMロールにはめるというイメージを持つことで，この構造の理解が促進されると考えています。

IAMポリシーはJSONで記述されますが，一つのJSONは複数のStatementから構成され，一つのStatementには複数のフィールドが定義されます。

Statementで定義されるフィールドを可視化すると，下図のようになります。

Statementで定義されるフィールドをもう少し詳しく説明しておきます。

AWS初学者は，特にResourceの意味合いに注意してください。私はAWSを学び初めの頃，IAMポリシーにおけるResourceを「Actionの作用元」と誤解していました。例えば，IAMユーザAに対してEC2の削除を否定するIAMポリシーでは，ResouceにIAMユーザAを指定するのではなく，EC2を指定します。

解像度を上げるために，具体例としてルートユーザとパワーユーザのIAMポリシーを見てみましょう。ルートユーザには，下記のAdministratorAccessという管理ポリシーがアタッチされています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

全てのResourceに対して全てのActionをAllowするという恐ろしいポリシーです。

パワーユーザには，下記のPowerUserAccessという管理ポリシーがアタッチされています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization",
                "account:ListRegions"
            ],
            "Resource": "*"
        }
    ]
}

iam・organizations・account以外をAllowしつつ，これらの中でも例外として一部権限をAllowしています。

IAMポリシーの種類

IAMポリシーには，下記のような種類があります。

アクセスコントロールポリシーは，唯一JSONで記述されません。

これらを一緒くたにして理解するのは難しいので，下記のように構造化して捉えましょう。

「アクセス許可の境界かSCPでガードレールを設定し，アイデンティティベースのポリシーかリソースベースのポリシーで実際のアクセス許可を制御する。オプションとして，ACLやセッションポリシーを使うことがある。」と理解しておけば十分です。アイデンティティベースのポリシーかリソースベースのポリシーで許可しても，ガードレールで許可していないとアクセスは許可されない点がポイントです。

ACLはS3やVPCに用途が限られています。セッションポリシーは，アイデンティティベースのポリシーとリソースベースのポリシーだけでは実現できない細やかな制御のために利用されます。これらはオマケと捉えましょう。また，リソースベースポリシーに含まれるVPCエンドポイントポリシーもガードレールとして機能します。

アイデンティティベースのポリシー

アイデンティティ（ユーザ・グループ・ロール）にアタッチされるポリシーを，アイデンティティベースのポリシーとよびます。アイデンティティにアタッチされてプリンシパルは自明であることから，アイデンティティベースのポリシーではプリンシパルは省略されます。

アイデンティティにはIAMロールが含まれますが，IAMロールにアタッチしてAssumeの許可を制御するIAMポリシーは信頼ポリシーとよばれ，リソースベースのポリシーに分類されます。つまり，IAMロールにアタッチされるIAMポリシーには，Assumeの許可を制御する信頼ポリシーと，そのIAMロールがアタッチされたプリンシパルのアクセス許可を制御するアイデンティティベースのポリシーの二種類がアタッチされているということです。

信頼ポリシーはIAMロールに対して1つだけアタッチすることができます。

アイデンティティベースのポリシーは，独立して管理される管理ポリシーと，特定のアイデンティティ専用のインラインポリシーに分けられます。具体的には，マネコンからIAMポリシーの一覧に出てくるポリシーは管理ポリシー，特定のアイデンティティにアタッチされてマネコンのIAMポリシーの一覧には出てこないポリシーはインラインポリシーとなります。管理ポリシーはさらにAWS管理ポリシーとカスタマー管理ポリシーに分けられます。その名の通り，AWS管理ポリシーはAWSがデフォルトで管理している管理ポリシー，カスタマー管理ポリシーはカスタマーが独自に定義した管理ポリシーのことを指します。管理ポリシーとインラインポリシーはORで評価されます。

リソースベースのポリシー

リソースにアタッチされるポリシーを，リソースベースのポリシーとよびます。上でも述べた通り，リソースベースのポリシーのうち，IAMロールにアタッチされるAssumeRoleに特化したポリシーを信頼ポリシーとよびます。アイデンティティベースのポリシーとの違いは，ポリシーのアタッチ先とアクセス許可の対象が異なる点です。アイデンティティベースのポリシーではプリンシパルが自分自身であることから省略されますが，リソースベースのポリシーではプリンシパルを設定することができます。

※1はユーザ・グループ・ロール，※2はユーザ・ロール・リソースを表します。また，全てのリソースがリソースベースポリシーに対応している訳ではありません。

アクセス許可の境界

アクセス許可の境界は，その名の通りエンティティのアクセス許可の上限を定めるガードレールです。ガードレールは「仮に指定されていたとしたらアクセス許可」する権限を定めます。例えば，アクセス許可の境界でEC2を削除する権限を許可している場合には，アイデンティティベースのポリシーでEC2を削除する権限を付与できます。一方で，アイデンティティベースのポリシーでEC2を削除する権限をアタッチしたとしても，アクセス許可の境界で許可されていなければ拒否されてしまいます。アクセス許可の境界では，リソースベースのポリシーに対する上限は定められません。

サービスコントロールポリシー（SCP）

SCPはアクセス許可の境界と同じく，アクセス許可の上限を定めるガードレールです。アクセス許可の境界とSCPの違いとしては，前者はエンティティ単位で上限を定めるのに対し，後者はAWS OrganizationsのOU（Organizational Unit）単位で上限を定めます。アクセス許可の境界と同じく，SCPでアクセスが許可されていないと，アイデンティティベースのポリシーで許可したとしても拒否されてしまいます。ただし，アクセス許可の境界とは異なり，SCPではリソースベースのポリシーに対する上限も定めることができます。

アクセスコントロールポリシー（ACL）

ACLは主にS3やVPCで利用されるアクセス制御方式ですが，S3においては非推奨となっています。他のポリシータイプとは異なり，ACLはJSONで記述せずに単なるアクセス設定項目のリストとして設定します。

セッションポリシー

前提として，エンティティがAssumeRoleすると，主体がエンティティからセッションに変わります。このセッションはロールのポリシーを引き継ぎますので，基本的にはAssumeRoleするロールにアタッチされたポリシーとセッションで制御されるポリシーは同じになります。セッションポリシーは，AssumeRoleした後のセッションに対してアクセスを制御するためのポリシーになります。IAMロールだけでは設定できない細かなアクセス制御を実現できます。

評価ロジック

前提として，IAMポリシーはデフォルトでアクセスを拒否します。これを「暗黙的なDeny」といいます。対して，IAMポリシー内でAllowすることを「明示的なAllow」といい，IAMポリシー内でDenyすることを「明示的なDeny」といいます。これら三者の優先順位は，

暗黙的なDeny < 明示的なAllow < 明示的なDeny

となります。この前提のもと，各種IAMポリシーが順番に評価されていきます。これ以降，オプションとして捉えられるACLとセッションポリシーは除外して考えていきます。

全体像が見えたところで，詳細に踏み込んでいきましょう。IAMの評価ロジックでは，まずSCPによってOU単位でアクセス許可の上限を定めます。

実際にアクセス許可を定めるのは，リソースベースのポリシーとアイデンティティベースのポリシーでした。この際，SCPはアクセス許可の上限を定めるガードレールとして機能するため，SCPとリソースベースのポリシー・アイデンティティベースのポリシーはAND条件を用いて評価されます。つまり，SCPで許可されているアクセス権限のみがリソースベースのポリシーとアイデンティティベースのポリシーで許可されるということです。

アイデンティティベースのポリシーは，管理ポリシーとインラインポリシーに分けられます。これらはあくまでも管理方法が異なるだけで，アクセス許可を定めるという目的は同じですので，OR条件で評価されます。

アクセス許可の境界は，アイデンティティベースのポリシーのガードレールとして機能します。SCPと同様に，アイデンティティベースのポリシーとのAND条件で評価されます。

残りの観点としては，リソースベースのポリシーとアイデンティティベースのポリシーがどのように組み合わせて評価されるかですが，これは同一アカウント内でのアクセス制御とクロスアカウントでのアクセス制御で異なります。

同一アカウントの場合

同一アカウントの場合，基本思想は「単方向のアクセス許可で十分」となります。これをIAMポリシーの種類を用いて実現すると，アイデンティティベースのポリシーもしくはリソースベースのポリシーでAllowされていれば，アクセス許可が実現されることになります。

クロスアカウントの場合

クロスアカウントの場合，基本思想は「双方向のアクセス許可が必要」となります。これをIAMポリシーの種類を用いて実現すると，アイデンティティベースのポリシーかつリソースベースのポリシーでAllowされていれば，アクセス許可が実現されることになります。

FAQ

アイデンティティベースのポリシーとリソースベースのポリシーの違いは？

ポリシーのアタッチ先・アクセス許可の対象・管理方法が異なります。アイデンティティベースのポリシーでは，アタッチ先はIAMユーザ・IAMグループ・IAMロールとなります。一方，リソースベースのポリシーでは，アタッチ先はAWSリソースとなります。また，アイデンティティベースのポリシーでは，アクセス許可の対象はIAMユーザ・IAMグループ・IAMロールとなります。一方，リソースベースのポリシーでは，アクセス許可の対象はIAMユーザ・IAMロール・AWSリソースとなります。また，アイデンティティベースのポリシーでは，IAMポリシーの管理方法は管理ポリシーとインラインポリシーとなります。一方，リソースベースのポリシーでは，IAMポリシーの管理方法はインラインポリシーのみとなります。

スクロールできます

ベース	アタッチ先	アクセス許可の対象	管理方法
アイデンティティ	アイデンティティ ※1	アイデンティティ ※1	管理ポリシー インラインポリシー
リソース	リソース	プリンシパル ※2	インラインポリシー

※1はユーザ・グループ・ロール，※2はユーザ・ロール・リソースを表します。

アクセス許可の境界とサービスコントロールポリシー（SCP）の違いは？

アクセス許可の境界はエンティティ単位で上限を定めるのに対し，SCPはOrganizational Unit単位で上限を定めます。アクセス許可の境界と同じく，SCPでアクセスが許可されていないと，アイデンティティベースのポリシーで許可したとしても拒否されてしまいます。ただし，アクセス許可の境界とは異なり，SCPではリソースベースのポリシーに対する上限も定めることができます。

スクロールできます

	単位	対象	ポリシータイプ
アクセス許可の境界	エンティティ	エンティティ	アイデンティティベース
SCP	OU	エンティティ	アイデンティティベース リソースベース

AssumeRole・PassRole・SwitchRoleの違いは？

AssumeRoleはRoleを引き受けるためのAPI，PassRoleはRoleを渡すための権限，SwitchRoleはRoleを入れ替える操作のことを指します。PassRoleとSwitchRoleはAPIの名前ではないことに注意してください。

付録

IAMでは，耐障害性を担保するための設計として，コントロールプレーンとデータプレーンという概念が存在します。概念図は下記の通りです。

公式ドキュメントをベースに，上図を説明していきます。まず，耐障害性を担保する動機を説くため，IAMの重要性に関して以下のような記述があります。

AWSで行うすべての操作は，IAMによって認証および認可される必要があります。各リクエストを保存されているIDとポリシーに照らし合わせて確認し，リクエストが許可されるか拒否されるかを判断します。

AWS Identity and Access Managementでの耐障害性 より一部抜粋

続いて，コントロールプレーンとデータプレーンについて言及します。コントロールプレーンがプライマリやWriter，データプレーンがレプリカやReaderと捉えられると理解が促進されます。

IAMはコントロールプレーンとデータプレーンを分離して設計されているため，予期しない障害が発生した場合でもサービスが認証されます。コントロールプレーンとデータプレーンの両方がダウンタイムゼロを目指して構築され，すべてのソフトウェア更新とスケーリング操作が顧客には見えない方法で実行されます。

AWS Identity and Access Managementでの耐障害性 より一部抜粋

次に，コントロールプレーンの説明が続きます。RDS・ElasticacheのPrimary・Writerと同様に，IAMリソースの設定変更はコントロールプレーンで行われ，全リージョンのPrimary情報をバージニア北部（us-east-1）で一元管理しているとのことです。

ロールやポリシーなど，認可に使用されるIAMリソースはコントロールプレーンに保存されます。お客様は，IAMオペレーションを使用してこれらのリソースの設定を変更できます。これらの設定変更のリクエストは，コントロールプレーンに送られます。IAMのコントロールプレーンは，すべての商用AWSリージョン を対象とし，米国東部（バージニア北部）リージョンに 1 つ設置されています。

AWS Identity and Access Managementでの耐障害性 より一部抜粋

IAMにはリージョン別のエンドポイントは存在せず，us-east-1に単一のグローバルエンドポイントのみを持ちます。これは，IAMでは全リージョンのPrimary情報をバージニア北部（us-east-1）で一元管理していることの裏付けとなるでしょう。

グローバルサービスではリージョンがサポートされていません。以下のサービスには，それぞれ1つずつグローバルエンドポイントがあります。

• AWS Identity and Access Management (IAM)

AWSサービスエンドポイント より一部抜粋

最後に，データプレーンの説明です。RDS・ElasticacheのReplica・Readerと同様に，データプレーンはコントロールプレーンの読み取り専用のレプリカインスタンスとのことで，少なくとも3AZで冗長化され，各リージョンごとに読み取り処理を行うとのことです。

IAMシステムは，有効化されたすべてのAWSリージョンのIAMデータプレーンに設定変更を伝達します。データプレーンは，基本的にIAMコントロールプレーンの設定データの読み取り専用レプリカです。各AWSリージョンには，データプレーンの完全に独立したインスタンスがあり，同じリージョンからのリクエストに対して認証と認可を実行します。各リージョンでは，データプレーンは少なくとも 3 つのアベイラビリティーゾーンに分散されており，アベイラビリティーゾーンの損失を許容する十分な容量があり，顧客に障害を与えることはありません。

AWS Identity and Access Managementでの耐障害性 より一部抜粋

参考文献

• IAM Black Belt part1｜AWS公式
• IAM Black Belt part2｜AWS公式