←
AITYBlog
Cloud

Acesso Athena Cross-Account para Amazon Quick: Unificando Dados

Introdução

Na AITY, compreendemos a complexidade de gerenciar dados distribuídos em ambientes de nuvem. O Amazon Quick é um serviço de inteligência unificada, alimentado por IA, que consolida dados estruturados e conteúdo empresarial não estruturado – como documentos, e-mails e bases de conhecimento – em um único local para exploração, análise e ação. Com mais de 40 integrações, o Quick conecta insights à ação, permitindo que os usuários entendam seus dados e atuem diretamente. O Amazon Quick Sight, sua capacidade de Business Intelligence (BI), oferece dashboards interativos, consultas em linguagem natural, relatórios precisos, insights de Machine Learning (ML) e análises incorporadas em escala.

O Amazon Athena é um serviço de consulta interativa e serverless que permite analisar dados diretamente no Amazon Simple Storage Service (Amazon S3 usando SQL padrão, sem necessidade de gerenciar infraestrutura ou carregar dados. Você aponta o Athena para seus dados no S3, define o esquema usando o AWS Glue Data Catalog e começa a consultar.

Muitas empresas centralizam sua implantação do Amazon Quick em uma única conta AWS, enquanto seus dados residem em várias contas de unidades de negócio. Isso gerava desafios para consultar dados do Athena entre essas contas, exigindo múltiplas assinaturas do Quick ou a absorção de todos os custos de consulta na conta central.

Hoje, temos o prazer de anunciar o acesso Athena cross-account para Amazon Quick. Com essa funcionalidade, clientes podem consultar dados do Athena em outras contas AWS usando encadeamento de roles do AWS Identity and Access Management (IAM), com os custos de consulta sendo faturados para a conta onde os dados residem.

Definições de Termos Essenciais

Para facilitar a compreensão, apresentamos alguns termos importantes:

Visão Geral da Solução

A solução emprega um mecanismo de encadeamento de roles em duas etapas, envolvendo duas roles IAM:

Quando um usuário do Quick executa uma consulta, o serviço assume a Role A e, em seguida, usa essas credenciais para assumir a Role B na conta do consumidor. O Athena executa a consulta usando as credenciais da Role B, de modo que os custos de computação são faturados para a conta do consumidor.

Pré-requisitos

Antes de iniciar a configuração, garanta que os seguintes pontos estejam atendidos:

Para conectar múltiplas contas de consumidor, repita as etapas de configuração da role para cada conta. Planeje sua convenção de nomenclatura de roles IAM com antecedência para otimizar o gerenciamento em escala.

Arquitetura Técnica

À medida que as organizações adotam arquiteturas lakehouse e distribuem dados por unidades de negócio, Regiões AWS e contas AWS, elas precisam de uma maneira de consultar esses dados centralmente sem movê-los. O acesso Athena cross-account para Amazon Quick aborda este requisito. Usando encadeamento de roles IAM, uma implantação central do Quick pode acessar armazenamentos de dados distribuídos através de limites de contas sem replicação de dados, credenciais de longa duração compartilhadas ou múltiplas assinaturas do Quick. A arquitetura escala de um prova de conceito de duas contas para uma implantação em nível empresarial. Nesta seção, descrevemos três padrões, cada um construindo sobre o anterior.

Padrão 1: Configuração Básica de Duas Contas

A implantação mais direta conecta uma conta central do Quick a uma conta de consumidor. Esta é a configuração mínima viável e mapeia diretamente para o passo a passo neste post. O encadeamento de roles descrito na Visão Geral da Solução (Quick assume a Role A, a Role A encadeia para a Role B usando sts:AssumeRole, e o Athena executa a consulta sob as credenciais da Role B) se aplica diretamente aqui. Este padrão é adequado para validação inicial ou para conectar dados de uma única unidade de negócio a uma conta AWS de BI (Business Intelligence) compartilhada (central).

Padrão 2: Hub e Spoke

A maioria das empresas centraliza sua implantação do Quick em uma única conta (o hub) enquanto os dados são distribuídos por várias contas de unidades de negócio (os spokes). O modelo hub-and-spoke estende a configuração básica: a política de permissões da Role A lista múltiplos ARNs de roles de consumidor, que podem residir na mesma conta ou em contas diferentes, e uma fonte de dados separada é criada no Quick para cada um. A principal vantagem deste padrão é a independência entre os spokes. Adicionar uma nova unidade de negócio requer a criação de uma nova Role B na conta dessa unidade e o registro de uma nova fonte de dados no Quick, sem alterações nos spokes existentes. Cada spoke controla suas próprias permissões da Role B, determinando quais tabelas e prefixos S3 são expostos à conta AWS de BI central. A atribuição de custos segue naturalmente, as consultas do Athena de cada spoke são faturadas para sua própria conta. Como um único dashboard do Quick pode referenciar fontes de dados de múltiplas contas de consumidor, os autores de BI podem construir análises cross-unidade de negócio sem sair da experiência unificada do Quick. Este é o padrão recomendado para a maioria das empresas.

Ao escalar além de um punhado de spokes, considere templatizar a configuração do lado do consumidor. Um template do AWS CloudFormation ou CDK para a Role B, o workgroup do Athena e as políticas de confiança e permissão necessárias permite que as equipes das unidades de negócio façam seu autoatendimento na integração, ou que a equipe de BI central provisione novos spokes com uma única implantação de stack.

Padrão 3: Data Mesh

Em uma data mesh, produtores e consumidores são contas distintas. Uma conta produtora possui e gerencia seus dados brutos, provisionando-os em uma Consumer Account. Por exemplo, usando AWS Lake Formation com AWS Resource Access Manager (AWS RAM) para compartilhar tabelas entre contas. O mecanismo de provisionamento específico é escolha da equipe de domínio e está fora do escopo. A Consumer Account, contendo a Role B, o AWS Glue Data Catalog e o workgroup do Athena, é o que o Amazon Quick conecta através do encadeamento de roles. A conta publica produtos de dados governados para outras Consumer Accounts usando políticas de recursos do AWS Glue Data Catalog, tornando seus dados disponíveis para análises cross-domínio. Esse compartilhamento ponto a ponto entre Consumer Accounts, cada uma atuando como produtora e consumidora de produtos de dados, é o que define a mesh. Um autor de BI no Quick pode consultar várias Consumer Accounts em um único dashboard, com os custos de consulta atribuídos por Consumer Account. Em escala empresarial, uma única implantação do Amazon Quick pode se conectar a centenas de Consumer Accounts. Como as contas de domínio provisionam dados brutos em Consumer Accounts está fora do escopo.

Escolhendo um Padrão

O padrão correto depende da sua estratégia de dados. A configuração básica de duas contas valida o encadeamento de roles de ponta a ponta. A maioria das empresas adotará o hub-and-spoke à medida que integra unidades de negócio adicionais, pois mantém os spokes independentes, a atribuição de custos clara e as políticas de confiança diretas. Organizações com fortes limites de propriedade de dados ou equipes de domínio dedicadas evoluirão naturalmente para o padrão data mesh, onde as Consumer Accounts são distintas das contas produtoras que fornecem os dados, e o Amazon Quick serve como a camada de análise unificada para todas elas. Recomendamos começar pequeno e expandir à medida que os requisitos crescem.

Implementação Detalhada

O acesso Athena cross-account para Amazon Quick utiliza encadeamento de roles IAM para conectar sua conta central do Quick a uma ou mais contas de consumidor onde seus dados residem. Em vez de consolidar dados em uma única conta ou gerenciar assinaturas separadas do Quick por unidade de negócio, você configura duas roles IAM que funcionam em conjunto (uma em cada conta) para rotear consultas e atribuir custos corretamente.

Criar Role A (RunAsRole) na Conta Central do Quick

A Role A reside na conta central do Quick. O Amazon Quick assume esta role quando um usuário inicia uma consulta. A Role A não possui permissões de dados próprias; seu único propósito é encadear para a conta do consumidor. Ela precisa de duas coisas:

Crie a política de confiança. Isso permite que o principal de serviço do Quick assuma a Role A, com escopo para operações de fonte de dados em sua conta. Exemplo de política:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "quicksight.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "quicksight"
        }
      }
    }
  ]
}

