【AWS Certified Cloud Practitioner】AWSのユーザー認証を整理して理解する：IAM・IAM Identity Center・Cognito・Directory Serviceの違いを解説

2026年4月5日

AWSのユーザー認証を整理して理解する：IAM・IAM Identity Center・Cognito・Directory Serviceの違いをCloud Practitioner向けに解説

AWS Certified Cloud Practitionerでは、認証やアクセス管理に関するサービスがよく出題されます。ただし、似た名前のサービスが多く、初学者は「どれが誰向けの認証なのか」で混乱しやすい分野です。

そこで本記事では、AWSにおけるユーザー認証を「誰が」「何に」ログインするのかで整理し、代表的なサービスの違いを比較しながら分かりやすく解説します。試験対策としてはもちろん、実務でのイメージづくりにも役立つ構成にしています。

最初に結論：誰が何にログインするかで見分ける

AWSの認証系サービスは、まず次のように切り分けると理解しやすくなります。

サービス	主な対象	主な用途	試験での押さえどころ
AWSアカウントのルートユーザー	AWSアカウント所有者	アカウント作成直後の初期管理、特権操作	日常利用しない。MFAで厳重保護する
IAM	AWS内の人・システム	AWSリソースへの認可、ポリシー管理、ロール管理	認証だけでなく認可の中心
IAM Identity Center	社内ユーザー、管理者、開発者	AWSアカウントや業務アプリへのSSO	複数アカウントへの従業員向けログインに最適
Amazon Cognito User Pools	Web/モバイルアプリの一般ユーザー	会員登録、サインイン、MFA、ソーシャルログイン	自社アプリの利用者認証
Amazon Cognito Identity Pools	アプリ利用者	AWSへの一時認証情報の払い出し	アプリ利用者にS3などを使わせたい時
AWS Directory Service	Active Directory利用企業	既存ADとの連携、Windows系ワークロード	AD統合用途。Cognitoとは役割が違う
AWS STS	人・アプリケーション両方	一時的な認証情報の発行	ロール利用や一時認証情報の基盤

要するに、社内ユーザーがAWSへ入るなら IAM Identity Center、一般ユーザーが自社アプリへ入るなら Amazon Cognito、AWSの権限管理そのものは IAM と STS、既存のActive Directoryを活かしたいなら AWS Directory Service、という整理が基本です。

まず押さえたい前提：認証と認可の違い

AWSでは「認証」と「認可」を分けて考えることが大切です。

認証：その人やシステムが誰なのかを確認すること
認可：確認できた相手に何を許可するかを決めること

たとえば、社内の開発者がAWSコンソールにログインできたとしても、S3だけ見られるのか、EC2も操作できるのか、請求情報まで見られるのかは別問題です。この「何ができるか」を決める中心がIAMです。

公式ドキュメントでも、IAMは認証された主体に対してAWSリソースへのアクセス権を管理する基盤として説明されています。参考：https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

AWSアカウントのルートユーザー：最初に作られる特別なログイン

AWSアカウントを作成すると、最初に作られるのがルートユーザーです。これはそのAWSアカウントに対する最上位の権限を持つ特別な存在です。

ただし、試験でも実務でも重要なのは、ルートユーザーは日常業務で使わないという点です。AWSは、ルートユーザーの認証情報を厳重に保護し、ルートユーザーにしかできない作業に限定して使うことを強く推奨しています。また、MFAの有効化も重要です。

日常的な管理作業には使わない
MFAを有効にする
アクセスキーを作成しない
本当に必要な時だけ使う

Cloud Practitionerでは、「最も強い権限を持つのはルートユーザーだが、普段は使わない」という原則を押さえておくと得点しやすくなります。参考：https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html

IAM：AWSのアクセス制御の土台

AWS Identity and Access Management（IAM）は、AWSリソースへのアクセス権を管理する中核サービスです。ユーザー、グループ、ロール、ポリシーを使って「誰に何を許可するか」を制御します。

IAMで覚えるべき基本要素

IAMユーザー：個別のユーザーアカウント
IAMグループ：複数ユーザーをまとめる単位
IAMポリシー：権限ルール
IAMロール：人やサービスが一時的に引き受ける権限

IAMユーザーは今どう考えるべきか

以前は、AWS利用者ごとにIAMユーザーを作る構成もよく見られました。しかし現在のAWS公式ベストプラクティスでは、人間ユーザーにはフェデレーションと一時認証情報を使うことが推奨されています。つまり、社内ユーザーにIAMユーザーを大量発行するより、IAM Identity Centerや外部IdP連携を使うほうが基本です。

そのため試験では、IAMユーザーが完全に不要というわけではありませんが、「人間ユーザーの標準的な運用はIAM Identity Centerやフェデレーション寄り」という認識を持っておくと整理しやすくなります。参考：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html / https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html / https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

IAMロールが特に重要な理由

IAMロールは、EC2、Lambda、ECSなどのAWSサービスや、人間ユーザーが一時的に引き受ける権限です。長期固定のアクセスキーを埋め込まずに済むため、セキュリティ上とても重要です。

たとえば、EC2上のアプリケーションがS3へ画像を保存する場合、アクセスキーをアプリに書くのではなく、EC2にIAMロールを付けてS3への権限を与えます。これはCloud Practitionerでも非常に基本的な考え方です。

AWS STS：一時認証情報を発行する仕組み

AWS STS（Security Token Service）は、一時的なセキュリティ認証情報を発行するサービスです。IAMロールを引き受けると、期限付きの認証情報を受け取れます。

この仕組みにより、長期のアクセスキーを配布しなくても、必要な間だけ安全にAWSリソースへアクセスできます。AWSも、一時認証情報の利用を推奨しています。

試験では、次のような理解が重要です。

一時認証情報は長期認証情報より安全性が高い
ロールの利用とSTSは密接に関係する
クロスアカウントアクセスでも使われる

参考：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

IAM Identity Center：社内ユーザー向けのSSOサービス

AWS IAM Identity Centerは、従業員や管理者などのワークフォースユーザーが、複数のAWSアカウントや対応アプリケーションへシングルサインオンするためのサービスです。

以前はAWS Single Sign-Onという名称で知られていたため、過去資料ではSSOという言い方が残っていることがありますが、現在の正式名称はIAM Identity Centerです。

どんな場面で使うか

社内の開発者が複数AWSアカウントへログインする
管理者がAWS Organizations配下の複数アカウントをまとめて運用する
OktaやMicrosoft Entra IDなど既存のIdPと連携する
AWSコンソールだけでなくAWS CLIにも同じ認証基盤を使う

具体例

たとえば、ある会社が「開発用アカウント」「検証用アカウント」「本番アカウント」に分けてAWSを使っているとします。このとき、各社員に各アカウント分のIAMユーザーを作るのではなく、IAM Identity Centerで一元的にログインさせ、必要なアカウントに必要な権限だけを割り当てる構成が自然です。

試験での見分け方

問題文に「従業員」「複数AWSアカウント」「SSO」「既存IdP連携」といった語が出てきたら、IAM Identity Centerが正答候補になりやすいです。

参考：https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html / https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Amazon Cognito：アプリ利用者向けの認証基盤

Amazon Cognitoは、Webアプリやモバイルアプリの利用者を認証するためのサービスです。社内管理者ではなく、サービスの会員や顧客をログインさせる用途に向いています。

この点がIAM Identity Centerとの最大の違いです。

Cognito User Pools：会員登録やログインの中心

Cognito User Poolsは、アプリ利用者のユーザーディレクトリです。サインアップ、サインイン、パスワード管理、MFA、ソーシャルログイン、SAML/OIDC連携などを扱えます。アプリ側から見ると、OpenID ConnectのIdPのように使えます。

向いている例

会員制Webサイト
スマホアプリのログイン機能
メールアドレスやパスワードでの登録機能
GoogleやAppleアカウントを使ったログイン

また、Cognitoにはマネージドログイン画面もあり、ログインUIを一から作り込まなくても利用できます。参考：https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools.html / https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-managed-login.html / https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-social-idp.html

Cognito Identity Pools：AWSリソースを使わせるための橋渡し

Cognito Identity Poolsは、認証済みまたは未認証のアプリ利用者に対して、一時的なAWS認証情報を払い出す仕組みです。つまり、アプリ利用者にS3や他のAWSリソースを使わせたい時に役立ちます。

向いている例

ログインした利用者が画像をS3へ直接アップロードする
ゲストユーザーにも一部のAWSリソース閲覧を許可する
利用者の属性に応じて異なるAWS権限を与える

たとえば、写真投稿アプリでユーザーがログイン後に画像をアップロードする場合は、Cognito User Poolsで認証し、その後Identity Poolsを通じて一時認証情報を払い出してS3にアップロードさせる、という構成が典型です。

参考：https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html / https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html

API GatewayやALBと組み合わせるイメージ

Cognito User Poolsは、API Gatewayのオーソライザーとして使うことができます。利用者がログインして取得したトークンをAuthorizationヘッダーに付けてAPIを呼び出す、という形です。

また、Application Load Balancerと連携して、アプリ本体ではなくロードバランサー側で認証を処理する構成も可能です。こうした連携を知っておくと、Cognitoの役割がより具体的に見えてきます。

