- Newest
- Most votes
- Most comments
Based on your description, it sounds like you're encountering a common issue with the trust policy configuration for App Studio connectors. Let me help you troubleshoot this.
When setting up the IAM role for your connector, there are a few critical elements that need to be correctly configured:
-
Trust Policy Configuration: The trust policy needs to include the correct AWS account ID in the Principal section. This should be the AWS account ID of the account used to set up App Studio, not necessarily the account where your resources are located.
-
Required Tag Condition: Your trust policy must include the condition
"aws:PrincipalTag/IsAppStudioAccessRole": "true"in thests:AssumeRolesection. Note that this is different from the role tag you mentioned (IsAppStudioDataAccessRole). -
Role Tags: The IAM role itself needs to have the tag
IsAppStudioDataAccessRole: true(which you've already done correctly).
Here's what your trust policy should look like:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::YOUR_APP_STUDIO_ACCOUNT_ID:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/IsAppStudioAccessRole": "true"
}
}
}
]
}
Double-check that:
- You're using the correct AWS account ID where App Studio is set up
- The condition is specifically for
IsAppStudioAccessRole(notIsAppStudioDataAccessRole) - The IAM role has the tag
IsAppStudioDataAccessRole: true - There are no typos or formatting issues in your trust policy
This custom trust policy is required even if your AWS resources are in the same AWS account used to set up App Studio.
Sources
Troubleshooting connectors - AWS App Studio
answered 9 months ago
The AI-generated answer suggests typos, exact tag names, etc. I double checked this and believe my policy is correct. Here it is (with acct name and Instant-ID removed). I don't see any error. Still, the Connector "Verify" check fails.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<acct#>:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:PrincipalTag/IsAppStudioAccessRole": "true", "sts:ExternalId": "<36_characters_here>" } } } ] }
So, I still need help...
answered 9 months ago
Hey,
Hope you're keeping well.
The “App Studio was not able to assume the IAM role” error occurs when the Connector setup cannot pass the AWS sts:AssumeRole call because the trust policy or required tag configuration is incomplete. For App Studio, the IAM role must have the tag key IsAppStudioDataAccessRole set to the string "true" and a trust policy that explicitly allows the App Studio service principal to assume it. The correct principal format is arn:aws:iam::<AppStudioAccountId>:role/<AppStudioInstantId> and must match exactly what is shown under Settings → Instant ID in the App Studio console.
Thanks and regards,
Taz
answered 9 months ago
Thanks for your reply. Your suggestions aren't passing syntax checks in the editor, so let me clarify:
My Trust policy contains this principal statement: "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS account ID>:root" }, etc...
You suggested using "Principal": { "AWS": arn:aws:iam::<AppStudioAccountId>:role/<AppStudioInstantId> }, etc... Also, note, you're not using quotation marks for after the "AWS": portion, something the editor seems to require. I tried changing from ...:root version to your suggested :role/<AppStudioInstantId> version, but the policy editor states that this is an invalid Principal statement. It wouldn't even update the policy.
The IAM **role ** has the tag key IsAppStudioDataAccessRole and its value is set to the string "true".
So, it appears your suggestion has two issues: (1) Quotations are needed after the "AWS": portion (2) Replacing ":root" with ":role/<AppStudioInstantId>" appears to be an invalid principal statement
Can you/anyone chime in here? I just can't figure out why my policy seems to fail.
answered 9 months ago
Relevant content
asked 2 years ago
- AWS OFFICIALUpdated a year ago

This doesn't solve the problem, although it points to valid aspects. See my followup below.