QuickSight を使い始めて最初に戸惑いやすいのが、サインインまわりの用語です。
「ネイティブ」「IAM フェデレーション」「IAM Identity Center」と、名前は似ているのに指すものが違います。
とくに IAM フェデレーションと IAM Identity Center は混同しやすい2つです。

なお、この記事で扱うのは「どうやってサインインするか（認証）」だけで、サインイン後の「何を見られるか（認可＝ロールや権限）」には踏み込みません。

この記事で整理したいこと

この記事で整理するのは、次の3点です。

QuickSight のサインイン方式にはどんな種類があるのか（全体像）
よく混同する IAM フェデレーションと IAM Identity Center は何が違うのか
自分の環境がどの方式で動いているか、その見当のつけ方

この記事はサインイン方式（認証）の全体像に絞ります。以下は扱いません。

MFA（多要素認証。サインイン方式に並ぶものではなく、どれかに足す要素です¹）
SCIM プロビジョニング、SAML メタデータ等の具体的な設定
トラブルシュート
認可（ロールや共有）

QuickSight は Amazon Quick へ改称され、QuickSight 自体は「Amazon Quick Sight」機能として継続します。API や既存の設定は変更なしとされています²。正確な発表時期や、画面ラベルが「QuickSight」「Quick Sight」のどちらで表示されるかまでは本記事では確認できていないため、踏み込みません。

サインイン方式の全体像

QuickSight のサインインには複数の方式があり、公式ドキュメントでも認証まわりのツールとして IAM Identity Center・IAM federation・AWS Directory Service の AD・SAML SSO・MFA が並んでいます³。
ここでは「誰がユーザーを管理するか」で2つの系統に分けて整理します。

系統A：ネイティブ: QuickSight 自身がユーザーを管理する
系統B：外部ID連携（フェデレーション）: QuickSight の外にある仕組みにユーザー管理を委ねる

ただし、この2系統はあくまで理解のための整理で、公式の厳密な分類ではありません。
公式の一次的な区分は API に現れていて、ユーザー登録時の IdentityType は IAM / QUICKSIGHT / IAM_IDENTITY_CENTER の3値です⁴。以降の「系統A／B」は、この3値を分かりやすく束ね直した呼び方です。

系統A ネイティブ（QuickSight 自身がユーザー管理）

方式	API `IdentityType`	誰がユーザーを管理するか	エディション条件
QuickSight-managed	`QUICKSIGHT`	QuickSight 自身	Standard / Enterprise

系統B 外部ID連携（フェデレーション）

方式	API `IdentityType`	誰がユーザーを管理するか	エディション条件
IAM ユーザー・ロール	`IAM`	AWS の IAM	Standard / Enterprise
IAM フェデレーション（SAML 2.0）	`IAM`	企業の IdP ＋ IAM ロール	Standard / Enterprise
IAM Identity Center	`IAM_IDENTITY_CENTER`	IAM Identity Center	Enterprise のみ
Active Directory	—	AWS Directory Service の AD	Enterprise のみ

系統の A／B は前掲の整理、API の IdentityType は API リファレンス⁴、エディション条件は AWS のサインアップ設定ドキュメント³によります。

系統A ネイティブ（QuickSight 自身がユーザー管理）

系統A は、QuickSight 自身がユーザーを持つ方式です。

流れ: 管理者がメールアドレスでユーザーを招待 → 招待された人が QuickSight のユーザーとしてサインイン
特徴: 外部の IdP を用意しなくても完結する（Standard エディションでも「QuickSight 内で完結」または「IAM 連携」の範囲が使える³）
向く場面: 社内の ID 基盤と切り離して、まず QuickSight だけを小さく触りたいとき

系統B 外部ID連携（フェデレーション）

系統B は、QuickSight の外にある仕組みにユーザー管理を委ねる方式です。
まず素朴なのが、AWS の IAM ユーザーやロールをそのまま QuickSight に登録する形。そこから連携先を広げていくと、次の方式が出てきます。

IAM フェデレーションと IAM Identity Center ─ どこが違うのか

混同しやすいのが、この2つです。同じ SSO 的な体験に見えても、担い手と適用範囲が違います。

観点	IAM フェデレーション	IAM Identity Center（旧 AWS SSO）
ひとことで	QuickSight が IAM ロール経由で企業の IdP を相手にする	AWS 横断のサインイン基盤にまとめて委ねる
仕組み	SAML 2.0 で企業の IdP と直接連携し、サインイン時に IAM ロールを引き受ける	AWS アカウント・サービスをまたぐサインインを束ねる
API の `IdentityType`	`IAM`	`IAM_IDENTITY_CENTER`
エディション	Standard / Enterprise	Enterprise のみ

※ API 上の区別は⁴、エディション条件は³による。IAM フェデレーションは、IdP 側のグループを QuickSight へ同期する機能を持ちません⁵。

連携先としての AD とサードパーティ IdP

Active Directory: AWS Directory Service の AWS Managed Microsoft AD と AD Connector の両方に対応。オンプレミスの AD も、AD Connector やフェデレーション経由でつなげます⁶
サードパーティ IdP: SAML 2.0 に対応していれば連携でき、AD FS・Okta・Ping などが例に挙がります⁵
OIDC（CUSTOM_OIDC・COGNITO）: web identity federation ＝ IAM ロールへの紐づけとして使えます。ただしネイティブなアカウント ID の供給源とは別枠です⁴⁷

どの方式を使えるか＆自分の環境の見分け方

使える方式はエディションで決まります。

IAM Identity Center・Active Directory: Enterprise エディション限定³
IAM フェデレーション・SAML SSO: Standard / Enterprise の両方³
Standard: 「QuickSight 内でユーザー管理を完結」または「IAM と連携」の範囲³

認証方式はアカウントを作るときに選び、作成後は変更できません³。
サインアップ画面の選択肢は Password-based or Single-Sign On／IAM Identity Center／Single-Sign On Only／Active Directory⁸。最初の選択が、そのまま運用の前提になります。

自分の環境がどれかを見分ける手がかりは、次のあたりです。

サインイン画面: QuickSight 独自のログインか、企業の IdP や AWS のサインインに飛ぶか
入口: AWS マネジメントコンソール経由か、QuickSight 固有の URL からか

　※ 画面からの見分けは断定しづらいため、確実なのはアカウントを作成した管理者に「どの ID 方式で作ったか」を確認することです。

関連記事

QuickSight の権限を「認証 → 認可 → RLS → IAM 境界」の順にたどる入口記事です。

1本目 QuickSight のログイン方式を整理する（認証）（本記事）
2本目 QuickSight のアクセスはロールとリソース共有で決まる（認可）
3本目 QuickSight の行レベルセキュリティ(RLS)とは
4本目 QuickSight の権限と IAM の関係を整理する（IAM 境界）