参考：https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html / https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html

AWS Directory Service：既存のActive Directoryを使いたい時の選択肢

AWS Directory Serviceは、Microsoft Active Directory（AD）をAWS環境で利用したい企業向けのサービス群です。CognitoがWebアプリの会員認証向けなのに対し、Directory Serviceは企業ディレクトリ連携に強いのが特徴です。

AWS Managed Microsoft AD

AWS Managed Microsoft ADは、AWS上でマネージドなMicrosoft Active Directoryを提供するサービスです。AWSが高可用なドメインコントローラー、監視、復旧、レプリケーション、スナップショット、更新管理を担います。

Windowsベースの企業システムや、AWS上でADが必要なワークロードに向いています。

参考：https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html

AD Connector

AD Connectorは、AWS側に新しいADの実体を作るのではなく、既存のオンプレミスActive Directoryへディレクトリ要求を中継するゲートウェイです。AWSは、クラウド側にディレクトリ情報をキャッシュしないと説明しています。

つまり、「ユーザー情報の正本は社内ADに残したい」という企業に向いています。

参考：https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html

Simple AD

Simple ADは、Samba 4ベースのAD互換ディレクトリです。比較的小規模・低コスト向けの選択肢として位置付けられています。

Cloud Practitionerでは、細かな仕様を暗記する必要はありませんが、本格的なMicrosoft AD連携なら AWS Managed Microsoft AD、既存ADへの中継なら AD Connector、小規模な簡易用途なら Simple AD という違いを押さえると十分です。

参考：https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_simple_ad.html / https://docs.aws.amazon.com/whitepapers/latest/active-directory-domain-services/directory-services-options-in-aws.html

サービス比較：試験で間違えやすいポイント

IAM と IAM Identity Center の違い

IAMはAWS権限管理の基盤です。一方、IAM Identity Centerは社内ユーザーに対するSSOの入口です。問題文で「従業員が複数アカウントへログイン」という話なら、IAM単独よりIAM Identity Centerを考えるほうが自然です。

IAM Identity Center と Cognito の違い

どちらもログイン基盤のように見えますが、対象が違います。IAM Identity Centerは社内ユーザー向け、Cognitoは自社アプリ利用者向けです。

Cognito User Pools と Identity Pools の違い

User Poolsはアプリ利用者の認証を担当し、Identity Poolsはその利用者にAWS認証情報を払い出します。つまり、User Poolsは「ログイン」、Identity Poolsは「AWSリソース利用のための橋渡し」です。

Directory Service と Cognito の違い

Directory Serviceは企業ディレクトリやAD連携向けであり、CognitoはWeb/モバイルアプリの一般利用者認証向けです。似た認証系でも用途がかなり違います。

Cloud Practitioner試験でよくある出題パターン

従業員が複数AWSアカウントにSSOでログインしたい
→ IAM Identity Center
Webアプリの一般会員にサインアップやサインイン機能を提供したい
→ Amazon Cognito User Pools
ログインしたアプリ利用者にS3へ直接アップロードさせたい
→ Amazon Cognito Identity Pools と IAMロール
既存の社内Active Directoryを使ってAWSサービスと連携したい
→ AWS Directory Service（要件に応じて AWS Managed Microsoft AD または AD Connector）
AWSリソースへの権限を最小権限で管理したい
→ IAMポリシーとIAMロール
最も強い権限を持つアカウントだが日常利用すべきでないものは何か
→ ルートユーザー

学習のコツ：細部より「主語」を見る

この分野は機能を細かく暗記しようとすると混乱しやすいため、まずは「誰がログインするのか」を見るのがおすすめです。

アカウント所有者 → ルートユーザー
社内の人 → IAM Identity Center
アプリ利用者 → Cognito
AWSリソース権限 → IAM
一時認証情報 → STS
AD統合 → Directory Service

この整理ができると、Cloud Practitionerの問題文を読んだ時に選択肢をかなり絞りやすくなります。

まとめ

AWSのユーザー認証は、似た名前のサービスが多い一方で、役割は比較的はっきり分かれています。

ルートユーザーは最上位権限だが日常利用しない
IAMはAWSの認可とアクセス管理の中心
IAM Identity Centerは社内ユーザー向けSSO
Amazon Cognitoはアプリ利用者向け認証基盤
Cognito Identity PoolsはAWSへの一時認証情報払い出し
AWS Directory ServiceはActive Directory連携向け
STSは一時認証情報の基盤

試験対策としては、個々のサービス名だけでなく、「誰に使うのか」「何のための認証か」を結び付けて覚えることが重要です。ここが整理できれば、この分野はかなり得点しやすくなります。

参考資料（AWS公式）

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！