Amazon QuickSightのダッシュボードを別のAWSアカウントへ移すときは、アセットバンドルで定義をエクスポートし、移行先へインポートする方法が使えます。ただし、ダッシュボードの見た目をコピーするだけで、接続先や閲覧権限まで利用可能になるとは限りません。
移行を考える際は、「画面の定義」「参照するデータ」「利用者のアクセス」の3つを順に準備すると、確認漏れを減らせます。
アセットバンドルで移せるもの
対象には、ダッシュボード、分析、データセット、データソース、テーマ、更新スケジュール、VPC接続、フォルダーなどがあります。一方、ファイルアップロード型のデータソース・データセットは非対応です。対応範囲は公式のアセットバンドル仕様で確認してください。
エクスポートされるのはアセットの定義であり、アセット内の実データは含まれません。データセット定義を移せても、元のデータベースやS3のデータが別アカウントへコピーされるわけではありません。移行先から既存データを参照するか、データ自体も別途移すかを先に決めます。
1. 移行先でデータを利用できる状態を用意する
移行先アカウントではQuickSightの利用設定を済ませ、必要なユーザー・グループを準備します。データソースに対するアクセス許可と通信経路も確認します。VPC内のデータベースなら、接続情報だけでなく、ネットワーク経路やセキュリティグループも移行計画に含めます。
| 確認する対象 | 移行前に決めること |
|---|---|
| データソース | 元の接続先を使うか、移行先のDB・S3へ変更するか |
| 認証情報 | 移行先で使う資格情報をどう設定するか |
| 利用者 | どのユーザー・グループに閲覧や編集を許可するか |
| アセットID | 移行先の既存アセットと衝突しないか |
2. ダッシュボードと依存関係をエクスポートする
移行元で StartAssetBundleExportJob を呼び出し、対象のARNを指定します。ダッシュボードはデータセットやデータソースなどを参照するため、IncludeAllDependencies を使って依存する定義も含めると、まとめて準備しやすくなります。
処理は非同期です。開始APIが返った段階ではファイル取得まで完了していないため、DescribeAssetBundleExportJob で成功を確認し、返されたダウンロードURLからバンドルを取得します。詳細はエクスポート操作の公式手順を参照できます。
3. 移行方法に合わせて形式を選ぶ
| 形式 | 移行先への適用方法 | 検討しやすい用途 |
|---|---|---|
| QUICKSIGHT_JSON | QuickSightのインポートAPIで.qsバンドルを読み込む | アセットを直接コピーし、接続先などを上書きする |
| CLOUDFORMATION_JSON | CloudFormationのスタックとして適用する | 他の構成と合わせてテンプレートで管理する |
形式によって投入先が異なります。CloudFormation形式のファイルを StartAssetBundleImportJob へ渡すことはできません。以降はQUICKSIGHT_JSON形式をインポートする流れです。
4. 移行先の値でインポートする
移行先アカウントで StartAssetBundleImportJob を実行し、必要に応じてデータソースの接続情報などを上書きします。S3経由でバンドルを渡す場合は、移行先QuickSightと同じAWSアカウントのバケットを使用します。
依存するアセットはバンドルへ含めるか、移行先にあらかじめ用意しておく必要があります。実行後は DescribeAssetBundleImportJob で状態とエラーを確認します。失敗時のロールバック方針も指定できるため、既存環境へ投入する前に決めておきます。設定項目はインポート操作の公式手順を確認してください。
API実行権限と、ダッシュボード利用権限を分ける
エクスポート・インポートを実行するIAMプリンシパルは、QuickSightのユーザーとして登録されている必要はありません。ただし、API実行に必要なIAM権限が必要です。QuickSight内のAdminやAuthorであることだけで、この権限確認を置き換えることはできません。
権限設計の出発点として、AWS管理ポリシー AWSQuickSightAssetBundleExportPolicy と AWSQuickSightAssetBundleImportPolicy があります。適用する際は対象アセットと操作範囲を確認します。詳細はアセットバンドルのアクセス許可を参照してください。
また、APIを実行できることと、利用者が移行後のダッシュボードを開けることは別です。移行先のユーザー・グループへの共有を明示的に確認します。権限を含めるオプションを使う場合も、移行元の利用者の識別情報を、そのまま移行先で使えると決めつけないようにします。
完了の判断は「画面が作成された」より先まで
- 移行先の閲覧者でダッシュボードを開けるか。
- データソースへ接続でき、必要なデータを取得できるか。
- SPICEを利用する場合、取り込み・更新が成功するか。
- フィルターや計算項目を含め、代表的な条件で期待する結果になるか。
- 更新スケジュールと共有範囲が運用要件に合うか。
まず小さなダッシュボードで、定義の移行からデータ取得・閲覧までの一連の流れを確認すると、全体移行に必要な作業を見積もりやすくなります。
