hidekazu-konishi.com

AWS IAM Identity Center Complete Setup Guide - Multi-Account SSO Design Patterns from Organization Structure to ABAC

First Published: 2026-04-28
Last Updated: 2026-04-28

1. Introduction — The Position of IAM Identity Center

• Long-lived IAM access keys: every IAM user added to a member account is a long-term credential surface. Identity Center sessions are temporary by construction.
• Per-account user duplication: with raw IAM, the same engineer needs an IAM user (or a per-account role) in every account. Identity Center centralizes the user once and projects roles outward.
• Permission sprawl: ad-hoc IAM policies multiply per account. Permission Sets are templates that provision identical IAM roles into every assigned account.
• Audit fragmentation: CloudTrail events from per-account IAM users are hard to attribute to a real human. Identity Center sessions carry the corporate identity and surface in CloudTrail under predictable event sources.

2. Prerequisites

• Instance type: An organization instance (recommended) is created from the management account of an AWS Organization and is the only instance type that can manage cross-account permissions. An account instance is bound to a single account and is intended for AWS-managed application access only. You should not use an account instance for workforce console access.
• Home Region: The organization instance is created in one home Region. Replication to additional Regions is supported for resiliency, but the original home Region selection is operationally sticky — pick a Region that aligns with your data residency story and your CloudTrail/Organization Trail Region.
• Identity source: One of Identity Center directory (default), Active Directory, or External IdP via SAML 2.0 + SCIM v2. Switching between sources later deletes existing users and groups and removes all assignments, which means everyone, including admins, loses SSO access until reprovisioned. Decide early.
• Delegated administrator: After enablement, register one member account as the delegated administrator so that day-to-day Identity Center operations do not require the management account. The delegated administrator can do almost everything except modify Permission Sets that grant access to the management account.

• An AWS Organization with all features enabled, in the same management account where you will enable Identity Center.
• An IAM principal in the management account with permission to enable IAM Identity Center. AWS publishes recommended managed policies for administrative access (for example AWSSSOMemberAccountAdministrator for delegated admin operations), plus the service-linked role AWSServiceRoleForSSO that is created automatically at enablement. The legacy AWSSSOMasterAccountAdministrator managed policy is no longer published, and AWS-managed policy names in this space have been refactored more than once — do not hard-code the policy name in production IaC. Verify the current set of recommended managed policies at IAM Identity Center authentication and access control, and prefer a narrower, custom-authored least-privilege policy for the management account so future renames do not silently expand or revoke admin reach.
• If you plan to use Active Directory, an existing AWS Managed Microsoft AD directory or AD Connector in AWS Directory Service in the same Region.
• If you plan to use an external IdP, an account on that IdP with permission to create a SAML 2.0 application and (optionally) configure SCIM provisioning.

2.1 Cost Reference

• AWS Managed Microsoft AD — Standard edition: approximately $0.146 / directory-hour (~$108 / month per directory) in ap-northeast-1. Enterprise edition: approximately $0.40 / directory-hour (~$292 / month). Multi-Region replication is billed under a separate "additional region" SKU per replicated Region (priced at parity with the primary directory hour, but accounted independently). Verify current values on the AWS Directory Service pricing page.
• AD Connector — Small: approximately $0.05 / directory-hour (~$36 / month). Large: approximately $0.20 / directory-hour (~$144 / month). Network egress to on-prem AD is metered separately.
• External IdPs — billed by the vendor; reference list prices below are starting tiers and may change. Confirm with the vendor before commitment:
  • Okta Workforce Identity from approximately $2 / user / month (Okta pricing)
  • Microsoft Entra ID P1 from approximately $6 / user / month (Microsoft Entra ID pricing)
  • Google Cloud Identity Premium from approximately $6 / user / month (Google Cloud Identity pricing)
  • JumpCloud from approximately $2 / user / month for SSO-only (JumpCloud pricing)
• SCIM provisioning calls and CloudTrail management events for Identity Center are not separately metered. CloudTrail data events and downstream services (S3 storage, Athena queries on the trail) are billed normally.
• Trusted identity propagation does not introduce a separate charge for Identity Center, but the downstream service (Amazon Q Business per-user, Redshift per-cluster) bills as usual.

3. Initial Setup

