{"slug": "amazon-quick-arns-cross-account-migration-and-namespace-permissions", "title": "Amazon Quick ARNs: Cross-account migration and namespace permissions", "summary": "Amazon Quick ARNs change when dashboards migrate across AWS accounts, causing permissions to not transfer automatically because the account ID component of the ARN differs. For example, a dashboard with ARN `arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-dash-001` in development becomes `arn:aws:quicksight:us-east-1:222222222222:dashboard/sales-dash-001` in QA, requiring separate IAM policies for each account. Understanding ARN structure is critical for diagnosing access issues, designing multi-tenant namespaces, and planning cross-account migration strategies in Amazon Quick.", "body_md": "[Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# Amazon Quick ARNs: Cross-account migration and namespace permissions\n\nYou migrate dashboards from development to production, but the permissions don’t carry over. You share a dashboard with your Finance team, but they keep getting “access denied.” You set up namespaces for multi-tenant isolation, and the same username works in one namespace but not another.\n\nThese are real tasks that Amazon Quick administrators tackle regularly, and getting them right requires a clear understanding of how Amazon Resource Names (ARNs) work.\n\n[Amazon Quick](https://aws.amazon.com/quicksight/) is a unified, AI-powered business intelligence service that helps you build interactive dashboards, query data in natural language, automate workflows, and embed analytics directly into applications. As you scale your deployments across multiple AWS accounts and namespaces, understanding how Amazon Quick identifies and secures resources through ARNs becomes critical.\n\nIn this post, we cover the structure of Amazon Quick ARNs and provide a practical mental model for working with them. By the end, you can look at an ARN and immediately understand what it means for your migration strategy, diagnose permission issues faster, and design multi-tenant architectures with confidence.\n\n## A note on naming\n\nAmazon Quick is the service that you use today, but ARNs and API endpoints still use “quicksight” as the service identifier. We keep this for compatibility with existing AWS Identity and Access Management (IAM) policies, automation, and integrations across customer environments.\n\nThroughout this post, you see ARNs like:\n\nThe “quicksight” portion refers to the Quick Sight capability within Amazon Quick. Existing code, IAM policies, and CLI commands continue to work without modification for current implementations. For more information, see [Amazon Quick Sight Resource ARNs](https://docs.aws.amazon.com/quicksight/latest/APIReference/qs-resource-arns.html).\n\n## Think of ARNs as postal addresses\n\nJust as “123 Main Street, Springfield, MA” uniquely identifies a location, an ARN uniquely identifies a resource in AWS. The following is a visual representation of the components of an ARN:\n\nHere’s how the components map:\n\nComponent |\nAnalogy |\nWhat it represents |\n| aws | Planet | AWS partition- aws / aws-cn / aws-gov-us |\n| quicksight | Country | The Service within an AWS partition |\n| us-east-1 | State | AWS Region |\n| 111111111111 | City | AWS Account ID |\n| dashboard | Street | Resource Type |\n| 04f736b4-bd1b-… | House number | Unique Resource ID |\n\nThe account ID is part of the address. Move to a new city, and your address changes, even if you get a house with the same street number. The same applies to Amazon Quick resources. Migrate a dashboard from your development account to production, and the ARN changes because the account ID is different.\n\n## What this looks like in practice: Dev/QA/Prod\n\nAnyCompany has three AWS accounts for their Amazon Quick deployment:\n\n- Development (Account: 111111111111): Where analysts build new dashboards.\n- QA (Account: 222222222222): Where dashboards are tested before release.\n- Production (Account: 333333333333): Where business users access approved dashboards.\n\nSaanvi, a data analyst at AnyCompany, builds a sales dashboard in Development:\n\nShe uses the [Asset Bundle APIs](https://docs.aws.amazon.com/quicksight/latest/developerguide/asset-bundle-ops.html) to migrate it to QA. The dashboard now has a new ARN:\n\nWhat changed and what didn’t:\n\n- Account ID changed (111111111111 → 222222222222).\n- Resource ID stayed the same (sales-dash-001).\n- Region stayed the same (us-east-1).\n\nThe dashboard in QA is a different resource than the one in Development, even though they share the same resource ID. Different ARNs mean different addresses in the AWS universe.\n\n### Why permissions don’t transfer during migration\n\nIn development, Saanvi granted view access to her team:\n\nAfter migration to QA, the dashboard has no permissions. Amazon Quick stores permissions as relationships between resource ARNs and principal ARNs. The original permission said “the DataAnalysts group in account 111111111111 can view this dashboard.” But in QA:\n\n- The dashboard has a new ARN (different account).\n- The DataAnalysts group in account 111111111111 doesn’t exist in account 222222222222.\n- A DataAnalysts group in QA has a different ARN (it references QA’s account ID).\n\nPermissions don’t migrate because they reference account-specific ARNs. You must re-establish permissions in each target environment, either during import or after.\n\n### How the dependency chain works\n\nSaanvi’s dashboard doesn’t exist in isolation. It depends on:\n\n- A dataset (sales-data) that transforms the raw data.\n- A data source (sales-db-connection) that connects to the database.\n\nEach has its own ARN, and the dashboard internally references them:\n\nWhen the Asset Bundle APIs import the bundle into the target account, they automatically update these internal ARN references to reflect the new account ID:\n\nThe import process handles this ARN transformation automatically, but only for assets included in the bundle. If you import only the dashboard without its dataset and data source dependencies, the dashboard references resources that don’t exist in the target account.\n\nAlways include all dependencies in your export bundle (use IncludeAllDependencies=True). The import process updates internal ARN references automatically, but only for assets that are part of the bundle.\n\n### Reusing existing resources with OverrideParameters\n\nA common scenario: QA already has a data source configured for the QA database. You don’t want a duplicate. You want the imported dashboard to use the existing connection.\n\nOverrideParameters in the StartAssetBundleImportJob API handles this. It lets you override data source connection parameters, credentials, and resource ID behavior during import:\n\nNote the following about OverrideParameters:\n\n- ResourceIdOverrideConfiguration controls whether imported resource IDs get a prefix (useful for avoiding ID conflicts).\n- With DataSources, you can override connection parameters and credentials per data source.\n- Credential methods: You can use CredentialPair (username/password), CopySourceArn (copy from an existing data source), or SecretArn (reference an AWS Secrets Manager secret directly). Use SecretArn when your organization manages database credentials in AWS Secrets Manager:\n\nYou have full control over how ARN references are resolved during migration. Preserve IDs, map to existing resources, or reconfigure connections, all through the import configuration.\n\n## Namespaces: How identity works in multi-tenant environments\n\nAmazon Quick [namespaces](https://docs.aws.amazon.com/quicksight/latest/developerguide/namespace-operations.html) provide multi-tenant isolation within a single AWS account. They’re commonly used by:\n\n- Software as a service (SaaS) providers who embed Amazon Quick for multiple customers.\n- Enterprises with strict departmental boundaries.\n- Companies that need to isolate user populations.\n\nHere’s the concept that matters most: namespaces affect principal ARNs, not asset ARNs.\n\n### A multi-tenant example\n\nAnyCompany is a SaaS company providing analytics to their customers. They use a single Amazon Quick account with namespaces for isolation:\n\nLook at the user “alice” in HR:\n\nAnd the “Analysts” group in HR:\n\nThe namespace (HR) is embedded in the ARN. Compare this to asset ARNs, which have no namespace component:\n\nAssets exist outside namespaces. Users and groups exist inside them. This is what supports cross-namespace sharing: a single dashboard can be shared with users from multiple namespaces. But it also means that you must always specify full principal ARNs. The namespace is part of the identity.\n\n### Same username, different people\n\nConsider two namespaces in the same account: the HR namespace and the Marketing namespace. Both have a user named “nikki_wolf”:\n\nThese are completely different principals. They share a username, but their ARNs are different because the namespace is different.\n\nGrant dashboard access to HR’s nikki_wolf, and Marketing’s nikki_wolf still can’t see it. Different ARNs, different identities.\n\nThe same username in different namespaces represents completely different principals. Always use the full principal ARN (including namespace) when granting or troubleshooting permissions.\n\n### Cross-namespace sharing\n\nAnyCompany wants to share a platform-wide announcement dashboard with all customers:\n\nA single dashboard (one ARN) has permissions granted to principals from three different namespaces. The dashboard doesn’t belong to any namespace. It exists at the account level and can be shared with anyone.\n\nDashboards and other assets are namespace-independent. You can share a single asset with principals from any number of namespaces by granting permissions to their full principal ARNs.\n\n### Wildcard permissions\n\nAmazon Quick supports wildcard principal ARNs for namespace-scoped grants:\n\nThis grants access to all users in the HR namespace, current and future:\n\nKeep the following in mind:\n\n- The wildcard applies only within the specified namespace. Marketing users won’t gain access.\n- Wildcards are also supported in OverridePermissions during asset bundle import, so you can set broad permission patterns as part of your migration pipeline.\n- Wildcards work best for read-only access patterns. For write or administrative access, explicit group-based grants are preferred.\n\nWildcards grant access to all current and future users in a namespace. They simplify broad read access but should be used carefully for write permissions.\n\n## Putting it all together: end-to-end migration\n\nHere’s a complete workflow that combines everything in the preceding sections.\n\nScenario: AnyCompany is migrating their Sales Analytics suite from Development to Production. They have:\n\n- Three dashboards.\n- Five datasets.\n- Two data sources (one Amazon Athena, one Amazon Redshift).\n- Users in two namespaces (SalesTeam, Executives).\n\n### Step 1: Export from development\n\nUse the StartAssetBundleExportJob API to package the dashboards and all their dependencies (datasets, data sources) into a portable bundle. Setting IncludeAllDependencies=True supports capturing the full dependency tree without manually tracking each referenced resource.\n\n### Step 2: Import to production with overrides\n\nProduction already has data sources configured. Map the imported assets to use them, and set permissions during import:\n\nUsing **OverridePermissions** alongside **OverrideParameters** sets permissions during import rather than as a separate step, reducing the window where resources exist without proper access controls.\n\n### Step 3: Grant additional granular permissions\n\nWildcards in Step 2 gave broad read access to the entire SalesTeam namespace. For role-specific access, such as limiting certain dashboards to the Leadership group within the Executives namespace, grant permissions individually after import:\n\n### ARN transformation summary\n\nAsset |\nDevelopment ARN |\nProduction ARN |\n| Dashboard | …111111111111:dashboard/sales-overview | …333333333333:dashboard/sales-overview |\n| Dataset | …111111111111:dataset/sales-data | …333333333333:dataset/sales-data |\n| Data Source | …111111111111:datasource/dev-athena-source | …333333333333:datasource/dev-athena-source |\n\nResource IDs stayed the same. Account IDs changed. The import process updated internal references automatically. You set permissions through OverridePermissions and follow-up grants.\n\nUse OverrideParameters to reconfigure data source connections and OverridePermissions to set access controls during import. This gives you a complete, repeatable migration in a single API call.\n\n## Quick reference: ARN formats\n\nNote: ARNs use the “quicksight” as identifier for backward compatibility.\n\n### Asset ARNs (no namespace)\n\nResource Type |\nARN Format |\n| Dashboard | arn:aws:quicksight:{region}:{account}:dashboard/{id} |\n| Analysis | arn:aws:quicksight:{region}:{account}:analysis/{id} |\n| Dataset | arn:aws:quicksight:{region}:{account}:dataset/{id} |\n| Data Source | arn:aws:quicksight:{region}:{account}:datasource/{id} |\n| Theme | arn:aws:quicksight:{region}:{account}:theme/{id} |\n| Folder | arn:aws:quicksight:{region}:{account}:folder/{id} |\n| Topic | arn:aws:quicksight:{region}:{account}:topic/{id} |\n\n### Principal ARNs (with namespace)\n\nPrincipal Type |\nARN Format |\n| User | arn:aws:quicksight:{region}:{account}:user/{namespace}/{username} |\n| Group | arn:aws:quicksight:{region}:{account}:group/{namespace}/{groupname} |\n| Wildcard (all users in namespace) | arn:aws:quicksight:{region}:{account}:user/{namespace}/* |\n\n## Utility functions\n\nThe following Python helper functions make it easier to parse, transform, and construct ARNs programmatically. Use them in your migration scripts and CI/CD pipelines to avoid manual string manipulation errors.\n\n## Troubleshooting guide\n\nThe following sections cover the most common ARN-related issues you encounter during migration and permission management, along with diagnostic steps to resolve them.\n\n### “Resource not found” after migration\n\nSymptom: Dashboard loads but shows “Dataset not found” errors.\n\nCause: The dashboard references a dataset ARN from the source account, or dependencies were not included in the import bundle.\n\nFix: Verify all dependencies were included in the export (use IncludeAllDependencies=True), or use ResourceIdOverrideConfiguration to map to existing target resources. Confirm the import job completed successfully by calling DescribeAssetBundleImportJob.\n\n### “Access denied” for a user who should have access\n\nSymptom: A user can’t see a dashboard that was shared with them.\n\nDiagnosis checklist:\n\n- What namespace is the user in?\n- What principal ARN did you grant permissions to?\n- Do they match?\n- Is the resource in a restricted folder?\n\nRestricted folders: If the resource is in a restricted folder, you can’t share it directly regardless of ARN correctness. You can access resources in restricted folders only through container permissions within the restricted folder hierarchy. The ARN and permissions might look correct, but the folder-level restriction takes precedence.\n\n### “Invalid principal” when granting permissions\n\nSymptom: API returns an error when trying to grant permissions.\n\nCause: The principal ARN is malformed, or the user/group doesn’t exist in the specified namespace.\n\nFix: Verify the principal exists before granting:\n\n## Conclusion\n\nIn this post, we showed how Amazon Quick ARNs work in cross-account migration and namespace permission scenarios. Understanding Amazon Quick ARNs comes down to four things:\n\n- ARNs are account-bound. When you migrate between accounts, the address changes even if the resource ID stays the same.\n- Permissions reference full ARNs, not names. Granting access to “nikki_wolf” requires specifying account and namespace. You’re always granting to a specific ARN.\n- Assets live outside namespaces and principals live inside them. This supports cross-namespace sharing but means you need full principal ARNs every time. The same username in different namespaces represents different people.\n- Migration changes ARNs but preserves resource IDs. The Asset Bundle APIs handle internal reference updates. You can set permissions during import using OverridePermissions or grant them separately afterward.\n\n## Next steps\n\nTo start applying these concepts in your own environment:\n\n- Review the\n[Asset Bundle Operations documentation](https://docs.aws.amazon.com/quicksight/latest/developerguide/asset-bundle-ops.html)to set up your first cross-account migration pipeline. - Explore\n[Amazon Quick namespaces](https://docs.aws.amazon.com/quicksight/latest/user/namespaces.html)if you’re planning multi-tenant architectures. - Reference the\n[StartAssetBundleImportJob API](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_StartAssetBundleImportJob.html)for the full OverrideParameters and OverridePermissions schema. - Review\n[Amazon Quick permissions](https://docs.aws.amazon.com/quicksight/latest/user/security_iam_quicksight-manage-permissions.html)for IAM integration patterns. - Refer to the list of\n[Amazon Quick ARNs](https://docs.aws.amazon.com/quicksight/latest/APIReference/qs-resource-arns.html)for all the resource ARN formats.\n\nTry this solution yourself in the [AWS Management Console](https://quicksight.aws.amazon.com/) and let us know how it works for your migration and multi-tenant scenarios.", "url": "https://wpnews.pro/news/amazon-quick-arns-cross-account-migration-and-namespace-permissions", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/amazon-quick-arns-cross-account-migration-and-namespace-permissions/", "published_at": "2026-06-08 16:07:29+00:00", "updated_at": "2026-06-11 17:30:52.098537+00:00", "lang": "en", "topics": ["artificial-intelligence"], "entities": ["Amazon Quick", "AWS", "Amazon Resource Names", "Finance team"], "alternates": {"html": "https://wpnews.pro/news/amazon-quick-arns-cross-account-migration-and-namespace-permissions", "markdown": "https://wpnews.pro/news/amazon-quick-arns-cross-account-migration-and-namespace-permissions.md", "text": "https://wpnews.pro/news/amazon-quick-arns-cross-account-migration-and-namespace-permissions.txt", "jsonld": "https://wpnews.pro/news/amazon-quick-arns-cross-account-migration-and-namespace-permissions.jsonld"}}