Amazon Quick ARNs：跨アカウント移行と名前空間権限の解説
Amazon QuickSight のクロスアカウント移行やネームスペース管理における権限エラーを解決するため、ARN（Amazon Resource Name）の構造と実用的な理解方法を解説する技術記事です。
キーポイント
QuickSight と ARN の命名規則の関係性
サービス名は「QuickSight」だが、ARN や API エンドポイントでは互換性を保つため「quicksight」が識別子として使用され続ける理由と、既存ポリシーへの影響について説明しています。
ARN を住所に例えた理解モデル
ARN の各コンポーネント（パーティション、サービス、リージョン、アカウント ID など）を郵便番号や住所の構成要素に例え、リソースの特定方法を直感的に理解できる枠組みを提供しています。
クロスアカウント移行と権限管理の実践
開発環境から本番環境へのダッシュボード移行時や、他チームとの共有時に発生する「アクセス拒否」エラーを ARN の観点から診断し、解決するための具体的なアプローチを示しています。
マルチテナントアーキテクチャの設計指針
ネームスペースを活用したマルチテナント環境において、同じユーザー名が異なるネームスペースで異なる権限を持つ理由を ARN の構造から解説し、堅牢なアーキテクチャ設計への示唆を与えています。
ネームスペースとアイデンティティの厳密な区別
同じユーザー名でも異なるネームスペースに属すれば全く別のプリンシパルとして扱われ、権限付与にはフル ARN（ネームスペースを含む）を指定する必要があります。
クロスネームスペース共有とワイルドカード
アセットはネームスペースに属さないため複数のネームスペースのユーザーへ共有可能であり、特定のネームスペース内の全ユーザー（新規含む）への権限付与にはワイルドカード ARN が利用できます。
エンドツーエンドな移行ワークフロー
開発環境から依存関係を含むアセットバンドルをエクスポートし、プロダクション環境でデータソースのマップと権限オーバーライドを設定してインポートする一連の手順が推奨されます。
影響分析・編集コメントを表示
影響分析
本記事は、AWS QuickSight を大規模かつ複雑な環境（複数アカウント・マルチテナント）で運用している組織にとって、権限管理のボトルネックを解消し、セキュリティリスクを低減するための重要な技術的指針となります。ARN の構造的理解を深めることで、開発から本番への移行プロセスや、他部門とのデータ共有における摩擦を大幅に削減でき、インフラ設計の成熟度を高める効果が期待されます。
編集コメント
AWS の主要 BI サービスである QuickSight を運用するエンジニアにとって、ARN の仕組みを深く理解することは、権限管理の迷走を防ぐための必須知識です。特に大規模展開やセキュリティ要件が厳しい環境では、この基礎的な理解がシステム全体の安定性を支える重要な要素となります。
開発環境から本番環境へダッシュボードを移行しても、権限が引き継がれないことがあります。Finance チームとダッシュボードを共有しても、「アクセス拒否」のエラーが頻発します。マルチテナント分離のために名前空間を設定しても、同じユーザー名はある名前空間では機能するものの、別の名前空間では動作しないといった問題が発生します。
これらは Amazon Quick の管理者が日常的に取り組む実際のタスクであり、正しく処理するには Amazon Resource Names (ARNs) がどのように機能するかを明確に理解する必要があります。
Amazon Quick は、インタラクティブなダッシュボードの構築、自然言語によるデータクエリ、ワークフローの自動化、アプリケーションへの分析埋め込みを支援する、統合された AI 駆動型のビジネスインテリジェンスサービスです。AWS アカウントや名前空間を跨ぐデプロイメントをスケールさせるにつれ、Amazon Quick が ARN を通じてリソースを識別し保護する方法を理解することが極めて重要になります。
本稿では、Amazon Quick の ARN の構造と、それらを活用するための実用的なメンタルモデルについて解説します。読み終える頃には、ARN を見た瞬間にそれが移行戦略に何を意味するかを理解できるようになり、権限の問題をより迅速に診断し、自信を持ってマルチテナントアーキテクチャを設計できるようになります。
命名に関する注記
今日あなたが利用しているサービスは Amazon Quick ですが、ARN や API エンドポイントでは依然として「quicksight」がサービス識別子として使用されています。これは、既存の AWS Identity and Access Management (IAM) ポリシー、自動化ツール、および顧客環境間の統合との互換性を保つためです。
本記事全体を通じて、以下のような ARN を見ることができます:
arn:aws:quicksight:us-east-1:123456789012:dashboard/...
「quicksight」という部分は、Amazon Quick 内の Quick Sight の機能を指しています。既存のコード、IAM ポリシー、および CLI コマンドは、現在の実装において変更なしで引き続き動作します。詳細については、Amazon Quick Sight Resource ARNs を参照してください。
ARN を郵便住所と考える
「123 Main Street, Springfield, MA」が場所を一意に特定するのと同様に、ARN は AWS 内のリソースを一意に識別します。以下は、ARN の構成要素の視覚的な表現です:
各構成要素のマッピングは以下の通りです:
Component | Analogy | What it represents
---|---|---
aws | 惑星 | AWS パーティション - aws / aws-cn / aws-gov-us
quicksight | 国 | AWS パーティション内のサービス
us-east-1 | 州 | AWS リージョン
111111111111 | 都市 | AWS アカウント ID
dashboard
Street
Resource Type
04f736b4-bd1b-…
House number
Unique Resource ID
*アカウントIDは住所の一部です。新しい都市へ引っ越せば、同じ番地の家でも住所は変わります。Amazon Quick リソースについても同様で、開発用アカウントから本番環境のアカウントへダッシュボードを移行すると、アカウントIDが異なるため ARN が変更されます。
実際の運用例：Dev/QA/Prod
AnyCompany は Amazon Quick のデプロイメントに 3 つの AWS アカウントを使用しています:
- Development (Account: 111111111111): アナリストが新しいダッシュボードを構築する場所。
- QA (Account: 222222222222): リリース前にダッシュボードを検証する場所。
- Production (Account: 333333333333): ビジネスユーザーが承認されたダッシュボードにアクセスする場所。
AnyCompany のデータアナリストである Saanvi は、Development で売上ダッシュボードを構築します:
arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-dash-001
She uses the Asset Bundle APIs to migrate it to QA. The dashboard now has a new ARN:
arn:aws:quicksight:us-east-1:222222222222:dashboard/sales-dash-001
What changed and what didn't:
- アカウント ID が変更されました (111111111111 → 222222222222)。
- リソース ID はそのままです (sales-dash-001)。
- リージョンも同じままです (us-east-1)。
QA のダッシュボードと開発環境のダッシュボードは、リソース ID が共通していても別々のリソースです。異なる ARN は AWS 内における異なるアドレスを意味します。
移行時に権限が引き継がれない理由
開発環境では、Saanvi がチームに閲覧アクセス権限を付与しました:
# Development account permissions
qs.update_dashboard_permissions(
AwsAccountId='111111111111',
DashboardId='sales-dash-001',
GrantPermissions=[{
'Principal': 'arn:aws:quicksight:us-east-1:111111111111:group/default/DataAnalysts',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
}]
)
QA への移行後、ダッシュボードには権限がありません。Amazon QuickSight は、リソース ARN とプリンシパル ARN の間の関係として権限を保存します。元の権限は「アカウント 111111111111 の DataAnalysts グループはこのダッシュボードを閲覧できる」という意味でしたが、QA では:
- ダッシュボードに新しい ARN が付与されました (異なるアカウント)。
- アカウント 111111111111 の DataAnalysts グループは、アカウント 222222222222 には存在しません。
- QA にある DataAnalysts グループは異なる ARN を持っています (QA のアカウント ID を参照)。
*権限はアカウント固有の ARN を参照しているため移行されません。各ターゲット環境で、インポート時または移行後に権限を再設定する必要があります。*
依存チェーンの仕組み
Saanvi のダッシュボードは孤立して存在しているわけではありません。以下のものに依存しています：
- 生データを変換するデータセット (sales-data)。
- データベースに接続するデータソース (sales-db-connection)。
それぞれが固有の ARN を持ち、ダッシュボード内部でこれらを参照しています：
開発アカウント (111111111111):
├── ダッシュボード: arn:aws:quicksight:...:111111111111:dashboard/sales-dash-001
│ └── 参照先: arn:aws:quicksight:...:111111111111:dataset/sales-data
│ └── 参照先: arn:aws:quicksight:...:111111111111:datasource/sales-db-connection
アセットバンドル API を使用してバンドルをターゲットアカウントにインポートすると、これらの内部 ARN 参照は自動的に更新され、新しいアカウント ID が反映されます：
QA アカウント (222222222222):
├── ダッシュボード: arn:aws:quicksight:...:222222222222:dashboard/sales-dash-001
│ └── 参照先: arn:aws:quicksight:...:222222222222:dataset/sales-data
│ └── 参照先: arn:aws:quicksight:...:222222222222:datasource/sales-db-connection
インポートプロセスはこの ARN の変換を自動的に処理しますが、バンドルに含まれるアセットのみが対象となります。データセットやデータソースの依存関係を持たずにダッシュボードだけをインポートした場合、そのダッシュボードはターゲットアカウントに存在しないリソースを参照することになります。
*エクスポートバンドルにはすべての依存関係を含めてください（IncludeAllDependencies=True を使用してください）。インポートプロセスは内部 ARN 参照を自動的に更新しますが、これはバンドルの一部であるアセットに対してのみ適用されます。
OverrideParameters を使用した既存リソースの再利用
一般的なシナリオとして、QA 環境にはすでに QA データベース用のデータソースが設定されている場合があります。重複を作成したくありません。インポートされたダッシュボードで既存の接続を使用したいのです。
StartAssetBundleImportJob API の OverrideParameters はこれに対応します。これにより、インポート時にデータソース接続パラメータ、認証情報、およびリソース ID の動作をオーバーライドできます：
response = qs.start_asset_bundle_import_job(
AwsAccountId='222222222222',
AssetBundleImportJobId='import-sales-dash-to-qa',
AssetBundleImportSource={'Body': bundle_bytes},
OverrideParameters={
'ResourceIdOverrideConfiguration': {
'PrefixForAllResources': False
},
'DataSources': [{
'DataSourceId': 'sales-db-connection',
'DataSourceParameters': {
'AthenaParameters': {
'WorkGroup': 'qa-workgroup'
}
},
'Credentials': {
'CredentialPair': {
'Username': 'qa_service_user',
'Password': '{{resolve:secretsmanager:qa-db-creds:SecretString:password}}'
}
}
}]
}
)
OverrideParameters に関する以下の点にご注意ください：
- ResourceIdOverrideConfiguration は、インポートされたリソース ID にプレフィックスが付与されるかどうかを制御します（ID 競合の回避に有用です）。
- DataSources を使用すると、データソースごとに接続パラメータと認証情報を上書きできます。
- 認証方法：CredentialPair（ユーザー名/パスワード）、CopySourceArn（既存のデータソースからコピー）、または SecretArn（AWS Secrets Manager のシークレットを直接参照）を使用できます。組織が AWS Secrets Manager でデータベース認証情報を管理している場合は、SecretArn を使用してください：
'Credentials': {
'SecretArn': 'arn:aws:secretsmanager:us-east-1:222222222222:secret:qa-db-creds'
}
*移行中に ARN 参照がどのように解決されるかについて、完全な制御権を有します。ID の維持、既存リソースへのマッピング、接続の再構成など、すべてインポート設定を通じて行えます。
Namespaces: マルチテナント環境におけるアイデンティティの仕組み
Amazon Quick namespaces は、単一の AWS アカウント内でマルチテナント分離を提供します。主に以下のような場面で使用されます：
- Amazon Quick を複数の顧客に埋め込む Software as a service (SaaS) プロバイダー。
- 厳格な部門境界を持つ企業。
- ユーザー層を隔離する必要がある企業。
最も重要な概念は、名前空間が影響を与えるのはプリンシパル ARN であり、アセット ARN ではないということです。
マルチテナントの例
AnyCompany は、顧客に分析サービスを提供する SaaS 企業です。彼らは分離のために名前空間を持つ単一の Amazon Quick アカウントを使用しています:
Account: 444444444444
├── Namespace: HR
│ ├── Users: alice, bob
│ └── Groups: Analysts, Executives
├── Namespace: Marketing
│ ├── Users: charlie, diana
│ └── Groups: Analysts, Executives
└── Namespace: default (internal AnyCompany users)
├── Users: admin, sarah
└── Groups: PlatformTeam
HR のユーザー「alice」を見てみましょう:
arn:aws:quicksight:us-east-1:444444444444:user/HR/alice
そして HR の「Analysts」グループを見てみましょう:
arn:aws:quicksight:us-east-1:444444444444:group/HR/Analysts
名前空間 (HR) は ARN に埋め込まれています。これに対し、名前空間コンポーネントを持たないアセットの ARN と比較してみましょう:
Dashboard ARN (名前空間なし):
arn:aws:quicksight:us-east-1:444444444444:dashboard/shared-metrics
User ARN (名前空間あり):
arn:aws:quicksight:us-east-1:444444444444:user/HR/alice
*アセットは名前空間の外に存在します。ユーザーとグループはその内部に存在します。これが名前空間間共有を可能にする仕組みです：単一のダッシュボードを複数の名前空間からのユーザーと共有できます。しかし同時に、常に完全なプリンシパル ARN を指定する必要があります。名前空間はアイデンティティの一部なのです。
同じユーザー名でも異なる人物
同じアカウント内の 2 つの名前空間、すなわち HR 名前空間と Marketing 名前空間を想定してください。両方とも「nikki_wolf」という名前のユーザーを持っています:
HR nikki_wolf: arn:aws:quicksight:us-east-1:444444444444:user/HR/nikki_wolf
Marketing nikki_wolf: arn:aws:quicksight:us-east-1:444444444444:user/Marketing/nikki_wolf
これらは完全に異なるプリンシパルです。ユーザー名は共通していますが、名前空間が異なるため ARN（Amazon リソース名）は異なります。
HR の nikki_wolf にダッシュボードへのアクセス権限を付与しても、Marketing の nikki_wolf はそれを見ることができません。ARN が異なれば、アイデンティティも異なります。
*同じユーザー名でも、異なる名前空間に属する場合は完全に異なるプリンシパルとして扱われます。権限の付与やトラブルシューティングを行う際は、必ずフルパスのプリンシパル ARN（名前空間を含む）を使用してください。*
名前空間を跨ぐ共有
AnyCompany は、全顧客向けにプラットフォーム全体の告知ダッシュボードを共有したいと考えています：
qs.update_dashboard_permissions(
AwsAccountId='444444444444',
DashboardId='platform-announcements',
GrantPermissions=[
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/HR/Executives',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
},
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/Marketing/Executives',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
},
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/default/PlatformTeam',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard',
'quicksight:UpdateDashboard']
}
]
)
1 つのダッシュボード（ARN 1 つ）に対して、3 つの異なる名前空間からのプリンシパルに権限が付与されています。このダッシュボードはいかなる名前空間にも属していません。アカウントレベルで存在し、誰でも共有可能です。
- ダッシュボードやその他のアセットは名前空間に依存しません。各プリンシパルの完全な ARN に権限を付与することで、単一のアセットを任意の名前空間からの複数のプリンシパルと共有できます。
ワイルドカード権限
Amazon QuickSight は、名前空間スコープの付与に対してワイルドカード形式のプリンシパル ARN をサポートしています:
arn:aws:quicksight:us-east-1:444444444444:user/HR/*
これは、HR 名前空間内のすべてのユーザー（現在および将来）へのアクセスを付与します。
qs.update_dashboard_permissions(
AwsAccountId='444444444444',
DashboardId='customer-a-overview',
GrantPermissions=[{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:user/HR/*',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
}]
)
次の点に注意してください:
- ワイルドカードは指定された名前空間内でのみ適用されます。マーケティングユーザーにはアクセス権が付与されません。
- アセットバンドルのインポート時に、OverridePermissions（オーバーライド権限）でもワイルドカードがサポートされているため、移行パイプラインの一部として広範な権限パターンを設定できます。
- ワイルドカードは読み取り専用アクセスパターンにおいて最も効果的です。書き込みや管理アクセスについては、明示的なグループベースの付与が推奨されます。
*ワイルドカードにより、名前空間内の現在および将来のすべてのユーザーにアクセス権が付与されます。広範な読み取りアクセスを簡素化しますが、書き込み権限には注意して使用してください。*
すべてを組み合わせて：エンドツーエンドの移行
前のセクションで説明した内容をすべて組み合わせた完全なワークフローをご紹介します。
シナリオ: AnyCompany は、Sales Analytics スイートを開発環境から本番環境へ移行しています。同社には以下のリソースがあります:
- ダッシュボードが 3 つ。
- データセットが 5 つ。
- データソースが 2 つ（1 つは Amazon Athena、もう 1 つは Amazon Redshift）。
- 2 つの名前空間に所属するユーザー（SalesTeam、Executives）。
ステップ 1：開発環境からのエクスポート
StartAssetBundleExportJob API を使用して、ダッシュボードとそれらのすべての依存関係（データセット、データソース）をポータブルなバンドルにパッケージ化します。IncludeAllDependencies=True に設定することで、参照される各リソースを手動で追跡することなく、完全な依存関係ツリーを取得できます。
export_response = qs.start_asset_bundle_export_job(
AwsAccountId='111111111111',
AssetBundleExportJobId='sales-analytics-export',
ResourceArns=[
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-overview',
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-details',
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-trends'
],
IncludeAllDependencies=True,
ExportFormat='QUICKSIGHT_JSON'
)
ステップ 2：オーバーライド付きでの本番環境へのインポート
本番環境にはすでにデータソースが設定されています。インポートされたアセットをそれらにマッピングし、インポート時に権限を設定します：
import_response = qs.start_asset_bundle_import_job(
AwsAccountId='333333333333',
AssetBundleImportJobId='sales-analytics-import',
AssetBundleImportSource={'Body': bundle_bytes},
OverrideParameters={
'ResourceIdOverrideConfiguration': {
'PrefixForAllResources': False
},
'DataSources': [
{
'DataSourceId': 'dev-athena-source',
'Name': 'Production Athena',
'DataSourceParameters': {
'AthenaParameters': {'WorkGroup': 'prod-workgroup'}
}
},
{
'DataSourceId': 'dev-redshift-source',
'Name': 'Production Redshift',
'DataSourceParameters': {
'RedshiftParameters': {
'Host': 'prod-cluster.xxxxx.us-east-1.redshift.amazonaws.com',
'Database': 'analytics',
'Port': 5439
}
},
'Credentials': {
'SecretArn
原文を表示
You 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.
These are real tasks that Amazon Quick administrators tackle regularly, and getting them right requires a clear understanding of how Amazon Resource Names (ARNs) work.
Amazon Quick 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.
In 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.
A note on naming
Amazon 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.
Throughout this post, you see ARNs like:
arn:aws:quicksight:us-east-1:123456789012:dashboard/...The “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.
Think of ARNs as postal addresses
Just 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:
Here’s how the components map:
Component
Analogy
What it represents
aws
Planet
AWS partition- aws / aws-cn / aws-gov-us
quicksight
Country
The Service within an AWS partition
us-east-1
State
AWS Region
111111111111
City
AWS Account ID
dashboard
Street
Resource Type
04f736b4-bd1b-…
House number
Unique Resource ID
The 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.
What this looks like in practice: Dev/QA/Prod
AnyCompany has three AWS accounts for their Amazon Quick deployment:
- Development (Account: 111111111111): Where analysts build new dashboards.
- QA (Account: 222222222222): Where dashboards are tested before release.
- Production (Account: 333333333333): Where business users access approved dashboards.
Saanvi, a data analyst at AnyCompany, builds a sales dashboard in Development:
arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-dash-001She uses the Asset Bundle APIs to migrate it to QA. The dashboard now has a new ARN:
arn:aws:quicksight:us-east-1:222222222222:dashboard/sales-dash-001What changed and what didn’t:
- Account ID changed (111111111111 → 222222222222).
- Resource ID stayed the same (sales-dash-001).
- Region stayed the same (us-east-1).
The 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.
Why permissions don’t transfer during migration
In development, Saanvi granted view access to her team:
# Development account permissions
qs.update_dashboard_permissions(
AwsAccountId='111111111111',
DashboardId='sales-dash-001',
GrantPermissions=[{
'Principal': 'arn:aws:quicksight:us-east-1:111111111111:group/default/DataAnalysts',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
}]
)After 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:
- The dashboard has a new ARN (different account).
- The DataAnalysts group in account 111111111111 doesn’t exist in account 222222222222.
- A DataAnalysts group in QA has a different ARN (it references QA’s account ID).
Permissions don’t migrate because they reference account-specific ARNs. You must re-establish permissions in each target environment, either during import or after.
How the dependency chain works
Saanvi’s dashboard doesn’t exist in isolation. It depends on:
- A dataset (sales-data) that transforms the raw data.
- A data source (sales-db-connection) that connects to the database.
Each has its own ARN, and the dashboard internally references them:
Development Account (111111111111):
├── Dashboard: arn:aws:quicksight:...:111111111111:dashboard/sales-dash-001
│ └── References: arn:aws:quicksight:...:111111111111:dataset/sales-data
│ └── References: arn:aws:quicksight:...:111111111111:datasource/sales-db-connectionWhen the Asset Bundle APIs import the bundle into the target account, they automatically update these internal ARN references to reflect the new account ID:
QA Account (222222222222):
├── Dashboard: arn:aws:quicksight:...:222222222222:dashboard/sales-dash-001
│ └── References: arn:aws:quicksight:...:222222222222:dataset/sales-data
│ └── References: arn:aws:quicksight:...:222222222222:datasource/sales-db-connectionThe 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.
Always 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.
Reusing existing resources with OverrideParameters
A 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.
OverrideParameters in the StartAssetBundleImportJob API handles this. It lets you override data source connection parameters, credentials, and resource ID behavior during import:
response = qs.start_asset_bundle_import_job(
AwsAccountId='222222222222',
AssetBundleImportJobId='import-sales-dash-to-qa',
AssetBundleImportSource={'Body': bundle_bytes},
OverrideParameters={
'ResourceIdOverrideConfiguration': {
'PrefixForAllResources': False
},
'DataSources': [{
'DataSourceId': 'sales-db-connection',
'DataSourceParameters': {
'AthenaParameters': {
'WorkGroup': 'qa-workgroup'
}
},
'Credentials': {
'CredentialPair': {
'Username': 'qa_service_user',
'Password': '{{resolve:secretsmanager:qa-db-creds:SecretString:password}}'
}
}
}]
}
)Note the following about OverrideParameters:
- ResourceIdOverrideConfiguration controls whether imported resource IDs get a prefix (useful for avoiding ID conflicts).
- With DataSources, you can override connection parameters and credentials per data source.
- 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:
'Credentials': {
'SecretArn': 'arn:aws:secretsmanager:us-east-1:222222222222:secret:qa-db-creds'
}You 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.
Namespaces: How identity works in multi-tenant environments
Amazon Quick namespaces provide multi-tenant isolation within a single AWS account. They’re commonly used by:
- Software as a service (SaaS) providers who embed Amazon Quick for multiple customers.
- Enterprises with strict departmental boundaries.
- Companies that need to isolate user populations.
Here’s the concept that matters most: namespaces affect principal ARNs, not asset ARNs.
A multi-tenant example
AnyCompany is a SaaS company providing analytics to their customers. They use a single Amazon Quick account with namespaces for isolation:
Account: 444444444444
├── Namespace: HR
│ ├── Users: alice, bob
│ └── Groups: Analysts, Executives
├── Namespace: Marketing
│ ├── Users: charlie, diana
│ └── Groups: Analysts, Executives
└── Namespace: default (internal AnyCompany users)
├── Users: admin, sarah
└── Groups: PlatformTeamLook at the user “alice” in HR:
arn:aws:quicksight:us-east-1:444444444444:user/HR/aliceAnd the “Analysts” group in HR:
arn:aws:quicksight:us-east-1:444444444444:group/HR/AnalystsThe namespace (HR) is embedded in the ARN. Compare this to asset ARNs, which have no namespace component:
Dashboard ARN (no namespace):
arn:aws:quicksight:us-east-1:444444444444:dashboard/shared-metrics
User ARN (has namespace):
arn:aws:quicksight:us-east-1:444444444444:user/HR/aliceAssets 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.
Same username, different people
Consider two namespaces in the same account: the HR namespace and the Marketing namespace. Both have a user named “nikki_wolf”:
HR nikki_wolf: arn:aws:quicksight:us-east-1:444444444444:user/HR/nikki_wolf
Marketing nikki_wolf: arn:aws:quicksight:us-east-1:444444444444:user/Marketing/nikki_wolfThese are completely different principals. They share a username, but their ARNs are different because the namespace is different.
Grant dashboard access to HR’s nikki_wolf, and Marketing’s nikki_wolf still can’t see it. Different ARNs, different identities.
The same username in different namespaces represents completely different principals. Always use the full principal ARN (including namespace) when granting or troubleshooting permissions.
Cross-namespace sharing
AnyCompany wants to share a platform-wide announcement dashboard with all customers:
qs.update_dashboard_permissions(
AwsAccountId='444444444444',
DashboardId='platform-announcements',
GrantPermissions=[
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/HR/Executives',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
},
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/Marketing/Executives',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
},
{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/default/PlatformTeam',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard',
'quicksight:UpdateDashboard']
}
]
)A 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.
Dashboards 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.
Wildcard permissions
Amazon Quick supports wildcard principal ARNs for namespace-scoped grants:
arn:aws:quicksight:us-east-1:444444444444:user/HR/*This grants access to all users in the HR namespace, current and future:
qs.update_dashboard_permissions(
AwsAccountId='444444444444',
DashboardId='customer-a-overview',
GrantPermissions=[{
'Principal': 'arn:aws:quicksight:us-east-1:444444444444:user/HR/*',
'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
}]
)Keep the following in mind:
- The wildcard applies only within the specified namespace. Marketing users won’t gain access.
- Wildcards are also supported in OverridePermissions during asset bundle import, so you can set broad permission patterns as part of your migration pipeline.
- Wildcards work best for read-only access patterns. For write or administrative access, explicit group-based grants are preferred.
Wildcards grant access to all current and future users in a namespace. They simplify broad read access but should be used carefully for write permissions.
Putting it all together: end-to-end migration
Here’s a complete workflow that combines everything in the preceding sections.
Scenario: AnyCompany is migrating their Sales Analytics suite from Development to Production. They have:
- Three dashboards.
- Five datasets.
- Two data sources (one Amazon Athena, one Amazon Redshift).
- Users in two namespaces (SalesTeam, Executives).
Step 1: Export from development
Use 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.
export_response = qs.start_asset_bundle_export_job(
AwsAccountId='111111111111',
AssetBundleExportJobId='sales-analytics-export',
ResourceArns=[
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-overview',
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-details',
'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-trends'
],
IncludeAllDependencies=True,
ExportFormat='QUICKSIGHT_JSON'
)Step 2: Import to production with overrides
Production already has data sources configured. Map the imported assets to use them, and set permissions during import:
import_response = qs.start_asset_bundle_import_job(
AwsAccountId='333333333333',
AssetBundleImportJobId='sales-analytics-import',
AssetBundleImportSource={'Body': bundle_bytes},
OverrideParameters={
'ResourceIdOverrideConfiguration': {
'PrefixForAllResources': False
},
'DataSources': [
{
'DataSourceId': 'dev-athena-source',
'Name': 'Production Athena',
'DataSourceParameters': {
'AthenaParameters': {'WorkGroup': 'prod-workgroup'}
}
},
{
'DataSourceId': 'dev-redshift-source',
'Name': 'Production Redshift',
'DataSourceParameters': {
'RedshiftParameters': {
'Host': 'prod-cluster.xxxxx.us-east-1.redshift.amazonaws.com',
'Database': 'analytics',
'Port': 5439
}
},
'Credentials': {
'SecretArn
関連記事
Amazon Athena と Amazon QuickSight を活用した Amazon SageMaker 上のエージェント型 AI アナリティクスの実現
Amazon は、大規模な構造化・非構造化データから迅速に洞察を得るため、Amazon SageMaker でエージェント型 AI アナリティクスを可能にするアーキテクチャを発表しました。これにより、SQL やデータモデリングの専門知識がなくても意思決定を加速できます。
AWSがセキュリティテストとクラウド運用のためのフロンティアエージェントをローンチ
AWSは、オンデマンドのペネトレーションテストを行う「AWS Security Agent」と「AWS DevOps Agent」を一般提供開始した。これらはre:Inventで発表された自律型AIシステム「フロンティアエージェント」の新カテゴリを代表する。
リスクを発見し、修正する：Cloudflare CASBの修復機能を導入
Cloudflareは、Cloudflare CASBにリスク修正機能を追加した。同社のAPIベースのCASBは、SaaSアプリケーションのファイル共有リスクを可視化・検出するだけでなく、ダッシュボードから直接修正できるようになった。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み