3.1 Enable IAM Identity Center (Console)

1. Open the IAM Identity Center console in your chosen home Region.
2. Choose Enable. AWS creates the organization instance and the service-linked role AWSServiceRoleForSSO in the management account.
3. Note the AWS access portal URL (format https://d-xxxxxxxxxx.awsapps.com/start). You can replace the random subdomain with a vanity alias on the Settings page.
4. Open Settings → Identity source and pick one of the three sources described in 3.3.

3.2 Enable IAM Identity Center (CLI)

# Run from the management account
aws organizations enable-aws-service-access \
  --service-principal sso.amazonaws.com

# Verify the instance and capture its ARN + Identity Store ID
aws sso-admin list-instances
# {
#   "Instances": [
#     {
#       "InstanceArn": "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx",
#       "IdentityStoreId": "d-xxxxxxxxxx"
#     }
#   ]
# }

# Register a delegated administrator (member account ID)
aws organizations register-delegated-administrator \
  --account-id 111122223333 \
  --service-principal sso.amazonaws.com

3.3 Choose the Identity Source

3.4 Multi-Factor Authentication Posture

• Context-aware (default): Identity Center prompts for MFA only when sign-in context changes — new device, new browser, unfamiliar IP, or trust expiry. Trusted devices are remembered for up to 30 days (configurable under Settings → Authentication → Standard authentication). Lower friction; appropriate for the majority of workforces.
• Always-on: every sign-in requires MFA. Use for environments with regulatory requirements (FedRAMP High, PCI DSS, HIPAA-aligned controls) or as a temporary hardening posture during incident response.

4. Permission Set Design Patterns

arn:aws:iam::<account-id>:role/aws-reserved/sso.amazonaws.com/<region>/AWSReservedSSO_<PermissionSetName>_<16-hex-suffix>

• Up to 1 inline policy per Permission Set, with a documented quota of 32,768 characters (verified 2026-04 at IAM Identity Center quotas); the AWS-managed and customer-managed policies you also attach count against the IAM role's separate per-policy limits, so factor in both ceilings when sizing
• Up to 10 attached managed policies (the underlying IAM role limit; can be raised per account via IAM service quotas)
• Session duration: default 1 hour, configurable up to 12 hours (PT12H) per Permission Set (verified 2026-04 at Set session duration)
• One permissions boundary (AWS-managed or customer-managed) optional but strongly recommended for non-admin sets

4.1 Three Layered Patterns

• Job-Function (predefined): pick one AWS-managed job-function policy — AdministratorAccess, PowerUserAccess, ViewOnlyAccess, Billing, DatabaseAdministrator, DataScientist. Fast for sandboxes. Too broad for production. For break-glass specifically, do not reuse AdministratorAccess for ordinary admin work — create a dedicated BreakGlassAdmin Permission Set assigned to a 2–3-person group, and pair it with a CloudTrail metric filter that pages security on every AssumeRoleWithSAML targeting that role.
• Custom Single-Purpose: one or more managed policies + a tight inline policy + a permissions boundary. Use for the ~10 named roles your platform actually needs (e.g., AppDeveloper, ReadOnlyAuditor, FinOpsViewer, SecOpsResponder).
• Tenant × Function (the matrix you should avoid expanding): AppDeveloper-TeamA, AppDeveloper-TeamB, ... — tempting and quickly explodes. Solve this with ABAC instead (section 7) so you keep one AppDeveloper set and let the user's Team attribute scope the access.

4.2 A Starter Custom Permission Set (Inline Snippet)

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "AllowAppPlane",
      "Effect": "Allow",
      "Action": [
        "lambda:*", "apigateway:*", "states:*",
        "dynamodb:*", "s3:*",
        "logs:*", "cloudwatch:*", "xray:*"
      ],
      "Resource": "*" },
    { "Sid": "DenySensitiveControls",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser", "iam:CreateAccessKey",
        "iam:Put*Policy", "iam:DeleteRole",
        "kms:ScheduleKeyDeletion", "kms:Disable*",
        "ec2:*Vpc*", "ec2:*RouteTable*", "ec2:*Subnet*"
      ],
      "Resource": "*" }
  ]
}