Crie a role usando o AWS CLI:

aws iam create-role --role-name QuickCrossAccountRunAsRole --assume-role-policy-document file://role-a-trust-policy.json

Crie a política de permissões. Anexe esta política de permissões como uma política inline. Isso permite que a Role A assuma a Role B na conta do consumidor. A condição ExternalId garante que apenas as fontes de dados do Quick possam acionar o encadeamento de roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<CONSUMER_ACCOUNT_ID>:role/QuickAthenaConsumerRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "arn:aws:quicksight:<REGION>:<ACCOUNT_ID>:datasource/<DATASOURCE_ID>"
        }
      }
    }
  ]
}

Anexe a política de permissões como uma política inline usando o AWS CLI:

aws iam put-role-policy --role-name QuickCrossAccountRunAsRole --policy-name QuickCrossAccountConsumerRolePermissions --policy-document file://role-a-permission-policy.json

Adicionalmente, o principal IAM que está criando a fonte de dados do Quick precisa da permissão iam:PassRole na Role A.

Criar Role B na Conta do Consumidor

A Role B reside na conta do consumidor onde suas tabelas do Athena, AWS Glue Data Catalog e dados S3 residem. A Role A assume a Role B para executar a consulta.

Crie a política de confiança. Isso permite que a conta do Quick assuma a Role B, com uma condição ExternalId vinculada ao ARN da fonte de dados. Exemplo de política:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:role/QuickCrossAccountRunAsRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "arn:aws:quicksight:<REGION>:<CENTRAL_QUICK_ACCOUNT_ID>:datasource/<DATASOURCE_ID>"
        }
      }
    }
  ]
}

