O problema dos dados em silos
Grandes empresas raramente concentram todos os seus dados em uma única conta AWS. O cenário mais comum é justamente o oposto: uma instituição financeira, por exemplo, pode manter dados de banco de varejo em uma conta, investimentos em outra e gestão de riscos em uma terceira. Ao mesmo tempo, a área de BI (Business Intelligence) costuma operar de forma centralizada.
Até agora, quem usava o Amazon Quick nesse tipo de ambiente tinha duas opções ruins: gerenciar múltiplas assinaturas do serviço — uma por conta de dados — ou absorver todos os custos de consulta na conta central, perdendo a visibilidade de gastos por unidade de negócio. A AWS acaba de resolver esse impasse com o lançamento do acesso cross-account ao Amazon Athena para o Amazon Quick.
O que é o Amazon Quick e o papel do Athena
O Amazon Quick é um serviço unificado de inteligência com IA que reúne dados estruturados e conteúdo corporativo não estruturado — documentos, e-mails, bases de conhecimento — em um único ambiente onde qualquer pessoa pode explorar, analisar e agir sobre as informações. Ele conta com mais de 40 integrações com aplicações e inclui o Amazon QuickSight, sua camada de BI com dashboards interativos, consultas em linguagem natural, relatórios e insights com ML (Machine Learning).
O Amazon Athena, por sua vez, é um serviço de consulta interativa e serverless que analisa dados diretamente no Amazon Simple Storage Service (Amazon S3) usando SQL padrão, sem necessidade de gerenciar infraestrutura ou carregar dados previamente. Basta apontar o Athena para os dados no S3, definir o esquema via AWS Glue Data Catalog e começar a consultar.
O novo recurso: acesso cross-account ao Athena
Com o novo recurso anunciado pela AWS, é possível consultar dados do Athena em outras contas AWS diretamente a partir de uma implantação centralizada do Amazon Quick, usando encadeamento de funções IAM (Identity and Access Management). Os custos de consulta são cobrados na conta onde os dados residem — não na conta central.
O mecanismo central é o role chaining (encadeamento de funções): o Amazon Quick, operando na conta central, assume uma primeira função IAM (Função A), que por sua vez assume uma segunda função IAM (Função B) na conta consumidora. É a Função B que executa as consultas no Athena e no AWS Glue Data Catalog, sem que credenciais de longo prazo sejam compartilhadas entre contas.
Definições importantes
- Conta Central do Quick (Source Account): conta AWS onde o Amazon Quick está implantado.
- Conta Consumidora (Consumer Account): conta AWS onde residem os dados do Athena (bancos de dados, tabelas, dados no S3).
- RunAsRole (Função A): função IAM na conta central que o Quick assume primeiro; não tem permissões de dados, apenas permissão para encadear na Função B.
- Consumer Account Role (Função B): função IAM em cada conta consumidora que concede acesso ao Athena, AWS Glue e S3; confia na Função A.
- Role Chaining: processo de credenciais em dois passos — o Quick assume a Função A, depois usa essas credenciais para assumir a Função B.
- ExternalId: condição de segurança (definida como o ARN do DataSource) usada nas trust policies para prevenir ataques do tipo confused deputy.
- Scope-Down Policy: política IAM inline aplicada em tempo de execução para restringir as credenciais encadeadas a assumir apenas a função consumidora específica.
- Athena Workgroup: ambiente de execução do Athena na conta consumidora onde as consultas são executadas e os custos são rastreados.
Arquitetura e padrões de implantação
A AWS descreve três padrões arquiteturais que evoluem conforme a maturidade da organização.
Padrão 1: Configuração básica com duas contas
A configuração mais simples conecta uma conta central do Quick a uma única conta consumidora. É o ponto de partida ideal para validar o encadeamento de funções de ponta a ponta. A Função A, na conta central, encadeia na Função B via sts:AssumeRole, e o Athena executa a consulta com as credenciais da Função B.
Padrão 2: Hub and Spoke
A maioria das empresas centraliza o Quick em uma única conta (o hub) enquanto os dados ficam distribuídos por múltiplas contas de unidades de negócio (os spokes). Nesse modelo, a política de permissões da Função A lista os ARNs de múltiplas funções consumidoras, e uma fonte de dados separada é criada no Quick para cada conta.
A grande vantagem desse padrão é a independência entre os spokes. Adicionar uma nova unidade de negócio exige apenas criar uma nova Função B na conta dessa unidade e registrar uma nova fonte de dados no Quick — sem alterar os spokes existentes. Cada spoke controla suas próprias permissões, definindo quais tabelas e prefixos S3 ficam visíveis para a conta central de BI. Os custos de consulta são atribuídos automaticamente a cada conta consumidora.
Para escalar além de alguns poucos spokes, a AWS recomenda usar templates de AWS CloudFormation ou CDK para a configuração do lado consumidor, permitindo que equipes de unidades de negócio façam o onboarding de forma autônoma.
Padrão 3: Data Mesh
Em uma arquitetura de data mesh, produtores e consumidores são contas distintas. Uma conta produtora gerencia seus dados brutos e os disponibiliza para contas consumidoras — por exemplo, usando AWS Lake Formation com AWS RAM (Resource Access Manager) para compartilhar tabelas entre contas. A conta consumidora, contendo a Função B, o AWS Glue Data Catalog e o Athena workgroup, é o ponto ao qual o Amazon Quick se conecta via encadeamento de funções.
Nesse modelo, um autor de BI no Quick pode consultar múltiplas contas consumidoras em um único dashboard, com custos atribuídos por conta consumidora. Em escala enterprise, uma única implantação do Amazon Quick pode se conectar a centenas de contas consumidoras.
Como escolher o padrão certo
A AWS recomenda começar com a configuração básica de duas contas para validar o encadeamento. A maioria das empresas evoluirá para o hub-and-spoke ao integrar novas unidades de negócio, pela simplicidade na atribuição de custos e na gestão de trust policies. Organizações com fortes limites de propriedade de dados e equipes de domínio dedicadas naturalmente migrarão para o data mesh.
Passo a passo: configuração técnica
Pré-requisitos
- Amazon Quick Enterprise Edition ativo na conta central.
- Acesso administrativo IAM em ambas as contas.
- AWS CLI instalada e configurada com credenciais para ambas as contas, ou acesso ao Console de Gerenciamento AWS.
- Familiaridade com conceitos IAM: trust policies, permission policies e assunção de funções (
sts:AssumeRole).
- Athena workgroup configurado na conta consumidora.
- Bucket S3 na conta consumidora para resultados de consultas do Athena (geralmente com prefixo
aws-athena-query-results-*).
Etapa 1: Criar a Função A (RunAsRole) na conta central
A Função A vive na conta central. O Amazon Quick a assume quando um usuário inicia uma consulta. Ela não tem permissões de dados — sua única função é encadear na conta consumidora. São necessários dois elementos: uma trust policy que permite ao serviço Quick assumi-la, e uma permission policy que permite assumir a Função B.
Crie o arquivo role-a-trust-policy.json:
{
"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/*"
}
}
}
]
}
Crie a função via 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"
Crie o arquivo 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/*"
}
}
}
]
}
Anexe a política inline via AWS CLI:
aws iam put-role-policy \
--role-name qs-athena-cross-account-role-a \
--policy-name AssumeConsumerRolePolicy \
--policy-document file://role-a-permission-policy.json
O principal IAM que criar a fonte de dados no Quick também precisa da permissão iam:PassRole sobre a Função A.
Etapa 2: Criar a Função B na conta consumidora
A Função B vive na conta consumidora, onde estão as tabelas do Athena, o AWS Glue Data Catalog e os dados no S3. A Função A a assume para executar as consultas.
Crie o arquivo role-b-trust-policy.json:
{
"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/*"
}
}
}
]
}
Crie a função via 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"
Crie o arquivo role-b-permission-policy.json com permissões para Athena, AWS Glue e S3. A AWS recomenda escopo para recursos específicos, não wildcards genéricos:
{
"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-*/*"
]
}
]
}
Anexe a política inline via AWS CLI:
aws iam put-role-policy \
--role-name qs-athena-consumer-role \
--policy-name AthenaGlueS3Access \
--policy-document file://role-b-permission-policy.json
Etapa 3: Criar a fonte de dados cross-account no Quick
Com as funções configuradas, o próximo passo é criar a fonte de dados no Amazon Quick, na conta central. Isso pode ser feito via 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>
Ou via 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'])
Para verificar se a fonte de dados foi criada com sucesso:
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}'
A saída esperada é:
{
"Name": "Athena Cross Account - Consumer Data",
"Status": "CREATION_SUCCESSFUL",
"Type": "ATHENA"
}
Etapa 4: Compartilhar a fonte de dados e criar datasets
Com a fonte de dados ativa, ela pode ser compartilhada com autores do Quick usando o seguinte comando:
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>
A partir daí, os autores podem acessar o Quick, navegar até Datasets, criar um novo dataset selecionando a fonte de dados cross-account e navegar pelos bancos de dados e tabelas AWS Glue da conta consumidora — tudo a partir da conta central, com os custos de consulta cobrados na conta consumidora.
Conectando múltiplas contas consumidoras
Para conectar contas consumidoras adicionais, basta repetir o processo de criação de funções para cada conta, atualizar a política de permissões da Função A para incluir o ARN da nova função consumidora, criar a Função B na nova conta com as políticas de trust e acesso a dados apropriadas, e criar uma nova fonte de dados no Quick com o novo ConsumerAccountRoleArn. Cada fonte de dados mapeia para uma conta consumidora.
Segurança e atribuição de custos
O modelo de segurança é construído em camadas. A condição ExternalId na trust policy da Função B previne ataques do tipo confused deputy — somente fontes de dados Quick da conta central autorizada conseguem completar o encadeamento. Além disso, o Quick aplica uma scope-down policy inline cada vez que assume a Função A, restringindo cada sessão a uma única função consumidora, mesmo quando a Função A tem permissões para múltiplas contas.
A cadeia completa de funções é registrada no AWS CloudTrail em ambas as contas — desde o AssumeRole inicial na conta central até as consultas no Athena na conta consumidora. Isso fornece uma trilha de auditoria completa e suporta alertas sobre padrões anômalos.
Quanto à atribuição de custos: como as consultas do Athena são executadas sob as credenciais da Função B na conta consumidora, todos os custos associados aparecem na fatura dessa conta. A conta central do Quick incorre apenas nos custos de sessão do Quick e armazenamento SPICE. Antes desse recurso, as organizações precisavam absorver todos os custos centralmente ou operar assinaturas separadas do Quick por unidade de negócio — o novo recurso elimina esse trade-off.
O que isso significa para o futuro com IA agêntica
À medida que capacidades de IA agêntica amadurecem, a habilidade de acessar dados onde eles residem — com governança, atribuição de custos e auditabilidade — se torna fundamental. O acesso cross-account ao Athena é um bloco de construção para esse futuro. O mesmo mecanismo de encadeamento de funções IAM pode ser estendido para agentes de IA que consultam o Athena em nome de usuários de negócio, aplicam regras de governança em tempo real e roteiam custos de computação para o proprietário dos dados — sem centralizar dados em uma única conta.
Conclusão
O acesso cross-account ao Athena para o Amazon Quick permite que empresas mantenham uma conta central de BI enquanto respeitam os limites de governança de dados e custos em ambientes multi-account. A abordagem de role chaining garante atribuição correta de custos, mantém a soberania de dados por unidade de negócio e se integra aos controles de segurança IAM existentes.
Para começar, basta criar as funções IAM nas contas do Quick e consumidoras conforme descrito neste guia, e então criar a fonte de dados usando o parâmetro ConsumerAccountRoleArn. Mais detalhes estão disponíveis no Guia do Usuário do Amazon Quick.
Fonte
From siloed data to unified insights: Cross-account Athena Access for Amazon Quick (https://aws.amazon.com/blogs/machine-learning/from-siloed-data-to-unified-insights-cross-account-athena-access-for-amazon-quick/)
