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

Amazon Quick is an AI-powered unified intelligence service that brings together an organization’s data, structured data and unstructured enterprise content like documents, emails, and knowledge bases into a single service where anyone can explore, analyze, and take action. With over 40 application integrations, Quick bridges the *last-mile gap* between insights and action so users can understand their data and act on it directly.

Amazon Quick Sight, the business intelligence (BI) capability of Amazon Quick, is a unified BI service. It provides modern interactive dashboards, natural language querying, pixel-perfect reports, machine learning (ML) insights, and embedded analytics at scale. Amazon Quick brings together AI agents for business insights, research, and automation in one integrated experience, helping you work smarter and faster while maintaining security and access policies.

Amazon Athena is a serverless, interactive query service that’s used to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL, with no infrastructure to manage and no data to load. You point Athena at your data stored in Amazon S3, define the schema using the AWS Glue Data Catalog, and start querying.

Many enterprises centralize their Amazon Quick deployment in a single AWS account while their data resides across multiple business unit accounts. A financial services company might run Quick in a central AWS account, while retail banking data lives in Account A, investment banking in Account B, and risk management in Account C. Until now, querying Amazon Athena data across these accounts meant either managing multiple Quick subscriptions or absorbing all query costs in the central account.

Today, we’re announcing cross-account Athena access for Amazon Quick. With this feature, customers can query Athena data in other AWS accounts using AWS Identity and Access Management (IAM) role chaining, with query costs billed to the account where the data resides. In the context of cross-account Athena access, role chaining enables Amazon Quick in a publisher account to assume a role in the customer’s consumer account, which in turn has permissions to query data in Athena and the AWS Glue Data Catalog without sharing long-term credentials across account boundaries. In this post, we walk through the end-to-end setup: creating the IAM roles, configuring trust policies, creating the cross-account data source in Quick, and building datasets from it.

Term definitions

• Central Quick Account (Source Account): The AWS account where Amazon Quick is deployed

• Consumer Account: An AWS account where Athena data assets (databases, tables, S3 data) reside, accessed from the central Quick account

• RunAsRole (Role A): An IAM role in the central Quick account that Quick assumes first; holds no data permissions, only permission to chain into consumer account roles

• Consumer Account Role (Role B): An IAM role in each consumer account that grants Athena, AWS Glue, and S3 access; trusts Role A

• Role Chaining: A two-step credential process where Quick assumes the RunAsRole, then uses those credentials to assume the consumer account role

• ExternalId: A security condition (set to the DataSource ARN) used in trust policies to prevent confused deputy attacks during role assumption

• Scope-Down Policy: An inline IAM policy attached at runtime to restrict chained credentials to only assuming the specific consumer account role

• Athena Workgroup: The Athena execution environment in the consumer account under which queries run and costs are tracked

Solution overview

The solution uses a two-step role chaining mechanism involving two IAM roles:

• Role A (RunAsRole) – lives in the central Quick account. Quick assumes this role first.

• Role B (Consumer Account Role) – lives in the consumer account where Athena data resides. Role A chains into Role B to execute queries.

When a Quick user runs a query, the service assumes Role A, then uses those credentials to assume Role B in the consumer account. Athena executes the query using Role B’s credentials, so compute costs are billed to the consumer account.

Prerequisites

Before you begin, make sure the following are in place:

• Amazon Quick Enterprise Edition active in the central account

• IAM administrative access in both accounts. You will create and configure roles in each

• AWS Command Line Interface (AWS CLI) installed and configured with credentials for both accounts, or access to the AWS Management Console

• Familiarity with IAM concepts, specifically trust policies, permission policies, and role assumption (sts:AssumeRole)

• Athena workgroup configured in the consumer account (the default primary workgroup works for getting started)

• S3 bucket in the consumer account for Athena query results (typically prefixed aws-athena-query-results-*)

Note: To connect multiple consumer accounts, repeat the role setup steps for each account. Plan your IAM role naming convention in advance to streamline management at scale.

Technical architecture

As organizations adopt lakehouse architectures and distribute data across business units, AWS Regions, and AWS accounts, they need a way to query that data centrally without moving it. Cross-account Athena access for Amazon Quick addresses this requirement. Using IAM role chaining, a central Quick deployment can reach into distributed data stores across account boundaries without data replication, shared long-lived credentials, or multiple Quick subscriptions. The architecture scales from a two-account proof of concept to an enterprise-wide deployment. In this section, we describe three patterns, each building on the previous one.

Pattern 1: Basic two account setup

The most straightforward deployment connects one central Quick account to one consumer account. This is the minimum viable configuration and maps directly to the step-by-step walkthrough in this post. The role chain described in the Solution Overview (Quick assumes Role A, Role A chains into Role B using sts:AssumeRole, and Athena executes the query under Role B’s credentials) applies directly here. This pattern is well suited for initial validation or for connecting a single business unit’s data to a shared (central) BI AWS account.

Pattern 2: Hub and Spoke

