サイロ化されたデータから統合インサイトへ：Amazon QuickSight のクロスアカウント Athena アクセス機能

[Amazon Quick](https://aws.amazon.com/quick/?trk=0ea79374-057c-4897-84f0-5fe792905a8f&sc_channel=ps&ef_id=CjwKCAjwzevPBhBaEiwAplAxvus2pWA3UIIYO3w6ecz02XUi77CqvrqnGA_0qB3LzVzjF3Kmrc7CJRoCWoIQAvD_BwE:G:s&s_kwcid=AL!4422!3!806967542617!e!!g!!amazon%20quick!23532473728!195603221991&gad_campaignid=23532473728&gbraid=0AAAAADjHtp_X2ozTdAbqORLdxLt91FDC0&gclid=CjwKCAjwzevPBhBaEiwAplAxvus2pWA3UIIYO3w6ecz02XUi77CqvrqnGA_0qB3LzVzjF3Kmrc7CJRoCWoIQAvD_BwE) は、AI を活用した統合インテリジェンスサービスであり、組織のデータ、構造化データ、ドキュメントやメール、ナレッジベースなどの非構造化エンタープライズコンテンツを単一のサービスに集約し、誰でも探索・分析・アクションを起こせるようにします。40 以上のアプリケーション連携機能を備え、Quick はインサイトとアクションの間の「ラストマイルギャップ」を解消し、ユーザーがデータを理解して直接行動に移せるよう支援します。 Amazon Quick Sight は、Amazon Quick のビジネスインテリジェンス（BI）機能であり、統合 BI サービスです。モダンなインタラクティブダッシュボード、自然言語クエリ、ピクセル単位で完璧なレポート、機械学習（ML: Machine Learning）によるインサイト、そして大規模展開可能な埋め込み分析を提供します。Amazon Quick は、ビジネスインサイト、調査、自動化のための AI エージェントを一つの統合された体験にまとめ、セキュリティとアクセスポリシーを維持しながら、より賢く、迅速に作業を進めることを支援します。 [Amazon Athena](https://aws.amazon.com/athena/) は、標準 SQL を使用して [Amazon Simple Storage Service](https://aws.amazon.com/pm/serv-s3/?trk=50b671a1-06f5-4224-9505-fa45ee881c08&sc_channel=ps&trk=319436d7-2418-4600-ad06-bad3656784a3&sc_channel=ps&ef_id=CjwKCAjwwpDQBhAuEiwAa-4Wo05YQaewdvhDQclCqp15mo5bz32SpGoRdPuTVUAjw9q5DI74fHxb8BoCQuQQAvD_BwE:G:s&s_kwcid=AL!4422!3!795876995201!e!!g!!aws%20s3!23522747487!196433733807&gad_campaignid=23522747487&gclid=CjwKCAjwwpDQBhAuEiwAa-4Wo05YQaewdvhDQclCqp15mo5bz32SpGoRdPuTVUAjw9q5DI74fHxb8BoCQuQQAvD_BwE) (Amazon S3) に保存されたデータを直接分析するためのサーバーレス型インタラクティブクエリサービスです。インフラの管理も不要で、データのロードも必要ありません。Athena を Amazon S3 内のデータに指し示し、AWS Glue Data Catalog を使用してスキーマを定義するだけで、すぐにクエリを開始できます。 多くの企業では、Amazon Quick のデプロイメントを単一の AWS アカウントに集約している一方で、データは複数の事業部門アカウントに分散されています。例えば、金融サービス会社の場合、Quick は中央の AWS アカウントで実行される一方、小売銀行のデータはアカウント A に、投資銀行のデータはアカウント B に、リスク管理のデータはアカウント C に格納されているといったケースがあります。これまで、これらのアカウント間で Amazon Athena データをクエリするには、複数の Quick サブスクリプションを管理するか、すべてのクエリコストを中央アカウントで負担するかのどちらかしかありませんでした。 本日、Amazon Quick におけるクロスアカウント Athena アクセスを発表いたします。この機能により、顧客は AWS Identity and Access Management (IAM) ロールチェーンを使用して、他の AWS アカウント内の Athena データを照会でき、クエリコストはデータが保存されているアカウントに請求されます。クロスアカウント Athena アクセスの文脈において、ロールチェーンはパブリッシャーアカウント内の Amazon Quick が、顧客のコンシューマーアカウント内のロールを引き受けることを可能にし、そのロールには長期認証情報をアカウント間で共有することなく、Athena および AWS Glue Data Catalog 内のデータを照会する権限が付与されます。本稿では、IAM ロールの作成、信頼ポリシーの設定、Quick 内でのクロスアカウントデータソースの作成、およびそこからデータセットを構築するというエンドツーエンドのセットアップ手順について解説します。 ## 用語定義 - クイック中央アカウント（ソースアカウント）：Amazon Quick がデプロイされている AWS アカウント - コンシューマーアカウント：Athena データ資産（データベース、テーブル、S3 データ）が存在し、クイック中央アカウントからアクセスされる AWS アカウント - RunAsRole（ロール A）：クイックが最初に引き受けるクイック中央アカウント内の IAM ロール。データ権限は持たず、コンシューマーアカウントのロールへ連鎖するための権限のみを持つ - コンシューマーアカウントロール（ロール B）：各コンシューマーアカウントに存在し、Athena、AWS Glue、S3 へのアクセスを付与する IAM ロールで、ロール A を信頼する - ロールチェーン：クイックが RunAsRole を引き受けた後、その資格情報を使用してコンシューマーアカウントのロールを引き受けるという 2 ステップの資格情報プロセス - ExternalId（外部 ID）：信頼ポリシーに設定されるセキュリティ条件（データソース ARN に設定）で、ロール引き受け時に混乱したデュープ攻撃を防ぐために使用される - スコープダウンポリシー：ランタイム時に添付されるインライン IAM ポリシーで、連鎖された資格情報が特定のコンシューマーアカウントロールのみを引き受けるように制限する - Athena ワークグループ：クエリが実行されコストが追跡される、コンシューマーアカウント内の Athena 実行環境 ## ソリューション概要 本ソリューションは、2 つの IAM ロールを関与させる 2 ステップのロールチェーン機構を使用します： - ロール A (RunAsRole) – 中央の Quick アカウントに存在します。Quick はまずこのロールを仮定します。 - ロール B (Consumer Account Role) – Athena データが存在する消費者アカウントに存在します。ロール A はクエリを実行するためにロール B にチェーンされます。 Quick ユーザーがクエリを実行すると、サービスはロール A を仮定し、その資格情報を使用して消費者アカウント内のロール B を仮定します。Athena はロール B の資格情報を使用してクエリを実行するため、計算コストは消費者アカウントに請求されます。 ## 前提条件 開始する前に、以下の準備が整っていることを確認してください: - 中央アカウントで Amazon Quick Enterprise Edition がアクティブであること - 両方のアカウントで IAM の管理アクセス権限があること。各アカウントでロールの作成と設定を行います - AWS Command Line Interface (AWS CLI) がインストールされ、両方のアカウントの資格情報で構成されているか、または AWS Management Console にアクセスできること - IAM の概念、特に信頼ポリシー、権限ポリシー、およびロールの仮定 (sts:AssumeRole) に関する知識があること - 消費者アカウントに Athena ワークグループが設定されていること（開始にはデフォルトのプライマリーワークグループで十分です） - 消費者アカウント内に Athena クエリ結果用の S3 バケットが存在すること（通常、aws-athena-query-results-* というプレフィックスが付与されます） **注:** 複数の消費者アカウントを接続する場合は、各アカウントに対してロール設定の手順を繰り返してください。大規模な管理を円滑にするために、IAM ロールの命名規則を事前に計画してください。 ## 技術アーキテクチャ 組織がレイクハウスアーキテクチャを採用し、データをビジネスユニット、AWS リージョン、および AWS アカウントに分散させるにつれ、データを移動せずに中央から照会する方法が必要となります。Amazon Quick 用のクロスアカウント Athena アクセスは、この要件に対応します。IAM ロールチェーン（IAM role chaining）を使用することで、中央の Quick デプロイメントがデータ複製や共有された長期有効な認証情報、あるいは複数の Quick サブスクリプションを必要とすることなく、アカウント境界を越えて分散したデータストアにアクセスできます。本アーキテクチャは、2 つのアカウントによる概念実証から企業全体の展開までスケールします。このセクションでは、それぞれが前回のパターンに基づいて構築される 3 つのパターンについて説明します。 ## パターン 1: 基本的な 2 アカウントセットアップ 最も単純なデプロイメントは、1 つの中央 Quick アカウントを 1 つのコンシューマーアカウントに接続するものです。これは最小限の実行可能な構成であり、本記事の手順別ウォークスルーと直接対応しています。ソリューション概要で説明されているロールチェーン（Quick がロール A を仮定し、sts:AssumeRole を使用してロール A からロール B へ連鎖し、Athena がロール B の認証情報のもとでクエリを実行する）がそのまま適用されます。このパターンは、初期検証に適しており、単一のビジネスユニットのデータを共有（中央）BI AWS アカウントに接続する場合にも適しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20930-image-1.jpg) ## パターン 2：ハブ・アンド・スポーク 多くの企業では、Quick のデプロイを単一のアカウント（ハブ）に集約し、データは複数の事業部門アカウント（スポーク）に分散配置しています。このハブ・アンド・スポークモデルは基本設定を拡張したもので、ロール A の権限ポリシーには複数のコンシューマーロール ARN がリストされ、これらは同じアカウント内または異なるアカウント内に存在し得ます。また、Quick 上では各データソースに対して個別にデータソースが作成されます。このパターンの最大の利点は、スポーク間の独立性です。新しい事業部門を追加する際、その部門のアカウントで新しいロール B を作成し、Quick で新しいデータソースを登録するだけで済み、既存のスポークに変更を加える必要はありません。各スポークは独自のロール B 権限を管理し、中央の BI AWS アカウントに対してどのテーブルや S3 プレフィックスが公開されるかを決定します。コストの帰属も自然に実現され、各スポークの Athena クエリはそのアカウントごとに請求されます。単一の Quick ダッシュボードが複数のコンシューマーアカウントからのデータソースを参照できるため、BI 作成者は統一された Quick の体験から離れることなく、事業横断的な分析を構築できます。これは、ほとんどの企業にとって推奨されるパターンです。 スポークの数が数個を超えてスケールする場合は、コンシューマー側のセットアップをテンプレート化することを検討してください。ロール B、Athena ワークグループ、および必要な信頼関係と権限ポリシーに対する AWS CloudFormation または CDK テンプレートを使用することで、事業部門チームがオンボーディングをセルフサービスで実行したり、中央の BI チームが単一のスタックデプロイで新しいスポークをプロビジョニングしたりすることが可能になります。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20930-image-2.jpg) ## パターン 3: データメッシュ データメッシュでは、データの生産者と消費者は異なるアカウントに属します。生産者アカウントが生のデータを所有・管理し、それを消費者アカウントへプロビジョニング（設定）します。例えば、AWS Lake Formation と AWS Resource Access Manager (AWS RAM) を使用して、アカウント境界を越えてテーブルを共有する方法があります。具体的なプロビジョニングの仕組みはドメインチームの判断に委ねられ、本稿の範囲外となります。ロール B、AWS Glue Data Catalog（データカタログ）、Athena ワークグループを含む消費者アカウントが、Amazon Quick によってロールチェーンを通じて接続先となります。このアカウントは、AWS Glue Data Catalog のリソースポリシーを用いて他の消費者アカウントへ管理されたデータ製品を公開し、ドメイン横断的な分析のためにデータを利用可能にします。各々がデータ製品の生産者かつ消費者として機能する消費者アカウント間のピアツーピアな共有こそが、メッシュを定義する要素です。Quick 内の BI 作成者は、単一のダッシュボード内で複数の消費者アカウントを跨るクエリを実行でき、クエリコストは各消費者アカウントごとに按分されます。企業規模では、単一の Amazon Quick デプロイメントが数百の消費者アカウントに接続可能です。ドメインアカウントが生産者アカウントへ生のデータをどのようにプロビジョニングするかは本稿の範囲外です。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/13/ML-20930-image-3.jpg) ## パターンの選択 適切なパターンは、あなたのデータ戦略に依存します。基本的な 2 アカウント構成では、ロールチェーンがエンドツーエンドで検証されます。多くの企業は追加の事業部門をオンボーディングする際にハブ・アンド・スポークを採用し、これにより各スポークを独立させ、コスト帰属を明確にし、信頼ポリシーを単純に保ちます。強力なデータ所有権の境界線や専任ドメインチームを持つ組織は、自然とデータメッシュパターンへと進化します。このパターンでは、コンシューマーアカウントはデータを供給するプロデューサーアカウントとは区別され、Amazon Quick はそれらすべての間で統一された分析レイヤーとして機能します。要件が拡大するにつれて小規模から始めて拡張していくことを推奨します。 ## 今後の展望 エージェント型 AI の機能が成熟し、AI エージェントが組織の境界を越えて自律的にデータを照会・変換・処理し始めるようになると、データが存在する場所で、ガバナンスされ、コスト帰属が可能で、監査可能な状態でのアクセス能力が基盤となります。クロスアカウント Athena アクセスは、その未来を支える構成要素です。現在は Quick ダッシュボードを分散したデータレイクに接続していますが、エージェント型パターンが進化すれば、同じ IAM ロールチェーン機構は、ビジネスユーザーに代わって Athena を照会し、リアルタイムでガバナンスルールを適用し、データを単一のアカウントに集約することなく計算コストをデータ所有者へルーティングする AI エージェントへと拡張されます。 ## ソリューション Amazon Quick におけるクロスアカウント Athena アクセスは、IAM ロールチェーンを使用して、中央の Quick アカウントとデータが存在する 1 つ以上のコンシューマーアカウントを橋渡しします。データを単一のアカウントに統合したり、ビジネスユニットごとに個別の Quick サブスクリプションを管理したりするのではなく、2 つの IAM ロール（各アカウントに 1 つずつ）を設定して連携させ、クエリをルーティングしコストを正しくアトリビュートします。 **中央 Quick アカウントでロール A (RunAsRole) を作成** ロール A は中央 Quick アカウント内に存在します。ユーザーがクエリを開始すると Amazon Quick がこのロールを引き受けます（Assume）。ロール A 自体にはデータ権限を持たず、その唯一の目的はコンシューマーアカウントへのチェーンです。必要なものは以下の 2 つだけです。 - Quick サービスがこのロールを引き受けられるようにする信頼ポリシー。 - コンシューマーアカウント内のロール B を引き受けられるようにする権限ポリシー。 **信頼ポリシーを作成**し、**role-a-trust-policy.json** という名前にします。これにより、Quick サービスプリンシパルがデータソース操作にスコープを限定してロール A を引き受けることができます。サンプルポリシーは以下の通りです： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "quicksight.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "aws:SourceAccount": "", "aws:SourceArn": "arn:aws:quicksight:*::datasource/*" } } } ] } ``` **AWS CLI を使用してロールを作成する** aws iam create-role \ --role-name qs-athena-cross-account-role-a \ --assume-role-policy-document file://role-a-trust-policy.json" \ --description "Quick Athena Cross Account - RunAsRole" 権限ポリシーを作成し、**role-a-permission-policy.json** という名前にします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:::role/", "Condition": { "StringLike": { "sts:ExternalId": "arn:aws:quicksight:*::datasource/*" } } } ] } AWS CLI を使用して、この権限ポリシーをロールにインラインポリシーとしてアタッチします。これにより、ロール A がコンシューマーアカウント内のロール B を引き受けることが可能になります。ExternalId 条件により、Quick のデータソースのみがロールチェーンのトリガーとなることが保証されます。 aws iam put-role-policy \ --role-name qs-athena-cross-account-role-a \ --policy-name AssumeConsumerRolePolicy \ --policy-document file://role-a-permission-policy.json さらに、Quick のデータソースを作成する IAM プリンシパルには、ロール A に対する iam:PassRole 権限が必要です。 **コンシューマーアカウントでロール B を作成する** ロール B は、Athena テーブル、AWS Glue データカタログ、および S3 データが存在するコンシューマーアカウント内に存在します。ロール A がロール B を引き受けることでクエリが実行されます。 信頼ポリシーを作成し、**role-b-trust-policy.json** という名前にします。これにより、Quick アカウントはデータソース ARN に紐付いた ExternalId 条件付きでロール B を引き受けることができます。サンプルポリシー： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::root" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "sts:ExternalId": "arn:aws:quicksight:*::datasource/*" } } } ] } **AWS CLI を使用してロールを作成します：** aws iam create-role \ --role-name qs-athena-consumer-role \ --assume-role-policy-document file://role-b-trust-policy.json \ --description "Quick Athena Cross Account - Consumer Account Role" Athena、AWS Glue、および S3 に対する権限ポリシーを作成し、**role-b-permission-policy.json** という名前にします。このポリシーは、データに関連する特定のデータベース、テーブル、S3 ロケーションにスコープを限定してください。 翻訳全文 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:BatchGetQueryExecution", "athena:CancelQueryExecution", "athena:GetCatalogs", "athena:GetExecutionEngine", "athena:GetExecutionEngines", "athena:GetNamespace", "athena:GetNamespaces", "athena:GetQueryExecution", "athena:GetQueryExecutions", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:GetTable", "athena:GetTables", "athena:ListQueryExecutions", "athena:RunQuery", "athena:StartQueryExecution", "athena:StopQueryExecution", "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:GetWorkGroup", "athena:GetDataCatalog", "athena:GetDatabase", "athena:GetTableMetadata", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:ListTableMetadata" ], "Resource": [ "arn:aws:athena:::workgroup/", "arn:aws:athena:::datacatalog/" ] }, { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:::catalog", "arn:aws:glue:::database/", "arn:aws:glue:::table//*" ] }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*", "arn:aws:s3:::aw

サイロ化されたデータから統合インサイトへ：Amazon QuickSight のクロスアカウント Athena アクセス機能

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

調べる

選ぶ

サイト