Account access manager: GetRoleCredentials returns InternalServerException for member account role (AssumeRole itself succeeds)

This is almost certainly a service-side issue in the Account Access Manager federation path, not a misconfiguration on your end. The fact that AssumeRole succeeds in Account B's CloudTrail proves the trust policy and SCPs are correct — the failure is happening after credential issuance, inside the portal's GetRoleCredentials layer that brokers between your Identity Center token and the assumed-role session.

---

Analysis

• AssumeRole succeeds (Account B CloudTrail) → Trust policy is valid; SCPs are not blocking.

• GetRoleCredentials fails (Account A CloudTrail) → The portal/federation layer cannot complete the credential hand-off to the browser.

• Same-account role (Account A) works → The service can federate — but only for roles local to the management account.

• SCP in Account B is benign (RI deny + FullAWSAccess) → Not relevant — AssumeRole already succeeded.

The GetRoleCredentials API is an internal portal call (part of the SSO/Account Access portal service). An InternalServerException here means the service itself hit an unhandled condition — it's not an access-denied or policy-evaluation failure that you can fix from the outside.

---

Likely root causes

1. Missing "assignment" step via Account Access Manager
   Creating the IAM role + trust policy in Account B is necessary but not sufficient. Account Access Manager requires you to assign the role to a user/group through its own API or console flow (IAM console → Account Access Manager → create entitlement/application → select account + role + principal). Without this registration, the portal doesn't know how to federate into that specific cross-account role.
   ➡️ Verify: In the IAM console (Account A) → Account Access Manager section, confirm that Account B's role actually appears as an assigned entitlement for your test user.

2. Propagation delay (feature is < 2 weeks old)
   Account Access Manager was launched on August 10, 2026. Cross-account trust propagation — especially for INVITED member accounts that don't have the full Organizations bootstrap (no automatic OrganizationAccountAccessRole) — may require additional internal registration that hasn't completed yet or isn't fully automated for invited accounts.

3. Service-Linked Role (SLR) propagation
   You mentioned manually creating AWSServiceRoleForAccountAccessManager in Account B. If the SLR was supposed to be auto-created by the service during enablement but wasn't (possibly because the account was INVITED, not CREATED), the portal may be unable to complete its internal operations in that account.

4. Possible INVITED vs. CREATED gap
   Accounts joined via INVITED don't get the same automatic bootstrap as CREATED accounts (e.g., no OrganizationAccountAccessRole). It's plausible that Account Access Manager's internal cross-account discovery has a similar gap that hasn't been documented yet.

---

Recommended actions

1. Check the Account Access Manager assignment flow
   Ensure the role in Account B was assigned through the Account Access Manager console/API — not just created as an IAM role with the correct trust policy. The assignment step registers the role with the portal.

2. Wait 24–48 hours and retry
   Given the feature's age (9 days at time of writing), there may be eventual-consistency delays that haven't been documented.

3. Try with a CREATED member account (if possible)
   If you have or can create a member account via Organizations (not invited), test the same role setup there. This would confirm whether the issue is specific to INVITED accounts.

4. Submit console feedback with CloudTrail request IDs
   Even without a technical support case, you can submit feedback via the console feedback icon (bottom-left in the AWS Console). Include the GetRoleCredentials CloudTrail event request IDs — this routes to the service team.

5. Check AWS Health Dashboard
   Look for any active events for IAM or Identity Center in ap-northeast-1. A similar InternalServerException on GetRoleCredentials occurred in 2022 due to a transient service issue that wasn't posted to the Health Dashboard.

---

Historical precedent

In October 2022, multiple users reported the exact same InternalServerException on GetRoleCredentials during an unannounced SSO service degradation. That issue resolved itself within ~1 hour and was never reflected in the Health Dashboard. Your case differs in that it's persistent and scoped specifically to cross-account (member account) roles, which points more toward a functional gap than a transient outage.

---

TL;DR

Your configuration looks correct. The InternalServerException is a server-side failure in the Account Access Manager portal federation path for cross-account roles. Most likely cause: the role assignment/entitlement registration step in Account Access Manager was missed, or the service doesn't yet fully support INVITED member accounts (possible day-1 limitation of a 9-day-old feature). File console feedback with your CloudTrail request IDs so the service team can investigate.