Amazon Quick ARNs: Cross-account migration and namespace permissions｜Amazon Quick ARNs：跨アカウント移行と名前空間権限の解説 | AIニュース最前線

開発環境から本番環境へダッシュボードを移行しても、権限が引き継がれないことがあります。Finance チームとダッシュボードを共有しても、「アクセス拒否」のエラーが頻発します。マルチテナント分離のために名前空間を設定しても、同じユーザー名はある名前空間では機能するものの、別の名前空間では動作しないといった問題が発生します。 これらは Amazon Quick の管理者が日常的に取り組む実際のタスクであり、正しく処理するには Amazon Resource Names (ARNs) がどのように機能するかを明確に理解する必要があります。 [Amazon Quick](https://aws.amazon.com/quicksight/) は、インタラクティブなダッシュボードの構築、自然言語によるデータクエリ、ワークフローの自動化、アプリケーションへの分析埋め込みを支援する、統合された 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](https://docs.aws.amazon.com/quicksight/latest/APIReference/qs-resource-arns.html) を参照してください。 ## ARN を郵便住所と考える 「123 Main Street, Springfield, MA」が場所を一意に特定するのと同様に、ARN は AWS 内のリソースを一意に識別します。以下は、ARN の構成要素の視覚的な表現です: ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/02/ML-20693-1.png) 各構成要素のマッピングは以下の通りです: 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](https://docs.aws.amazon.com/quicksight/latest/developerguide/asset-bundle-ops.html) 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](https://docs.aws.amazon.com/quicksight/latest/developerguide/namespace-operations.html) は、単一の 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

Amazon Quick ARNs：跨アカウント移行と名前空間権限の解説

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト