从孤立数据到统一洞察：Amazon Quick 的跨账户 Athena 访问

标题：从数据孤岛到统一洞察：Amazon Quick 的跨账户 Athena 访问 | Amazon Web Services

来源网址：https://aws.amazon.com/blogs/machine-learning/from-siloed-data-to-unified-insights-cross-account-athena-access-for-amazon-quick/

发布时间：2026-05-14T09:17:50-08:00

Amazon Quick 是一项由人工智能驱动的统一智能服务，将组织的数据、结构化数据以及文档、电子邮件和知识库等非结构化企业内容整合到一个服务中，使任何人都可以探索、分析并采取行动。通过超过 40 个应用程序集成，Quick 弥合了洞察与行动之间的“最后一公里”差距，让用户能够理解其数据并直接采取行动。

Amazon Quick Sight 是 Amazon Quick 的商业智能（BI）功能，是一项统一的 BI 服务。它提供现代化的交互式仪表板、自然语言查询、像素级精准报表、机器学习（ML）洞察以及大规模嵌入式分析。Amazon Quick 将用于业务洞察、研究和自动化的 AI 智能体集成在一个统一体验中，帮助您更智能、更高效地工作，同时保持安全性和访问策略。

Amazon Athena 是一种无服务器的交互式查询服务，可用于使用标准 SQL 直接分析存储在 Amazon Simple Storage Service（Amazon S3）中的数据，无需管理基础设施，也无需加载数据。您只需将 Athena 指向存储在 Amazon S3 中的数据，使用 AWS Glue 数据目录定义模式，即可开始查询。

许多企业将 Amazon Quick 部署集中在一个 AWS 账户中，而其数据则分布在多个业务部门账户中。例如，一家金融服务公司可能在中央 AWS 账户中运行 Quick，而零售银行业务数据位于账户 A，投资银行业务数据位于账户 B，风险管理部门数据位于账户 C。在此之前，跨这些账户查询 Amazon Athena 数据意味着必须管理多个 Quick 订阅，或由中央账户承担所有查询费用。

今天，我们宣布推出 Amazon Quick 的跨账户 Athena 访问功能。借助此功能，客户可以通过 AWS Identity and Access Management (IAM) 角色链式调用查询其他 AWS 账户中的 Athena 数据，且查询费用将记入数据所在账户。在跨账户 Athena 访问的场景中，角色链式调用使 Amazon Quick 能够首先在发布者账户中承担一个角色，然后该角色进一步承担客户消费者账户中的角色，后者拥有查询 Athena 和 AWS Glue 数据目录的权限，而无需在账户边界之间共享长期凭证。本文将逐步介绍端到端的配置过程：创建 IAM 角色、配置信任策略、在 Quick 中创建跨账户数据源，并基于该数据源构建数据集。

术语定义

• 中央 Quick 账户（源账户）：部署 Amazon Quick 的 AWS 账户
• 消费者账户：存放 Athena 数据资产（数据库、表、S3 数据）的 AWS 账户，由中央 Quick 账户访问
• RunAsRole（角色 A）：位于中央 Quick 账户中的 IAM 角色，Quick 首先承担此角色；不持有任何数据权限，仅具有链式调用消费者账户角色的权限
• 消费者账户角色（角色 B）：位于每个消费者账户中的 IAM 角色，授予对 Athena、AWS Glue 和 S3 的访问权限；信任角色 A
• 角色链式调用：一种两步凭证流程，Quick 先承担角色 A，再使用该凭证承担消费者账户中的角色 B
• ExternalId：一种安全条件（设置为数据源 ARN），在信任策略中用于防止角色承担过程中的混淆委托人攻击
• 范围缩小策略（Scope-Down Policy）：在运行时附加的内联 IAM 策略，用于限制链式调用的凭证只能承担特定的消费者账户角色
• Athena 工作组：在消费者账户中执行查询并跟踪成本的 Athena 执行环境

解决方案概述

该解决方案采用涉及两个 IAM 角色的两步角色链式调用机制：

1. 角色 A（RunAsRole）——位于中央 Quick 账户中，Quick 首先承担此角色。
2. 角色 B（消费者账户角色）——位于存放 Athena 数据的消费者账户中，角色 A 通过链式调用进入角色 B 以执行查询。

当 Quick 用户运行查询时，服务会先承担角色 A，然后使用这些凭证承担消费者账户中的角色 B。Athena 使用角色 B 的凭证执行查询，因此计算成本将由消费者账户承担。

**前提条件**

在开始之前，请确保已具备以下条件：

• Amazon Quick 企业版 在中心账户中已激活
• 在两个账户中均具备 IAM 管理权限。你将在每个账户中创建和配置角色
• 已安装并配置 AWS 命令行界面 (AWS CLI)，且已为两个账户配置凭据，或可访问 AWS 管理控制台
• 熟悉 IAM 概念，特别是信任策略、权限策略和角色代入（sts:AssumeRole）
• 在消费者账户中配置了 Athena 工作组（默认的 primary 工作组可用于快速开始）
• 在消费者账户中拥有用于 Athena 查询结果的 S3 存储桶（通常以 aws-athena-query-results-* 为前缀）

注意： 要连接多个消费者账户，请对每个账户重复角色设置步骤。请提前规划 IAM 角色命名规范，以便在大规模部署时简化管理。

技术架构

随着组织采用湖仓一体架构并将数据分布在不同的业务单元、AWS 区域和 AWS 账户之间，他们需要一种无需移动数据即可集中查询这些数据的方法。Amazon Quick 的跨账户 Athena 访问功能正是为满足这一需求而设计的。通过 IAM 角色链机制，一个中心化的 Quick 部署可以跨越账户边界访问分布式数据存储，而无需数据复制、共享长期有效的凭证或多个 Quick 订阅。该架构可从两账户的概念验证扩展至企业级部署。在本节中，我们将介绍三种模式，每种模式都以前一种为基础逐步演进。

模式 1：基础双账户设置

最简单的部署方式是将一个中心 Quick 账户连接到一个消费者账户。这是最小可行配置，与本文中的分步操作指南直接对应。解决方案概述中描述的角色链（Quick 代入角色 A，角色 A 使用 sts:AssumeRole 链接到角色 B，Athena 在角色 B 的凭证下执行查询）在此场景中直接适用。此模式非常适合初始验证，或用于将单个业务单元的数据连接到共享（中心）BI AWS 账户。

模式 2：中心辐射型（Hub-and-Spoke）

大多数企业将 Quick 部署集中在一个账户（中心，hub）中，而数据则分布在多个业务单元账户（分支，spokes）中。“中心-分支”模型扩展了基础设置：角色 A 的权限策略列出多个消费者角色 ARN，这些 ARN 可位于同一账户或不同账户中，并且在 Quick 中为每个角色创建独立的数据源。此模式的关键优势在于各分支之间的独立性。添加新的业务单元时，只需在其账户中创建新的角色 B，并在 Quick 中注册一个新的数据源，而无需更改现有分支。每个分支自行控制其角色 B 的权限，决定向中心 BI AWS 账户暴露哪些表和 S3 前缀。成本归属也自然实现——每个分支的 Athena 查询费用由其自身账户承担。由于单个 Quick 仪表板可以引用来自多个消费者账户的数据源，BI 开发人员可以在不脱离统一 Quick 体验的前提下构建跨业务单元的分析报表。这是大多数企业的推荐模式。

当你扩展到多个分支时，建议将消费者侧的设置模板化。使用 AWS CloudFormation 或 CDK 模板来定义角色 B、Athena 工作组以及所需的信任和权限策略，可以让业务单元团队自助完成接入，或让中心 BI 团队通过单个堆栈部署快速开通新分支。