Most enterprises centralize their Quick deployment in a single account (the hub) while data is distributed across multiple business unit accounts (the spokes). The hub-and-spoke model extends the basic setup: Role A’s permission policy lists multiple consumer role ARNs, which can reside in the same account or across different accounts, and a separate data source is created in Quick for each. The key advantage of this pattern is independence between spokes. Adding a new business unit requires creating a new Role B in that unit’s account and registering a new data source in Quick, with no changes to existing spokes. Each spoke controls its own Role B permissions, determining which tables and S3 prefixes are exposed to the central BI AWS Account. Cost attribution follows naturally, each spoke’s Athena queries are billed to its own account. Because a single Quick dashboard can reference data sources from multiple consumer accounts, BI authors can build cross-business-unit analytics without leaving the unified Quick experience. This is the recommended pattern for most enterprises.

As you scale beyond a handful of spokes, consider templatizing the consumer-side setup. An AWS CloudFormation or CDK template for Role B, the Athena workgroup, and the required trust and permission policies allows business unit teams to self-service their onboarding, or the central BI team to provision new spokes with a single stack deployment.

Pattern 3: Data Mesh

In a data mesh, producers and consumers are distinct accounts. A producer account owns and manages its raw data, provisioning it into a Consumer Account. For example, using AWS Lake Formation with AWS Resource Access Manager (AWS RAM) to share tables across account boundaries. The specific provisioning mechanism is the domain team’s choice and outside the scope. The Consumer Account, containing Role B, AWS Glue Data Catalog, and Athena workgroup, is what Amazon Quick connects to through role chain. The account publishes governed data products to other Consumer Accounts using AWS Glue Data Catalog resource policies, making its data available for cross-domain analytics. This peer-to-peer sharing between Consumer Accounts, each acting as both producer and consumer of data products, is what defines the mesh.A BI author in Quick can query across multiple Consumer Accounts in a single dashboard, with query costs attributed per Consumer Account. At enterprise scale, a single Amazon Quick deployment can connect to hundreds of Consumer Accounts. How domain accounts provision raw data into Consumer Accounts is outside of scope.

Choosing a pattern

The right pattern depends on your data strategy. The basic two-account setup validates the role chain end to end. Most enterprises will adopt hub-and-spoke as they onboard additional business units because it keeps spokes independent, cost attribution clean, and trust policies straightforward. Organizations with strong data ownership boundaries or dedicated domain teams will naturally evolve into the data mesh pattern, where Consumer Accounts are distinct from the producer accounts that supply the data, and Amazon Quick serves as the unified analytics layer across all of them. We recommend starting small and expanding as requirements grow.

Looking ahead

As agentic AI capabilities mature and AI agents begin to autonomously query, transform, and act on data across organizational boundaries, the ability to access data where it lives, governed, cost-attributed, and auditable, becomes foundational. Cross-account Athena access is a building block for that future. Today, it connects Quick dashboards to distributed data lakes. As agentic patterns evolve, the same IAM role chaining mechanism can extend to AI agents that query Athena on behalf of business users, apply governance rules in real time, and route compute costs to the data owner without centralizing data into a single account.

Solution

Cross-account Athena access for Amazon Quick uses IAM role chaining to bridge your central Quick account with one or more consumer accounts where your data lives. Rather than consolidating data into a single account or managing separate Quick subscriptions per business unit, you configure two IAM roles that work in tandem (one in each account) to route queries and attribute costs correctly.

Create Role A (RunAsRole) in the Central Quick account

Role A lives in the central Quick account. Amazon Quick assumes this role when a user initiates a query. Role A holds no data permissions of its own; its sole purpose is to chain into the consumer account. It needs two things:

• A trust policy allowing the Quick service to assume it.

• A permission policy allowing it to assume Role B in the consumer account.

Create the trust policy and name it as role-a-trust-policy.json. This allows the Quick service principal to assume Role A, scoped to data source operations in your account. Sample policy:

{
    "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/*"
                }
            }
        }
    ]
}

Create the role using the 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"

Create the permissions policy and name it 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/*"
                }
            }
        }
    ]
}

Attach the permission policy as an inline policy using AWS CLI. This allows Role A to assume Role B in the consumer account. The ExternalId condition ensures only Quick data sources can trigger the role chain:

aws iam put-role-policy \
--role-name qs-athena-cross-account-role-a \
--policy-name AssumeConsumerRolePolicy \
--policy-document file://role-a-permission-policy.json

Additionally, the IAM principal creating the Quick data source needs iam:PassRole permission on Role A.

Create Role B in the Consumer Account

Role B lives in the consumer account where your Athena tables, AWS Glue Data Catalog, and S3 data reside. Role A assumes Role B to execute the query.

Create the trust policy and name it role-b-trust-policy.json. This allows the Quick account to assume Role B, with an ExternalId condition tied to the data source ARN. Sample policy:

{
"Version": "2012-10-17",
"Statement": [
        {
        "Effect": "Allow",
        "Principal": {
        "AWS": "arn:aws:iam:::root"
            },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringLike": {
            "sts:ExternalId": "arn:aws:quicksight:*::datasource/*"
                }
            }
        }
    ]
}

Create the role using the 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"

Create the Athena, AWS Glue, and S3 permissions policy and name it role-b-permission-policy.json. Scope these to the specific databases, tables, and S3 locations relevant to your data.

{

"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