Crie a role usando o AWS CLI:

aws iam create-role --role-name QuickAthenaConsumerRole --assume-role-policy-document file://role-b-trust-policy.json

Crie a política de permissões para Athena, AWS Glue e S3. Escopo estas permissões para os bancos de dados, tabelas e locais S3 específicos relevantes para seus dados.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "athena:GetWorkGroup",
        "athena:GetDataCatalog",
        "athena:StartQueryExecution",
        "athena:GetQueryExecution",
        "athena:GetQueryResults",
        "athena:StopQueryExecution",
        "athena:BatchGetQueryExecution",
        "athena:ListQueryExecutions",
        "athena:ListWorkGroups",
        "athena:ListNamedQueries",
        "athena:GetDatabase",
        "athena:GetTable",
        "athena:ListDatabases",
        "athena:ListTableMetadata",
        "glue:GetDatabase",
        "glue:GetTable",
        "glue:GetPartition",
        "glue:GetPartitions",
        "glue:GetDatabases",
        "glue:GetTables",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:athena:<REGION>:<CONSUMER_ACCOUNT_ID>:workgroup/primary",
        "arn:aws:glue:<REGION>:<CONSUMER_ACCOUNT_ID>:catalog",
        "arn:aws:glue:<REGION>:<CONSUMER_ACCOUNT_ID>:database/my_database",
        "arn:aws:glue:<REGION>:<CONSUMER_ACCOUNT_ID>:table/my_table",
        "arn:aws:s3:::my-athena-results-bucket/*",
        "arn:aws:s3:::my-data-bucket/*"
      ]
    }
  ]
}

Anexe a política de permissões como uma política inline usando o AWS CLI:

aws iam put-role-policy --role-name QuickAthenaConsumerRole --policy-name QuickAthenaAccess --policy-document file://role-b-permission-policy.json

Criar a Fonte de Dados Athena Cross-Account no Quick (conta central ou de origem)

Usando o AWS CLI, insira o seguinte:

aws quicksight create-data-source \
    --aws-account-id <CENTRAL_QUICK_ACCOUNT_ID> \
    --data-source-id "AthenaCrossAccountDataSource" \
    --name "Athena Cross Account Data Source" \
    --type ATHENA \
    --data-source-parameters "AthenaParameters={WorkGroup=<ATHENA_WORKGROUP_NAME>,RoleArn=arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:role/QuickCrossAccountRunAsRole,ConsumerAccountRoleArn=arn:aws:iam::<CONSUMER_ACCOUNT_ID>:role/QuickAthenaConsumerRole}" \
    --permissions '[{"Principal": "arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:user/<IAM_USER_NAME>", "Actions": ["quicksight:UpdateDataSource", "quicksight:DeleteDataSource", "quicksight:PassDataSource", "quicksight:DescribeDataSource", "quicksight:CreateDataSet"]}]'