模式 3：数据网格（Data Mesh）

在数据网格架构中，生产者和消费者是不同的账户。生产者账户拥有并管理其原始数据，并将其提供给消费者账户。例如，使用 AWS Lake Formation 结合 AWS 资源访问管理器（AWS RAM）跨账户边界共享表。具体的数据供给机制由领域团队自行选择，不在本文讨论范围内。包含角色 B、AWS Glue 数据目录和 Athena 工作组的消费者账户，才是 Amazon Quick 通过角色链连接的目标。该账户通过 AWS Glue 数据目录资源策略发布受治理的数据产品给其他消费者账户，使其数据可用于跨域分析。这种消费者账户之间点对点的数据共享，每个账户同时作为数据产品的生产者和消费者，正是数据网格的核心特征。Quick 中的 BI 开发人员可以在单个仪表板中跨多个消费者账户进行查询，查询成本按各消费者账户分别归因。在企业级规模下，单个 Amazon Quick 部署可连接数百个消费者账户。各领域账户如何将原始数据供给到消费者账户，不属于本文范围。

如何选择模式

合适的模式取决于你的数据战略。基础双账户设置可用于端到端验证角色链功能。大多数企业在接入更多业务单元时会选择“中心-分支”模式，因为它保持了分支间的独立性，成本归属清晰，信任策略简单明了。而对于具有明确数据所有权边界或设有专门领域团队的组织，则会自然演进到数据网格模式——在这种模式中，消费者账户与提供数据的生产者账户分离，而 Amazon Quick 成为所有账户之上的统一分析层。我们建议从小规模开始，随着需求增长逐步扩展。

展望未来

随着代理式 AI 能力的成熟，AI 代理开始跨组织边界自主查询、转换和操作数据，此时能够直接在数据所在位置访问数据，并实现治理、成本归属和审计，变得至关重要。跨账户的 Athena 访问正是构建这一未来的基础能力。如今，它已将 Quick 仪表板连接至分布式的数据湖；随着代理模式的发展，相同的 IAM 角色链机制可扩展至代表业务用户查询 Athena 的 AI 代理，实现实时应用治理规则，并将计算成本路由回数据所有者，而无需将数据集中到单一账户中。

解决方案

Amazon Quick 的跨账户 Athena 访问使用 IAM 角色链，将其中央 Quick 账户与一个或多个存储数据的消费者账户连接起来。您无需将数据集中到单个账户，也无需为每个业务单元单独管理 Quick 订阅，而是配置两个协同工作的 IAM 角色（每个账户一个），以正确路由查询并分配成本。

在中央 Quick 账户中创建角色 A（RunAsRole）

角色 A 位于中央 Quick 账户中。当用户发起查询时，Amazon Quick 将承担此角色。角色 A 自身不持有任何数据权限，其唯一作用是链入消费者账户。它需要以下两项内容：

1. 允许 Quick 服务承担该角色的信任策略。
2. 允许其承担消费者账户中角色 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": "<Quick-account-id>",
                "aws:SourceArn": "arn:aws:quicksight:*:<Quick-account-id>: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::<consumer-account-id>:role/<consumer-role-name>",
        "Condition": {
            "StringLike": {
            "sts:ExternalId": "arn:aws:quicksight:*:<Quick-account-id>: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 账户承担角色 B，并通过与数据源 ARN 关联的 ExternalId 条件进行限制。示例策略如下：

{
"Version": "2012-10-17",
"Statement": [
        {
        "Effect": "Allow",
        "Principal": {
        "AWS": "arn:aws:iam::<Quick-account-id>:root"
            },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringLike": {
            "sts:ExternalId": "arn:aws:quicksight:*:<Quick-account-id>: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:<region>:<account-id>:workgroup/<your-workgroup>",
        "arn:aws:athena:<region>:<account-id>:datacatalog/<your-catalog>"
      ]
        },
        {
            "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:<region>:<account-id>:catalog",
                        "arn:aws:glue:<region>:<account-id>:database/<your-database>",
                        "arn:aws:glue:<region>:<account-id>:table/<your-database>/*"
                    ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject",
				"s3:PutObject",
				"s3:AbortMultipartUpload",		 
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::<your-data-bucket>",
                "arn:aws:s3:::<your-data-bucket>/*",
                "arn:aws:s3:::aws-athena-query-results-*",
                "arn:aws:s3:::aws-athena-query-results-*/*"
            ]
        }
    ]
}

代码

使用 AWS CLI 将权限策略作为内联策略附加

aws iam put-role-policy \
--role-name qs-athena-consumer-role \
--policy-name AthenaGlueS3Access \
--policy-document file://role-b-permission-policy.json

代码

在 Quick 中创建跨账户 Athena 数据源（中心账户或源账户）

使用 AWS CLI，输入以下命令：

aws quicksight create-data-source \
--aws-account-id <Quick-account-id> \
--data-source-id "athena-cross-account" \
--name "Athena 跨账户 - 消费者数据" \
--type ATHENA \
--data-source-parameters '{
"AthenaParameters": {
"WorkGroup": "primary",
"RoleArn": "arn:aws:iam::<Quick-account-id>:role/qs-athena-cross-account-role-a",
"ConsumerAccountRoleArn": "arn:aws:iam::<consumer-account-id>:role/qs-athena-consumer-role"
}
}' \
--permissions '[{
"Principal": "arn:aws:quicksight:<region>:<Quick-account-id>:user/default/<your-user>",
"Actions": [
"quicksight:DescribeDataSource",
"quicksight:DescribeDataSourcePermissions",
"quicksight:PassDataSource",
"quicksight:UpdateDataSource",
"quicksight:DeleteDataSource",
"quicksight:UpdateDataSourcePermissions"
]
}]' \
--region <region>

代码

或者使用 Python (Boto3)：

import boto3

client = boto3.client('quicksight', region_name='us-east-1')

response = client.create_data_source(
AwsAccountId='<Quick-account-id>',
DataSourceId='athena-cross-account',
Name='Athena 跨账户 - 消费者数据',
Type='ATHENA',
DataSourceParameters={
'AthenaParameters': {
'WorkGroup': 'primary',
'RoleArn': 'arn:aws:iam::<Quick-account-id>:role/qs-athena-cross-account-role-a',
'ConsumerAccountRoleArn': 'arn:aws:iam::<consumer-account-id>:role/qs-athena-consumer-role'
}
}
)
print(response['CreationStatus'])

代码

验证数据源是否成功创建：

aws quicksight describe-data-source \
--aws-account-id <Quick-account-id> \
--data-source-id "athena-cross-account" \
--region <region> \
--query 'DataSource.{Name:Name,Status:Status,Type:Type}'

CSS

预期输出：

{
"Name": "Athena 跨账户 - 消费者数据",
"Status": "CREATION_SUCCESSFUL",
"Type": "ATHENA"
}

CSS

共享数据源并创建数据集

数据源激活后，可使用以下示例代码将其共享给 Quick 用户：

aws quicksight update-data-source-permissions \
--aws-account-id <Quick-account-id> \
--data-source-id "athena-cross-account" \
--grant-permissions '{
"Principal": "arn:aws:quicksight:<region>:<Quick-account-id>:user/default/<author-user>",
"Actions": [
"quicksight:DescribeDataSource",
"quicksight:DescribeDataSourcePermissions",
"quicksight:PassDataSource"
]
}' \
--region <region>

CSS

现在用户可以打开 Quick，进入“数据集”页面，创建新的数据集，选择 Athena 跨账户 数据源，并浏览来自消费者账户的 AWS Glue 数据库和表。他们可以在中心 Quick 账户中构建数据集、应用转换并创建仪表板，而查询费用将由消费者账户承担。

连接多个消费者账户

要连接额外的消费者账户，对每个角色/账户重复上述解决方案即可。

• 更新角色 A 的权限策略，以包含新的消费者账户角色 ARN（如果您的消费者角色遵循命名约定，也可以使用通配符模式）。
• 在新的消费者账户中创建具有适当信任关系和数据访问策略的角色 B。
• 在 Quick 中使用新的 ConsumerAccountRoleArn 创建一个新的数据源。
• 共享该数据源。
• 每个数据源对应一个消费者账户。作者根据需要访问哪个业务单元的数据来选择合适的数据源。

安全注意事项

跨账户 Athena 访问的安全模型旨在实现大规模的分布式数据访问，同时确保每个查询都经过授权、作用域受限且可审计。如操作指南所述，角色 B 信任策略中的 ExternalId 条件可防止混淆委托人攻击。只有来自已授权（中心）账户的 Quick 数据源才能完成角色链。此外，Quick 每次代入角色 A 时都会应用一个内联的作用域缩小策略，即使角色 A 的常规权限涵盖多个账户，也能将每个会话限制为仅访问单个消费者角色。这些机制共同确保了每个查询链既经过身份验证又具有严格的作用域限制。消费者账户通过角色 B 的权限维持自身的最小权限边界。每个业务单元独立决定中心 BI AWS 账户可以访问哪些表、数据库和 S3 前缀。我们建议将 AWS Glue 和 S3 权限限定到具体资源而非使用通配符，将角色 B 限制在启用了查询结果加密和成本限制的指定 Athena 工作组内，并在消费者账户包含不同分类级别的数据时使用独立的角色 B 实例。

完整的角色链会在两个账户的 AWS CloudTrail 日志中被记录下来，从中心账户最初的 AssumeRole 操作开始，贯穿整个链条进入消费者账户并执行后续的 Athena 查询。这提供了从查询发起至数据访问的完整审计轨迹，并支持对异常模式（例如意外的源账户或扫描数据量激增）发出告警。

如操作指南第 1 步所述，创建数据源的 IAM 主体必须拥有对角色 A 的 iam:PassRole 权限，以防止管理员将任意角色关联到数据源。这些机制（ExternalId、作用域缩小、最小权限、CloudTrail 和 PassRole）构成了纵深防御模型，完全由策略驱动且可编程，随着该领域工具的发展，非常适合实现自动化治理。

成本归属

由于 Athena 查询是在消费者账户内以角色 B 的凭证执行的，所有相关的 AWS API 调用均发生在该账户中。标准 AWS 计费会自动处理成本分离。消费者账户将在其账单中看到 Athena 查询费用、S3 访问成本以及 AWS Glue 目录调用费用。中心 Quick 账户仅产生 Quick 会话费用和 SPICE 存储费用。在此功能推出之前，企业要么将所有查询成本集中在中心账户（失去按业务单元的成本可见性），要么为每个业务单元运行独立的 Quick 订阅，导致 BI 体验碎片化。跨账户 Athena 访问消除了这种权衡：既能统一部署 Quick，又能实现按业务单元的成本可见性，且无需自定义分摊计费逻辑。

清理

为了避免持续产生费用，请删除实验过程中创建的 AWS 资源（IAM 角色、Quick Sight 数据源、策略）。具体操作说明请参见服务文档。

结论

Amazon Quick 的跨账户 Athena 访问功能使企业能够在维护集中式 BI AWS 账户的同时，尊重多账户环境下的数据治理和成本边界。角色链机制提供了准确的成本归属，保持了各业务单元的数据主权，并与现有的 IAM 安全控制机制集成。

要开始使用，请按照本文描述在您的 Quick 账户和消费者账户中创建 IAM 角色，然后使用 ConsumerAccountRoleArn 参数创建数据源。更多详细信息，请参阅 Amazon Quick 用户指南。

• * *

关于作者