4.3 Customer Managed Policy References

  SecOpsResponderPS:
    Type: AWS::SSO::PermissionSet
    Properties:
      Name: SecOpsResponder
      InstanceArn: !Ref InstanceArn
      SessionDuration: PT2H
      ManagedPolicies:
        - arn:aws:iam::aws:policy/SecurityAudit
      CustomerManagedPolicyReferences:
        - Name: SecOpsResponderActions
          Path: /security/
        - Name: BoundaryForSecOps
          Path: /boundaries/
      PermissionsBoundary:
        CustomerManagedPolicyReference:
          Name: BoundaryForSecOps
          Path: /boundaries/

5. Account Assignment — Automation with IaC

1. Permission Set definition (lives in the management account or delegated admin account)
2. Account Assignment: (group OR user) × Permission Set × target account

5.1 CloudFormation Sample

AWSTemplateFormatVersion: "2010-09-09"
Description: Permission Set + Account Assignment for AppDeveloper

Parameters:
  InstanceArn:
    Type: String
    Description: arn:aws:sso:::instance/ssoins-xxxx
  GroupId:
    Type: String
    Description: Identity Store group ID for "AppDevelopers"
  TargetAccountId:
    Type: String

Resources:
  AppDeveloperPS:
    Type: AWS::SSO::PermissionSet
    Properties:
      Name: AppDeveloper
      InstanceArn: !Ref InstanceArn
      Description: Application developers in non-prod accounts
      SessionDuration: PT4H
      ManagedPolicies:
        - arn:aws:iam::aws:policy/ReadOnlyAccess
      InlinePolicy: |
        {
          "Version": "2012-10-17",
          "Statement": [
            { "Effect": "Allow",
              "Action": ["lambda:*", "logs:*", "states:*"],
              "Resource": "*" }
          ]
        }
      Tags:
        - Key: ManagedBy
          Value: cloudformation

  AppDeveloperAssignment:
    Type: AWS::SSO::Assignment
    Properties:
      InstanceArn: !Ref InstanceArn
      PermissionSetArn: !GetAtt AppDeveloperPS.PermissionSetArn
      PrincipalType: GROUP
      PrincipalId: !Ref GroupId
      TargetType: AWS_ACCOUNT
      TargetId: !Ref TargetAccountId

5.2 Terraform Sample

data "aws_ssoadmin_instances" "this" {}

locals {
  instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
}

resource "aws_ssoadmin_permission_set" "app_developer" {
  name             = "AppDeveloper"
  instance_arn     = local.instance_arn
  session_duration = "PT4H"
}

resource "aws_ssoadmin_managed_policy_attachment" "ro" {
  instance_arn       = local.instance_arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  permission_set_arn = aws_ssoadmin_permission_set.app_developer.arn
}

resource "aws_ssoadmin_account_assignment" "dev_team_a" {
  for_each           = toset(var.nonprod_account_ids)
  instance_arn       = local.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.app_developer.arn
  principal_id       = var.app_developers_group_id
  principal_type     = "GROUP"
  target_id          = each.value
  target_type        = "AWS_ACCOUNT"
}

5.3 AWS Control Tower and Account Factory Integration

1. Account Factory creates the account in the target OU.
2. The new account inherits all SCPs attached to the OU and its ancestors.
3. A CloudFormation StackSet with OU-based auto-deployment fans out the Permission Set Assignment resources from section 5.1 to the new account within minutes.
4. If you use customer managed policy references (section 4.3), a separate StackSet first creates the named CMPs in the new account so the Assignment can resolve them.

5.4 Event-Driven Automation

HRIS / IdP change
   ↓
SCIM push to IAM Identity Center
   ↓
identitystore.amazonaws.com event in CloudTrail
   ↓
EventBridge rule  →  Lambda
   ↓
sso-admin:CreateAccountAssignment / DeleteAccountAssignment

6. Multi-Account Strategy — Mapping OUs to Permission Sets

• Define Permission Sets by function, not by team: Admin, PowerUser, AppDeveloper, ReadOnlyAuditor, BillingViewer, SecOpsResponder, BreakGlass.
• Define groups by team and seniority in your IdP: aws-team-a-engineers, aws-team-a-leads, aws-platform-admins.
• Map (Group, Permission Set) to OU: a YAML matrix that StackSets / Terraform consume. Example:

