Novo recurso de Lambda triggers para federação no Cognito
A AWS anunciou a introdução de Lambda triggers para federação de entrada (inbound federation) no Amazon Cognito. Este novo recurso permite transformar e personalizar atributos de usuários federados durante o processo de autenticação. Isso significa que você agora consegue modificar respostas provenientes de provedores SAML e OIDC externos antes que essas informações sejam armazenadas em seu pool de usuários.
A grande vantagem é oferecer controle programático completo sobre o fluxo de federação sem a necessidade de fazer alterações na configuração do provedor de identidade externo.
O que o novo recurso resolve
O Lambda trigger para federação de entrada aborda limitações significativas que existiam em fluxos de autenticação federada. Um dos principais problemas é o limite de tamanho de atributos que o Cognito suporta: até 2.048 caracteres por atributo. Quando provedores SAML ou OIDC externos enviam atributos de grupo grandes que ultrapassam esse limite, o fluxo de autenticação pode ser bloqueado.
Com essa nova capacidade, você consegue adicionar, sobrescrever ou suprimir valores de atributos conforme necessário. Por exemplo, é possível modificar atributos de grupo que são particularmente grandes antes de criar novos usuários federados ou atualizar perfis de usuários federados existentes no Cognito. Isso oferece flexibilidade para trabalhar com dados de provedores externos sem que eles causem problemas de compatibilidade.
Como implementar
O novo Lambda trigger para federação de entrada está disponível através da interface de usuário hospedada (versão clássica) e do managed login em todas as regiões da AWS onde o Amazon Cognito opera.
Para começar a usar o recurso, você pode configurar o trigger através de diferentes ferramentas:
AWS Management Console
AWS Command Line Interface (Interface de Linha de Comando — CLI)
AWS Software Development Kits (Kits de Desenvolvimento de Software — SDKs)
Cloud Development Kit (Kit de Desenvolvimento em Nuvem — CDK)
AWS CloudFormation
A configuração é feita adicionando o novo parâmetro à configuração de Lambda do seu pool de usuários (User Pool LambdaConfig).
Para obter exemplos práticos de implementação e as melhores práticas, consulte a documentação do Amazon Cognito onde você encontrará informações detalhadas sobre como usar esse novo recurso.
O desafio crescente da gestão de conteúdo empresarial
Organizações enfrentam um desafio crescente ao gerenciar volumes cada vez maiores de conteúdo corporativo. Catálogos de produtos, artigos de suporte, bases de conhecimento e documentação técnica precisam permanecer precisos, relevantes e alinhados com as realidades do negócio em constante evolução. Quando esses processos dependem exclusivamente de revisão manual, o resultado é operações lentas, custosas e incapazes de acompanhar as mudanças nos requisitos empresariais.
Pesquisa da McKinsey indica que organizações que adotam IA generativa em atividades de conhecimento, incluindo revisão de conteúdo e garantia de qualidade, conseguem aumentar a produtividade em até 30-50%, reduzindo significativamente o tempo gasto em tarefas repetitivas de verificação. Estudos do Deloitte complementam essa perspectiva, mostrando que operações de conteúdo impulsionadas por IA não apenas ganham eficiência, mas também ajudam as organizações a manter maior precisão de conteúdo e reduzir riscos operacionais.
Uma abordagem baseada em agentes de IA
A AWS, através do Amazon Bedrock AgentCore — uma infraestrutura propositalmente construída para implantar e operar agentes de IA em escala — combinou essa capacidade com Strands Agents, um SDK de código aberto para construir agentes de IA. Essa combinação permite que organizações automatizem fluxos de trabalho abrangentes de revisão de conteúdo.
O enfoque baseado em agentes capacita empresas a avaliar conteúdo quanto à precisão, verificar informações contra fontes autorizadas e gerar recomendações acionáveis de melhoria. Quando agentes especializados trabalham em conjunto de forma autônoma, experts humanos conseguem concentrar-se em tarefas estratégicas de revisão enquanto o sistema de agentes de IA lida com a validação em larga escala.
Esse padrão é aplicável a qualquer tipo de conteúdo empresarial: desde documentação de produtos e bases de conhecimento até materiais de marketing e especificações técnicas. Para ilustrar os conceitos na prática, a solução apresenta um exemplo concreto de revisão de conteúdo de blog focado em precisão técnica. Os padrões e técnicas podem ser adaptados para diferentes necessidades de revisão ajustando as configurações dos agentes, ferramentas e fontes de verificação.
Estrutura da solução multi-agente
A solução implementa um padrão de fluxo de trabalho multi-agente, onde três agentes de IA especializados, construídos com Strands Agents e implantados no Amazon Bedrock AgentCore, trabalham em um pipeline coordenado. Cada agente recebe a saída do agente anterior, processa-a de acordo com sua função especializada e passa informações enriquecidas para o próximo agente da sequência. Isso cria um processo de refinamento progressivo:
Agente scanner de conteúdo: analisa conteúdo bruto e extrai informações relevantes
Agente de verificação de conteúdo: valida os elementos extraídos contra fontes autorizadas
Agente de recomendações: transforma achados da verificação em atualizações de conteúdo acionáveis
A manutenção de conteúdo técnico requer múltiplos agentes especializados porque varrer manualmente, verificar e atualizar documentação é ineficiente e propenso a erros. Cada agente tem um papel focado: o scanner identifica elementos sensíveis ao tempo, o verificador valida a precisão atual e o agente de recomendações elabora atualizações precisas. O design modular do sistema, com interfaces e responsabilidades claras, facilita a adição de novos agentes ou expansão de capacidades conforme a complexidade do conteúdo cresce.
Exemplo prático: revisão de conteúdo técnico
Para demonstrar como esse sistema de revisão baseado em agentes funciona na prática, a solução apresenta uma implementação que revisa posts técnicos de blog quanto à precisão. Empresas de tecnologia frequentemente publicam posts detalhando novos recursos, atualizações e boas práticas. Contudo, o ritmo rápido de inovação significa que alguns recursos podem ficar obsoletos ou ser atualizados, tornando desafiador manter informações atualizadas em centenas ou milhares de posts publicados.
Embora o padrão seja demonstrado com conteúdo de blog, a arquitetura é agnóstica quanto ao tipo de conteúdo e oferece suporte a qualquer tipo configurando os agentes com prompts, ferramentas e fontes de dados apropriadas.
Arquitetura do fluxo de trabalho
O fluxo de trabalho inicia quando uma URL de blog é fornecida ao agente scanner de blog, que recupera o conteúdo usando a ferramenta http_request do Strands e extrai reivindicações técnicas-chave que requerem verificação. O agente de verificação então consulta o servidor MCP de documentação da AWS para buscar a documentação mais recente e validar as reivindicações técnicas contra a documentação atual. Finalmente, o agente de recomendações sintetiza os achados e gera um relatório de revisão abrangente com recomendações acionáveis para o time de blog. O código é de código aberto e hospedado no GitHub.
Agente scanner de conteúdo: extração inteligente para detecção de obsolescência
O agente scanner de conteúdo funciona como o ponto de entrada do fluxo de trabalho multi-agente. É responsável por identificar informações técnicas potencialmente obsoletas, especificamente direcionando elementos que tendem a se tornar desatualizados com o tempo. O agente analisa o conteúdo e produz uma saída estruturada que categoriza cada elemento técnico por tipo, localização no blog e sensibilidade temporal. Esse formato estruturado permite que o agente de verificação receba dados bem organizados que consiga processar eficientemente.
Agente de verificação de conteúdo: validação baseada em evidências
O agente de verificação de conteúdo recebe os elementos técnicos estruturados do agente scanner e realiza validação contra fontes autorizadas. O agente de verificação usa o servidor MCP de documentação da AWS para acessar documentação técnica atual. Para cada elemento técnico recebido do agente scanner, ele segue um processo de verificação sistemático orientado por prompts específicos que focam em critérios objetivos e mensuráveis.
O agente verifica:
Informações específicas de versão: o número de versão, endpoint de API ou parâmetro de configuração mencionado ainda existe?
Disponibilidade de recursos: o recurso de serviço descrito ainda está disponível nas regiões ou camadas especificadas?
Precisão de sintaxe: exemplos de código, comandos CLI ou snippets de configuração correspondem à documentação atual?
Validade de pré-requisitos: os requisitos, dependências ou passos de configuração listados ainda são precisos?
Preços e limites: custos mencionados, cotas ou limites de serviço se alinham com informações atuais publicadas?
Para cada elemento técnico recebido do agente scanner, o agente realiza os seguintes passos: gera consultas de busca direcionadas com base no tipo de elemento e conteúdo, consulta o servidor de documentação para informações atuais, compara a reivindicação original contra fontes autorizadas usando os critérios acima, classifica o resultado da verificação como CURRENT, PARTIALLY_OBSOLETE ou FULLY_OBSOLETE, e documenta discrepâncias específicas com evidências.
Um exemplo de verificação em ação: quando o agente scanner identifica a reivindicação “Amazon Bedrock está disponível apenas nas regiões us-east-1 e us-west-2”, o agente de verificação gera a consulta de busca “Amazon Bedrock regiões disponíveis” e recupera a disponibilidade regional atual da documentação da AWS. Ao descobrir que Bedrock agora está disponível em 8+ regiões incluindo eu-west-1 e ap-southeast-1, ele classifica isso como PARTIALLY_OBSOLETE com a evidência: “A reivindicação original lista 2 regiões, mas a documentação atual mostra disponibilidade em us-east-1, us-west-2, eu-west-1, ap-southeast-1 e 4 regiões adicionais a partir da data de verificação.”
A saída do agente de verificação mantém a estrutura de elemento do agente scanner enquanto adiciona esses detalhes de verificação e classificações baseadas em evidências.
Agente de recomendações: geração de atualizações acionáveis
O agente de recomendações representa o estágio final no fluxo de trabalho multi-agente, transformando achados de verificação em atualizações de conteúdo prontas para implementação. Esse agente recebe os resultados de verificação e gera recomendações específicas que mantêm o estilo do conteúdo original enquanto corrigem imprecisões técnicas.
Adaptando o padrão para diferentes casos de uso
O padrão de fluxo de trabalho multi-agente pode ser rapidamente adaptado para qualquer cenário de revisão de conteúdo sem mudanças arquiteturais. Seja revisando documentação de produtos, materiais de marketing ou documentos de conformidade regulatória, o mesmo fluxo sequencial de três agentes se aplica. Os prompts do sistema precisam ser modificados para cada agente focando em elementos específicos do domínio e potencialmente alternando ferramentas ou fontes de conhecimento.
Por exemplo, enquanto o exemplo de revisão de blog usa uma ferramenta http_request para buscar o conteúdo do blog e o servidor MCP de documentação da AWS para verificação, um sistema de revisão de catálogo de produtos poderia usar uma ferramenta de conector de banco de dados para recuperar informações de produtos e consultar APIs de gerenciamento de inventário para verificação. Similarmente, um sistema de revisão de conformidade ajustaria o prompt do agente scanner para identificar declarações regulatórias em vez de reivindicações técnicas, conectaria o agente de verificação a bancos de dados legais em vez de documentação técnica, e configuraria o agente de recomendações para gerar relatórios prontos para auditoria em vez de atualizações de conteúdo.
Os passos sequenciais centrais — extração, verificação e recomendação — permanecem constantes em todos esses cenários, fornecendo um padrão comprovado que escala desde blogs técnicos para qualquer tipo de conteúdo empresarial.
Personalizando a solução
As seguintes mudanças são recomendadas para personalizar a solução para outros tipos de conteúdo. Substitua os valores das variáveis CONTENT_SCANNER_PROMPT, CONTENT_VERIFICATION_PROMPT e RECOMMENDATION_PROMPT com suas instruções de prompt personalizadas:
CONTENT_SCANNER_PROMPT = """<replace with your prompt instructions>"""
CONTENT_VERIFICATION_PROMPT = """<replace with your prompt instructions>"""
RECOMMENDATION_PROMPT = """<replace with your prompt instructions>"""
Atualize o servidor MCP de documentação oficial para o agente de verificação de conteúdo:
product_db_mcp_client = MCPClient(
lambda: stdio_client(StdioServerParameters(
command="uvx",
args=["<replace with your official documentation MCP server>"]
))
)
Adicione ferramentas apropriadas de acesso a conteúdo como database_query_tool e cms_api_tool para o agente scanner de conteúdo quando a ferramenta http_request for insuficiente:
Essas modificações direcionadas permitem que o mesmo padrão arquitetural lide com qualquer tipo de conteúdo mantendo a estrutura de fluxo de trabalho de três agentes comprovada, garantindo confiabilidade e consistência em diferentes domínios de conteúdo sem exigir mudanças na lógica de orquestração central.
Próximos passos e conclusão
A solução apresentada demonstra como arquitetar um sistema de revisão de conteúdo impulsionado por agentes de IA usando o Amazon Bedrock AgentCore e Strands Agents. O padrão de fluxo de trabalho multi-agente, onde agentes especializados trabalham em conjunto para varrer conteúdo, verificar precisão técnica contra fontes autorizadas e gerar recomendações acionáveis, oferece uma abordagem escalável e modular.
É recomendado testar o código de exemplo disponível no GitHub em sua própria conta para ganhar experiência prática com a solução. Como próximos passos, considere começar com um projeto piloto em um subconjunto do seu conteúdo, personalizar os prompts dos agentes para seu domínio específico e integrar fontes de verificação apropriadas para seu caso de uso. A natureza modular dessa arquitetura permite refinar iterativamente as capacidades de cada agente conforme você expande o sistema para lidar com as necessidades completas de revisão de conteúdo da sua organização.
Nova capacidade de alteração de criptografia no S3
A AWS anunciou um novo recurso que simplifica significativamente a gestão da criptografia de dados armazenados no Amazon S3. Agora é possível alterar o tipo de criptografia de objetos já existentes sem necessidade de movimentação de dados, uma funcionalidade particularmente valiosa para organizações que precisam atualizar suas estratégias de segurança sem causar impacto operacional.
Como funciona o UpdateObjectEncryption API
O novo recurso utiliza a API UpdateObjectEncryption para realizar mudanças de criptografia de forma atômica, independentemente do tamanho do objeto ou da classe de armazenamento utilizada. Isso significa que a operação ocorre de forma consistente e confiável, sem riscos de corrupção ou inconsistência de dados.
Para cenários em larga escala, a AWS integrou essa capacidade ao S3 Batch Operations, permitindo que organizações padronizem o tipo de criptografia em buckets inteiros de objetos. Uma vantagem importante é que a operação preserva as propriedades dos objetos e mantém a elegibilidade para políticas de S3 Lifecycle, evitando reprocessamento desnecessário.
Conformidade e requisitos regulatórios
As organizações em diversos setores enfrentam demandas crescentes e complexas no que diz respeito à segurança e privacidade de dados. Um requisito comum nos frameworks de conformidade é a implementação de padrões de criptografia mais rigorosos para dados em repouso, muitas vezes exigindo que os dados sejam criptografados utilizando um serviço de gerenciamento de chaves dedicado.
O novo UpdateObjectEncryption API resolve esse cenário de forma prática. Organizações que utilizam a criptografia gerenciada pela própria AWS (SSE-S3 — Criptografia no lado do servidor com chaves gerenciadas pelo S3) agora podem migrar facilmente para a criptografia no lado do servidor com chaves gerenciadas pelo AWS KMS (SSE-KMS — Criptografia no lado do servidor com AWS Key Management Service).
Flexibilidade na gestão de chaves
Além da migração entre tipos de criptografia, o recurso oferece flexibilidade para trocar a chave gerenciada pelo KMS utilizada na criptografia dos dados, permitindo que organizações se adequem a padrões personalizados de rotação de chaves. O recurso também possibilita habilitar S3 Bucket Keys, reduzindo o volume de solicitações ao AWS KMS e, consequentemente, otimizando custos de operação.
Disponibilidade e como começar
O Amazon S3 UpdateObjectEncryption API está disponível em todas as regiões AWS. Para iniciar, as organizações podem utilizar o AWS Management Console ou os SDKs AWS mais recentes para atualizar o tipo de criptografia de seus objetos. Para informações técnicas detalhadas, recomenda-se consultar a documentação técnica.
Organizações que gerenciam centenas de contratos anualmente enfrentam desafios operacionais significativos. Sistemas fragmentados e fluxos de trabalho complexos obrigam equipes jurídicas e de procurement a gastar horas em ciclos de revisão. Esses processos manuais não apenas consomem recursos valiosos, mas também aumentam o risco de inconsistências e erros.
Para resolver esses problemas, a AWS apresenta uma abordagem inovadora baseada em colaboração multiagente. Agentes de IA especializados trabalham simultaneamente em diferentes aspectos da análise contratual, reduzindo ciclos de processamento enquanto mantêm precisão e supervisão adequada.
A combinação estratégica: Quick Suite e Bedrock AgentCore
A solução integra dois serviços principais da AWS. O Amazon Quick Suite funciona como espaço de trabalho agentico, oferecendo uma interface unificada para chat, pesquisa, inteligência de negócios e automação. Ele facilita a transição de obter respostas para tomar ações, automatizando tarefas que variam de atividades rotineiras até processos complexos como análise e processamento de contratos.
O Amazon Bedrock AgentCore complementa essa arquitetura fornecendo capacidades avançadas de colaboração multiagente. Ao usar AgentCore com Quick Suite, as organizações conseguem encapsular lógica de negócio em agentes de IA altamente capazes, operando em escala e com segurança aprimorada. Os serviços do AgentCore funcionam com múltiplos frameworks, incluindo Strands Agents, além de modelos fundamentais disponíveis dentro ou fora do Amazon Bedrock.
Visão geral da solução
O sistema de gestão de contratos inteligente utiliza o Quick Suite como interface de usuário e base de conhecimento, enquanto o Bedrock AgentCore oferece funcionalidade de colaboração multiagente. Agentes especializados analisam contratos, avaliam riscos, verificam conformidade e fornecem insights estruturados através de uma arquitetura simplificada.
Componentes da arquitetura
A solução é construída sobre diversos componentes integrados:
Componentes Quick Suite:
Spaces para organizar fluxos de trabalho de gestão de contratos
Agentes de chat para interações conversacionais sobre contratos
Bases de conhecimento para integrar documentos legais armazenados em Amazon S3
Topics para integrar dados estruturados de contratos
Actions para conectar agentes customizados desenvolvidos com Bedrock AgentCore
Flows para processos de revisão de documentos semicondutuais e recorrentes
Automate para tarefas de automação de contratos diária e mensal
Sistema multiagente com AgentCore:
Agente de colaboração contratual: orquestrador central que coordena o fluxo de trabalho
Agente legal: analisa termos legais e extrai obrigações-chave
Agente de risco: avalia riscos financeiros e operacionais
Agente de conformidade: avalia conformidade regulatória
A solução implementa um fluxo de trabalho otimizado que reduz significativamente o tempo de processamento e melhora a precisão. O sistema processa contratos através de agentes de IA coordenados, normalmente completando análise em minutos comparado a dias de revisão manual.
Os agentes trabalham de forma coordenada em etapas bem definidas:
O agente de colaboração contratual identifica o documento e define quais análises (legal, risco, conformidade) são necessárias
O agente legal extrai informações das partes, termos de pagamento e obrigações principais
O agente de risco identifica exposição financeira e pontos de alavancagem para negociação
O agente de conformidade avalia requisitos regulatórios e sinaliza potenciais problemas
O agente de colaboração consolida os achados em um relatório abrangente
Preparação e pré-requisitos
Antes de configurar o Quick Suite, é necessário ter:
No Quick Suite, crie um novo espaço chamado Contract Management para organizar fluxos de trabalho e recursos relacionados a contratos. Este espaço permitirá usar o assistente para fazer consultas sobre os recursos contidos nele.
Configuração de base de conhecimento para dados não estruturados
Para integrar documentos contratuais armazenados em Amazon S3:
Navegue até Knowledge bases na seção Integrations
Selecione Amazon S3 como fonte de dados
Configure o bucket S3 que armazenará seus documentos de contrato
Após criar a base de conhecimento, adicione-a ao espaço Contract Management
Configuração de base de conhecimento para dados estruturados
Para integrar dados estruturados de contratos:
Na seção Datasets, configure seu data warehouse de contratos (Amazon Redshift) para dados contratuais estruturados. Siga as instruções em Criando um dataset a partir de um banco de dados e aguarde a configuração ser concluída
Na seção Topics, integre fontes de dados de contratos estruturados como: bancos de dados de contratos, sistemas de informação de fornecedores e sistemas de rastreamento de conformidade
Adicione os topics relevantes ao seu espaço Contract Management
Implementação prática: Parte 2 – Implantação do Bedrock AgentCore
O Bedrock AgentCore oferece infraestrutura de nível empresarial para implantar agentes de IA com isolamento de sessão. Cada sessão executa com recursos isolados de CPU, memória e sistema de arquivos, criando separação entre sessões de usuários e ajudando a proteger processos de raciocínio stateful dos agentes.
O código necessário está disponível em um repositório GitHub. Navegue até a pasta legal-contract-solution/deployment.
A solução inclui um script de deploy_agents.py que automatiza completamente a implantação dos agentes de IA na AWS usando builds centrados em nuvem. As instruções requerem Python>=3.10.
O processo de implantação é totalmente automatizado e gerencia:
Gerenciamento de dependências: instala automaticamente o bedrock-agentcore-starter-toolkit se necessário e verifica pacotes Python obrigatórios
Configuração de infraestrutura AWS: cria papéis IAM com permissões necessárias para execução de agentes, configura repositório Amazon ECR (Registro de Container) para imagens de container e configura logs de Amazon CloudWatch para monitoramento
Implantação de agentes: implanta quatro agentes especializados e usa AWS CodeBuild para builds de container ARM64 centrados em nuvem, sem necessidade de Docker local
Gerenciamento de configuração: configura automaticamente protocolos de comunicação entre agentes, estabelece limites de segurança e configura monitoramento e observabilidade
Após implantação, os agentes podem ser visualizados no console do Amazon Bedrock AgentCore.
Implementação prática: Parte 3 – Integração do Bedrock AgentCore com Quick Suite
O Quick Suite pode conectar-se a soluções empresariais e agentes através de integrações de actions, tornando ferramentas disponíveis para agentes de chat e fluxos de automação.
Implantação de API Gateway e Lambda
Na pasta legal-contract-solution/deployment, execute:
python3 deploy_quicksuite_integration.py
Isto fornecerá Amazon Cognito com um user pool para permissionar acesso ao endpoint do API Gateway. A configuração do Quick Suite referencia os detalhes OAuth deste user pool.
Após implantação bem-sucedida, dois arquivos serão gerados para integração com Quick Suite: quicksuite_integration_config.json (configuração completa) e quicksuite_openapi_schema.json (esquema OpenAPI para importar no Quick Suite).
Configuração de integração de actions no Quick Suite
Na seção Actions, prepare os pontos de integração que conectarão aos agentes implantados pelo AgentCore:
Obtenha o arquivo de especificação OpenAPI quicksuite_openapi_schema.json da pasta de trabalho
Na seção Integrations/Actions, acesse OpenAPI Specification
Crie uma nova integração OpenAPI fazendo upload do arquivo api_gateway_openapi_schema.json e insira as informações solicitadas
Utilize o endpoint com a URL usando informações do arquivo quicksuite_integration_config.json
Para os agentes, use Name: “Legal Contract Analyzer” e Description: “Analyze a legal contract using AI agents for clause extraction, risk assessment, and compliance checking”
Definição de agente de chat
Na seção Chat agents, configure um novo agente com os seguintes detalhes:
Name: Legal Contract AI Analyzer
Description: Um sistema alimentado por IA que analisa contratos legais e realiza avaliações abrangentes de risco usando capacidades avançadas de machine learning para identificar potenciais problemas, lacunas de conformidade e riscos contratuais
Agent identity: Você é um sistema especializado de análise de contratos legais alimentado por capacidades avançadas de IA generativa. Seu propósito é fornecer serviços abrangentes de revisão contratual e avaliação de risco
Persona instructions: Use o analisador de contratos legais quando possível. Sempre categorize riscos por severidade (Alto, Médio, Baixo). Destaque cláusulas não-padrão, provisões faltantes e potenciais problemas de conformidade. Forneça recomendações específicas para melhorias de contrato. Ao analisar cláusulas de responsabilidade, preste atenção especial a disposições de indenização, limitações de responsabilidade e provisões de força maior. Sinalize qualquer condição de rescisão incomum ou preocupações com propriedade intelectual
Communication style: Profissional, preciso e analítico com terminologia jurídica clara
Response format: Forneça análise estruturada com categorização clara de risco, níveis de severidade e recomendações acionáveis. Use bullet points para achados-chave e listas numeradas para recomendações priorizadas
Length: Análise abrangente cobrindo todos os aspectos críticos mantendo clareza e foco em insights acionáveis
Welcome message: Bem-vindo ao Legal Contract AI Analyzer. Faça upload de contratos para análise inteligente e avaliação de risco
Suggested prompts: “Analyze this contract for potential legal risks and compliance issues”, “Review the liability clauses in this agreement for red flags”, “Assess the termination conditions and notice requirements in this contract”
Testando a solução de gestão de contratos
Com a infraestrutura implantada e Quick Suite configurado, teste a solução selecionando o espaço Contract Management. Você pode usar a interface do agente para fazer perguntas sobre a base de conhecimento e instruir agentes a revisar documentos.
Limpeza de recursos
Há custos de infraestrutura associados à solução implantada. Quando não precisar mais dela em sua conta AWS, navegue até a pasta legal-contract-solution/deployment e execute:
python3 cleanup.py
Considerações finais
A combinação de Quick Suite e Bedrock AgentCore oferece aos times de procurement e legal benefícios operacionais imediatos enquanto os posiciona para avanços futuros em IA. A colaboração multiagente da AWS permite construir e gerenciar múltiplos agentes especializados que trabalham juntos para resolver fluxos de trabalho comerciais cada vez mais complexos.
Ao implementar essa solução de gestão de contratos inteligente, as organizações podem transformar seus processos de procurement, reduzir ciclos de contrato e permitir que seus times se concentrem em decisões estratégicas em vez de tarefas administrativas. A arquitetura extensível da solução permite começar com funções centrais de gestão de contratos e expandir gradualmente para casos de uso mais complexos conforme as necessidades da organização evoluem.
Novo recurso de visibilidade para tráfego de IA generativa
A AWS anunciou uma expansão significativa do AWS Network Firewall, incorporando a capacidade de identificar e controlar tráfego de aplicações que usam inteligência artificial generativa (IA generativa). O novo recurso funciona por meio de filtros baseados em categorias web, permitindo que as organizações visualizem e gerenciem o acesso a serviços de IA generativa, plataformas de mídia social, sites de streaming e outras categorias de conteúdo diretamente nas regras do firewall.
Como funciona o controle por categorias web
A abordagem implementada pela AWS utiliza categorias de URL pré-definidas para inspeção de tráfego. Isso significa que, em vez de necessário identificar manualmente cada domínio individual a ser bloqueado ou permitido, os administradores podem agrupar serviços por categoria e aplicar políticas de segurança de forma consolidada.
Este modelo simplifica significativamente a governança de segurança, especialmente para equipes que lidam com conformidade regulatória. Os times de segurança e compliance conseguem estabelecer políticas consistentes em todos os ambientes AWS, ao mesmo tempo que ganham visibilidade sobre o uso de tecnologias emergentes como IA generativa.
Casos de uso e benefícios práticos
O novo recurso viabiliza diversos cenários operacionais:
Bloqueio seletivo de domínios — As organizações podem restringir acesso a domínios considerados inadequados ou de alto risco para seu contexto operacional
Governança de ferramentas de IA — É possível limitar o uso de ferramentas de IA generativa apenas aos serviços previamente aprovados pela empresa
Atendimento a requisitos regulatórios — O controle granular auxilia no cumprimento de normas e regulamentações específicas do setor
Redução de overhead operacional — Comparado com abordagens manuais, a administração centralizada de categorias reduz a carga administrativa
Integração com inspeção TLS
Quando combinado com o recurso de inspeção TLS (Transport Layer Security) do AWS Network Firewall, o novo filtro oferece controle ainda mais granular. Isso permite que os administradores inspecionem o caminho completo da URL e apliquem regras de categoria de forma mais precisa, identificando não apenas o domínio, mas o contexto específico da requisição.
Disponibilidade e primeiros passos
O recurso está disponível em todas as regiões comerciais da AWS onde o AWS Network Firewall é suportado. Para começar, os administradores podem atualizar seus grupos de regras com estado (stateful rule groups) através de diferentes interfaces:
Monitoramento de Integridade de Arquivos: Uma Abordagem Escalável
As organizações enfrentam o desafio constante de rastrear mudanças em seus ambientes de nuvem. Isso inclui monitorar arquivos, softwares instalados e configurações em várias instâncias. Detectar alterações não autorizadas é crítico para a segurança, especialmente quando essas mudanças precisam ser integradas aos fluxos de trabalho existentes.
A AWS oferece uma solução altamente escalável e serverless para esse problema. O conceito apresentado utiliza o AWS Systems Manager Inventory para coletar metadados de arquivos em instâncias Amazon EC2, envia esses dados por meio do recurso de sincronização do Systems Manager para um bucket Amazon S3 com versionamento, e implementa uma função AWS Lambda que compara versões de inventário para detectar mudanças. Quando alterações são identificadas, a função cria achados no AWS Security Hub, que são posteriormente ingeridos pelo Amazon Security Lake em formato padronizado.
Fluxo de monitoramento de integridade de arquivos — fonte: Aws
Vantagens desta Abordagem
Esta solução oferece uma alternativa ao padrão de integração entre AWS Config e Security Hub, que se baseia em dados limitados sem incluir, por exemplo, timestamps de modificação de arquivos. A abordagem aqui apresentada fornece flexibilidade e controle para implementar lógica personalizada de detecção adaptada às necessidades operacionais específicas de cada organização.
Além disso, o modelo é extensível. O AWS Systems Manager Inventory pode coletar não apenas metadados de arquivos, mas também dados sobre aplicativos instalados, configurações de rede ou entradas do Windows Registry, permitindo criar lógica de detecção customizada para uma ampla gama de casos de uso operacionais e de segurança.
Etapas de Implementação
Pré-requisitos
Antes de começar, você precisará de uma conta AWS com permissões para criar e gerenciar recursos como Amazon EC2, AWS Systems Manager, Amazon S3 e Lambda.
Etapa 1: Configuração da Instância EC2
O primeiro passo é iniciar uma instância EC2 e criar um arquivo de configuração que será modificado posteriormente para simular uma alteração não autorizada.
Você precisará criar um papel AWS Identity and Access Management (IAM) para permitir que a instância EC2 se comunique com o Systems Manager. No console do IAM, crie um novo papel, selecione EC2 como caso de uso e anexe a política gerenciada AmazonSSMManagedInstanceCore. Nomeie esse papel como SSMAccessRole.
Em seguida, inicie uma instância EC2, mantendo a imagem Linux padrão e uma classe de instância como t3.micro. Nos detalhes avançados, atribua o papel SSMAccessRole que foi criado anteriormente. Para criar um arquivo de configuração de aplicativo durante a inicialização, use o script fornecido na seção User Data:
Este script cria um diretório e um arquivo de configuração que será monitorado. Você pode deixar as demais configurações com seus valores padrão e prosseguir sem um key pair, já que o acesso será feito via Session Manager.
Etapa 2: Ativar Security Hub e Security Lake
Caso esses serviços já estejam ativados em sua conta, pule para a próxima etapa. Caso contrário, comece ativando o AWS Security Hub CSPM, que coleta e agrega achados de segurança e adiciona monitoramento contínuo.
No console do Security Hub, acesse a opção CSPM e selecione ativar. Para esta demonstração, você não necessita das opções de padrões de segurança, portanto, pode desmarcá-las.
A próxima etapa é ativar o Amazon Security Lake para começar a coletar achados do Security Hub. No console do Security Lake, selecione “Começar”, escolha ingerir fontes AWS específicas e selecione Security Hub como fonte de log e eventos. Escolha a região específica onde você está trabalhando, use a opção padrão para criar um novo papel de serviço e conclua a configuração.
Etapa 3: Configurar Systems Manager Inventory e Sincronização com S3
Com Security Hub e Security Lake ativados, o próximo passo é configurar o Systems Manager Inventory para coletar metadados de arquivos e exportar esses dados para S3.
Crie um bucket S3 seguindo as orientações da documentação AWS para sincronização de dados de recursos. Após criar o bucket, ative o versionamento em suas propriedades. O versionamento garante que cada novo snapshot de inventário seja salvo como uma versão separada, permitindo rastrear mudanças ao longo do tempo.
Em produção, recomenda-se ativar logging de acesso ao S3, forçar acesso apenas por HTTPS e ativar eventos de dados do CloudTrail para auditoria completa.
No console do Systems Manager, acesse Fleet Manager e configure o inventário, selecionando apenas o tipo de dados “File”. Defina o caminho para a coleta limitada aos arquivos relevantes, neste caso:
/etc/paymentapp/
Em seguida, create a sincronização de dados de recursos no Fleet Manager, fornecendo um nome para a sincronização e o nome do bucket S3 versionado criado anteriormente.
Etapa 4: Implementar a Função Lambda
Para completar a solução, você precisa criar uma função Lambda que detecte mudanças quando novos dados de inventário chegarem ao S3. Cada vez que o Systems Manager escreve um novo objeto no S3, uma Amazon S3 Event Notification acionará a função Lambda, que comparará as versões mais recentes e anteriores do objeto.
Se forem encontrados arquivos criados, modificados ou deletados, a função cria um achado de segurança em formato ASFF (AWS Security Finding Format) no Security Hub.
Crie a função Lambda no console com o nome fim-change-detector, selecione Python como runtime e copie o código principal da função:
import boto3, os, json, re
from datetime import datetime, UTC
from urllib.parse import unquote_plus
from helpers import is_critical, load_file_metadata, is_modified, extract_instance_id
s3 = boto3.client('s3')
securityhub = boto3.client('securityhub')
CRITICAL_FILE_PATTERNS = os.environ["CRITICAL_FILE_PATTERNS"].split(",")
SEVERITY_LABEL = os.environ["SEVERITY_LABEL"]
def lambda_handler(event, context):
# Safe event handling
if "Records" not in event or not event["Records"]:
return
# Extract S3 event
record = event['Records'][0]
bucket = record['s3']['bucket']['name']
key = unquote_plus(record['s3']['object']['key'])
current_version = record['s3']['object'].get('versionId')
if not current_version:
return
# Fetching the region name
account_id = context.invoked_function_arn.split(":")[4]
region = boto3.session.Session().region_name
# Get object versions (latest first)
versions = s3.list_object_versions(Bucket=bucket, Prefix=key).get('Versions', [])
versions = sorted(versions, key=lambda v: v['LastModified'], reverse=True)
# Find previous version
idx = next((i for i,v in enumerate(versions) if v["VersionId"] == current_version), None)
if idx is None or idx + 1 >= len(versions):
return
prev_version = versions[idx+1]["VersionId"]
# Load both versions
current = load_file_metadata(bucket, key, current_version)
previous = load_file_metadata(bucket, key, prev_version)
# Compare
created = {p for p in set(current) - set(previous) if is_critical(p)}
deleted = {p for p in set(previous) - set(current) if is_critical(p)}
modified = {p for p in set(current) & set(previous) if is_critical(p) and is_modified(p, current, previous)}
# Report if changes were found
if created or deleted or modified:
instance_id = extract_instance_id(bucket, key, current_version)
now = datetime.now(UTC).isoformat(timespec='milliseconds').replace('+00:00', 'Z')
finding = {
"SchemaVersion": "2018-10-08",
"Id": f"fim-{instance_id}-{now}",
"ProductArn": f"arn:aws:securityhub:{region}:{account_id}:product/{account_id}/default",
"AwsAccountId": account_id,
"GeneratorId": "ssm-inventory-fim",
"CreatedAt": now,
"UpdatedAt": now,
"Types": ["Software and Configuration Checks/File Integrity Monitoring"],
"Severity": {"Label": SEVERITY_LABEL},
"Title": "File changes detected via SSM Inventory",
"Description": (
f"{len(created)} created, {len(modified)} modified, "
f"{len(deleted)} deleted file(s) on instance {instance_id}"
),
"Resources": [{"Type": "AwsEc2Instance", "Id": instance_id}]
}
securityhub.batch_import_findings(Findings=[finding])
# No change – delete older S3 version
else:
if prev_version != current_version:
try:
s3.delete_object(Bucket=bucket, Key=key, VersionId=prev_version)
except Exception as e:
print(f"Delete previous S3 object version failed: {e}")
Configurar Variáveis de Ambiente
A função Lambda requer duas variáveis de ambiente. No console Lambda, acesse a aba Configuração e defina:
A função Lambda precisa de permissões específicas. Crie uma política inline no papel de execução da função com as seguintes permissões (substitua <bucket-name>, <region> e <account-id> pelos seus valores):
Para melhor modularidade, crie um Lambda layer contendo funções auxiliares. Abra o AWS CloudShell e execute o seguinte script:
#!/bin/bash
set -e
FUNCTION_NAME="fim-change-detector"
LAYER_NAME="fim-change-detector-layer"
mkdir -p python
cat > python/helpers.py << 'EOF'
import json, re, os
from dateutil.parser import parse as parse_dt
import boto3
s3 = boto3.client('s3')
CRITICAL_FILE_PATTERNS = os.environ.get("CRITICAL_FILE_PATTERNS", "").split(",")
def is_critical(path):
return any(re.match(p.strip(), path) for p in CRITICAL_FILE_PATTERNS if p.strip())
def load_file_metadata(bucket, key, version_id):
obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
data = {}
for line in obj['Body'].read().decode().splitlines():
if line.strip():
i = json.loads(line)
n, d, m = i.get("Name","").strip(), i.get("InstalledDir","").strip(), i.get("ModificationTime","").strip()
if n and d and m:
data[f"{d.rstrip('/')}/{n}"] = m
return data
def is_modified(path, current, previous):
try:
return parse_dt(current[path]) != parse_dt(previous[path])
except:
return current[path] != previous[path]
def extract_instance_id(bucket, key, version_id):
obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
for line in obj['Body'].read().decode().splitlines():
if line.strip():
r = json.loads(line)
if "resourceId" in r:
return r["resourceId"]
return None
EOF
zip -r helpers_layer.zip python >/dev/null
LAYER_VERSION_ARN=$(aws lambda publish-layer-version \
--layer-name "$LAYER_NAME" \
--description "Helper functions for File Integrity Monitoring" \
--zip-file fileb://helpers_layer.zip \
--compatible-runtimes python3.13 \
--query 'LayerVersionArn' \
--output text)
aws lambda update-function-configuration \
--function-name "$FUNCTION_NAME" \
--layers "$LAYER_VERSION_ARN" >/dev/null
echo "Layer created and attached to the Lambda function."
Etapa 5: Configurar Notificações de Eventos S3
Configure as S3 Event Notifications para acionar a função Lambda quando novos dados de inventário chegarem. No console S3, abra o bucket de inventário, acesse propriedades e crie uma notificação de evento com o seguinte configuração:
No prefixo, defina AWS%3AFile/ para limitar os acionadores apenas aos objetos de inventário de arquivos
Selecione o tipo de evento “Put”
Aponte para a função Lambda recém-criada
A coleta de inventário é executada a cada 30 minutos por padrão, mas pode ser ajustada conforme os requisitos de segurança da organização.
Etapa 6: Testar a Detecção de Mudanças
Com a instância EC2 em execução e o arquivo de configuração inicializado, você está pronto para simular uma alteração não autorizada.
Use o Session Manager para conectar à instância e modificar o arquivo:
echo "db_password=hacked456" | sudo tee /etc/paymentapp/config.yaml
Para acelerar o teste, force uma execução imediata do inventário através do State Manager no console do Systems Manager. Após a conclusão bem-sucedida, verifique o bucket S3 e o console do Security Hub. Você deve ver um novo achado relatando a mudança detectada no arquivo.
Análise e Visualização de Dados
Enquanto o Security Hub oferece uma visão centralizada de achados, é possível aprofundar a análise utilizando o Amazon Athena para executar consultas SQL diretamente nos dados normalizados do Security Lake armazenados em S3, que seguem o padrão Open Cybersecurity Schema Framework (OCSF).
Um exemplo de consulta:
SELECT finding_info.desc AS description, class_uid AS class_id, severity AS severity_label, type_name AS finding_type, time_dt AS event_time, region, accountid
FROM amazon_security_lake_table_us_east_1_sh_findings_2_0
Ajuste a cláusula FROM conforme a região utilizada. O Security Lake processa os achados antes deles aparecerem no Athena, portanto, espere um pequeno atraso.
Para exploração visual e insights em tempo real, integre o Security Lake com o Amazon OpenSearch Service e Amazon QuickSight, ambos com suporte amplo a IA generativa. Consulte a documentação para um guia detalhado sobre visualização de achados.
Limpeza de Recursos
Após testar a solução, remova os recursos criados para evitar custos contínuos:
Termine a instância EC2
Delete a sincronização de dados de recursos e a associação de inventário
Remova a função Lambda
Desative o Security Lake e Security Hub CSPM
Delete os papéis IAM criados
Delete os buckets S3 utilizados para sincronização de dados e Security Lake
Considerações para Ambientes Produtivos
Em produção, considere as seguintes práticas recomendadas para a função Lambda:
Configure concorrência reservada para evitar escalabilidade sem limite
Configure uma fila de letra morta para capturar invocações que falharam
Opcionalmente, anexe a função a uma Amazon VPC para isolamento de rede
Além disso, o Security Lake suporta coleta de dados em múltiplas contas e regiões utilizando o AWS Organizations. Um Systems Manager resource data sync também pode ser configurado para enviar dados de inventário a um bucket S3 centralizado, simplificando a gestão em ambientes de múltiplas contas.
Conclusão
A solução apresentada demonstra como combinar o Systems Manager Inventory, Security Hub e Security Lake para criar um sistema robusto de monitoramento de integridade de arquivos. A abordagem oferece flexibilidade, controle e escalabilidade para organizações que buscam aprofundar a visibilidade sobre mudanças em seus ambientes AWS.
Integração entre Transfer Family e FSx para NetApp ONTAP
A AWS anunciou em janeiro de 2026 que o Transfer Family passou a oferecer suporte nativo para o Amazon FSx para NetApp ONTAP. Essa integração permite que clientes da AWS acessem dados armazenados em sistemas de arquivos FSx for ONTAP utilizando protocolos padronizados como SFTP (Protocolo Seguro de Transferência de Arquivo), FTPS (FTP com Segurança de Camada de Transporte) e FTP (Protocolo de Transferência de Arquivo).
O Transfer Family, que já oferecia transferências de arquivos totalmente gerenciadas em protocolos como SFTP, FTP, FTPS, AS2 e interfaces baseadas em navegador, agora expande sua capacidade de alcance para incluir infraestruturas ONTAP. Essa adição representa uma evolução importante para organizações que utilizam sistemas de armazenamento NetApp e precisam modernizar seus fluxos de transferência de dados.
Como funciona a integração
Acesso através de S3 Access Points
O mecanismo que viabiliza essa integração envolve o uso de S3 Access Points do Transfer Family. Os usuários podem agora acessar sistemas de arquivos FSx para ONTAP pelos protocolos suportados do Transfer Family, enquanto mantêm simultaneamente o acesso através dos protocolos nativos de arquivo — NFS (Sistema de Arquivos de Rede) e SMB (Bloco de Mensagem do Servidor).
Essa abordagem híbrida permite que as organizações preservem seus fluxos de trabalho existentes enquanto adicionam camadas de segurança e acesso padronizado para parceiros externos e usuários internos que necessitam de protocolos industriais específicos.
Controle de segurança e conformidade
O acesso aos dados é gerenciado através de mecanismos padrão da AWS: Políticas IAM (Gestão de Identidade e Acesso) e configurações de S3 Access Points. Essa estrutura centralizada de controle oferece às organizações ferramentas robustas para atender requisitos de segurança de dados e conformidade regulatória, elementos críticos em ambientes corporativos.
Disponibilidade e próximos passos
O suporte do Transfer Family para FSx para ONTAP está disponível em regiões selecionadas da AWS. Para começar, os clientes podem acessar o console do Transfer Family ou utilizar ferramentas de programação como AWS CLI (Interface de Linha de Comando) e SDKs (Kits de Desenvolvimento de Software).
A documentação técnica completa encontra-se no Guia do Usuário do Transfer Family, que oferece instruções passo a passo para configurar a integração com FSx para ONTAP e aproveitar todo o potencial dessa nova funcionalidade.
Por que isso importa
Essa integração elimina fricções comuns em migrações para a nuvem: organizações que dependem de NetApp ONTAP podem modernizar seus processos de compartilhamento de arquivos sem abandonar investimentos em infraestrutura existente. O Transfer Family oferece a ponte entre ambientes legados e abordagens nativas de nuvem, tudo sob um único serviço gerenciado.
A AWS anunciou uma atualização no Amazon Bedrock que oferece uma opção de tempo de vida (TTL — Time-To-Live) de 1 hora para cache de prompts, disponível para modelos selecionados da Anthropic Claude. Essa funcionalidade amplia as possibilidades de retenção de conteúdo em cache em relação ao intervalo padrão de 5 minutos, trazendo ganhos significativos em eficiência de custos e desempenho.
Quando o cache estendido faz diferença
Anteriormente, o conteúdo armazenado em cache permanecia ativo por uma janela fixa de 5 minutos e era atualizado sempre que reutilizado. Com a opção de TTL de 1 hora, torna-se possível manter contexto para usuários que interagem com menor frequência, bem como para agentes complexos que precisam de mais tempo entre etapas — como uso de ferramentas, recuperação de dados e orquestração.
A duração estendida de cache também se mostra útil em cenários de sessões prolongadas e processamento em lote, onde o conteúdo em cache precisa persistir por períodos mais longos. Essa capacidade reduz a necessidade de reprocessamento e diminui custos operacionais em conversas multi-turno complexas.
Disponibilidade e modelos suportados
O cache com TTL de 1 hora está disponível de forma geral para os modelos Claude Sonnet 4.5, Claude Haiku 4.5 e Claude Opus 4.5 da Anthropic em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US) onde esses modelos estão disponíveis.
É importante destacar que o cache de 1 hora é cobrado a uma taxa diferente daquela aplicada ao cache padrão de 5 minutos, sendo necessário considerar essa diferença ao calcular custos da solução.
Um gateway de IA funciona como um padrão arquitetural intermediário que potencializa a disponibilidade, segurança e observabilidade de modelos de linguagem grandes (LLMs). Diferentemente de uma conexão direta aos modelos, um gateway centraliza múltiplas necessidades organizacionais em um único ponto.
Usuários finais buscam baixa latência e experiências fluidas. Desenvolvedores precisam de arquiteturas flexíveis e extensíveis. Equipes de segurança necessitam governança para proteger informações e garantir disponibilidade. Engenheiros de sistemas requerem soluções de monitoramento e observabilidade. Gerentes de produtos precisam de dados sobre desempenho com usuários. E gestores de orçamento exigem controles de custo. Uma solução de gateway adequada precisa atender a todos esses públicos simultaneamente.
A Proposta da AWS com AppSync Events
A AWS apresenta uma arquitetura baseada em AppSync Events que oferece websockets seguros e escaláveis. O diferencial está na propagação de eventos com baixa latência entre modelos de IA generativos e usuários individuais, um requisito crítico para experiências conversacionais responsivas.
A solução inclui capacidades essenciais para um gateway de IA em produção:
Identidade – Autenticação e autorização de usuários a partir de diretórios internos, corporativos e provedores de identidade externa como Amazon, Google e Facebook
APIs – Acesso de baixa latência para aplicações e usuários aos modelos de IA generativa
Autorização – Controle granular sobre quais recursos cada usuário pode acessar na aplicação
Limitação de taxa e medição – Mitigação de tráfego bot, bloqueio de acesso e gerenciamento de consumo de modelos para controle de custos
Acesso a modelos diversos – Suporte a múltiplos modelos base, agentes e salvaguardas para proteger usuários
Logging – Observabilidade, troubleshooting e análise do comportamento das aplicações
Analytics – Extração de valor dos logs para construção de insights significativos
Monitoramento – Rastreamento de métricas-chave que permitem reação rápida a eventos
Cache – Redução de custos através da detecção de consultas comuns e retorno de respostas predeterminadas
Arquitetura: Identidade e APIs
A arquitetura proposta segue um fluxo específico de comunicação entre cliente, autenticação e modelos:
A aplicação cliente obtém identidade e autorização do usuário através do Amazon Cognito. Em seguida, o cliente se inscreve em um canal do AppSync Events para receber eventos como respostas em streaming do Amazon Bedrock. Uma função Lambda específica (SubscribeHandler) anexada ao namespace de Mensagens de Saída valida se o usuário está autorizado a acessar aquele canal.
Quando o cliente publica uma mensagem (como uma pergunta ao modelo), a função ChatHandler recebe a mensagem e verifica autorização para publicação. Em seguida, ela chama a API Amazon Bedrock ConverseStream usando AWS Lambda e aguarda a resposta. As mensagens de resposta são encaminhadas para o canal de Mensagens de Saída do usuário, que retorna os eventos ao websocket aguardando mensagens.
A organização utiliza namespaces e canais como blocos construtivos. Cada namespace pode ter integrações diferentes de publicação e subscrição. Os canais são estruturados para proporcionar comunicação um-para-um entre usuário e servidor:
O atributo “sub” (subject) chega como contexto do Cognito nas funções Lambda e representa um identificador de usuário único e imutável dentro do pool de usuários. Isso permite segmentação segura dos nomes de canais.
Implementação de Autorização
A identidade é estabelecida pelo Cognito, mas a autorização ainda precisa ser implementada. A função SubscribeHandler valida se o primeiro segmento do canal corresponde ao “sub” do usuário. Se não corresponder, a subscrição é rejeitada com uma mensagem de erro. Se corresponder, retorna None indicando sucesso.
O mesmo padrão é aplicado na função ChatHandler para garantir que usuários apenas publiquem em seus próprios canais de entrada. Este modelo simples demonstra como regras de autorização complexas podem ser implementadas com funções Lambda para controlar acesso aos canais.
Controle de Taxa e Medição de Tokens
Entender e controlar o número de tokens consumidos é crítico para muitos clientes. Tokens de entrada e saída são o mecanismo de preço primário para LLMs baseados em texto no Bedrock. A solução usa a API Converse do Amazon Bedrock para acesso aos modelos, que fornece uma interface consistente funcionando com diferentes modelos.
Parte dessa interface é um evento de metadados de stream emitido ao final de cada transmissão, fornecendo contagem de tokens consumidos:
A solução implementa dois tipos de limites: um limite mensal estático (reset mensal) e um limite diário em janela móvel de 10 minutos. Amazon DynamoDB oferece contadores atômicos, acesso em tempo real aos contadores por usuário e remoção automática de dados antigos através de TTL (Time To Live).
A tabela DynamoDB utiliza dois atributos-chave:
Chave de partição – user_id (String), identificador único do usuário do atributo “sub”
Chave de ordenação – period_id (String), identificador do período com ordenação lexicográfica
Cada registro mantém colunas de contadores de input_tokens e output_tokens (incrementados com operação ADD atômica do DynamoDB), timestamp de criação/atualização e ttl para remoção automática em 24 horas.
Para verificação de uso, consultas de range exploram as chaves ordenadas naturalmente para recuperar apenas registros dos últimos 24 horas. O cálculo mensal é mais simples — recupera o registro específico do mês atual e compara contra limites.
Acesso a Múltiplos Modelos
O código de exemplo usa a API Converse do Amazon Bedrock, mas muitos modelos estão inclusos para exploração rápida. A inovação não para nos modelos AWS. Existem múltiplas formas de desenvolver soluções de IA generativa em cada nível de abstração.
A AWS disponibiliza recursos como Strands Agents (um SDK de agentes de IA open source) e Amazon Bedrock AgentCore, um conjunto de serviços de nível empresarial que ajuda desenvolvedores a implantar e operar agentes de IA em escala usando um framework e modelo hospedado no Bedrock ou em outro lugar. Para aprofundamento em arquiteturas de agentes, existe referência técnica disponível sobre Strands Agents SDK com foco em arquiteturas de agentes e observabilidade.
Logging e Observabilidade
Múltiplas partes interessadas precisam de logs. Desenvolvedores querem entender funcionamento das aplicações. Engenheiros de sistema necessitam acompanhar disponibilidade e planejamento de capacidade. Líderes de negócios querem analytics e tendências para decisões melhores.
O Amazon CloudWatch Logs centraliza logs de sistemas, aplicações e serviços AWS em um único serviço altamente escalável. Permite visualização, busca por códigos de erro ou padrões, filtragem por campos específicos e arquivamento seguro para análise futura.
A arquitetura de gateway de IA integra CloudWatch Logs em múltiplos níveis:
Logging da API AppSync Events – Configurado com nível ERROR para capturar problemas em nível de API, falhas de autenticação e questões críticas
Logging estruturado em funções Lambda – Usa AWS Lambda Powertools para logging estruturado. A função ChatHandler implementa classe MessageTracker que fornece contexto para cada conversa, rastreando identificadores de usuário, conversa, modelo, tokens consumidos e timestamps
ID de correlação – Cada função Lambda define um ID de correlação para rastreamento de requisição, facilitando seguir uma solicitação única pelo sistema
O CloudWatch Logs Insights permite consultas tipo SQL nos dados de log, ajudando a rastrear padrões de uso de tokens por modelo ou usuário, monitorar tempos de resposta, detectar padrões de erro e criar métricas customizadas com alarmes.
Analytics e Inteligência de Negócios
CloudWatch Logs fornece observabilidade operacional, mas para inteligência de negócios, a AWS oferece múltiplos serviços de analytics. A arquitetura de gateway de IA transforma dados sem requerer infraestrutura dedicada.
O fluxo de dados segue: a função ChatHandler transmite dados de log estruturado para um stream de entrega do Amazon Data Firehose ao final de cada resposta de usuário. O Firehose gerencia escalabilidade automática, eliminando necessidade de provisionamento.
Os dados são armazenados automaticamente em formato Parquet no Amazon S3, melhorando performance de consulta e reduzindo custos comparado a logs JSON brutos. Os dados são particionados por ano, mês e dia.
O AWS Glue Data Catalog define esquema para os dados de analytics com atributos como user_id, conversation_id, model_id, contagens de tokens e timestamps. Partições são adicionadas conforme novos objetos são armazenados pelo Firehose.
Com Amazon Athena, analistas podem usar SQL familiar para extração de insights. O Athena é serverless e cobrado por consulta baseado em dados escaneados, ideal para análise única sem infraestrutura de banco de dados:
-- Exemplo: Uso de tokens por modelo
SELECT model_id,
SUM(input_tokens) as total_input_tokens,
SUM(output_tokens) as total_output_tokens,
COUNT(*) as conversation_count
FROM firehose_database.firehose_table
WHERE year='2025' AND month='08'
GROUP BY model_id
ORDER BY total_output_tokens DESC;
Esta pipeline serverless transforma eventos em tabelas estruturadas e consultáveis com mínima sobrecarga operacional. Com dados catalogados no AWS Glue, você acessa a suíte completa de serviços de analytics e machine learning AWS como Amazon Quick Sight e Amazon SageMaker Unified Studio.
Monitoramento e Métricas
AppSync Events e funções Lambda enviam métricas para CloudWatch permitindo monitoramento de performance, troubleshooting e otimização de operações da API. Para um gateway de IA, informações adicionais sobre consumo de tokens e latência dos modelos são críticas.
A aplicação de exemplo inclui chamadas a métricas CloudWatch para registrar consumo de tokens e latência do LLM ao final de cada turno de conversa, fornecendo visibilidade em tempo real aos operadores. As métricas incluem o identificador do modelo como dimensão, permitindo rastreamento de consumo e latência por modelo.
Além de métricas, consultas CloudWatch Logs Insights sobre dados formatados em JSON permitem análise de logs para monitoramento. Exemplos práticos incluem identificação de usuários com mais conversas em uma janela de tempo ou computação de usuários únicos em intervalos de 5 minutos.
Cache de Respostas Preparadas
Muitos gateways de IA implementam mecanismo de cache para situações onde múltiplos usuários fazem exatamente a mesma pergunta. Exemplo apropriado: “Vai chover em São Paulo hoje?” — todos devem ver a mesma resposta. Exemplo inadequado: “Quantas horas de férias tenho?” — informação privada que não deve ser compartilhada em cache.
A implementação calcula hash da mensagem do usuário para consulta em tabela DynamoDB com respostas armazenadas. Se existe mensagem disponível para aquele hash, a aplicação retorna o texto, registra cache hit em CloudWatch e passa evento ao AppSync Events notificando conclusão de resposta. Este comportamento fica encapsulado na estrutura de evento que a aplicação compreende.
Instalação e Custos
O código de exemplo está disponível no repositório GitHub. Consulte o arquivo README no GitHub para instruções de instalação. Tanto implantação quanto remoção são conduzidas por comando único usando o AWS Cloud Development Kit (AWS CDK).
A tabela de custos estimados para uso leve em ambiente de desenvolvimento fornece referência mensal entre $35–55, variando conforme padrões de uso específicos de sua organização. Serviços incluem taxas por operações de API, conexões, armazenamento, requisições e duração de computação.
Conclusão
Conforme o cenário de IA generativa evolui, você necessita de infraestrutura que se adapte com a mesma velocidade dos modelos. Uma arquitetura centralizada em AppSync Events com padrões serverless – incluindo autenticação por Cognito, medição por DynamoDB, observabilidade por CloudWatch e analytics por Athena – fornece fundação que cresce com suas necessidades.
A aplicação de exemplo oferece ponto de partida demostrando padrões do mundo real, permitindo desenvolvedores explorar integração de IA, arquitetos desenhar soluções empresariais e líderes técnicos avaliar abordagens. O código-fonte completo e instruções de implantação estão disponíveis no repositório GitHub. Para começar, implante a aplicação de exemplo e explore as arquiteturas em ação. Você pode customizar lógica de autorização conforme requisitos de sua organização e estender seleção de modelos para incluir seus modelos preferidos no Amazon Bedrock.
A AWS expandiu a disponibilidade do Amazon Managed Grafana para as regiões AWS GovCloud (US-West) e AWS GovCloud (US-East). Essa expansão permite que órgãos governamentais e empresas de setores regulados visualizem e analisem seus dados operacionais de forma segura, atendendo aos rigorosos requisitos de conformidade exigidos pelo setor público norte-americano.
O Amazon Managed Grafana
O Amazon Managed Grafana é um serviço totalmente gerenciado baseado na plataforma de código aberto Grafana. Ele simplifica o processo de visualização e análise de dados operacionais em larga escala, permitindo que equipes de tecnologia monitorem infraestruturas complexas de forma centralizada e intuitiva.
O diferencial desse serviço é eliminar a necessidade de manutenção tradicional de software. Em vez de instalar, configurar e gerenciar instâncias do Grafana em seus próprios ambientes, as organizações podem contar com uma solução completamente administrada pela AWS.
Capacidades nas regiões GovCloud
Praticamente todas as funcionalidades do Amazon Managed Grafana estão disponíveis nas regiões AWS GovCloud (US). A única exceção diz respeito aos plugins Enterprise, que não são suportados nessas regiões específicas.
Essa disponibilidade é particularmente importante para organizações do setor público que precisam manter seus dados dentro de ambientes com conformidade rigorosa, garantindo que suas operações de monitoramento e análise atendam aos padrões federais de segurança e privacidade.
Para aprofundar o conhecimento sobre esse serviço, estão disponíveis a página do produto e a página de preços, onde é possível compreender melhor as funcionalidades oferecidas e analisar as opções de custeamento.
Relevância para o mercado regulado
Essa expansão de disponibilidade reflete a estratégia da AWS de oferecer seus serviços em ambientes que atendem a exigências rigorosas de conformidade. Para organizações que operam em setores regulados, como administração pública federal, defesa ou instituições financeiras altamente controladas, dispor de ferramentas de monitoramento nativas em regiões GovCloud reduz complexidades de arquitetura e facilita o atendimento a regulamentações específicas.
