Amazon Quick получил cross-account Athena access для запросов к данным в других AWS-аккаунтах
Amazon Quick — это сервис унифицированной интеллектуальной аналитики на базе ИИ, который объединяет данные организации, структурированный контент и неструктурированный корпоративный контент, такой как документы, письма и базы знаний, в единый сервис, где любой пользователь может исследовать данные, анализировать их и действовать на основе полученных выводов. Благодаря более чем 40 интеграциям приложений Quick закрывает last-mile gap между инсайтами и действиями, чтобы пользователи могли понимать данные и сразу применять результаты на практике.
Amazon Quick Sight, BI-возможность Amazon Quick, — это единый BI-сервис. Он предоставляет современные интерактивные дашборды, запросы на естественном языке, отчеты с пиксельной точностью, ML-выводы и встроенную аналитику в масштабе. Amazon Quick объединяет AI-агентов для бизнес-аналитики, исследований и автоматизации в одном интегрированном опыте, помогая работать быстрее и эффективнее при сохранении политик безопасности и доступа.
Amazon Athena — это бессерверный интерактивный сервис запросов, который позволяет анализировать данные напрямую в Amazon Simple Storage Service (Amazon S3) с использованием стандартного SQL, без управления инфраструктурой и без загрузки данных. Вы указываете Athena на данные, хранящиеся в Amazon S3, задаете схему через AWS Glue Data Catalog и начинаете выполнять запросы.
Многие предприятия централизуют развертывание Amazon Quick в одном AWS-аккаунте, тогда как данные находятся в нескольких аккаунтах бизнес-подразделений. Например, финансовая компания может запускать Quick в центральном AWS-аккаунте, а данные розничного банкинга хранить в Account A, инвестиционного банкинга — в Account B, а управления рисками — в Account C. До сих пор запросы к данным Amazon Athena в этих аккаунтах означали либо управление несколькими подписками Quick, либо перенос всех расходов на запросы в центральный аккаунт.
Сегодня мы объявляем о cross-account Athena access для Amazon Quick. С этой функцией клиенты могут выполнять запросы к данным Athena в других AWS-аккаунтах с использованием IAM role chaining, а стоимость запросов будет списываться на тот аккаунт, где находятся данные. В контексте cross-account Athena access role chaining позволяет Amazon Quick в publisher account взять на себя роль в consumer account клиента, а эта роль уже получает права на запросы к данным в Athena и AWS Glue Data Catalog без передачи долгоживущих учетных данных через границы аккаунтов. В этой статье мы покажем полную настройку: создание IAM roles, настройку trust policies, создание cross-account data source в Quick и формирование datasets на его основе.
Определения терминов
- Central Quick Account (Source Account): AWS-аккаунт, в котором развернут Amazon Quick
- Consumer Account: AWS-аккаунт, в котором находятся активы данных Athena (базы данных, таблицы, данные в S3), доступные из центрального Quick account
- RunAsRole (Role A): IAM role в центральном Quick account, которую Quick запрашивает первой; не содержит прав на данные, а дает только возможность цепочки в роли consumer account
- Consumer Account Role (Role B): IAM role в каждом consumer account, которая предоставляет доступ к Athena, AWS Glue и S3; доверяет Role A
- Role Chaining: Двухэтапный процесс получения учетных данных, при котором Quick запрашивает RunAsRole, а затем использует эти учетные данные для запроса consumer account role
- ExternalId: Условие безопасности (задается как DataSource ARN), используемое в trust policies для предотвращения атак confused deputy при принятии роли
- Scope-Down Policy: Встроенная IAM policy, прикрепляемая во время выполнения, чтобы ограничить chained credentials только принятием конкретной consumer account role
- Athena Workgroup: Среда выполнения Athena в consumer account, в которой запускаются запросы и учитываются расходы
Обзор решения
Решение использует двухшаговый механизм role chaining с двумя IAM roles:
- Role A (RunAsRole) — находится в центральном Quick account. Quick сначала запрашивает именно эту роль.
- Role B (Consumer Account Role) — находится в consumer account, где хранятся данные Athena. Role A переходит в Role B для выполнения запросов.
Когда пользователь Quick запускает запрос, сервис сначала запрашивает Role A, а затем использует эти учетные данные для запроса Role B в consumer account. Athena выполняет запрос с учетными данными Role B, поэтому вычислительные расходы списываются на consumer account.
Предварительные требования
Перед началом убедитесь, что выполнены следующие условия:
- Amazon Quick Enterprise Edition активирован в центральном аккаунте
- IAM administrative access есть в обоих аккаунтах. В каждом из них вы будете создавать и настраивать роли
- AWS Command Line Interface (AWS CLI) установлен и настроен с учетными данными для обоих аккаунтов, либо есть доступ к AWS Management Console
- Понимание IAM concepts, в частности trust policies, permission policies и role assumption (sts:AssumeRole)
- Athena workgroup настроен в consumer account (для начала подойдет стандартный primary workgroup)
- S3 bucket в consumer account для результатов запросов Athena (обычно с префиксом aws-athena-query-results-*)
Примечание: Чтобы подключить несколько consumer accounts, повторите шаги настройки ролей для каждого аккаунта. Заранее продумайте схему именования IAM roles, чтобы упростить масштабное управление.
Техническая архитектура
По мере того как организации переходят к lakehouse-архитектурам и распределяют данные по бизнес-подразделениям, AWS Regions и AWS accounts, им нужен способ централизованно запрашивать эти данные без их перемещения. Cross-account Athena access для Amazon Quick решает именно эту задачу. С помощью IAM role chaining центральное развертывание Quick может обращаться к распределенным хранилищам данных через границы аккаунтов без репликации данных, общих долгоживущих учетных данных и нескольких подписок Quick. Архитектура масштабируется от proof of concept на два аккаунта до развертывания уровня всего предприятия. В этом разделе описаны три паттерна, каждый из которых развивает предыдущий.
Паттерн 1: базовая схема из двух аккаунтов
Самое простое развертывание соединяет один центральный Quick account с одним consumer account. Это минимально жизнеспособная конфигурация, которая напрямую соответствует пошаговому руководству в этой статье. Цепочка ролей, описанная в обзоре решения (Quick запрашивает Role A, Role A переходит в Role B через sts:AssumeRole, а Athena выполняет запрос под учетными данными Role B), применяется здесь напрямую. Этот паттерн хорошо подходит для первичной проверки или для подключения данных одного бизнес-подразделения к общему (центральному) BI AWS account.
Паттерн 2: Hub and Spoke
Большинство предприятий централизуют развертывание Quick в одном аккаунте (hub), а данные распределяют по нескольким аккаунтам бизнес-подразделений (spokes). Модель hub-and-spoke развивает базовую схему: permission policy Role A перечисляет несколько ARN consumer roles, которые могут находиться как в одном аккаунте, так и в разных, а для каждого создается отдельный data source в Quick. Главное преимущество этого паттерна — независимость spoke-аккаунтов. Добавление нового бизнес-подразделения требует создать новую Role B в аккаунте этого подразделения и зарегистрировать новый data source в Quick, без изменений для уже существующих spokes. Каждый spoke сам контролирует права Role B, определяя, какие таблицы и S3 prefixes видны центральному BI AWS account. Распределение затрат происходит естественно: запросы Athena каждого spokes списываются на его собственный аккаунт. Поскольку один дашборд Quick может ссылаться на data sources из нескольких consumer accounts, BI-авторы могут строить аналитику по нескольким подразделениям, не покидая унифицированную среду Quick. Это рекомендуемый паттерн для большинства предприятий.
Если количество spokes растет, стоит шаблонизировать настройку на стороне consumer. Шаблон AWS CloudFormation или CDK для Role B, Athena workgroup и необходимых trust- и permission policies позволит командам бизнес-подразделений самостоятельно подключаться, либо центральной BI-команде — создавать новые spokes одним развертыванием стека.
Паттерн 3: Data Mesh
В data mesh producer accounts и consumer accounts — это разные аккаунты. Producer account владеет и управляет своими исходными данными, подготавливая их для Consumer Account. Например, можно использовать AWS Lake Formation вместе с AWS Resource Access Manager (AWS RAM), чтобы делиться таблицами через границы аккаунтов. Конкретный механизм подготовки данных зависит от domain team и выходит за рамки статьи. Consumer Account, в котором находятся Role B, AWS Glue Data Catalog и Athena workgroup, — это именно тот аккаунт, к которому Amazon Quick подключается через role chain. Аккаунт публикует управляемые data products в другие Consumer Accounts с помощью resource policies AWS Glue Data Catalog, делая свои данные доступными для междоменной аналитики. Именно такое peer-to-peer sharing между Consumer Accounts, где каждый выступает и как producer, и как consumer data products, и определяет mesh. BI-автор в Quick может выполнять запросы сразу к нескольким Consumer Accounts в одном дашборде, а расходы на запросы распределяются по каждому Consumer Account. На масштабе предприятия одно развертывание Amazon Quick может подключаться к сотням Consumer Accounts. То, как domain accounts подготавливают исходные данные для Consumer Accounts, в статье не рассматривается.
Выбор паттерна
Подходящий паттерн зависит от вашей data strategy. Базовая схема из двух аккаунтов проверяет role chain end to end. Большинство предприятий будут переходить к hub-and-spoke по мере подключения новых бизнес-подразделений, потому что этот подход сохраняет независимость spokes, делает распределение затрат понятным и оставляет trust policies простыми. Организации с жесткими границами владения данными или выделенными domain teams естественным образом придут к паттерну data mesh, где Consumer Accounts отделены от producer accounts, поставляющих данные, а Amazon Quick выступает единым аналитическим слоем для всех них. Мы рекомендуем начинать с малого и расширяться по мере роста требований.
Что дальше
По мере того как возможности agentic AI будут развиваться, а AI agents начнут автономно запрашивать, преобразовывать и использовать данные через организационные границы, возможность обращаться к данным там, где они хранятся, при наличии governance, cost attribution и аудита, станет базовой. Cross-account Athena access — это строительный блок для такого будущего. Сегодня он связывает дашборды Quick с распределенными data lakes. По мере развития agentic patterns тот же механизм IAM role chaining можно будет использовать для AI agents, которые запрашивают Athena от имени бизнес-пользователей, применяют правила governance в реальном времени и относят вычислительные расходы к владельцу данных без централизации данных в одном аккаунте.
Решение
Cross-account Athena access для Amazon Quick использует IAM role chaining, чтобы связать центральный Quick account с одним или несколькими consumer accounts, где хранятся ваши данные. Вместо консолидации данных в одном аккаунте или управления отдельными подписками Quick для каждого business unit вы настраиваете две IAM roles, которые работают вместе: по одной в каждом аккаунте, чтобы корректно направлять запросы и атрибутировать затраты.
Создайте Role A (RunAsRole) в центральном Quick account
Role A находится в центральном Quick account. Amazon Quick запрашивает эту роль, когда пользователь инициирует запрос. У Role A нет собственных прав на данные; ее единственная задача — перейти в consumer account. Для этого ей нужны две вещи:
- Trust policy, разрешающая сервису Quick принимать эту роль.
- Permission policy, разрешающая Role A принимать Role B в consumer account.
Создайте trust policy и сохраните ее под именем role-a-trust-policy.json. Она позволяет service principal Quick принимать Role A, ограничивая это операциями data source в вашем аккаунте. Пример policy:
{
"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"
Создайте permissions policy и назовите ее 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/*"
}
}
}
]
}
Прикрепите permissions policy как inline policy с помощью AWS CLI. Это позволяет Role A принимать Role B в consumer account. Условие ExternalId гарантирует, что цепочку ролей смогут инициировать только Quick data sources:
aws iam put-role-policy \
--role-name qs-athena-cross-account-role-a \
--policy-name AssumeConsumerRolePolicy \
--policy-document file://role-a-permission-policy.json
Кроме того, IAM principal, который создает Quick data source, должен иметь разрешение iam:PassRole на Role A.
Создайте Role B в consumer account
Role B находится в consumer account, где расположены ваши таблицы Athena, AWS Glue Data Catalog и данные в S3. Role A принимает Role B, чтобы выполнить запрос.
Создайте trust policy и назовите ее role-b-trust-policy.json. Она позволяет Quick account принимать Role B, с условием ExternalId, привязанным к ARN data source. Пример policy:
{
"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"
Создайте permissions policy для Athena, AWS Glue и S3 и назовите ее role-b-permission-policy.json. Ограничьте ее конкретными базами данных, таблицами и S3 locations, связанными с вашими данными.
{
"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-*/*"
]
}
]
}
Прикрепите permissions policy как inline policy с помощью AWS CLI
aws iam put-role-policy \
--role-name qs-athena-consumer-role \
--policy-name AthenaGlueS3Access \
--policy-document file://role-b-permission-policy.json
Создайте Cross-Account Athena Data Source в Quick (central or source account)
С помощью AWS CLI введите следующее:
aws quicksight create-data-source \
--aws-account-id <Quick-account-id> \
--data-source-id "athena-cross-account" \
--name "Athena Cross Account - Consumer Data" \
--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 Cross Account - Consumer Data',
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'])
Проверьте, что data source создан успешно:
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}'
Ожидаемый вывод:
{
"Name": "Athena Cross Account - Consumer Data",
"Status": "CREATION_SUCCESSFUL",
"Type": "ATHENA"
}
Поделитесь Data Source и создайте Datasets
После активации data source поделитесь им с авторами 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>
Теперь авторы могут открыть Quick, перейти в Datasets, создать новый dataset, выбрать data source Athena Cross Account и просмотреть базы данных и таблицы AWS Glue из consumer account. Они могут строить datasets, применять преобразования и создавать дашборды из центрального Quick account, а расходы на запросы будут списываться на consumer account.
Подключение нескольких consumer accounts
Чтобы подключить дополнительные consumer accounts, повторите описанное выше решение для каждой пары role/account
- Обновите permission policy Role A, добавив ARN новой consumer account role (или используйте шаблон с wildcard, если ваши consumer roles имеют единый шаблон именования).
- Создайте Role B в новом consumer account с соответствующими trust и data access policies.
- Создайте новый data source в Quick с новым ConsumerAccountRoleArn.
- Поделитесь data source.
- Каждый data source соответствует одному consumer account. Авторы выбирают нужный data source в зависимости от того, данные какого business unit им нужны.
Соображения безопасности
Модель безопасности cross-account Athena access рассчитана на то, чтобы обеспечить распределенный доступ к данным в масштабе, при этом каждая операция запроса была авторизована, ограничена по объему и поддавалась аудиту. Как описано в руководстве, условие ExternalId в trust policy Role B предотвращает атаки confused deputy. Только Quick data sources из авторизованного (центрального) аккаунта могут завершить цепочку ролей. Кроме того, каждый раз, когда Quick запрашивает Role A, он применяет inline scope-down policy, ограничивая каждую сессию одной consumer role, даже если постоянные права Role A охватывают несколько аккаунтов. Вместе эти механизмы гарантируют, что каждая цепочка запросов и аутентифицирована, и строго ограничена. Consumer account поддерживает собственную границу least privilege через права Role B. Каждое бизнес-подразделение независимо определяет, какие таблицы, базы данных и S3 prefixes видны центральному BI AWS account. Мы рекомендуем ограничивать разрешения AWS Glue и S3 конкретными ресурсами, а не использовать wildcard, ограничивать Role B выделенным Athena workgroup с включенным шифрованием результатов запросов и лимитами затрат, а также использовать отдельные экземпляры Role B, если в consumer account есть данные разных уровней классификации.
Полная цепочка ролей фиксируется в AWS CloudTrail в обоих аккаунтах: от первоначального AssumeRole в центральном аккаунте через переход в consumer account и далее к последующим Athena-запросам. Это обеспечивает полный аудит-трейл от запуска запроса до доступа к данным и позволяет настраивать оповещения о необычных паттернах, таких как неожиданные source accounts или резкий рост объема просканированных данных.
Как отмечено в шаге 1 руководства, IAM principal, создающий data source, должен иметь iam:PassRole на Role A, что не позволяет администраторам связывать с data sources произвольные роли. Эти механизмы — ExternalId, scope-down, least privilege, CloudTrail и PassRole — формируют модель defense in depth, полностью основанную на политиках и программной автоматизации, что хорошо подходит для автоматизированного governance по мере развития инструментов в этой области.
Распределение затрат
Поскольку запросы Athena выполняются под учетными данными Role B в consumer account, все связанные вызовы AWS API происходят в этом аккаунте. Стандартная система биллинга AWS автоматически разделяет затраты. В consumer account отражаются расходы на запросы Athena, доступ к S3 и вызовы AWS Glue catalog. Центральный Quick account несет только расходы на сессии Quick и SPICE storage. До появления этой функции организации либо централизованно брали на себя все расходы на запросы, теряя видимость по бизнес-подразделениям, либо использовали отдельные подписки Quick для каждого подразделения, фрагментируя BI-опыт. Cross-account Athena access снимает этот компромисс: единое развертывание Quick с видимостью затрат по подразделениям без необходимости в собственной логике chargeback.
Очистка ресурсов
Чтобы избежать дальнейших расходов, удалите AWS resources (IAM roles, Quick Sight data sources, policies), которые вы создали в ходе эксперимента. Инструкции приведены в документации сервиса.
Заключение
Cross-account Athena access для Amazon Quick позволяет предприятиям сохранять централизованный BI AWS account, одновременно соблюдая multi-account data governance и границы затрат. Подход на основе role chaining обеспечивает корректное распределение затрат, сохраняет data sovereignty для каждого business unit и интегрируется с существующими IAM security controls.
Чтобы начать, создайте IAM roles в своих Quick и consumer accounts, как описано в этой статье, а затем создайте data source с параметром ConsumerAccountRoleArn. Дополнительные сведения см. в Amazon Quick User Guide.
Материал — перевод статьи с английского.
Оригинал: From siloed data to unified insights: Cross-account Athena Access for Amazon Quick