assignments:
  - group: aws-team-a-engineers
    permission_set: AppDeveloper
    ous: [Workloads/NonProd]
  - group: aws-team-a-leads
    permission_set: PowerUser
    ous: [Workloads/NonProd]
  - group: aws-platform-admins
    permission_set: Admin
    ous: [Workloads, Security, Sandbox]
  - group: aws-finops
    permission_set: BillingViewer
    ous: [_root_]

7. ABAC — Tag-Based Permissions Inside One Permission Set

1. The user has attributes in the identity source (e.g., Department=AppA, CostCenter=1234).
2. In Identity Center, on Settings → Attributes for access control, you map those attributes to session tags (key: Department, value: ${path:enterprise.department} or, for external IdPs, the SAML attribute path).
3. Resources in member accounts are tagged with the same key (e.g., S3 bucket tag Department=AppA).
4. The Permission Set's policy uses aws:PrincipalTag/<Key> to scope the action to matching resources.

7.1 Inline Policy Snippet

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "TeamScopedS3",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}

7.2 Where ABAC Falls Short

8. Application Access — SAML and AWS-Managed Apps

• Customer-managed SAML 2.0 apps: any third-party SaaS that supports SAML 2.0 SP-initiated or IdP-initiated flows. You add the application in the Identity Center console, exchange metadata, and define attribute mappings (e.g., Subject NameID = email).
• AWS-managed applications: Amazon Q (Business and Developer), Amazon QuickSight, Amazon Redshift Query Editor v2, AWS IoT SiteWise Monitor, and others. These are configured from inside the application's own console; Identity Center supplies the user identity transparently.

8.1 Trusted Identity Propagation

8.2 Trusted Token Issuers (OAuth 2.0 / OIDC)

1. The third-party application authenticates the user against the external IdP and receives an OIDC ID token.
2. The application calls Identity Center's CreateTokenWithIAM API, presenting the IdP token.
3. Identity Center validates the token's iss against the registered TTI, the aud against the registered audience, and the signature against the JWKS endpoint.
4. Identity Center maps the IdP claim (typically email or a custom claim like aws-uid) to a SCIM-mirrored Identity Center user, then issues an Identity Center access token bound to that user.
5. The application uses that Identity Center token to call AWS services that participate in TIP (e.g., Lake Formation queries, Q Business indices) on behalf of the human, with full attribution in CloudTrail.

9. Auditing and Monitoring

• sso.amazonaws.com — admin APIs (Permission Sets, Assignments, settings)
• identitystore.amazonaws.com — user / group create / update / delete
• identitystore-scim.amazonaws.com — SCIM-driven provisioning from the IdP

1. Roll out a new Permission Set with a broad starter policy (e.g., PowerUserAccess).
2. Wait 30–90 days while CloudTrail captures real usage.
3. Use Access Analyzer to generate a policy reflecting only the actions actually used.
4. Review, tighten further if needed, and replace the broad policy with the generated one.

9.1 Permission Set Provisioning State and Bulk Re-Provisioning

# Which accounts have a given Permission Set provisioned?
aws sso-admin list-accounts-for-provisioned-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxx/ps-yyyy \
  --provisioning-status LATEST_PERMISSION_SET_NOT_PROVISIONED

# Provisioning status of recent reconciliations
aws sso-admin list-permission-set-provisioning-status \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx

aws sso-admin provision-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxx/ps-yyyy \
  --target-type ALL_PROVISIONED_ACCOUNTS

# Returns RequestId; poll status:
aws sso-admin describe-permission-set-provisioning-status \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx \
  --provision-permission-set-request-id <RequestId>

10. Migration from IAM Users

1. Inventory existing IAM users in every member account: aws iam list-users per account, dump access-key age with aws iam list-access-keys. Anything older than 90 days is a candidate for early rotation.
2. Map each IAM user to (group, function): which team are they on, what do they do? This becomes the input to the section 6 matrix.
3. Stand up Identity Center alongside IAM users: do not delete anything yet. Have everyone log in via the AWS access portal in parallel for two weeks.
4. Switch CLI users to aws configure sso: short-term credentials with automatic refresh. AWS SDKs in v2 / boto3 read the SSO profile transparently. A minimal ~/.aws/config example:

   [sso-session my-org]
   sso_start_url = https://my-org.awsapps.com/start
   sso_region = ap-northeast-1
   sso_registration_scopes = sso:account:access
   
   [profile dev-power]
   sso_session = my-org
   sso_account_id = 111111111111
   sso_role_name = PowerUserAccess
   region = ap-northeast-1
   

   The day-to-day developer profile resolves to PowerUserAccess (or a custom AppDeveloper Permission Set) rather than AdministratorAccess — the latter is reserved for the dedicated BreakGlassAdmin Permission Set described in section 4.1, and should never be assigned to a routine CLI profile.
   
