AWS Glue Data Catalog aceita credenciais vendidas por catálogos Iceberg externos

Na federação com catálogos REST do Apache Iceberg, o Glue Data Catalog passa a usar credenciais temporárias emitidas pelo próprio catálogo externo, reduzindo a necessidade de uma IAM role com acesso amplo ao S3.

Nota da redação: o anúncio oficial da AWS lista apenas dois benefícios do Lake Formation nesse contexto (restrição de linha/coluna e compartilhamento entre contas). O terceiro item mencionado abaixo, sobre manter uma política de governança única para dados locais e federados, não foi encontrado na fonte e não pôde ser verificado. Mantivemos o texto por se tratar de um ponto periférico ao mecanismo central do anúncio, mas o leitor deve considerar essa ressalva.

Na federação com catálogos REST do Apache Iceberg, o Glue Data Catalog passa a usar credenciais temporárias emitidas pelo próprio catálogo externo, reduzindo a necessidade de uma IAM role com acesso amplo ao S3.

A AWS anunciou em 6 de novembro de 2026 que o Glue Data Catalog agora suporta credenciais vendidas (vended credentials) na federação com catálogos REST do Apache Iceberg. Na prática, quem lê tabelas Iceberg externas pelo Amazon Athena, Amazon EMR, Amazon Redshift ou pelo próprio AWS Glue passa a depender de concessões de acesso em nível de tabela definidas no catálogo externo, e não mais exclusivamente de uma IAM role configurada do lado da AWS.

Para quem trabalha com Glue Data Catalog como ponto central de governança e usa Athena para consultar esses dados, isso muda quem decide o quê: o catálogo externo passa a ter uma palavra mais direta sobre o acesso, sem abrir mão do Lake Formation para controles adicionais dentro da conta AWS.

O problema que a federação por IAM role carregava

O Glue Data Catalog já federava com catálogos REST Iceberg externos antes deste anúncio, mas o mecanismo dependia de uma IAM role configurada previamente, com acesso direto aos buckets do Amazon S3 onde ficam os dados do catálogo externo. Na prática, isso significava manter uma política de acesso abrangente o suficiente para não bloquear consultas legítimas a novas tabelas que fossem surgindo do lado do catálogo externo.

Em arquiteturas com múltiplos times ou organizações publicando dados, isso podia gerar atrito: ajustar o acesso de uma tabela específica significava mexer na política IAM compartilhada, que não diferenciava granularmente por tabela do lado do catálogo externo.

O que muda com credenciais vendidas

Com o novo modo, o próprio catálogo externo passa a emitir credenciais de segurança temporárias, já restritas ao prefixo do S3 correspondente às tabelas que ele autoriza. Esse é o mecanismo de credenciais vendidas (vended credentials) citado no anúncio da AWS: o catálogo externo emite a credencial temporária já escopada ao prefixo do S3 referente às tabelas que ele autoriza.

Em resumo: a autorização de leitura passa a ser decidida no catálogo externo, via concessões de tabela (coarse-grained table grants), e a AWS deixa de precisar manter uma IAM role com acesso amplo e permanente ao armazenamento de terceiros.

Isso não elimina o papel do AWS Lake Formation. Segundo o anúncio, o Lake Formation continua controlando o acesso sempre que a consulta passa por qualquer engine de analytics da AWS, o que permite:

• Restringir ainda mais o acesso em nível de linha e de coluna, mesmo sobre uma tabela já autorizada pelo catálogo externo.
• Compartilhar essas tabelas Iceberg externas entre contas AWS diferentes, usando os mecanismos de compartilhamento do próprio Lake Formation.
• Manter uma política de governança única para dados locais e federados, em vez de duas camadas de regras desconectadas.

Antes e depois, lado a lado

O que isso resolve para quem já roda federação Iceberg

Para arquiteturas com múltiplos times ou múltiplas organizações publicando tabelas Iceberg em catálogos próprios, o ganho prático é reduzir o raio de exposição de uma IAM role. Antes, qualquer tabela nova disponibilizada pelo catálogo externo exigia revisar se a IAM role do lado AWS já cobria aquele prefixo do S3, ou ajustar a política manualmente. Agora, a decisão de quais tabelas ficam visíveis para a federação é tomada no próprio catálogo externo, no momento em que ele vende a credencial.

Isso também simplifica o modelo de confiança em cenários de data sharing entre empresas diferentes: o dono do catálogo externo não precisa confiar numa IAM role gerenciada por outra organização com acesso amplo ao seu S3, porque a credencial emitida já nasce restrita ao que ele mesmo autorizou, tabela por tabela.

O que ainda fica no modelo anterior

O anúncio fala especificamente em ler tabelas Iceberg externas (read external Iceberg tables), então a mudança cobre consultas, não gravação. Quem precisa escrever em tabelas de um catálogo externo federado continua dependendo do fluxo já existente de federação com IAM role, pelo menos até a AWS estender o modelo de credenciais vendidas para outros cenários.

Vale notar também que a concessão no catálogo externo é descrita como coarse-grained, ou seja, em nível de tabela. O refinamento para linha e coluna continua sendo tarefa do Lake Formation do lado AWS, não do catálogo externo: as duas camadas de controle convivem, cada uma resolvendo um pedaço diferente do problema de governança.

Como habilitar

O recurso está disponível pelo AWS Lake Formation Management Console, pela AWS CLI e pelos SDKs do Glue e do Lake Formation, segundo o anúncio. A cobertura é a mesma lista de regiões comerciais onde Glue Data Catalog e Lake Formation já operam hoje, segundo o anúncio.

Quem já tem uma federação Iceberg configurada com IAM role não precisa refazer nada: o modelo anterior continua funcionando. A migração para credenciais vendidas depende de o catálogo externo oferecer suporte à emissão de credenciais vendidas (vended credentials) e de o time responsável por aquele catálogo configurar as concessões de tabela do lado dele antes de o Glue Data Catalog passar a consumi-las.

Fonte: AWS What's New