Ou usando Python (Boto3):

import boto3

quicksight_client = boto3.client('quicksight')

response = quicksight_client.create_data_source(
    AwsAccountId='<CENTRAL_QUICK_ACCOUNT_ID>',
    DataSourceId='AthenaCrossAccountDataSource',
    Name='Athena Cross Account Data Source',
    Type='ATHENA',
    DataSourceParameters={
        'AthenaParameters': {
            'WorkGroup': '<ATHENA_WORKGROUP_NAME>',
            'RoleArn': 'arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:role/QuickCrossAccountRunAsRole',
            'ConsumerAccountRoleArn': 'arn:aws:iam::<CONSUMER_ACCOUNT_ID>:role/QuickAthenaConsumerRole'
        }
    },
    Permissions=[
        {
            'Principal': 'arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:user/<IAM_USER_NAME>',
            'Actions': [
                'quicksight:UpdateDataSource',
                'quicksight:DeleteDataSource',
                'quicksight:PassDataSource',
                'quicksight:DescribeDataSource',
                'quicksight:CreateDataSet'
            ]
        }
    ]
)
print(response)

Verifique se a fonte de dados foi criada com sucesso:

aws quicksight describe-data-source --aws-account-id <CENTRAL_QUICK_ACCOUNT_ID> --data-source-id AthenaCrossAccountDataSource

Saída esperada:

{
    "DataSource": {
        "Arn": "arn:aws:quicksight:<REGION>:<CENTRAL_QUICK_ACCOUNT_ID>:datasource/AthenaCrossAccountDataSource",
        "DataSourceId": "AthenaCrossAccountDataSource",
        "Name": "Athena Cross Account Data Source",
        "Type": "ATHENA",
        "Status": "CREATION_SUCCESSFUL",
        "CreatedTime": "2026-06-07T10:00:00Z",
        "LastUpdatedTime": "2026-06-07T10:00:00Z",
        "DataSourceParameters": {
            "AthenaParameters": {
                "WorkGroup": "<ATHENA_WORKGROUP_NAME>",
                "RoleArn": "arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:role/QuickCrossAccountRunAsRole",
                "ConsumerAccountRoleArn": "arn:aws:iam::<CONSUMER_ACCOUNT_ID>:role/QuickAthenaConsumerRole"
            }
        },
        "Permissions": [
            {
                "Principal": "arn:aws:iam::<CENTRAL_QUICK_ACCOUNT_ID>:user/<IAM_USER_NAME>",
                "Actions": [
                    "quicksight:UpdateDataSource",
                    "quicksight:DeleteDataSource",
                    "quicksight:PassDataSource",
                    "quicksight:DescribeDataSource",
                    "quicksight:CreateDataSet"
                ]
            }
        ]
    }
}

Compartilhar a Fonte de Dados e Criar Conjuntos de Dados

Depois que a fonte de dados estiver ativa, compartilhe-a com os autores do Quick usando o seguinte código de exemplo:

aws quicksight update-data-source-permissions \
    --aws-account-id <CENTRAL_QUICK_ACCOUNT_ID> \
    --data-source-id AthenaCrossAccountDataSource \
    --grant-permissions '[{"Principal": "arn:aws:quicksight:us-east-1:<CENTRAL_QUICK_ACCOUNT_ID>:user/<QUICKSIGHT_USER_NAME>", "Actions": ["quicksight:DescribeDataSource", "quicksight:CreateDataSet"]}]'

Os autores agora podem abrir o Quick, navegar para "Datasets", criar um novo dataset, selecionar a fonte de dados Athena Cross Account e navegar pelos bancos de dados e tabelas do AWS Glue da conta do consumidor. Eles podem construir datasets, aplicar transformações e criar dashboards, tudo a partir da conta central do Quick, com os custos de consulta faturados para a conta do consumidor.

