What's changed: Service coverage: added a catalog section (s4) for governance/security/end-user services
1.2Cross-Account Access and Identity Federation
Understand secure access across accounts—cross-account IAM roles, IAM Identity Center (SSO), SAML/OIDC federation, and Resource Access Manager (RAM). Design org-wide access with least privilege.
Across accounts, role assumption (AssumeRole) and centralized identity are key. Avoid long-lived keys; use temporary credentials.
1.2.1Cross-account and federation
- Cross-account IAM role: assume another account’s role via sts:AssumeRole for temporary credentials; the trust policy defines who may assume it.
- IAM Identity Center (formerly AWS SSO): centralizes single sign-on and permission sets across accounts/apps.
- Federation: integrate a corporate IdP (SAML 2.0/OIDC) so existing identities access AWS.
- Resource Access Manager (RAM): shares resources like VPC subnets and Transit Gateways across accounts.
Common on SAP-C02: SSO for many accounts with existing corporate identities = IAM Identity Center, assume another account’s role = sts:AssumeRole + trust policy, resource sharing (subnets, etc.) = AWS RAM, external IdP = SAML/OIDC federation. Avoid distributing long-lived keys; use temporary credentials.
A cross-account role needs both a trust policy (who can assume) and a permissions policy (what they can do). Use an ExternalId condition for third parties to prevent the confused-deputy problem.
Org-wide access splits into “humans” and “workloads.” For humans, connect an external IdP to IAM Identity Center (SAML 2.0; user sync via SCIM), assign permission sets (job-function permission templates) to OUs/accounts, and SSO from the portal. For workloads/cross-account, assume an IAM role via sts:AssumeRole with both a trust policy (who may assume) and a permissions policy (what they can do). Don’t distribute long-lived keys—use temporary credentials, and let EC2/Lambda be credential-less via instance profiles/execution roles. For third parties (e.g., external SaaS), prevent the confused deputy with ExternalId, and scope to the org with an aws:PrincipalOrgID condition. For fine-grained delegation use permissions boundaries (a cap on grantable permissions) and ABAC (tag-based authorization). Share resources with AWS RAM (subnets, Transit Gateways, Route 53 Resolver rules, catalogs). Centralized identity (Identity Center) + temporary credentials (AssumeRole) + least privilege is the rule.
| Need | Use | Point |
|---|---|---|
| Human SSO (many accounts) | IAM Identity Center + permission sets | External IdP via SAML/SCIM |
| Access another account | Cross-account IAM role | AssumeRole + trust/permissions |
| Third-party assumption | ExternalId condition | Prevents confused deputy |
| Resource sharing | AWS RAM | Share subnets/TGW, etc. |
Scenario: safely give an external monitoring vendor read-only access to your account. → Create a cross-account IAM role, allow the vendor’s account in the trust policy with an ExternalId condition (prevents confused deputy), and scope the permissions policy to read-only. Hand over no long-lived keys; the vendor assumes the role for temporary credentials.
FAQ: Q. How to separate human vs workload access? → A. Humans use IAM Identity Center (SSO + permission sets); workloads/cross-account use IAM role AssumeRole. Both yield temporary credentials. Q. Why ExternalId? → A. A shared secret that prevents the confused-deputy attack when a third party assumes your role.
Trap: “hand over long-lived access keys for cross-account integration” is wrong—use AssumeRole + trust policy for temporary credentials. Also “create IAM users per account for human access across accounts” is wrong—centralize with IAM Identity Center.
1.2.2Section summary
- Cross-account = AssumeRole + trust policy (temporary credentials)
- Central identity = IAM Identity Center / external IdP = SAML/OIDC / sharing = RAM
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want employees to use existing corporate identities for SSO across multiple AWS accounts. What?
Q2. How should an app in account A access account B’s resources securely with temporary credentials?
Q3. You want to share VPC subnets created in a central network account with other member accounts. What?