Amazon Quick ARNs Are Account-Bound: Permissions Die on Migration

ARNs are account-bound. That single fact explains why every cross-account migration of Amazon Quick resources requires re-establishing permissions from scratch. A dashboard at arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-dash-001 becomes arn:aws:quicksight:us-east-1:222222222222:dashboard/sales-dash-001 after migration. Same resource ID, different ARN, different identity. Permissions don't travel because they reference the old principal ARNs — and those don't exist in the target account.

ARNs: Postal Addresses for Your Quick Resources

AWS splits an ARN into partition, service, region, account ID, resource type, and resource ID. The account ID is the city in the address analogy from Josh Anderson, Amruth Nag, and Priya Kakarla at AWS. Move your dashboard to a new account, and the address changes even if the house number stays the same. The Asset Bundle Export and Import APIs handle the internal ARN transformations automatically — but only for the assets in the bundle. If you export a dashboard without its dataset and data source dependencies (set IncludeAllDependencies=True), the imported dashboard will reference resources that don't exist in the target.

Why Permissions Don't Follow the Dashboard

Permissions are stored as relationships between a resource ARN and a principal ARN. When Saanvi grants access to the DataAnalysts group in account 111111111111, the permission reads arn:aws:quicksight:us-east-1:111111111111:group/default/DataAnalysts. After migration to QA account 222222222222, that group ARN is meaningless. Even if a DataAnalysts group exists in QA, its ARN is different. The AWS post makes this explicit: you must re-establish permissions in each target environment, either during import using OverridePermissions or as a separate step after the import completes.

Namespaces: Principal ARNs, Not Asset ARNs

Assets (dashboards, datasets, data sources) live outside namespaces. Their ARNs have no namespace component. Users and groups live inside namespaces, and their ARNs embed the namespace. Two users named nikki_wolf in the HR and Marketing namespaces are completely different principals: arn:aws:quicksight:us-east-1:444444444444:user/HR/nikki_wolf vs arn:aws:quicksight:us-east-1:444444444444:user/Marketing/nikki_wolf. Grant access to one, and the other still gets "access denied." The namespace is part of the identity. Wildcard ARNs like arn:aws:quicksight:us-east-1:444444444444:user/HR/* grant read access to all current and future users in that namespace — handy for broad read-only patterns, but AWS warns against using wildcards for write or admin access.

Migration in One API Call (If You Know the Overrides)

The StartAssetBundleImportJob API accepts OverrideParameters to remap data sources and OverridePermissions to set access controls during import. This avoids a window where assets exist without permissions. AWS shows a complete workflow: export with IncludeAllDependencies=True, import with OverrideParameters for existing data sources (using SecretArn for credentials from Secrets Manager), and OverridePermissions to grant namespace-wide wildcard read access. After import, add granular permissions per group via update_dashboard_permissions. The Python helper functions provided — parse_asset_arn, parse_principal_arn, transform_arn_for_account, build_principal_arn — make it easy to script this pipeline without manual string manipulation.

Troubleshooting common issues: a "Resource not found" error after migration usually means dependencies were missing from the bundle. An "Access denied" for a user who should have access probably means the principal ARN you granted doesn't match the user's namespace or account. Use describe_dashboard_permissions to list granted principals and describe_user to confirm the user's actual ARN. Remember that restricted folders override share permissions entirely – the folder hierarchy takes precedence regardless of ARN correctness.

The next step is obvious: audit your existing migration scripts for the missing IncludeAllDependencies=True flag and switch from manual permission assignment to OverridePermissions in the import job. Automating ARN-aware migration is no longer guesswork.

Source: Amazon Quick ARNs: Cross-account migration and namespace permissions
Domain: aws.amazon.com