Conectando Múltiplas Contas de Consumidor

Para conectar contas de consumidor adicionais, repita as etapas da solução acima para cada role/conta:

Considerações de Segurança

O modelo de segurança para acesso Athena cross-account foi projetado para permitir o acesso a dados distribuídos em escala, garantindo que cada consulta seja autorizada, escopada e auditável. Conforme descrito no guia, a condição ExternalId na política de confiança da Role B previne ataques de "confused deputy". Somente as fontes de dados do Quick da conta autorizada (central) podem completar o encadeamento de roles. Além disso, o Quick aplica uma política de "scope-down" inline cada vez que assume a Role A, restringindo cada sessão a uma única role de consumidor, mesmo quando as permissões permanentes da Role A cobrem múltiplas contas. Juntos, esses mecanismos garantem que cada encadeamento de consulta seja autenticado e estritamente escopado. A conta do consumidor mantém seu próprio limite de privilégio mínimo através das permissões da Role B. Cada unidade de negócio determina independentemente quais tabelas, bancos de dados e prefixos S3 são visíveis para a conta AWS de BI central. Recomendamos escopar as permissões do AWS Glue e S3 para recursos específicos em vez de usar curingas, restringir a Role B a um workgroup do Athena designado com criptografia de resultados de consulta e limites de custo habilitados, e usar instâncias separadas da Role B quando a conta do consumidor contiver dados em diferentes níveis de classificação.

Todo o encadeamento de roles é capturado no AWS CloudTrail em ambas as contas, desde o AssumeRole inicial na conta central até o encadeamento na conta do consumidor e as consultas do Athena que se seguem. Isso fornece um rastro de auditoria completo desde a iniciação da consulta até o acesso aos dados e suporta alertas sobre padrões anômalos, como contas de origem inesperadas ou picos na quantidade de dados escaneados.

Conforme observado na Etapa 1 do guia, o principal IAM que está criando a fonte de dados requer permissão iam:PassRole na Role A, o que impede que administradores associem roles arbitrárias a fontes de dados. Esses mecanismos (ExternalId, scope-down, privilégio mínimo, CloudTrail e PassRole) formam um modelo de defesa em profundidade que é inteiramente impulsionado por políticas e programático, tornando-o adequado para governança automatizada à medida que as ferramentas nesse espaço amadurecem.

Atribuição de Custos

Como as consultas do Athena são executadas sob as credenciais da Role B na conta do consumidor, todas as chamadas de API AWS associadas ocorrem nessa conta. A faturação padrão da AWS lida com a separação de custos automaticamente. A conta do consumidor verá os encargos de consulta do Athena, custos de acesso ao S3 e chamadas do catálogo AWS Glue em sua própria fatura. A conta central do Quick incorre apenas em custos de sessão do Quick e armazenamento SPICE. Antes deste recurso, as organizações absorviam todos os custos de consulta centralmente (perdendo a visibilidade por unidade de negócio) ou operavam assinaturas separadas do Quick por unidade de negócio, fragmentando a experiência de BI. O acesso Athena cross-account remove essa desvantagem: uma implantação unificada do Quick com visibilidade de custos por unidade de negócio que não requer lógica de chargeback personalizada.

Limpeza

Para evitar incorrer em cobranças contínuas, exclua os recursos da AWS (roles IAM, fontes de dados do Quick Sight, políticas) que você criou como parte da experimentação. Para obter instruções, consulte a documentação do serviço.

Conclusão

O acesso Athena cross-account para Amazon Quick permite que as empresas da AITY mantenham uma conta AWS de BI centralizada, respeitando a governança de dados multi-contas e os limites de custo. A abordagem de encadeamento de roles fornece atribuição de custos adequada, mantém a soberania dos dados por unidade de negócio e se integra aos controles de segurança IAM existentes.

Para começar, crie as roles IAM em suas contas Quick e de consumidor conforme descrito neste artigo e, em seguida, crie a fonte de dados usando o parâmetro ConsumerAccountRoleArn. Para mais detalhes, consulte o Guia do Usuário do Amazon Quick.

Comentários

Interações
Seu Perfil

Aguardando Login...