A AWS anunciou a disponibilidade de saídas estruturadas no Amazon Bedrock, uma capacidade que garante respostas consistentes e legíveis por máquina dos modelos de fundação que aderem aos esquemas JSON que você define. Em vez de formular prompts esperando que a IA gere JSON válido e adicionar verificações extras na sua aplicação, agora você pode especificar exatamente qual formato deseja e receber respostas que correspondem a ele — tornando fluxos de trabalho em produção mais previsíveis e resilientes.
Por Que Isso Importa em Produção
Saídas estruturadas se mostram particularmente úteis em tarefas comuns de produção, como extração de campos específicos e automação de fluxos que utilizam APIs ou ferramentas. Em cenários onde pequenos erros de formatação podem quebrar sistemas a jusante, essa capacidade é um diferencial significativo. Ao garantir conformidade com esquemas predefinidos, a funcionalidade reduz a necessidade de lógica de validação customizada e diminui a sobrecarga operacional através de menos requisições falhadas e retentativas — permitindo que você implante aplicações de IA com confiança, sabendo que receberá respostas previsíveis e estruturadas corretamente.
Como Utilizar Saídas Estruturadas
A AWS oferece dois caminhos para trabalhar com saídas estruturadas:
Definir um esquema JSON que descreva o formato de resposta desejado
Usar definições rigorosas de ferramentas para garantir que as chamadas de ferramentas do modelo correspondam às suas especificações
Disponibilidade e Modelos Suportados
Saídas estruturadas está disponível de forma geral para modelos Anthropic Claude 4.5 e modelos de peso aberto selecionados nas APIs Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream em todas as regiões comerciais da AWS onde o Amazon Bedrock é suportado. Para obter mais detalhes sobre quais modelos suportam essa funcionalidade e como implementá-la em seus projetos, consulte a documentação do Amazon Bedrock.
Expansão das Instâncias G7e para a Costa Oeste Americana
A AWS anunciou a disponibilidade das instâncias EC2 G7e em mais uma região dos Estados Unidos. Equipadas com GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition, essas máquinas estão agora acessíveis na região US West (Oregon), ampliando as opções para desenvolvedores e empresas que dependem de processamento intensivo de IA e gráficos.
Desempenho e Capacidades Técnicas
As instâncias G7e representam um salto significativo em relação à geração anterior. Elas oferecem até 2,3 vezes melhor desempenho em tarefas de inferência, tornando-as especialmente adequadas para cenários que exigem processamento rápido e eficiente.
Configuração de Hardware
Cada instância G7e é equipada com até 8 GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition, sendo que cada GPU dispõe de 96 GB de memória dedicada. O processador é um Intel Xeon de 5ª geração, capaz de suportar até 192 vCPUs (processadores virtuais). A conectividade atinge até 1600 Gbps de largura de banda de rede.
Funcionalidades de Processamento Paralelo
Um diferencial importante é o suporte a NVIDIA GPUDirect Peer to Peer (P2P), que melhora significativamente o desempenho quando múltiplas GPUs trabalham juntas. Além disso, instâncias G7e com várias GPUs também suportam NVIDIA GPUDirect Remote Direct Memory Access (RDMA) integrado ao EFA (Elastic Fabric Adapter) em EC2 UltraClusters, reduzindo a latência em cargas de trabalho multi-nó em pequena escala.
Casos de Uso Ideais
A AWS posiciona as instâncias G7e como solução de ponta para múltiplos cenários. Elas são particularmente adequadas para implantação de modelos de linguagem grande (LLMs), modelos de IA agêntica, modelos de IA generativa multimodal e modelos de IA física.
Além dos casos de uso relacionados a IA, as instâncias G7e oferecem o mais alto desempenho para cargas de trabalho de computação espacial, bem como para aquelas que combinam necessidades de processamento gráfico e de IA.
Disponibilidade e Opções de Compra
Atualmente, as instâncias G7e estão disponíveis em três regiões da AWS: US West (Oregon), US East (N. Virginia) e US East (Ohio).
Os clientes podem adquirir essas instâncias de três formas: como Instâncias On-Demand (pagamento conforme uso), como Spot Instances (com preços mais competitivos), ou como parte de Savings Plans (planos de economia com compromisso de prazo).
Como Começar
Para iniciar o uso de instâncias G7e, há várias ferramentas disponíveis: o AWS Management Console (interface web), a AWS Command Line Interface (CLI para linha de comando) e os AWS SDKs (kits de desenvolvimento para programação).
Para aprofundar os conhecimentos técnicos e explorar as especificações completas, consulte a documentação detalhada sobre instâncias G7e.
A AWS anunciou em fevereiro de 2026 que o Lake Formation está agora disponível na região Ásia-Pacífico (Nova Zelândia). Esta expansão geográfica amplia as opções para organizações que precisam manter conformidade regional e reduzir latência ao trabalhar com dados em localidades específicas.
O que é AWS Lake Formation
O Lake Formation é um serviço que simplifica a governança de dados em larga escala. Sua principal função é permitir que você defina centralmente onde seus dados residem e quais políticas de acesso e segurança devem ser aplicadas a eles. Este é um ponto crucial para empresas que lidam com dados sensíveis ou que precisam cumprir regulamentações rigorosas sobre proteção de informações.
Funcionalidades Principais
Gestão Centralizada de Permissões
Uma das características diferenciais do Lake Formation é a capacidade de gerenciar permissões de acesso com granularidade refinada de forma centralizada. Isso significa que você pode controlar precisamente quem tem acesso a quais dados, sem necessidade de configurações complexas e distribuídas por múltiplos sistemas.
Compartilhamento Seguro de Dados
O serviço facilita o compartilhamento seguro de dados dentro e fora da organização. Esta é uma capacidade essencial para empresas que colaboram com parceiros, clientes ou outras unidades de negócio, garantindo que o compartilhamento ocorra dentro de políticas de segurança bem definidas.
Integração com o Catálogo de Dados AWS Glue
O Lake Formation trabalha em conjunto com o AWS Glue Data Catalog (Catálogo de Dados do AWS Glue), um repositório centralizado que descreve os conjuntos de dados disponíveis e suas políticas de uso apropriadas. Os usuários podem acessar este catálogo centralizado para descobrir quais dados estão disponíveis e como utilizá-los adequadamente.
Compatibilidade com Ferramentas Analíticas
Após acessar os dados através do Lake Formation e do catálogo centralizado, os usuários podem trabalhar com esses conjuntos de dados usando diversos serviços de análise e machine learning. A AWS oferece integração com ferramentas como Amazon EMR para Apache Spark, Amazon Redshift, AWS Glue, Amazon QuickSight e Amazon Athena, permitindo flexibilidade na escolha das plataformas analíticas mais adequadas para cada caso de uso.
Próximas Ações
Para aprofundar seus conhecimentos sobre o Lake Formation e suas capacidades, você pode consultar a documentação técnica disponível. Além disso, para verificar a disponibilidade completa do Lake Formation em todas as regiões da AWS, consulte a tabela de regiões e serviços, onde você encontrará informações atualizadas sobre em quais localidades geográficas cada serviço está disponível.
Tabelas Globais do DynamoDB Agora Suportam Multi-Contas
A AWS anunciou uma nova capacidade para as tabelas globais do DynamoDB: suporte a replicação entre múltiplas contas AWS. O DynamoDB global tables é um banco de dados totalmente gerenciado, sem servidor, com suporte multi-região e multi-ativo, utilizado por dezenas de milhares de clientes para potencializar aplicações críticas para seus negócios.
Esta nova funcionalidade permite que as organizações repliquem tabelas tanto entre contas AWS quanto entre regiões, abrindo possibilidades significativas para melhorar a resiliência, isolar cargas de trabalho no nível de conta e aplicar controles distintos de segurança e governança conforme as necessidades específicas de cada departamento ou projeto.
Como Funciona a Replicação Multi-Conta
Com as tabelas globais multi-conta, o DynamoDB replica automaticamente as tabelas entre contas AWS e regiões. Essa capacidade fortalece a tolerância a falhas e contribui para que as aplicações permaneçam altamente disponíveis mesmo durante interrupções no nível de conta.
Simultaneamente, a solução permite que as organizações alinhem a colocação de dados com seus requisitos de segurança e conformidade, respeitando a estrutura organizacional e facilitando a implementação de políticas de isolamento de dados específicas de cada unidade de negócio.
Casos de Uso Ideais
As tabelas globais multi-conta são particularmente relevantes para organizações que adotam estratégias multi-conta ou utilizam o AWS Organizations para:
Melhorar o isolamento de segurança entre ambientes
Aplicar guardrails de perímetro de dados
Implementar estratégias de recuperação de desastres (DR)
Construir agentes de IA prontos para ambientes corporativos exige mais do que simplesmente conectar um modelo de linguagem a APIs existentes. A diferença entre um protótipo que impressiona em uma demonstração e um agente que realmente entrega valor em produção está fundamentada em práticas de engenharia disciplinadas, arquitetura robusta e melhorias contínuas.
A AWS desenvolveu o Amazon Bedrock AgentCore, uma plataforma agentic que oferece os serviços necessários para criar, implantar e gerenciar agentes de IA em escala. Este artigo explora nove práticas essenciais que os times podem aplicar imediatamente ao desenvolvê-los.
1. Comece Pequeno e Defina o Sucesso com Clareza
A primeira pergunta que as equipes devem responder não é “o que este agente pode fazer?”, mas “qual problema estamos resolvendo?”. Muitas vezes, times começam construindo agentes que tentam lidar com todos os cenários possíveis, resultando em complexidade excessiva, ciclos de iteração lentos e agentes que não se destacam em nada específico.
A abordagem recomendada é trabalhar de forma invertida, partindo de um caso de uso específico. Se o objetivo é construir um assistente financeiro, comece com as três tarefas mais comuns dos analistas. Para um assistente de RH, foque nas cinco perguntas de funcionários mais frequentes. Garanta que essas funcionalidades funcionem de forma confiável antes de expandir o escopo.
O planejamento inicial deve gerar quatro entregas concretas:
Definição clara do que o agente deve e não deve fazer
Tom e personalidade — decidindo entre formal ou conversacional, como cumprimentar usuários e o que fazer quando encontrar questões fora do escopo
Definições inequívocas para cada ferramenta, parâmetro e fonte de conhecimento
Conjunto de dados de referência contendo interações esperadas, casos comuns e casos extremos
Construir um prototipo com esse escopo limitado e testá-lo com usuários reais revelará problemas imprevistos — seja na análise de datas, no tratamento de abreviações ou na invocação de ferramentas incorretas quando as perguntas são formuladas de forma inesperada. Identificar essas questões em um prototipo pode custar algumas semanas; descobri-las em produção pode comprometer credibilidade e confiança.
2. Implemente Observabilidade desde o Primeiro Dia
Um dos maiores erros que times cometem é tratar observabilidade como algo a ser adicionado depois. Quando a necessidade de observabilidade se torna evidente, o agente já está em produção, dificultando a depuração efetiva.
Desde a primeira consulta de teste, é necessário visibilidade no que o agente está fazendo. O AgentCore emite rastreamentos OpenTelemetry (Telemetria Aberta) automaticamente, capturando invocações de modelos, chamadas de ferramentas e etapas de raciocínio. Quando uma consulta leva doze segundos, é possível identificar se o atraso veio do modelo de linguagem, de uma consulta ao banco de dados ou de uma chamada para uma API externa.
A estratégia de observabilidade deve incluir três camadas:
Depuração em nível de rastreamento durante o desenvolvimento, permitindo visualizar cada etapa da conversa
Dashboards de produção usando o AgentCore Observability para rastrear uso de tokens, percentis de latência, taxas de erro e padrões de invocação de ferramentas
Observabilidade serve diferentes necessidades conforme o papel. Desenvolvedores a utilizam para depuração, respondendo perguntas como por que o agente alucinava ou qual versão de prompt tem melhor desempenho. Times de plataforma a utilizam para governança, monitorando gastos por time, quais agentes causam aumentos de custo e o que aconteceu em um incidente específico.
3. Estabeleça uma Estratégia Deliberada de Ferramentas
Ferramentas são o mecanismo pelo qual agentes acessam o mundo real. Elas buscam dados em bancos de dados, chamam APIs externas, pesquisam documentação e executam lógica de negócios. A qualidade das definições de ferramentas impacta diretamente o desempenho do agente.
Na definição de uma ferramenta, clareza é mais importante que brevidade. Considere duas descrições para a mesma função:
Inadequada: “Obtém dados de receita”
Adequada: “Recupera dados de receita trimestral para uma região especificada e período. Retorna valores em milhões USD. Requer código de região (EMEA, APAC, AMER) e trimestre no formato AAAA-QN (ex: 2024-Q3).”
A primeira descrição força o agente a adivinhar quais entradas são válidas e como interpretar saídas. A segunda remove ambiguidades. Multiplicado por vinte ferramentas, a diferença torna-se dramática.
A estratégia de ferramentas deve abordar quatro áreas:
Tratamento de erros e resiliência: Ferramentas falham, APIs retornam erros, timeouts acontecem. Defina o comportamento esperado para cada modo de falha
Reutilização via Protocolo MCP (Model Context Protocol): Muitos provedores já oferecem servidores MCP para ferramentas como Slack, Google Drive, Salesforce e GitHub. Use-os em vez de construir integrações personalizadas
Catálogo centralizado de ferramentas: Times não devem construir o mesmo conector de banco de dados cinco vezes. Mantenha um catálogo aprovado de ferramentas revisadas por segurança e testadas em produção
Exemplos de código com cada ferramenta: Documentação sozinha não é suficiente. Forneça exemplos funcionais que os desenvolvedores possam copiar e adaptar
O AgentCore Gateway resolve o problema prático de proliferação de ferramentas. À medida que se constroem mais agentes, acumulam-se dezenas de ferramentas — algumas expostas por servidores MCP, outras por AWS Lambda, outras ainda pelo Amazon API Gateway. Sem o AgentCore Gateway, cada time de agentes reimplementa autenticação, gerencia endpoints separados e carrega todas as definições de ferramentas nos prompts, mesmo quando poucas são relevantes.
O Gateway oferece um ponto de entrada único para ferramentas onde quer que residam, com capacidade de busca semântica que permite aos agentes encontrar a ferramenta certa baseado no que estão tentando alcançar, autenticação abrangente e controle de quais agentes podem acessar quais ferramentas.
4. Automatize Avaliação Desde o Início
É necessário saber se um agente está melhorando ou piorando a cada alteração. Avaliação automatizada fornece esse ciclo de feedback. Comece definindo o que “bom” significa para o caso de uso específico. As métricas variam conforme a indústria e tarefa:
Um agente de atendimento ao cliente pode ser medido por taxa de resolução e satisfação
Um agente de análise financeira pode ser medido por precisão de cálculo e qualidade de citações
Um assistente de RH pode ser medido por precisão de políticas e completude de resposta
Equilibre métricas técnicas com métricas de negócio. Latência de resposta importa, mas apenas se as respostas forem corretas. Custo de tokens importa, mas apenas se usuários encontrarem valor no agente.
O conjunto de dados de avaliação deve incluir múltiplas formulações da mesma pergunta, casos extremos onde o agente deveria se recusar a responder ou escalar para um humano, e consultas ambíguas com múltiplas interpretações válidas.
5. Decomponha Complexidade com Sistemas Multi-Agentes
Quando um agente único tenta lidar com muitas responsabilidades, fica difícil de manter. Os prompts crescem em complexidade, a lógica de seleção de ferramentas falha e o desempenho se degrada. A solução é decompor o problema em múltiplos agentes especializados que colaboram.
Pense em organizar um time. Não se contrata uma pessoa para lidar com vendas, engenharia, suporte e finanças. Contratam-se especialistas que coordenam seu trabalho. O mesmo princípio aplica-se a agentes. Em vez de um agente tratando trinta tarefas diferentes, construa três agentes que cada um trata dez tarefas relacionadas.
Cada agente tem instruções mais claras, conjuntos de ferramentas mais simples e lógica mais focada. Padrões sequenciais funcionam quando tarefas têm uma ordem natural. Padrões hierárquicos funcionam quando é necessário roteamento inteligente. Padrões ponto-a-ponto funcionam quando agentes precisam colaborar dinamicamente sem um coordenador central.
O desafio chave em sistemas multi-agentes é manter contexto através de passagens de trabalho. Quando um agente passa trabalho para outro, o segundo agente precisa saber o que já aconteceu. O AgentCore Memory oferece contexto compartilhado que múltiplos agentes podem acessar dentro de uma sessão.
6. Dimensione Seguramente com Personalização
Passar de um protótipo que funciona para um desenvolvedor para um sistema em produção servindo milhares de usuários introduz novos requisitos de isolamento, segurança e personalização.
Isolamento de sessão vem em primeiro lugar. A conversa do usuário A não pode vazar para a sessão do usuário B sob qualquer circunstância. O AgentCore Runtime executa cada sessão em sua própria máquina virtual isolada com computação e memória dedicadas. Quando a sessão termina, a máquina virtual é encerrada e nenhum estado compartilhado existe entre usuários.
Personalização requer memória que persista entre sessões. O AgentCore Memory oferece memória de curto prazo para histórico de conversas e memória de longo prazo para fatos, preferências e interações passadas, tudo organizado por usuário para manter contexto privado.
Segurança e controle de acesso devem ser impostos antes que ferramentas executem. Usuários devem acessar apenas dados para os quais têm permissão. Quando um usuário interage com um agente, primeiro autentica-se através de um provedor de identidade, seja Amazon Cognito, Microsoft Entra ID ou Okta. O AgentCore Identity recebe o token de autenticação e extrai claims OAuth customizados que definem permissões e atributos do usuário.
O AgentCore Policy valida se um usuário específico tem permissão para invocar uma ferramenta específica com parâmetros específicos. Se um analista júnior tentar acessar dados de remuneração executiva, a solicitação é negada antes de alcançar qualquer banco de dados.
7. Combine Agentes com Código Determinístico
Uma das decisões arquiteturais mais importantes é saber quando confiar em comportamento agentic e quando usar código tradicional. Agentes são poderosos, mas não são apropriados para todas as tarefas.
Reserve agentes para tarefas que exigem raciocínio sobre entradas ambíguas — entender consultas em linguagem natural, determinar quais ferramentas invocar e interpretar resultados em contexto. Use código tradicional para cálculos, validações e lógica baseada em regras. O crescimento de receita é uma fórmula. Validação de datas segue padrões. Regras de negócio são declarações condicionais. Não é necessário um modelo de linguagem para calcular “subtrair Q2 de Q3 e dividir por Q2”. Escreva uma função Python que executa em milissegundos sem custo adicional.
A arquitetura correta tem agentes orquestrando funções de código. Quando um usuário pergunta “Qual foi nosso crescimento na EMEA neste trimestre?”, o agente usa raciocínio para entender a intenção e determinar qual dados buscar. Chama uma função determinística para executar o cálculo. Depois usa raciocínio novamente para explicar o resultado em linguagem natural.
8. Estabeleça Práticas de Teste Contínuo
Implantação em produção não é a linha de chegada. É a linha de saída. Agentes operam em um ambiente em constante mudança. Comportamento de usuários evolui. Lógica de negócio muda. Modelo pode sofrer deriva. Teste contínuo é necessário para detectar essas mudanças antes que impactem usuários.
Construa um pipeline de teste contínuo que execute em cada atualização. Mantenha um conjunto de testes com consultas representativas cobrindo casos comuns e casos extremos. Quando um prompt muda, uma ferramenta é adicionada ou modelos são trocados, o pipeline executa o conjunto de testes e avalia os resultados.
O AgentCore Evaluations simplifica a mecânica de executar essas avaliações, oferecendo modos de avaliação sob demanda e avaliações online que monitoram tráfego de produção continuamente.
9. Construa Capacidade Organizacional com Pensamento de Plataforma
O primeiro agente em produção é uma conquista. Mas o valor em nível empresarial vem do dimensionamento dessa capacidade pela organização. Isso requer pensamento de plataforma, não apenas pensamento de projeto.
Estabeleça um time de plataforma para estabelecer padrões e oferecer infraestrutura compartilhada. Quando um novo time quer construir um agente, começa com o toolkit de plataforma. Implemente monitoramento centralizado mostrando agentes, sessões e custos. Quando uso de tokens aumenta inesperadamente, líderes de plataforma podem ver imediatamente.
Promova colaboração entre times para que aprendam uns com os outros. Três times não devem construir três versões de um conector de banco de dados. Em vez disso, devem compartilhar ferramentas através do AgentCore Gateway, compartilhar estratégias de avaliação e hospedar sessões regulares onde times demonstram seus agentes e discutem desafios.
O padrão de dimensionamento organizacional é um processo de rastejar, caminhar, correr:
Fase rastejar: Implante o primeiro agente internamente para um pequeno grupo piloto. Foco em aprendizado e iteração. Falhas são baratas
Fase caminhar: Implante para um grupo controlado de usuários externos. Mais usuários, mais feedback, mais casos extremos descobertos
Fase correr: Dimensione o agente para usuários externos com confiança. Capacidades de plataforma permitem que outros times construam seus próprios agentes mais rapidamente
Componentes do Amazon Bedrock AgentCore
Para implementar essas práticas, a AWS oferece um conjunto integrado de serviços:
AgentCore Runtime hospeda agentes e ferramentas em ambientes isolados
AgentCore Gateway unifica comunicação entre agentes e ferramentas usando protocolos padrão
AgentCore Browser oferece um navegador seguro baseado em nuvem que permite agentes interagir com websites
AgentCore Code Interpreter permite agentes escrever e executar código mais seguramente em ambientes sandbox
Conclusão
Construir agentes de IA prontos para produção requer mais que conectar um modelo de fundação a APIs. Exige práticas de engenharia disciplinadas por todo o ciclo de vida: começar pequeno com um problema claramente definido, instrumentar tudo desde o primeiro dia, construir estratégia deliberada de ferramentas, automatizar avaliação, decompor complexidade com arquiteturas multi-agentes, dimensionar com segurança e personalização, combinar agentes com código determinístico, testar continuamente e construir capacidade organizacional com pensamento de plataforma.
A diferença entre agentes que impressionam em demonstrações e agentes que entregam valor de negócio está na execução consistente dessas fundamentações. Para aprender mais, verifique a documentação do Amazon Bedrock AgentCore e comece com exemplos de código e workshops práticos para começar e aprofundar seu conhecimento sobre AgentCore.
Simplificando Gerenciamento de Arquivos na Nuvem com IA
Muitas organizações enfrentam desafios significativos ao gerenciar uploads de arquivos entre diferentes sistemas de armazenamento em nuvem, mantendo simultaneamente altos padrões de segurança e conformidade regulatória. Embora o Google Drive ofereça APIs para integração, a maioria das empresas não dispõe de especialistas técnicos capazes de interagir diretamente com essas interfaces programáticas complexas.
O problema real vai além da simples disponibilidade de APIs: as organizações precisam de uma forma intuitiva e acessível para que seus usuários realizem uploads de arquivos utilizando linguagem natural, sem necessidade de conhecimento especializado em sistemas subjacentes ou em especificações técnicas de programação.
Apresentando o Amazon Quick Suite
A AWS disponibiliza o Amazon Quick Suite, uma plataforma de IA empresarial que oferece capacidades avançadas alimentadas por IA generativa, focadas em produtividade no ambiente corporativo e inteligência de negócios. Esta plataforma integra pesquisa assistida por IA, recursos de inteligência de negócios e automação em um único espaço de trabalho, possibilitando desde responder perguntas e gerar conteúdo até analisar dados e fornecer insights estratégicos.
Para expandir suas funcionalidades além da simples busca de dados, o Amazon Quick Suite oferece conectores de ações — componentes poderosos que permitem interação com sistemas empresariais externos. Através desses conectores, os usuários conseguem executar ações e acessar informações de diversas ferramentas corporativas sem precisar sair da interface do Quick Suite.
Tipos de Conectores Disponíveis
A plataforma suporta três categorias principais de conectores: conectores para serviços externos, conectores para serviços AWS e conectores personalizados. Os conectores para serviços externos fornecem integrações prontas para uso com aplicações empresariais comuns, permitindo que as organizações implementem rapidamente funcionalidades padrão.
No entanto, quando surgem necessidades especializadas — como integração com Google Drive ou construção de fluxos de trabalho personalizados para upload de arquivos — o Amazon Quick Suite disponibiliza conectores personalizados. Essa abordagem permite que as organizações executem tarefas complexas através de simples comandos conversacionais, criando um espaço de trabalho unificado ao conectar várias ferramentas através de especificações OpenAPI, eliminando a necessidade de alternar constantemente entre interfaces diferentes.
Esta estratégia reduz significativamente as barreiras técnicas para as organizações, garantindo simultaneamente que mantenham controle completo sobre segurança e permissões de acesso.
Arquitetura da Solução
A proposta em questão demonstra como construir uma solução segura de upload de arquivos, integrando Google Drive com os conectores personalizados do Amazon Quick Suite usando Amazon API Gateway e AWS Lambda.
Essa abordagem resolve desafios comuns enfrentados pelas organizações ao gerenciar operações de arquivo entre sistemas de armazenamento em nuvem: manutenção de conformidade de segurança, gerenciamento de permissões de usuário e redução de barreiras técnicas para os usuários finais.
Componentes Principais
A solução integra diversos serviços AWS funcionando de forma coordenada:
A plataforma utiliza as especificações OpenAPI configuradas de terceiros para determinar dinamicamente quais operações de API executar, atendendo à solicitação do usuário
As chamadas de API são autorizadas usando um autorizador do Amazon Cognito, que emprega identidade federada do Google para autorização
As APIs são implementadas através de API Gateway e funções Lambda
A função Lambda contém a lógica para verificar se o usuário autorizado possui as permissões necessárias para fazer upload de arquivo na pasta mencionada na consulta, e chama o serviço Google usando credenciais de conta de serviço armazenadas no AWS Secrets Manager para realizar o upload do arquivo para Google Drive
Caso de Uso Prático
Embora este artigo se concentre no caso de uso de upload de arquivo para Google Drive, a mesma abordagem pode ser aplicada para fazer upload de arquivos para outros sistemas de armazenamento empresarial, como Amazon Simple Storage Service (Amazon S3), Box, Dropbox, SharePoint e outras plataformas semelhantes.
Um exemplo prático envolve fabricantes que utilizam o Amazon Quick Suite para fazer upload de arquivos de texto em uma unidade compartilhada no Google Drive. Esse tipo de integração permite que colaboradores executem operações de arquivo através de conversas naturais, sem necessidade de conhecimento técnico profundo.
Configuração Técnica Detalhada
Preparação do Ambiente Google
Para que a integração funcione adequadamente, é necessário primeiro configurar o ambiente Google Workspace. Isso envolve habilitar as APIs Google Drive e Admin SDK, criar uma conta de serviço com uma chave privada em formato JSON para acesso programático, e configurar delegação em todo o domínio. A delegação deve estar associada à ID do cliente da conta de serviço com escopos OAuth específicos que permitam acesso aos dados organizacionais no Google Drive.
Para fins de validação, cria-se dois usuários de teste no Google Workspace: um com permissão de gerenciador de conteúdo em uma unidade compartilhada (permitindo gerenciamento completo de arquivos) e outro sem nenhuma permissão. Essa configuração possibilita validar que a solução enforça corretamente os controles de acesso com base nas permissões do Google Drive.
Preparação do Ambiente AWS
No lado da AWS, criam-se usuários correspondentes no IAM Identity Center que combinam com os usuários de teste criados no Google Workspace. Organiza-se esses usuários em um grupo do IAM Identity Center para facilitar gerenciamento de permissões em escala empresarial, com opção de conectar a um provedor de identidade externo para provisionamento automatizado de usuários.
As credenciais da conta de serviço Google são armazenadas de forma segura no Secrets Manager, com políticas de Gerenciamento de Identidade e Acesso (Controle de Identidade e Acesso — IAM) restringindo o acesso apenas à função Lambda que realiza uploads de arquivo. Essa abordagem protege credenciais sensíveis, permite que a função Lambda autentique com as APIs do Google Drive e suporta uploads seguros em nome de usuários autorizados, seguindo práticas recomendadas de segurança da AWS para gerenciamento de segredos de aplicação.
Configuração do Amazon Quick Suite e Autenticação
Cria-se uma conta Amazon Quick Suite na edição Enterprise (requisito necessário para configurar ações personalizadas). A autenticação é configurada através do IAM Identity Center, e o grupo criado anteriormente é adicionado como grupo de administradores, com posterior verificação de que ambos os usuários conseguem acessar a plataforma com sucesso.
O Amazon Cognito é configurado para gerenciar identidades de usuário, com a criação de um pool de usuários e aplicativo cliente do tipo máquina-para-máquina. Um domínio Cognito é criado e configurado com interface hospedada, e o Google é adicionado como um provedor de identidade federada usando credenciais OAuth do Google Workspace. Os escopos autorizados são configurados como profile, email e openid, com mapeamento dos atributos do pool de usuários Cognito para os atributos correspondentes do Google.
Implementação da Função Lambda e API Gateway
A função Lambda é implantada com código que valida permissões de usuário, interage com a API do Google Drive e faz upload de arquivos para a pasta designada. As variáveis de ambiente são configuradas com a ID do pool de usuários Cognito, a região AWS, e o nome (ARN) do segredo do Secrets Manager contendo as credenciais da conta de serviço Google.
A API REST é criada usando a especificação OpenAPI, com a configuração apropriada de região e ARN da função Lambda. Um estágio é criado para a API com configurações apropriadas ao ambiente, e um autorizador Cognito é configurado, vinculado ao pool de usuários Cognito criado anteriormente, com escopos de autorização definidos como openid, email, profile e aws.cognito.signin.user.admin.
A política baseada em recursos da função Lambda é modificada para conceder permissão de invocação ao API Gateway para o método POST. A API é então implantada no estágio criado, e a URL do endpoint é registrada para uso posterior na configuração do Amazon Quick Suite.
Criação do Conector Personalizado do Amazon Quick Suite
Localiza-se o arquivo de esquema OpenAPI no repositório fornecido e substituem-se os valores de espaço reservado pela URL do API Gateway com o estágio, nome do domínio Cognito, região, ID do pool de usuários e ID do cliente de aplicativo Cognito.
Acessa-se a conta Quick Suite como um dos usuários de teste e navega-se até a seção de integrações para criar uma nova ação usando o tipo de conector personalizado com especificação OpenAPI. O arquivo de esquema modificado é enviado, e a integração é criada com método de autenticação de usuário, configurando a URL base do API Gateway (incluindo o nome do estágio), ID do cliente Cognito, segredo do cliente Cognito, URL de token Cognito e URL de autorização Cognito.
A integração é então compartilhada com o grupo do IAM Identity Center contendo os dois usuários de teste.
Agentes de Chat e Validação de Acesso
Criam-se agentes de chat personalizado ou utiliza-se o assistente padrão do Quick Suite, vinculando o conector de ação criado. O agente é compartilhado com os usuários de teste com as permissões apropriadas.
Para validação, testa-se a solução em dois cenários: primeiro, como um usuário com permissão de gerenciador de conteúdo, que consegue fazer upload bem-sucedido de arquivo para a unidade compartilhada; segundo, como um usuário sem permissão, que recebe mensagem de erro informando falta de acesso. Esses testes confirmam que a solução enforça corretamente os controles de acesso baseados nas permissões do Google Drive.
Benefícios e Casos de Aplicação
Essa abordagem oferece diversos benefícios significativos. Melhora a experiência do usuário ao permitir upload de arquivos para Google Drive através de prompts em linguagem natural, sem exigir conhecimento especializado sobre APIs subjacentes e sistemas complexos.
A segurança e conformidade são aprimoradas através da imposição de controles de acesso, permitindo apenas que usuários com permissões necessárias façam upload de arquivos para unidades compartilhadas, com permissões de arquivo gerenciadas através do Google Drive e do pool de usuários Cognito.
A complexidade operacional diminui ao abstrair integrações técnicas complexas com serviços de armazenamento em nuvem de terceiros, permitindo que as organizações focarem em entregar capacidades valiosas aos usuários.
Próximos Passos
Para implementar essa solução, as organizações podem consultar o repositório do GitHub fornecido pela AWS, que contém guias passo a passo completos, arquivos de configuração, código de exemplo e esquemas OpenAPI necessários para a implementação.
Após implantação, recomenda-se testar a solução com os cenários descritos para validar que os controles de acesso funcionam conforme esperado e que a experiência de usuário atende às expectativas organizacionais.
Conclusão
A integração do Google Drive com o Amazon Quick Suite através de conectores personalizados com especificações OpenAPI representa uma evolução importante na forma como as organizações podem simplificar operações de gerenciamento de arquivo. Ao combinar as capacidades de IA generativa do Amazon Quick Suite com serviços de nuvem enterprise como API Gateway, Lambda, Amazon Cognito e Secrets Manager, as empresas conseguem oferecer experiências de usuário intuitivas, mantendo altos padrões de segurança e conformidade.
A solução demonstra claramente que o futuro do gerenciamento de arquivo corporativo passa pela combinação de IA em linguagem natural com integrações seguras e controladas de terceiros, reduzindo barreiras técnicas enquanto mantém segurança robusta.
Pesquisadores e epidemiologistas em saúde lidam com um paradoxo bem conhecido: possuem profundo conhecimento sobre padrões de doenças, cuidados ao paciente e resultados clínicos, mas enfrentam obstáculos técnicos enormes antes de responder uma única pergunta de pesquisa. A realidade é que essas profissionais gastam semanas navegando infraestruturas complexas de dados, escrevendo código repetitivo e resolvendo barreiras técnicas que pouco têm a ver com seu trabalho principal.
Este gargalo não é apenas uma inconveniência — ele atrasa decisões baseadas em evidências e pode impactar diretamente o cuidado ao paciente. Centros acadêmicos, laboratórios de pesquisa, instalações clínicas e organizações comerciais de saúde produzem volumes enormes de dados clínicos que deveriam ser explorados muito mais rapidamente.
Principais obstáculos na análise acelerada de dados em saúde
Dois desafios centrais travam a velocidade de pesquisa clínica:
Navegação em dados clínicos complexos: Os catálogos de dados em saúde usam terminologias médicas especializadas e sistemas de codificação que exigem expertise de domínio para serem compreendidos. Descobrir quais tabelas contêm coortes de pacientes específicas e entender como códigos de condições se mapeiam entre diferentes sistemas de classificação é uma barreira considerável antes que qualquer análise comece.
Preparação técnica para análise: Após localizar os dados, analistas de saúde passam tempo significativo escrevendo scripts Python ou PySpark para extrair coortes de pacientes, calcular métricas clínicas e executar análises estatísticas. Este ônus técnico é particularmente agudo porque pesquisadores clínicos são especialistas em epidemiologia ou bioestatística, não em engenharia de software.
A solução: SageMaker Data Agent com IA agnóstica
Em 21 de novembro de 2025, a AWS introduziu uma capacidade integrada no Amazon SageMaker que muda fundamentalmente essa equação. O SageMaker Data Agent funciona como um assistente de pesquisa inteligente dentro do Amazon SageMaker Unified Studio, com capacidade de compreender seu ambiente de dados específico e seus objetivos clínicos.
Quando um pesquisador faz uma pergunta como “Compare padrões de comorbidade entre coortes de pacientes diabéticos e hipertensos”, o agente de dados não apenas gera fragmentos de código. Ele pensa o problema de forma sistemática: cria um plano de análise com múltiplas etapas, identifica as tabelas clínicas relevantes, determina os métodos estatísticos apropriados, gera código validado na linguagem otimizada (SQL, Python ou PySpark) e executa cada passo com pontos de controle integrados para supervisão humana.
Como o Data Agent resolve os desafios
Navegação inteligente de dados clínicos: O SageMaker Data Agent está integrado ao AWS Glue Data Catalog e mapeia todo o seu panorama de dados de saúde. O agente compreende suas tabelas clínicas reais — demografias de pacientes, diagnósticos, encontros, condições, medicações, imunizações, procedimentos — pelos seus nomes verdadeiros e relacionamentos. Reconhece relacionamentos temporais entre encontros, entende como códigos de diagnóstico se estruturam e navega as hierarquias complexas de dados clínicos sem exigir memorização de esquemas de banco de dados.
Redução do esforço técnico: O agente transforma perguntas clínicas em linguagem natural em código analítico pronto para produção. Gera código otimizado em SQL para extração eficiente de coortes de pacientes, Python para análise estatística e PySpark para processamento de dados em larga escala — tudo sem exigir que o pesquisador dominie cada linguagem. Além disso, cria um plano de análise estruturado com múltiplas etapas que reflete como pesquisadores clínicos experientes abordam problemas: definição de coorte, depois características basais, depois comparação estatística e, por fim, visualização. Cada etapa inclui pontos de validação para o usuário revisar o processo do agente, assegurando validade clínica, tratamento apropriado de dados faltantes e uso de métodos estatisticamente apropriados.
Esta abordagem agnóstica desloca o tempo do pesquisador de preparação técnica para interpretação clínica — exatamente o inverso do que acontecia antes.
Segurança e governança integradas
O SageMaker Data Agent foi arquitetado para respeitar controles de segurança existentes. Ele opera de forma segura dentro de seu ambiente AWS, respeitando políticas de AWS Identity and Access Management (IAM) e limites de dados organizacionais. Isso ajuda sua organização a manter controles de segurança enquanto acelera análise clínica, assegurando conformidade com regulamentos de proteção de dados e governança.
Cenário de uso: análise de coorte clínica
Imagine uma epidemiologista em um centro médico acadêmico conduzindo análise detalhada de condições clínicas como sinusite, diabetes e hipertensão através de comparação de coortes e análise de sobrevida. Seu fluxo de trabalho tradicional envolve navegar múltiplos sistemas desconectados para localizar conjuntos de dados, aguardar aprovações de acesso, compreender esquemas de dados complexos e escrever código extenso em Python e PySpark — um processo de múltiplas semanas onde a maioria do tempo vai para preparação de dados em vez de análise clínica real.
Este gargalo limita pesquisadores a apenas 2-3 estudos abrangentes por trimestre, atrasando diretamente a geração de insights analíticos.
Dois modos de interação para flexibilidade
Painel do Agente para análise clínica abrangente: Ideal para projetos de pesquisa de ponta a ponta. Este modo divide perguntas complexas de saúde em etapas analíticas estruturadas com pontos de revisão intermediários, mantendo supervisão humana ao longo de todo o processo.
Assistência integrada para tarefas focadas: Ideal para pesquisadores experientes que desejam ajuda direcionada com desafios de codificação específicos, correção de erros ou melhorias de código, mantendo controle total de seu fluxo de trabalho.
Como começar: guia prático
Pré-requisitos e configuração
Para este exemplo, usa-se Synthea — uma ferramenta que gera dados sintéticos de pacientes em formato CSV, contendo informações sobre pacientes, condições, imunizações, alergias, encontros e procedimentos. A Synthea é um gerador sintético de pacientes de código aberto que modela o histórico médico de pacientes sintéticos. Nenhum dado humano real é usado neste processo.
Como parte da configuração do SageMaker, abra o console do SageMaker e escolha “Get started” para criar um domínio baseado em IAM e um projeto denominado ClinicalDataProject. Para instruções sobre como configurar um domínio baseado em IAM e criar um projeto, consulte a documentação sobre domínios e projetos baseados em IAM.
Explorando dados clínicos com SQL
Após configurar o ambiente, você pode visualizar dados usando SQL simples. No console do SageMaker, escolha “Open” e depois o projeto que criou. Será redirecionado para a página de visão geral do SageMaker Unified Studio. Escolha “Data” no painel de navegação e expanda AwsDataCatalog para visualizar os dados catalogados aos quais você tem acesso em sua conta.
Para este caso de uso, crie cada uma das tabelas (pacientes, condições, imunizações, alergias, encontros e procedimentos) sob sagemaker_sample_db usando os arquivos CSV gerados anteriormente. Antes de realizar a análise clínica complexa, execute uma consulta básica na tabela de condições:
select * from "AwsDataCatalog"."sagemaker_sample_db"."conditions" limit 10
Criando um notebook para análise detalhada
Para análise aprofundada, crie um notebook. Escolha “Notebooks” no painel de navegação e selecione “Create notebook”. Depois de criar o notebook, você pode interagir com os dados de duas formas:
Codificar diretamente dentro de células do notebook usando a interface de prompt integrado. Por exemplo, digite “Code to find patient records in conditions table who suffer from Sinusitis” (Código para encontrar registros de pacientes na tabela de condições que sofrem de Sinusite), escolha “Generate code” e execute a célula para exibir os resultados.
Usar o painel Data Agent, que suporta tarefas analíticas abrangentes dividindo-as em etapas estruturadas, cada uma com código gerado que se baseia em resultados anteriores.
Análise detalhada de dados clínicos com Data Agent
No painel Data Agent, insira a consulta: “Find top 20 conditions and perform a detailed analysis of patients with immunizations suffering from those conditions” (Encontre as 20 principais condições e realize análise detalhada de pacientes com imunizações sofrendo dessas condições) e gere o código.
O SageMaker Data Agent verifica o estado atual do notebook para compreender com quais dados você está trabalhando. Identifica as tabelas de condições, imunizações e pacientes no banco de dados sagemaker_sample_db. Prepara um plano abrangente e o lista para que você revise. Você pode revisar o plano, fazer alterações necessárias se needed e depois escolher “Run step-by-step”.
O agente escreve o código nas células do notebook. Você pode revisar o código e depois escolher “Accept and run”. Se algumas etapas falharem na execução, escolha “Fix with AI” para prosseguir. Quando a consulta for concluída, os resultados serão exibidos com visualizações incluindo análise demográfica de pacientes imunizados com as 20 principais condições, análise de prevalência de condições e análise temporal do aparecimento de condições.
Comparação de coorte e análise de sobrevida
Com a sinusite viral identificada como a condição principal, você pode realizar comparação de coorte e análise de sobrevida. Insira a seguinte consulta no painel Data Agent:
“Build two cohorts 1/ Cohort for Male patients who are suffering from viral sinusitis 2/ Cohort for Female patients who are suffering from viral sinusitis. Run a detailed cohort comparison and survival analysis.” (Construa duas coortes 1/ Coorte para pacientes do sexo masculino sofrendo de sinusite viral 2/ Coorte para pacientes do sexo feminino sofrendo de sinusite viral. Execute comparação detalhada de coorte e análise de sobrevida.)
O SageMaker Data Agent prepara um plano abrangente para criação de coorte, análise de comparação de coorte e análise de sobrevida. Revise o plano e escolha “Run step-by-step”. O resultado inclui gráficos de comparação demográfica entre coortes, curvas de Kaplan-Meier e gráficos cumulativos de eventos.
Limpeza de recursos
Para remover recursos criados durante este processo: primeiro, delete o projeto SageMaker Unified Studio navegando até o console, selecionando seu projeto da lista e escolhendo “Delete”. Segundo, remova recursos do AWS Glue Data Catalog abrindo o console do AWS Glue, navegando até “Databases” e deletando o banco de dados de exemplo. Terceiro, delete buckets S3 e dados abrindo o console do Amazon S3, localizando o bucket onde dados de saúde estão armazenados, esvaziando o conteúdo e deletando o bucket.
Por que isso importa para pesquisa em saúde
Com o SageMaker Data Agent alimentado por IA agnóstica, você vê seus conjuntos de dados acessíveis ao fazer login, valida qualidade de dados com visualizações rápidas e realiza análise através de prompts em linguagem natural — reduzindo esforço de codificação manual. O agente acelera sua capacidade de pesquisa, ajudando padrões de tratamento a serem identificados mais cedo.
Ao deslocar a vasta maioria do seu tempo de preparação de dados para análise real, o SageMaker Data Agent entrega descobertas de pesquisa mais eficientemente enquanto reduz custos de infraestrutura. As análises são documentadas em notebooks reproduzíveis que podem ser validadas e auditadas por stakeholders clínicos, suportando transparência enquanto acelera o caminho de dados para análise impactante.
Uma Camada Adicional de Segurança para Distribuições CloudFront
A AWS anunciou o suporte para autenticação TLS Mútuo (mTLS) no Amazon CloudFront, um protocolo de segurança que permite aos clientes verificar se as requisições dirigidas aos seus servidores de origem provêm apenas de distribuições CloudFront autorizadas, usando certificados TLS. Esse mecanismo de autenticação baseado em certificados fornece verificação criptográfica da identidade do CloudFront, eliminando a necessidade de os clientes implementarem controles de segurança personalizados.
O Problema com Abordagens Tradicionais
Anteriormente, comprovar que as requisições vinham de distribuições CloudFront exigia que os clientes desenvolvessem e mantivessem soluções de autenticação customizadas. Exemplos dessas abordagens incluem headers de secret compartilhado ou listas de IP permitidas, particularmente quando as origens eram públicas ou hospedadas externamente.
Essas estratégias demandavam sobrecarga operacional contínua: rotação de secrets, atualização de listas de permissão e manutenção de código personalizado. Com o tempo, isso representava um custo significativo em termos de tempo e complexidade da infraestrutura.
Autenticação Padronizada com Certificados
Com o suporte ao mTLS em origens, as organizações podem implementar uma abordagem de autenticação padronizada e baseada em certificados, eliminando esse trabalho operacional. Isso possibilita reforçar uma autenticação rigorosa para conteúdo proprietário, garantindo que apenas distribuições CloudFront verificadas consigam estabelecer conexões com infraestrutura de backend.
Essa infraestrutura pode incluir origens AWS, servidores locais, provedores de nuvem terceirizados e CDNs externos.
A configuração do mTLS em origens pode ser feita através do AWS Management Console, CLI, SDK, CDK ou CloudFormation. O recurso é suportado para todas as origens compatíveis com TLS Mútuo na AWS, incluindo Application Load Balancer e API Gateway, assim como origens on-premises e customizadas.
Custo e Disponibilidade
Não há cobrança adicional pelo uso de mTLS em origens. O recurso também está disponível nos planos de preço fixo Business e Premium.
Nova capacidade de distribuição de custos no GovCloud (US)
A AWS Network Firewall agora oferece suporte à alocação flexível de custos por meio de anexos nativos do AWS Transit Gateway nas regiões AWS GovCloud (US). Essa funcionalidade permite que as organizações distribuam automaticamente os custos de processamento de dados entre diferentes contas da AWS, resolvendo um dos principais desafios na gestão centralizada de segurança de rede.
Como funciona a alocação flexível
Um dos principais obstáculos para implementar firewalls centralizados é a dificuldade em rastrear quem está usando os recursos e como alocar os custos de forma justa. Anteriormente, todas as despesas ficavam concentradas na conta proprietária do firewall, dificultando a visualização do custo real de cada unidade de negócio ou aplicação.
Com essa nova capacidade, os clientes podem criar políticas de medição para aplicar cobranças de processamento de dados com base nos requisitos de chargeback da organização. Isso significa que em vez de consolidar todas as despesas em uma única conta, as equipes agora conseguem distribuir os custos de inspeção do firewall diretamente para as equipes de aplicação responsáveis pelo consumo.
Benefícios para equipes de segurança e rede
Essa abordagem oferece vantagens significativas para organizações que mantêm controles de segurança centralizados. As equipes de segurança e rede podem agora gerenciar melhor os custos do firewall centralizado distribuindo as cobranças com base no uso real de cada proprietário de aplicação. Simultaneamente, as organizações conseguem manter a centralização dos controles de segurança sem perder a rastreabilidade de despesas.
Outro benefício importante é a eliminação da necessidade de soluções customizadas para gestão de custos. As organizações podem automatizar completamente a alocação de inspeção de custos para as unidades de negócio ou proprietários de aplicação apropriados, simplificando significativamente a operação.
Disponibilidade e como começar
A funcionalidade de alocação flexível de custos está disponível nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Os clientes podem ativar esses recursos através do Console de Gerenciamento da AWS, da Interface de Linha de Comando (CLI) ou do Kit de Desenvolvimento de Software (SDK) da AWS.
Uma informação importante para o planejamento: não há cobranças adicionais pelo uso desse tipo de anexo ou pela alocação flexível de custos, além dos preços padrão do AWS Network Firewall e do AWS Transit Gateway.
Para começar a utilizar a funcionalidade, a AWS disponibiliza documentação técnica completa sobre alocação flexível de custos no serviço Transit Gateway.
Validação Aprimorada de Reivindicações de Identidade
A AWS anunciou uma expansão significativa nas capacidades do Serviço de Token de Segurança (STS – Security Token Service). Agora, o STS suporta validação de reivindicações específicas selecionadas de provedores de identidade externos, incluindo Google, GitHub, CircleCI e Oracle Cloud Infrastructure (OCI).
Essa nova funcionalidade integra-se às políticas de confiança de funções IAM (Gerenciamento de Identidade e Acesso) e políticas de controle de recursos, permitindo federação OpenID Connect (OIDC) para dentro da AWS através da API AssumeRoleWithWebIdentity.
Como Funciona
Controle de Acesso Granular
Com essa capacidade expandida, é possível referenciar reivindicações customizadas como chaves de condição nas políticas de confiança de funções IAM e nas políticas de controle de recursos. Isso significa que arquitetos e administradores de segurança podem implementar controle de acesso muito mais fino para identidades federadas.
Estabelecimento de Perímetros de Dados
A validação granular dessas reivindicações facilita o estabelecimento de perímetros de dados — conceito importante em arquiteturas de segurança em nuvem que definem limites claros de acesso com base em contexto e origem das identidades.
Construindo sobre Fundações Sólidas
Essa melhoria expande as capacidades já existentes de federação OIDC do IAM. Anteriormente, a AWS já oferecia a possibilidade de conceder credenciais temporárias do AWS a usuários autenticados através de provedores de identidade externos compatíveis com OIDC. Agora, com suporte a validação de reivindicações específicas de cada provedor, a segurança e a flexibilidade dessa abordagem avançam consideravelmente.
Disponibilidade e Documentação
A AWS disponibilizou essa funcionalidade em todas as regiões comerciais. Para implementar essa capacidade, os administradores podem consultar a documentação sobre as chaves disponíveis para federação OIDC no Guia do Usuário IAM, que fornece a lista completa de reivindicações suportadas e orientações sobre como utilizá-las em políticas de confiança de funções IAM e políticas de controle de recursos.
Perspectiva para Arquitetos e Administradores
Essa melhoria é particularmente relevante para organizações que utilizam múltiplos provedores de identidade e buscam implementar modelos de acesso mais seguros e específicos por contexto. A capacidade de validar reivindicações específicas de cada provedor (Google, GitHub, CircleCI, OCI) reduz a necessidade de lógica customizada adicional e oferece um caminho mais direto para construir perímetros de segurança bem definidos em ambientes multi-provedor.
