Instâncias P5en.48xl chegam ao SageMaker Notebook Instances
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 P5en no SageMaker Notebook Instances. Trata-se de uma atualização relevante para equipes que trabalham com cargas de trabalho intensivas em computação, como treinamento de modelos de aprendizado profundo, IA generativa, processamento de dados em tempo real e aplicações de Computação de Alto Desempenho (HPC).
O que há de novo nas P5en
As instâncias P5en.48xl são equipadas com 8 GPUs H200, que representam um salto considerável em relação às GPUs H100 presentes nas instâncias P5 anteriores:
1,7x mais memória de GPU em comparação com as H100
1,4x mais largura de banda de memória de GPU em relação às H100
Além das GPUs, as P5en combinam o poder das H200 com processadores Intel Xeon Scalable de 4ª Geração customizados de alto desempenho. Essa combinação habilita o uso de PCIe Gen5 entre CPU e GPU, o que entrega até 4x mais largura de banda nessa comunicação — impactando diretamente a performance de treinamento e inferência de IA.
Melhoria em rede e comunicações distribuídas
Outro destaque das P5en é a conectividade de rede. Essas instâncias contam com até 3.200 Gbps usando a terceira geração do EFA (Elastic Fabric Adapter) com Nitro v5. Na prática, isso representa uma redução de até 35% na latência em comparação com as instâncias P5, que utilizavam a geração anterior de EFA e Nitro.
Essa melhoria é especialmente relevante para cargas de trabalho de treinamento distribuído, onde a comunicação coletiva entre nós é um gargalo crítico de performance.
Disponibilidade por região
As instâncias EC2 P5en.48xl no SageMaker Notebook Instances estão disponíveis nas seguintes regiões da AWS:
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 P6-B200 na região US East (N. Virginia) para uso com o SageMaker Notebook Instances. Essa expansão regional representa um passo importante para equipes que trabalham com treinamento e ajuste fino de modelos de inteligência artificial de grande porte diretamente no ambiente gerenciado da AWS.
Hardware por trás das instâncias P6-B200
As instâncias P6-B200 são equipadas com 8 GPUs NVIDIA Blackwell e 1.440 GB de memória de GPU de alta largura de banda, além de processadores Intel Xeon de 5ª geração (codinome Emerald Rapids). Esse conjunto de hardware entrega até 2x mais desempenho em treinamento de IA quando comparado às instâncias P5en — o que representa um salto considerável para cargas de trabalho intensivas.
Para que servem essas instâncias
O foco principal das P6-B200 é o desenvolvimento interativo e o ajuste fino de grandes modelos de fundação, incluindo:
LLMs — Modelos de Linguagem de Grande Escala (Large Language Models)
Modelos de mistura de especialistas (mixture of experts)
Modelos de raciocínio multimodal
Com esse poder computacional disponível diretamente nos notebooks gerenciados, equipes de ciência de dados e engenharia de ML conseguem experimentar com modelos maiores sem precisar provisionar infraestrutura separada.
Ambientes de desenvolvimento suportados
As instâncias P6-B200 funcionam nos ambientes JupyterLab e CodeEditor dentro do SageMaker, permitindo experimentação ágil com modelos generativos voltados para aplicações como:
Copilotos corporativos (enterprise copilots)
Geração de conteúdo em texto, imagens e vídeo
Como começar
Para quem quiser configurar e explorar esses recursos, a AWS disponibiliza guias para desenvolvedores cobrindo tanto o JupyterLab quanto o CodeEditor no contexto do SageMaker Studio e das instâncias de notebook do SageMaker. A documentação oficial é o ponto de partida recomendado para entender as etapas de configuração e os requisitos de cada ambiente.
A AWS anunciou que o Amazon EMR agora oferece suporte ao Apache Spark 4.0.2 em disponibilidade geral, contemplando os três modelos de implantação do serviço. A novidade traz um conjunto relevante de melhorias para quem trabalha com pipelines de dados, controle de acesso e aplicações em tempo real.
Principais capacidades do Spark 4.0.2 no EMR
Pipelines de dados com ANSI SQL
Uma das mudanças mais práticas é o suporte nativo ao ANSI SQL padrão, o que torna a engenharia de dados acessível a um público mais amplo. Com isso, não é mais necessário aprender a sintaxe específica do Spark para construir e manter pipelines — quem já conhece SQL consegue trabalhar de forma produtiva desde o início.
Suporte a dados semiestruturados com VARIANT
O Spark 4.0.2 introduz suporte nativo a JSON e outros dados semiestruturados por meio dos tipos de dados VARIANT. Isso oferece mais flexibilidade para lidar com formatos de dados variados, sem a necessidade de transformações complexas antes do processamento.
Controle de acesso granular (FGAC)
O Controle de Acesso Refinado (FGAC — Fine-Grained Access Control) agora pode ser aplicado tanto em operações de leitura quanto de escrita nas tabelas registradas no AWS Lake Formation, dentro dos jobs do Apache Spark. Isso permite definir permissões no nível de linha ou coluna, aumentando a precisão no controle de quem acessa o quê.
Apache Iceberg v3 para governança e conformidade
O suporte ao formato de tabela Apache Iceberg v3 complementa as capacidades de segurança ao oferecer garantias de transação mais robustas e rastreamento de linhagem de dados. O resultado são trilhas de auditoria adequadas para atender a exigências regulatórias e fortalecer os frameworks de conformidade e governança.
Streaming aprimorado para aplicações em tempo real
Os controles de streaming foram aprimorados para simplificar o gerenciamento de operações stateful complexas e melhorar o monitoramento. Isso permite colocar em produção aplicações em tempo real com mais agilidade — casos de uso como detecção de fraudes, personalização e outros cenários sensíveis ao tempo são diretamente beneficiados.
Disponibilidade e como começar
O Apache Spark 4.0.2 está disponível em todas as regiões onde o Amazon EMR já opera. Para quem está migrando a partir de uma versão anterior, a AWS disponibiliza o agente de atualização do Apache Spark, uma ferramenta que acelera o processo de upgrade de aplicações EMR existentes.
Para criar uma nova aplicação EMR com Spark 4.0.2, basta acessar o Console de Gerenciamento da AWS e seguir o fluxo padrão de criação.
A AWS anunciou uma expansão no suporte do Amazon Bedrock ao AWS Service Quotas, o serviço centralizado de gerenciamento de cotas da plataforma. A partir de agora, os clientes conseguem visualizar as cotas de inferência do endpoint bedrock-mantle diretamente pelo console de Service Quotas — da mesma forma que já faziam com o endpoint bedrock-runtime e outros serviços da AWS.
Na prática, isso significa que equipes de engenharia e arquitetura ganham uma visão clara e padronizada dos limites que se aplicam às suas cargas de trabalho no Bedrock, sem precisar consultar documentação separada ou abrir chamados para descobrir qual é o teto de requisições disponível.
O que é o endpoint bedrock-mantle
O bedrock-mantle é o endpoint do Amazon Bedrock que oferece compatibilidade com três APIs amplamente utilizadas no mercado de Inteligência Artificial (IA) generativa:
OpenAI Responses API
OpenAI Chat Completions API
Anthropic Messages API
Essa compatibilidade permite que times que já possuem aplicações construídas sobre OpenAI ou Anthropic migrem para o Amazon Bedrock com mudanças mínimas no código. É uma porta de entrada direta para quem quer aproveitar a infraestrutura gerenciada da AWS sem reescrever integrações do zero.
O que ficou visível com esta atualização
Com a expansão do suporte a Service Quotas, o endpoint bedrock-mantle passa a expor, por modelo, as seguintes cotas:
Tokens de entrada por minuto (input-tokens-per-minute)
Tokens de saída por minuto (output-tokens-per-minute)
Essa granularidade por modelo é especialmente útil para equipes que trabalham com múltiplos modelos de fundação simultaneamente e precisam planejar a capacidade de cada um de forma independente.
Como acessar as cotas no console
O acesso é simples e segue o fluxo padrão do AWS Service Quotas:
Abra o console do AWS Service Quotas
Selecione Amazon Bedrock
Pesquise por “Bedrock Mantle” para visualizar as cotas disponíveis
Para solicitar aumento de qualquer uma dessas cotas, basta seguir o processo padrão de aumento de limites do Amazon Bedrock.
Disponibilidade por região
O suporte a Service Quotas para o endpoint bedrock-mantle está disponível em todas as regiões da AWS onde o endpoint é oferecido:
Para o público brasileiro, vale destacar a presença da região de São Paulo, o que garante baixa latência para aplicações hospedadas localmente.
Por que isso importa
Ter visibilidade de cotas de forma proativa é fundamental para quem opera em escala de produção. Sem esse tipo de informação, equipes costumam descobrir os limites apenas quando os erros começam a aparecer — o que pode significar interrupções inesperadas em aplicações críticas. Com essa atualização, o Amazon Bedrock se alinha ao padrão já consolidado de outros serviços da AWS, tornando o planejamento de capacidade mais previsível e menos reativo.
Suporte a instâncias P5.4xl no SageMaker Notebook Instances
A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 P5.4xl no SageMaker Notebook Instances. Essa novidade coloca poder computacional de alto nível diretamente nas mãos de quem trabalha com aprendizado profundo (DL — Deep Learning) e computação de alta performance (HPC — High Performance Computing) dentro do ambiente de notebooks gerenciados da AWS.
O que são as instâncias P5.4xl?
As instâncias Amazon EC2 P5.4xl são equipadas com GPUs NVIDIA H100 Tensor Core, consideradas referência de mercado para cargas de trabalho intensivas em IA. De acordo com a AWS, elas entregam até 4x mais velocidade na resolução de problemas em comparação com instâncias EC2 baseadas em GPU da geração anterior, além de uma redução de até 40% no custo de treinamento de modelos de aprendizado de máquina (ML — Machine Learning).
Para quais aplicações são indicadas?
As instâncias P5 são indicadas para treinar e implantar modelos complexos, como Grandes Modelos de Linguagem (LLMs — Large Language Models) e modelos de difusão que alimentam aplicações de IA generativa. Entre os casos de uso destacados pela AWS estão:
Resposta a perguntas (question answering)
Geração de código
Geração de vídeo e imagem
Reconhecimento de fala (speech recognition)
Disponibilidade por região
As instâncias Amazon EC2 P5.4xl já estão disponíveis no SageMaker Notebook Instances nas seguintes regiões da AWS:
US East (N. Virginia e Ohio)
US West (Oregon)
Asia Pacific (Mumbai, Tokyo e Jakarta)
South America (São Paulo)
A inclusão da região de São Paulo é especialmente relevante para equipes e empresas brasileiras que precisam manter dados e processamento dentro do território nacional ou em conformidade com requisitos de latência e residência de dados.
A Amazon Web Services (AWS) mantém um time global especializado em resposta a incidentes de segurança chamado AWS CIRT — sigla para Customer Incident Response Team (Equipe de Resposta a Incidentes de Clientes). Esse time opera 24 horas por dia, 7 dias por semana, e é composto por engenheiros de segurança que atuam diretamente em eventos ativos nos ambientes dos clientes.
É importante entender o escopo de atuação do AWS CIRT dentro do Modelo de Responsabilidade Compartilhada da AWS: o time foca no lado do cliente — ou seja, na segurança dentro da nuvem, não na infraestrutura física gerenciada pela própria AWS. Quando um cliente enfrenta acesso não autorizado, exfiltração de dados ou ransomware em seu ambiente AWS, é exatamente aí que o CIRT entra em ação.
Como acionar o suporte em caso de incidente ativo
Se você está passando por um evento de segurança ativo agora, o caminho mais direto é abrir um chamado de suporte. Veja como fazer isso corretamente:
Deixe claro na descrição do chamado que se trata de um incidente de segurança urgente.
Abrir o chamado a partir da conta comprometida permite que a AWS confirme a titularidade da conta e gere um número de acompanhamento. Se você tiver um time de conta (TAM, Account Manager ou Solutions Architect), pode acionar essa equipe para iniciar uma escalada. E caso tenha perdido o acesso à sua conta, ainda é possível enviar uma solicitação de assistência por outro canal.
O que o AWS CIRT faz durante um engajamento
Durante um atendimento, o AWS CIRT concentra sua análise nos logs de serviços AWS e no plano de controle da nuvem. As principais fontes utilizadas são AWS CloudTrail, Amazon VPC Flow Logs e findings do Amazon GuardDuty. A partir dessas fontes, o time realiza triagem, análise e contenção do incidente, além de oferecer recomendações para evitar recorrências.
Vale destacar um ponto importante: para investigações que vão além do plano de controle AWS — como análise de sistema operacional, memória ou revisão de código de aplicação — a recomendação é complementar o suporte do CIRT com um parceiro especializado da AWS em forense digital e resposta a incidentes (DFIR).
Catálogo de Técnicas de Ameaças para AWS (TTC)
Um dos recursos mais valiosos desenvolvidos pelo AWS CIRT é o Threat Technique Catalog for AWS (TTC) — Catálogo de Técnicas de Ameaças para AWS. O TTC nasceu como uma referência interna: o time precisava registrar e compartilhar os padrões que se repetiam entre os engajamentos, evitando que a mesma análise fosse refeita do zero a cada novo caso. Com o tempo, ficou evidente que esse conhecimento seria valioso para todos os clientes, e o catálogo foi tornado público.
O TTC é baseado na MITRE ATT&CK Cloud Matrix e documenta táticas, técnicas e procedimentos (TTPs) de agentes de ameaça específicos para ambientes AWS, com orientações de detecção e mitigação para cada entrada. É possível filtrar por serviços AWS presentes no seu ambiente para focar no que é mais relevante para a sua realidade. As descobertas do TTC também alimentam a lógica de detecção de serviços como o Amazon GuardDuty, fortalecendo as proteções automatizadas dos clientes.
Ferramentas open source disponibilizadas pelo CIRT
Além do catálogo de ameaças, o AWS CIRT abriu o código de diversas ferramentas desenvolvidas internamente para resolver problemas recorrentes nos engajamentos. Essas ferramentas complementam — e não substituem — o conjunto de segurança já existente no seu ambiente. Para uma visão abrangente de como estruturar um programa de resposta a incidentes, o ponto de partida recomendado é o Guia de Resposta a Incidentes de Segurança da AWS.
AWS Customer Playbook Framework: frameworks de resposta baseados nas lições aprendidas pelo CIRT em eventos reais de segurança.
AWS CloudSaga: ferramenta para testar controles e alertas de segurança no ambiente AWS, simulando eventos baseados em cenários reais observados pelo CIRT.
O AWS CIRT também mantém cinco workshops públicos, atualizados regularmente para simular eventos de segurança atuais. Os temas cobertos são: uso não autorizado de credenciais IAM, ransomware no Amazon S3, cryptomining, SSRF no IMDSv1 e ferramentas de preparação para resposta a incidentes.
Para participar, basta ter uma conta AWS e conexão com a internet. Os workshops são construídos com base nos mesmos cenários que o time usa internamente para treinamento — a ideia é tornar esse aprendizado acessível para qualquer profissional que queira se preparar melhor para resposta a incidentes na nuvem.
Como entrar em contato com o AWS CIRT
Qualquer cliente AWS pode acionar o CIRT por meio de um chamado de suporte, independentemente do plano contratado. Clientes que possuem um time de conta dedicado também podem iniciar uma escalada diretamente por esse canal. Para clientes com Enterprise Support ou Unified Operations, há ainda a opção de contratar o AWS Security Incident Response, um serviço gerenciado voltado para triagem e resposta a eventos de segurança.
Para feedbacks ou dúvidas, o CIRT pode ser contactado pelo e-mail aws-cirt@amazon.com. Por fim, recomenda-se também assinar os AWS Security Bulletins via feed RSS para receber notificações sobre eventos de segurança nos serviços AWS.
A AWS anunciou a expansão do Amazon GuardDuty Malware Protection for AWS Backup com suporte a backups contínuos do Amazon S3. Com essa novidade, equipes de segurança e operações podem escanear backups contínuos do S3 em busca de malware e identificar, ao longo de toda a linha do tempo de backup, quais pontos estão limpos e seguros para uma eventual recuperação.
O que muda na prática
Antes dessa atualização, a proteção contra malware do GuardDuty para o AWS Backup não alcançava os backups contínuos do S3 — um tipo de backup que captura alterações de forma incremental e permite restaurar dados para qualquer ponto no tempo. Agora, essa lacuna foi preenchida.
Com o novo suporte, é possível:
Habilitar varreduras completas ou incrementais de malware para backups contínuos do S3 diretamente dentro do plano de backup;
Executar varreduras sob demanda até qualquer ponto de restauração disponível;
Consultar o status da varredura em qualquer ponto da linha do tempo do backup contínuo por meio da nova API GetPITRMalwareScanResults — o que permite verificar se um determinado momento de recuperação está livre de ameaças antes de iniciar a restauração.
Por que isso importa
Backups contínuos são amplamente usados por equipes que precisam de baixa tolerância à perda de dados. O problema é que, sem verificação de integridade contra malware, um backup contínuo pode estar preservando arquivos comprometidos — e uma restauração a partir desse ponto poderia reintroduzir a ameaça no ambiente. Com essa integração, é possível garantir que o ponto de restauração escolhido é realmente seguro antes de acionar qualquer processo de recuperação.
Disponibilidade
O suporte a backups contínuos do S3 está disponível em todas as regiões da AWS onde o Amazon GuardDuty Malware Protection for AWS Backup já era suportado. Para começar a usar, basta acessar o console do AWS Backup, ou utilizar a API ou a Interface de Linha de Comando (CLI). Para mais detalhes técnicos, a AWS disponibiliza a documentação do AWS Backup e a documentação do Amazon GuardDuty Malware Protection.
Da prova de conceito para produção: o desafio real dos agentes de IA
A Inteligência Artificial (IA) generativa evoluiu rapidamente — e com essa evolução veio um problema prático: como levar sistemas de agentes de IA do laboratório para ambientes de produção confiáveis, escaláveis e com desempenho previsível? É exatamente esse cenário que a AWS aborda em um novo tutorial técnico, demonstrando como construir orquestrações multi-agente serverless de alto desempenho na nuvem AWS.
Construir agentes de IA de alta performance exige mais do que modelos poderosos. É preciso garantir latência consistente, preservar contexto entre interações e ter visibilidade profunda sobre como os agentes se comportam em produção. A solução apresentada pela AWS combina LangGraph Agents como orquestradores com o Amazon Bedrock AgentCore Memory e o Amazon Bedrock AgentCore Observability para endereçar exatamente esses desafios.
A base serverless: Lambda e Step Functions
A abordagem proposta para construir orquestrações multi-agente serverless e escaláveis combina dois serviços fundamentais da AWS: o AWS Lambda e o AWS Step Functions. Juntos, esses serviços permitem que desenvolvedores construam agentes LangGraph que escalam automaticamente, respondem a eventos em tempo real e eliminam a necessidade de gerenciar infraestrutura.
Essa combinação é especialmente adequada para cargas de trabalho de agentes que são dinâmicas e com picos imprevisíveis. Ao unir os dois serviços, é possível orquestrar fluxos de trabalho complexos com múltiplas ferramentas, gerenciamento de estado durável, mecanismos de retry e controle granular de custos.
O modelo de execução baseado em grafos explícitos do LangGraph habilita coordenação determinística, paralelismo e roteamento condicional entre agentes — tornando fluxos de trabalho multi-agente complexos mais fáceis de compreender e depurar. Ao separar a lógica de orquestração do comportamento individual dos agentes, é possível adicionar, remover ou evoluir agentes especializados de forma independente, mantendo um caminho de execução claro e auditável.
Visão geral da solução: revisão de campanhas de marketing
O sistema demonstrado é um revisor de campanhas de marketing com múltiplos agentes de IA generativa. A ideia é orquestrar revisões humanas usando diversas personas, garantindo que as campanhas ressoem de forma autêntica com os públicos-alvo e ao mesmo tempo mantenham alinhamento legal e padrões de marca.
A solução é composta por três agentes de IA especializados que analisam a campanha em paralelo:
Agente de revisão de personas: analisa o conteúdo sob perspectivas demográficas diversas e fornece pontuações de ressonância;
Agente validador: verifica o alinhamento legal e a aderência às diretrizes de marca;
Agente finalizador: sintetiza os feedbacks em recomendações práticas e acionáveis.
Os usuários fazem upload de documentos de campanha por meio de um frontend em React, que também consulta os resultados periodicamente e os exibe conforme ficam disponíveis.
Como o LangGraph orquestra os agentes
O LangGraph é utilizado para implementar tanto o orquestrador quanto os agentes especializados, modelando o sistema como um grafo de execução com estado. Cada nó representa uma função de agente discreta — revisão de persona, validação de conformidade e síntese de feedback — e as arestas definem o fluxo de controle entre essas etapas.
O orquestrador é implementado como o grafo supervisor, responsável por rotear a execução, disparar ramificações paralelas para os agentes especializados e coletar suas saídas para agregação final. O orquestrador LangGraph e os agentes especializados são empacotados juntos em um contêiner Docker.
O AWS Lambda é utilizado como ambiente de execução serverless gerenciado, permitindo que os agentes escalem automaticamente. As interfaces REST do agente orquestrador são expostas via Amazon API Gateway.
Observabilidade com AgentCore
A implementação utiliza o AgentCore Observability para fornecer visualizações detalhadas de cada etapa do fluxo de trabalho dos agentes. Com ele, desenvolvedores conseguem inspecionar caminhos de execução, auditar saídas intermediárias e identificar gargalos de desempenho.
Dentro do AgentCore Observability, há visibilidade em tempo real no Amazon CloudWatch com dashboards de desempenho operacional e telemetria para métricas como traces, contagem de sessões, latência, duração, uso de tokens e taxas de erro.
Memória compartilhada com AgentCore Memory
O AgentCore Memory é utilizado para dois casos de uso principais: memória compartilhada entre múltiplos agentes (fornecendo contexto e memória compartilhada entre execuções independentes) e suporte a conversas com múltiplos turnos. Essa implementação oferece suporte nativo para armazenar estado e histórico conversacional, o que permite estendê-la para criar uma interface de linguagem natural com um assistente de IA.
Pré-requisitos
Antes de implantar a solução, é necessário cumprir os seguintes pré-requisitos:
Salve os seguintes valores: ApiEndpoint (URL da API), CampaignOrchestratorApi (URL da API do agente), CloudFrontURL (URL do frontend) e FrontendBucket (bucket S3 do frontend).
Abra a URL no navegador para acessar a aplicação. Utilize o arquivo campaign_brief.md como documento de campanha de exemplo e faça o upload no painel esquerdo. O resultado da revisão pela orquestração multi-agente será exibido no painel direito. Para visualizar cada etapa do fluxo de trabalho dos agentes em detalhes, acesse o console do Bedrock AgentCore Observability e selecione o seu agente.
Limpeza dos recursos
Para evitar cobranças recorrentes após testar a solução, é necessário limpar os recursos criados:
A combinação entre LangGraph, Amazon Bedrock AgentCore e serviços serverless da AWS forma um padrão arquitetural repetível para construir agentes de IA de nível empresarial. O modelo de execução em grafo do LangGraph garante controle de fluxo determinístico, enquanto o AWS Lambda oferece escalabilidade automática e sobrecarga operacional mínima.
O AgentCore Memory e o AgentCore Observability resolvem dois dos desafios mais comuns em implantações reais de agentes: gerenciamento de estado e visibilidade. Juntos, fornecem contexto durável e compartilhado entre execuções de agentes e visibilidade profunda sobre comportamento, desempenho e custo.
Seja para sistemas de revisão de campanhas, assistentes digitais ou outros fluxos de raciocínio multi-agente, essa abordagem permite desacoplar orquestração de execução, escalar elasticamente com a demanda e manter total transparência sobre como os agentes raciocinam e interagem — viabilizando a transição de protótipos experimentais para sistemas de IA generativa confiáveis e escaláveis em produção.
Quem trabalha com operações em nuvem conhece bem o ciclo: alarmes do Amazon CloudWatch disparando, erros acumulando no AWS Lambda sem que ninguém perceba, e degradação de performance no Amazon Elastic Compute Cloud (Amazon EC2) que só vira problema quando o cliente liga reclamando. O time passa o dia alternando entre dashboards, triando alertas e investigando incidentes que já impactaram usuários — e o resultado é engenheiro de plantão esgotado, débito técnico crescendo e metas de Acordo de Nível de Serviço (SLA) sendo perdidas.
A raiz do problema é estrutural: as ferramentas de monitoramento atuais exigem que alguém esteja constantemente consultando, analisando e decidindo o que merece atenção. É um modelo que não escala. É nesse contexto que a AWS apresentou o AgentWatch.
O que são agentes ambientes?
Agentes ambientes representam uma mudança de paradigma em relação aos sistemas de IA tradicionais. Em vez de aguardar uma consulta direta, esses agentes escutam fluxos de eventos continuamente, respondem de forma dinâmica e processam múltiplas tarefas em paralelo — tudo isso reduzindo a carga operacional sobre as pessoas. Eles monitoram sem interrupção, mas envolvem humanos apenas nos momentos em que o julgamento humano é realmente necessário.
Para infraestrutura AWS, isso significa que um agente ambiente pode acompanhar recursos continuamente, identificar tendências e entregar inteligência acionável sem que a equipe precise abrir um dashboard manualmente ou vasculhar logs.
Apresentando o AgentWatch
O AgentWatch é um agente de monitoramento ambiente construído sobre o Modelo de Linguagem de Grande Escala (LLM) do Amazon Bedrock e implantado usando o Amazon Bedrock AgentCoreRuntime — um ambiente de hospedagem serverless e seguro, criado especificamente para executar agentes de IA em escala. Com o AgentCore Runtime, agentes são disponibilizados como endpoints HTTP que podem ser chamados programaticamente, enquanto autenticação, escalabilidade e gerenciamento de infraestrutura são tratados automaticamente.
A solução implementa um modelo híbrido: algumas tarefas são totalmente autônomas (como monitorar utilização de recursos e fornecer informações de baixo risco), enquanto outras exigem aprovação humana, como analisar causas de alarmes e implementar correções. O Slack funciona como interface principal, onde o agente posta relatórios e onde a equipe pode interagir com ele sob demanda.
Três padrões de supervisão humana
Supervisão humana no ciclo de decisão (HITL — Human-in-the-Loop) é fundamental para construir agentes ambientes confiáveis. O AgentWatch implementa três padrões que equilibram autonomia com controle adequado:
Padrão de Notificação (Notify)
A cada 15 minutos (intervalo parametrizável via MonitoringSchedule rate, com opções de 5, 10, 30 ou 60 minutos), o AgentWatch gera um relatório de monitoramento cobrindo alarmes do CloudWatch, problemas críticos e saúde dos recursos em múltiplas contas AWS. O agente posta esses relatórios em um canal do Slack, mantendo a equipe informada sem exigir ação imediata. O intervalo de 15 minutos foi escolhido para equilibrar detecção ágil de problemas com uso razoável de API — rápido o suficiente para capturar issues, mas sem gerar fadiga de alertas.
Padrão de Questionamento (Question)
Quando o AgentWatch detecta um alarme crítico mas não tem clareza suficiente para decidir entre remediação automatizada ou escalada para um engenheiro de plantão, ele posta uma pergunta no Slack pedindo orientação. Esse comportamento imita o que um Engenheiro de Confiabilidade de Site (SRE) faria ao consultar um administrador sênior antes de fazer mudanças significativas em sistemas de produção.
Padrão de Revisão (Review)
Para ações potencialmente impactantes — como modificar recursos AWS, ajustar políticas de escalabilidade ou alterar thresholds de alarmes — o agente apresenta a ação proposta no Slack junto com contexto e justificativa. A equipe pode aprovar a ação, rejeitá-la ou editar os parâmetros antes da execução.
Arquitetura e implementação
O ciclo de monitoramento do AgentWatch começa com o Amazon EventBridge disparando uma função AWS Lambda a cada 15 minutos via regra cron. Essa função Lambda autentica com o Amazon Cognito usando credenciais de cliente Autorização Aberta 2.0 (OAuth 2.0) para obter um token de acesso, e então chama o AgentCore Runtime com o prompt de monitoramento.
O AgentCore instancia um agente LangChain — framework para construir aplicações baseadas em modelos de linguagem — equipado com sete ferramentas especializadas de monitoramento para infraestrutura AWS. Essas ferramentas coletam sistematicamente dados de dashboards, grupos de logs, logs de serviços, padrões de erro, status de alarmes e métricas entre contas, proporcionando visibilidade abrangente do ambiente.
Após a coleta, o agente LangChain envia os dados agregados do CloudWatch para o modelo Claude Sonnet do Amazon Bedrock, que transforma as informações brutas de monitoramento em insights contextuais e legíveis por humanos. O resumo inteligente retorna pelo agente até o AgentCore Runtime, volta para a função Lambda, que formata a análise em blocos estruturados do Slack com seções organizadas para análise de logs e status de alarmes.
A infraestrutura de implantação tem três componentes principais:
Função Lambda: camada de orquestração que autentica com o Cognito, chama o endpoint do AgentCore Runtime e formata respostas para o Slack.
EventBridge: fornece invocação agendada via regra configurada para disparar a cada 15 minutos.
Amazon API Gateway: o Amazon API Gateway expõe a função Lambda como endpoint HTTP integrado ao app Slack via slash commands. Perguntas digitadas no Slack são roteadas para o API Gateway, que aciona o Lambda com a pergunta como prompt.
Essa arquitetura de duplo acionamento permite dois modos de operação: modo agendado, em que o agente roda autonomamente a cada 15 minutos postando relatórios proativos; e modo sob demanda, em que a equipe faz perguntas específicas via Slack e recebe respostas imediatas para troubleshooting interativo.
O trecho central do agente tem a seguinte estrutura:
No modo de monitoramento agendado, o AgentWatch gera e posta relatórios automaticamente a cada 15 minutos, entregando visibilidade contínua da saúde da infraestrutura AWS diretamente no canal do Slack da equipe — sem intervenção manual.
No modo sob demanda, a equipe usa slash commands do Slack para investigar situações específicas. Exemplos de consultas:
/ask What is the status of my CloudWatch alarms?
/ask Show me recent errors in my Lambda functions
/ask Analyze log patterns for the last hour
Casos de uso e benefícios
O AgentWatch entrega valor em múltiplos cenários operacionais. A solução identifica problemas potenciais antes que impactem usuários ao analisar continuamente métricas, logs e alarmes do CloudWatch em toda a infraestrutura AWS. Isso reduz a sobrecarga operacional — a equipe gasta menos tempo em tarefas rotineiras de monitoramento enquanto mantém visibilidade sobre a saúde dos sistemas.
A integração com Slack melhora a colaboração entre times de desenvolvimento e operações, suportando consultas em linguagem natural e discussões sobre problemas de infraestrutura. Para ambientes corporativos, o suporte multi-conta permite que grandes organizações monitorem infraestruturas AWS distribuídas a partir de um único agente centralizado.
Como começar
Para implantar o AgentWatch, é necessário ter uma conta AWS com permissões para CloudWatch, Lambda e EventBridge, um User Pool do Cognito configurado para autenticação OAuth 2.0 e um workspace do Slack com permissões para criar apps. Para desenvolvimento local e customizações, é necessário Python 3.11 ou superior.
Os comandos de configuração rápida são:
# Configurar o Provedor de Identidade
python idp_setup/setup_cognito.py
# Instalar a CLI mais recente do AgentCore
npm install -g @aws/agentcore
# Criar projeto AgentCore e trazer o código do agente existente
agentcore create --name AgentWatch --no-agent
agentcore add agent \
--name AgentWatch \
--type byo \
--code-location . \
--entrypoint ambient_agent.py \
--language Python
# Implantar no AgentCore Runtime
agentcore deploy
# Implantar infraestrutura
cd deployment
./deploy.sh
Após a execução do script de implantação, ele fornece a URL do webhook do Slack necessária para a configuração do app. O script automatiza todo o processo: configura o provedor de identidade (Cognito), implanta o agente no AgentCore Runtime e configura a função Lambda, a regra do EventBridge e o API Gateway. As instruções completas estão disponíveis no repositório GitHub.
Segurança e boas práticas
O AgentWatch implementa múltiplas camadas de segurança: OAuth 2.0 com Cognito para acesso seguro à API, assunção de papéis do Gerenciamento de Identidade e Acesso (IAM) para permissões granulares entre contas, e o AgentCore Runtime que adiciona capacidades de segurança e conformidade de nível corporativo. Os padrões HITL ajudam a prevenir ações autônomas inadequadas, e o registro de logs fornece trilhas de auditoria e capacidades de troubleshooting.
Extensões possíveis
A arquitetura de agente ambiente construída para monitoramento pode ser estendida para outros domínios operacionais:
Otimização de custos: adicionar ferramentas para analisar padrões de gastos e recomendar oportunidades de otimização.
Relatórios de conformidade: automatizar verificações de conformidade via AWS Config e AWS CloudTrail.
Análise de performance: aprimorar com monitoramento de performance de aplicações e recomendações de otimização.
Conclusão
O AgentWatch representa uma abordagem concreta para sair do ciclo reativo de monitoramento. Ao combinar operações autônomas com supervisão humana adequada, a solução realiza verificações de infraestrutura a cada 15 minutos, entrega relatórios acionáveis no Slack e responde a consultas em linguagem natural sobre o ambiente AWS — tudo isso mantendo a equipe informada e no controle.
A arquitetura usa os AWS Managed Services (AMS) e o Amazon Bedrock AgentCore Runtime para fornecer uma base escalável e segura para implantação de agentes ambientes. À medida que os agentes de IA se tornam mais sofisticados, arquiteturas como a do AgentWatch tendem a se tornar padrão para equipes que precisam operar com eficiência sem abrir mão do julgamento humano em decisões críticas de infraestrutura.
Para começar, acesse o AgentWatch no GitHub para instruções completas de implantação e detalhes de implementação.
Construir um aplicativo de inteligência artificial não deveria exigir um doutorado em aprendizado de máquina nem meses lidando com arquiteturas complexas. Mas é exatamente isso que acontece na prática quando você tenta orquestrar múltiplas chamadas de API, gerenciar o estado de uma conversa e criar agentes capazes de raciocinar de forma autônoma.
Ideias simples de IA acabam se transformando em projetos enormes, que demandam conhecimento especializado em processamento de linguagem natural e sistemas distribuídos. É nesse contexto que a AWS publicou um tutorial mostrando como o Strands Agents muda esse cenário — permitindo construir um assistente de pesquisa completamente funcional com apenas 30 linhas de código.
O que é o Strands Agents?
O Strands Agents é um framework open source que resolve diretamente os desafios do desenvolvimento de IA. Ele oferece uma forma direta de criar agentes inteligentes capazes de realizar tarefas como pesquisa, análise e geração de conteúdo, combinando o poder dos Modelos de Linguagem de Grande Escala (LLMs) com lógica personalizada e APIs via código Python.
A abordagem do framework é orientada pelo modelo: em vez de hardcoding complexo, ele usa LLMs para raciocínio e planejamento autônomos. Isso significa que você pode criar agentes com apenas um prompt e uma lista de ferramentas, enquanto o LLM cuida da lógica e do uso das ferramentas.
Entre os principais diferenciais do Strands Agents estão:
Arquitetura flexível: suporta desde agentes únicos até redes multi-agente e sistemas hierárquicos.
Integração via decorator @tool: permite conectar funções externas e APIs de forma simples.
Design agnóstico de modelo: funciona com diferentes provedores de LLM, incluindo Amazon Bedrock, Anthropic e OpenAI.
Integração nativa com AWS: conecta-se naturalmente com Amazon Bedrock e AWS Lambda.
Pronto para produção: equipes da AWS já utilizam o framework em serviços como Amazon Q e AWS Glue.
Licença Apache 2.0: open source com contribuições ativas da comunidade.
Respostas em streaming em tempo real: ideal para aplicações interativas que precisam de feedback imediato.
Além do Strands Agents, a AWS apresenta o Kiro, um Ambiente de Desenvolvimento Integrado (IDE) com IA que escreve código para que os desenvolvedores possam focar nas decisões. O Kiro possui um sistema de extensões chamado Kiro Powers, que empacota servidores MCP, arquivos de direcionamento e hooks em unidades reutilizáveis.
O Strands power, por exemplo, reúne busca na documentação do SDK, guias de introdução e padrões corretos de API para que o Kiro possa estruturar agentes com precisão. Com mais de 50 extensões curadas da AWS, parceiros e da comunidade — cobrindo design, implantação, segurança e observabilidade — a instalação é feita com um clique.
Pré-requisitos para começar
Antes de partir para o código, a AWS lista o que você precisa ter configurado:
Em seguida, é necessário anexar uma política inline de Gerenciamento de Identidade e Acesso (IAM) com escopo reduzido à função ou conjunto de permissões utilizado. Essa política concede apenas as permissões necessárias para o tutorial — invocar o modelo Claude Sonnet via Amazon Bedrock:
O ponto de partida é instalar o SDK do Strands Agents e o Streamlit no terminal do Kiro:
pip install strands-agents
pip install streamlit
Com isso, já é possível criar o primeiro agente em um arquivo Python chamado research.py:
from strands import Agent
# Create an agent with default settings
agent = Agent()
# Ask the agent a question
agent("Tell me about agentic AI")
Para executá-lo:
python -u research.py
Simples assim. Com essa base estabelecida, o próximo passo é evoluir para uma aplicação web com interface interativa.
Gerando o assistente completo com o Kiro
Aqui entra a vantagem do Kiro: usando linguagem natural, é possível descrever os requisitos e deixar o IDE gerar a implementação. O processo consiste em abrir o Kiro, criar um novo arquivo Python (por exemplo, research_assistant.py) e fornecer o seguinte prompt:
Create a Streamlit research assistant app using strands Agent library with these exact requirements:
1. App title: "Research Assistant" with subtitle "Enter a topic to get research analysis and recommendations"
2. Text input field with placeholder "e.g., renewable energy, artificial intelligence"
3. "Generate Research Report" button that when clicked:
- Shows spinner with "Researching and analyzing..." message
- Redirects stdout to prevent terminal output interference (import sys, os and use devnull)
- Creates Agent() instance
- Uses this exact prompt template:
"You are a research assistant. For the topic '{topic}':
1. Overview of the topic in about 50 words
2. Find recent 2 articles about {topic} in 20 words each
3. Things to know relevant to the topic and description as prerequisites in 20 words each
like if topic is agentic ai then prereq is machine learning and generative ai
4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each
5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
- Displays response using st.subheader(f"Research Report: {topic}") and st.write(response.message['content'][0]['text'])
- Restores stdout in finally block
- Shows warning if no topic entered
Use try/finally pattern for stdout redirection. Keep code minimal and functional.
O código gerado pelo Kiro é o seguinte:
import sys
import os
import streamlit as st
from strands import Agent
st.title("Research Assistant")
st.write("Enter a topic to get research analysis and recommendations")
topic = st.text_input("Research Topic", placeholder="e.g., renewable energy, artificial intelligence")
if st.button("Generate Research Report"):
if topic:
with st.spinner("Researching and analyzing..."):
old_stdout = sys.stdout
try:
sys.stdout = open(os.devnull, "w")
agent = Agent()
response = agent(
f"You are a research assistant. For the topic '{topic}': "
f"1. Overview of the topic in about 50 words "
f"2. Find recent 2 articles about {topic} in 20 words each "
f"3. Things to know relevant to the topic and description as prerequisites in 20 words each "
f"like if topic is agentic ai then prereq is machine learning and generative ai "
f"4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each "
f"5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
)
finally:
sys.stdout = old_stdout
st.subheader(f"Research Report: {topic}")
st.write(response.message["content"][0]["text"])
else:
st.warning("Please enter a topic to research.")
Observação importante: sem uma ferramenta de navegação web, o agente gera URLs a partir do seu conhecimento de treinamento. Esses links podem não refletir os artigos mais recentes. Para recuperação em tempo real, é necessário adicionar um servidor MCP apropriado como ferramenta.
Executando a aplicação
No terminal, navegue até o diretório onde o arquivo research_assistant.py foi salvo e execute:
streamlit run research_assistant.py
O Streamlit abrirá a interface no navegador. Basta inserir um tópico de interesse e clicar em “Generate Research Report” para receber o relatório de pesquisa.
Uso responsável de servidores MCP
O tutorial da AWS traz recomendações importantes sobre o uso de servidores MCP:
Fixe o servidor MCP em uma versão ou hash de commit específico (por exemplo, pip install "arxiv-mcp==X.Y.Z").
Revise o código-fonte antes de instalar.
Para casos de uso em produção, a recomendação é usar a recuperação nativa do Amazon Bedrock (Knowledge Bases/RAG).
Para implantações voltadas ao cliente ou entre organizações, passe servidores MCP de terceiros pelo processo de revisão jurídica e de segurança da sua organização.
Servidores MCP compartilham os privilégios do processo do agente, incluindo quaisquer credenciais AWS disponíveis. Trate-os como parte do seu perímetro de confiança.
A AWS reforça que o tutorial é um ponto de partida, e que antes de levar qualquer aplicação baseada nesse padrão para produção, é essencial considerar os seguintes pontos:
Valide a entrada do usuário: limite o tamanho do tópico e remova caracteres não imprimíveis antes de passar a string para o agente.
Ative o logging: habilite o registro de invocação de modelos no Amazon Bedrock e os eventos de dados do AWS CloudTrail para bedrock:InvokeModel e bedrock:Converse.
Controle de custos: configure um alarme de cota sob demanda no Amazon Bedrock e um limite de consultas por sessão para evitar esgotamento de custos.
Classifique dados persistidos: se armazenar histórico de conversas, classifique os dados e remova valores sensíveis antes de gravar.
Revise o modelo de responsabilidade compartilhada: consulte o Modelo de Responsabilidade Compartilhada da AWS para entender a divisão entre o que a AWS gerencia e o que é responsabilidade do cliente.
Além disso, o tutorial alerta que o streamlit run vincula ao endereço 127.0.0.1 por padrão, tornando a interface acessível apenas localmente. Não exponha a aplicação à rede local ou à internet sem adicionar autenticação, proteção contra CSRF e um limite de custo no Amazon Bedrock.
Conclusão
O tutorial da AWS demonstra como o Strands Agents, combinado com as capacidades de geração de código do Kiro, permite construir funcionalidades sofisticadas de IA com uma quantidade mínima de código. O framework reduz a complexidade do desenvolvimento de IA por meio de uma criação de agentes intuitiva, enquanto o Kiro aumenta a produtividade do desenvolvedor por meio de codificação assistida por IA.
As aplicações resultantes são ao mesmo tempo poderosas e fáceis de manter, com modificações personalizadas feitas rapidamente via engenharia de prompt. Para quem quer explorar mais sobre o Strands Agents, a AWS disponibilizou o artigo introdutório Apresentando o Strands Agents, um SDK de Agentes de IA Open Source.
