【Breaking News】Amazon QuickSight がついにクロスアカウント Athena アクセスを解禁！データサイロを破壊せよ。

Amazon QuickSight は、IAM ロールチェーンを使用して Amazon Athena データソースへのクロスアカウントアクセスをサポートしました。これにより、QuickSight がデプロイされているアカウントとは異なる AWS アカウントに存在する Athena データに直接クエリを実行可能になります。クエリの実行コストは、データが存在するターゲットアカウント側に請求される仕組みです。

🚀 エンジニアに朗報！データ集約の苦悩から解放される日

これまで、マルチアカウント構成の環境で「データはあっちのアカウントにあるけれど、QuickSight で可視化したい」という場合、データのコピーやETLによる集約作業が必要でした。これが、IAM ロールチェーンを活用した直接アクセスにより、劇的に簡素化されます。

💡 技術的なポイントと解決される課題

• データサイロの解消: 物理的なデータの移動なしに、セキュリティポリシーを維持したままクロスアカウントでの分析が可能になります。
• コスト責任の明確化: Athena のクエリ費用はデータ保持アカウント側に請求されるため、ガバナンスが効きやすい設計です。
• きめ細かな権限分離: 1つのアカウントに対して複数のロールをサポートしているため、チームごとのアクセス制御もバッチリです。

🇯🇵 日本国内での利用に関する注意点（重要！）

最新のリージョン状況を調査した結果、大阪リージョン (ap-northeast-3) では Amazon QuickSight 自体のデプロイメントが現在サポートされていない ことが判明しました。日本国内でこの機能を活用する場合は、東京リージョン (ap-northeast-1) で QuickSight を運用することが必須となります。構成を検討する際は、必ず東京リージョンでの展開を前提としてください。

🛠 実務でのアドバイス

• リージョン間転送コストに注意: QuickSight と Athena が別リージョンの場合は、データ転送コストが発生します。コスト最適化のため、同一リージョンでの構成を強く推奨します。
• セキュリティの鉄則: sts:AssumeRole の権限設定は慎重に。最小権限の原則に基づき、ターゲットアカウント側のロールを作成し、CloudTrail での監査ログを必ず有効にしておいてください。

✅ 次にやるべきこと

1. まずは検証環境で、QuickSight アカウントからターゲットアカウントの Athena へ ConsumerAccountRoleArn を設定して疎通確認を行いましょう。
2. IAM ロールの信頼関係が正しく設定されているか、公式の API リファレンスを確認してください。

参照元: Amazon QuickSight API - AthenaParameters (https://docs.aws.amazon.com/quicksight/APIReference/API_AthenaParameters.html) および Amazon QuickSight 公式リージョンガイド