5. Disable (not delete) IAM user passwords and access keys. Wait at least one billing cycle for stragglers.
6. Delete IAM users once CloudTrail confirms zero activity for the disabled credentials.

11. Common Pitfalls

• Wrong home Region: the home Region selection at first enablement is sticky. Replication helps, but you cannot move the primary freely. Pick a Region that aligns with the Region of your CloudTrail Organization Trail and your data-residency requirements.
• Identity-source switch wipes assignments: switching from "Identity Center directory" to "Active Directory" or to an external IdP deletes all users / groups and removes every assignment. Plan it as a maintenance event, not an incremental change.
• Provisioning lag: CreateAccountAssignment is async. The IAM role appears in the target account seconds-to-minutes after the API call. Onboarding scripts that call AWS APIs immediately after assigning will fail intermittently — poll DescribeAccountAssignmentCreationStatus.
• SCP collisions: Permission Sets project ordinary IAM roles into member accounts, and SCPs apply on top. A user with AdministratorAccess at the Permission Set level can still be denied by a Deny SCP at the OU level. Always test new Permission Sets against the SCPs of the target OU.
• Permission set quota: defaults of 3,500 Permission Sets per organization instance and 500 provisioned Permission Sets per account are generous, but the "tenant × function" anti-pattern (section 4.1) burns through them fast. ABAC is the cure.
• 10-managed-policies-per-role limit: the Permission Set role inherits the IAM ceiling of 10 attached managed policies. To stack more, raise the IAM service quota in each member account, or consolidate into a customer-managed policy.
• Inline policy size: 32,768 characters per Permission Set inline policy. Once you cross even half of that, refactor into a customer-managed policy (or a customer managed policy reference per section 4.3) so the policy body is reviewable in IAM and inheritable across accounts.
• AD assignments don't auto-clean: when an AD user is deleted, IAM Identity Center does not automatically remove their account assignments. Your offboarding runbook must handle this explicitly. (The Identity Center directory and SCIM-driven external IdPs do clean up automatically.)
• Cross-Region inference for managed apps: AWS-managed applications often live in specific Regions; users may need to switch the AWS access portal Region context to see them. This is a UX papercut, not an outage, but support tickets pile up if it isn't documented internally.
• Permission Set role ARN format depends on the Multi-Region replication setting: when replication is enabled the role path includes a <region> segment, and when replication is off it does not (see section 4). CloudTrail filters, trust-policy regexes, and policy-as-code rules that pattern-match these roles must accept both shapes — the most reliable anchor is the literal token AWSReservedSSO_<PermissionSetName>_ rather than any preceding path.

11.1 Troubleshooting Quick Reference

• "User signs into the access portal but sees no accounts." Check the assignment exists (aws sso-admin list-account-assignments for the user's group), the SCIM sync ran (CloudTrail event source identitystore-scim.amazonaws.com within the last sync interval), and the Permission Set is in Provisioned state for the target account (aws sso-admin describe-permission-set-provisioning-status). One of the three is almost always the culprit.
• "IAM role exists in the account but AssumeRoleWithSAML fails / shows the old policy." After editing a Permission Set, the IAM role enters OUT_OF_SYNC and continues to evaluate against the prior policy until re-provisioned (see section 9.1). Run aws sso-admin provision-permission-set --permission-set-arn ... --target-id <account> --target-type AWS_ACCOUNT, or use --target-type ALL_PROVISIONED_ACCOUNTS for a fleet-wide reconcile.
• "CloudTrail shows the role but I can't tell which human did it." Read userIdentity.sessionContext.sessionIssuer.arn for the Permission Set role, then read the role-session-name — it equals the Identity Center username. The chain is session-name → Identity Center user → IdP user.
• "Adding a user to a group in the IdP doesn't grant access." Confirm SCIM push fired (CloudTrail identitystore-scim.amazonaws.com), confirm the Permission Set assignment targets the group not the user, and confirm the group ID in Identity Store matches the assignment's PrincipalId. Group renames in the IdP can leave the SCIM-mirrored group with a stale display name but the same ID — this is fine.

12. Pre-Production Checklist

• Home Region aligned with the CloudTrail Organization Trail Region and data-residency policy (section 2).
• Identity source finalized; switch path documented as a maintenance event, not a runtime change (section 3.3).
• Delegated administrator registered; management-account login is a break-glass-only path (section 2).
• MFA posture selected (context-aware vs always-on) and tested for at least one user from each authenticator type (section 3.4).
• Break-glass Permission Set (BreakGlassAdmin) provisioned and assigned to a 2–3-person group; credential retrieval drill from the password vault rehearsed; CloudTrail metric filter on AssumeRoleWithSAML against this role wired to a paging channel (section 4.1).
• SCP compatibility: every new Permission Set tested against the SCPs of every target OU before announcement (section 11).
• StackSet auto-deployment enabled for the Assignment StackSet and (if used) the customer managed policy StackSet, with target-OU filters reviewed (sections 5.1, 4.3).
• Bulk re-provisioning hook wired into the Permission Set CI/CD pipeline (section 9.1).
• SCIM bearer token rotation calendar entry created (maximum lifetime 1 year, with automatic expiry-warning emails 30/15/3 days before expiry) and the procedure to rotate without service interruption documented.
• IAM Access Analyzer for IAM Identity Center enabled in the management or delegated admin account; 30–90-day baseline period scheduled before policy tightening (section 9).
• Orphan-assignment reconciliation job scheduled (cron, EventBridge, or CI) to compare live assignments against the source-of-truth YAML (section 9).
• ABAC tag governance: AWS Config required-tags rule deployed; SCP denying tag deletion of governance keys (e.g., Department, CostCenter) attached to the relevant OUs (section 7.2).
• Legacy IAM users inventory dumped, access-key age recorded, deactivation calendar entry set; one full billing cycle planned between deactivation and deletion (section 10).
• Read-only auditor Permission Set available for short-lived external auditor access without standing up a new IAM user.
• Internal documentation — AWS access portal URL, vanity alias, supported MFA methods, contact for break-glass — published to the team wiki and linked from the IdP launchpad.

13. Summary

• Decide the home Region and identity source before you click Enable: both are operationally sticky, especially the identity source whose change wipes assignments.
• Design Permission Sets by function, not by team: pair a small set of functions with ABAC session tags driven by the identity source, and the Permission Set count stays flat as the org grows.
• Automate Assignment via IaC + StackSets: the (Group × Permission Set × OU) matrix is the unit of policy. Code review it; do not click it.

14. References

• What is IAM Identity Center? — AWS IAM Identity Center User Guide
• IAM Identity Center renamed (formerly AWS Single Sign-On)
• Manage your identity source — considerations
• Automatic provisioning (SCIM v2)
• Permission sets — concepts
• Configure session duration for permission sets
• Referencing permission sets in IAM policies
• Attribute-based access control
• Attributes for access control
• Customer managed policies and permissions boundaries
• Trusted identity propagation overview
• Using applications with a trusted token issuer
• AWS Control Tower and IAM Identity Center
• AWS Directory Service pricing (AWS Managed Microsoft AD, AD Connector)
• Logging IAM Identity Center API calls with AWS CloudTrail
• IAM Identity Center quotas
• AWS::SSO resource type reference (CloudFormation)
• IAM best practices — require human users to use federation with an identity provider
• The History and Timeline of Amazon Cognito (related article)
• Amazon Cognito Federation Complete Implementation Guide — Google, Apple, Microsoft, OIDC, and SAML (companion article) — the customer-identity counterpart to this workforce-identity guide; pair both when designing an end-to-end identity architecture for an AWS account.
• IAM Policy Simulator Tool — simulate and validate IAM policy evaluation before applying Permission Sets in production.
• IAM Policy Analyzer Tool — analyze IAM policies for overly permissive actions to support least-privilege Permission Set design.