Novas Camadas de Proteção para Grupos de Auto Scaling
A AWS anunciou em janeiro de 2026 a introdução de novos mecanismos de proteção para o EC2 Auto Scaling, focando na prevenção de exclusões acidentais. Essas funcionalidades reforçam a segurança operacional e ajudam a manter a disponibilidade das aplicações.
Chave de Condição IAM para Controle de Exclusão Forçada
O primeiro mecanismo é a nova chave de condição de política autoscaling:ForceDelete. Essa chave funciona em conjunto com a ação DeleteAutoScalingGroup e permite controlar se o parâmetro ForceDelete pode ser utilizado durante a exclusão. Em outras palavras, ela determina se um grupo de Auto Scaling (ASG) pode ser removido enquanto ainda possui instâncias em execução.
Por meio de políticas IAM (Identity and Access Management), é possível restringir as permissões de exclusão usando essa chave de condição. Isso funciona como uma medida de segurança importante, evitando que exclusões acidentais removam grupos de Auto Scaling que ainda contêm instâncias ativas.
Proteção a Nível de Grupo
Além da chave de condição IAM, o EC2 Auto Scaling agora oferece proteção contra exclusão diretamente no nível do grupo. A nova configuração de proteção contra exclusão pode ser estabelecida tanto no momento da criação do grupo quanto em atualizações posteriores.
Esse recurso permite definir controles aprimorados com base na criticidade da sua carga de trabalho, oferecendo múltiplos níveis de proteção. Assim, é possível salvaguardar grupos críticos contra exclusões acidentais e garantir a continuidade das aplicações.
Defesa em Camadas contra Exclusões Indesejadas
A combinação da chave de condição autoscaling:ForceDelete com a proteção a nível de grupo cria uma defesa em múltiplas camadas. Dessa forma, você pode tanto restringir permissões IAM para operações de exclusão forçada quanto estabelecer controles aprimorados de proteção diretamente nos grupos de Auto Scaling críticos.
Disponibilidade e Próximos Passos
Os novos mecanismos estão disponíveis em todas as regiões da AWS Regions e em todas as regiões AWS GovCloud (US).
Certificação PCI PIN para AWS Payment Cryptography
A Amazon Web Services (AWS) finalizou com sucesso o processo de auditoria de conformidade conforme o padrão PCI PIN (Número de Identificação Pessoal da Indústria de Cartões de Pagamento) para seu serviço Payment Cryptography. Essa conquista representa um passo importante para organizações brasileiras que precisam processar pagamentos com cartão de forma segura e em conformidade com os requisitos regulatórios internacionais.
O serviço AWS Payment Cryptography permite que aplicações de processamento de pagamento utilizem módulos de segurança por hardware (HSMs) certificados como PCI PIN Transaction Security (PTS), totalmente gerenciados pela AWS com gerenciamento de chaves em conformidade com PCI PIN. Essa abordagem oferece maior flexibilidade para quem precisa implantar cargas de trabalho reguladas, reduzindo significativamente o esforço administrativo relacionado à conformidade.
Componentes principais do pacote de conformidade
O pacote de conformidade PCI PIN para AWS Payment Cryptography é composto por dois elementos essenciais:
Certificado de Conformidade (AOC)
O Certificado de Conformidade (Attestation of Compliance — AOC) demonstra que o AWS Payment Cryptography passou por validação bem-sucedida contra o padrão PCI PIN, sem nenhuma constatação de não-conformidade. Este documento valida que a infraestrutura e os processos de segurança atendem integralmente aos requisitos estabelecidos.
Responsabilidades na implementação
O Resumo de Responsabilidades PCI PIN fornece orientações claras para ajudar clientes a compreender suas próprias responsabilidades ao desenvolver e operar um ambiente altamente seguro para processamento de transações baseadas em PIN. Este documento é fundamental para que cada organização implemente adequadamente seus próprios controles.
Processo de avaliação e acesso aos relatórios
A AWS foi avaliada pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) independente. Os clientes podem acessar tanto o Certificado de Conformidade PCI PIN quanto o Resumo de Responsabilidades por meio do AWS Artifact, portal centralizado que reúne todos os documentos de conformidade relevantes.
Esta certificação é especialmente relevante para empresas brasileiras que operam em segmentos como fintech, varejo e serviços financeiros. A redução do overhead de conformidade permite que times de segurança dediquem seus esforços a iniciativas de inovação, em vez de gestar manualmente processos certificadores. Com a infraestrutura gerenciada e certificada pela AWS, as organizações podem focar em suas aplicações e processos de negócio, mantendo a segurança das transações financeiras como responsabilidade compartilhada claramente definida.
Escolhendo a Estratégia Certa para Gerenciar Segredos
Uma das perguntas mais comuns entre organizações que trabalham com a AWS diz respeito à centralização de segredos. Embora o debate frequentemente se concentre apenas no armazenamento centralizado, existem quatro dimensões importantes a considerar: criação, armazenamento, rotação e monitoramento de segredos. Cada uma dessas dimensões pode ser tratada de forma centralizada ou descentralizada, e a escolha tem implicações diretas na segurança, operação e escalabilidade da infraestrutura.
Não existe uma solução única que funcione para todas as organizações. A melhor estratégia depende da estrutura operacional, requisitos de segurança e capacidades técnicas de cada empresa. Neste artigo, exploramos os benefícios e desvantagens de cada abordagem.
Criação Centralizada de Segredos
Quando uma organização opta pela criação centralizada de segredos, o foco geralmente está em implementar práticas modernas de DevOps que automatizam e padronizam a implantação. Muitas empresas têm investido em plataformas internas de desenvolvedor, que utilizam o conceito de “caminhos de ouro” (golden paths) para permitir que desenvolvedores façam implantação em modelo de autoatendimento através de infraestrutura como código (IaC).
Essas plataformas oferecem templates pré-aprovados que implementam as melhores práticas da organização. Uma equipe de engenharia de plataforma central mantém esses caminhos, garantindo conformidade com padrões corporativos. Ferramentas como o AWS Service Catalog e projetos de código aberto como Backstage.io são exemplos de tecnologias que facilitam essa abordagem.
Um exemplo prático seria um caminho de ouro que padroniza a implantação de um microsserviço que acessa um banco de dados. Esse caminho poderia determinar que o serviço deve ser construído com o AWS Cloud Development Kit (AWS CDK), executado no Amazon Elastic Container Service (Amazon ECS), e que as credenciais de banco de dados sejam obtidas através do AWS Secrets Manager. A equipe de plataforma também pode incluir verificações automatizadas para garantir que a política de recurso do segredo apenas permite acesso ao papel (role) correto e que a criptografia utiliza chaves gerenciadas pelo cliente.
Nomenclatura e controle de acesso consistentes: Segredos criados centralmente podem seguir convenções de nomenclatura padronizadas baseadas em conta, workload, serviço ou classificação de dados. Isso facilita a implementação de padrões escaláveis como controle de acesso baseado em atributos (ABAC).
Verificações de privilégio mínimo em pipelines CI/CD: A criação de segredos dentro de pipelines IaC permite o uso de ferramentas como a AWS IAM Access Analyzer com a API check-no-new-access. Os pipelines podem ser templizados, permitindo que equipes individuais se beneficiem dos padrões organizacionais.
Colaboração entre engenharia de plataforma e segurança: Essa transição permite que equipes de segurança trabalhem em conjunto com engenharia de plataforma para incorporar segurança por padrão nos caminhos de ouro, em vez de implementá-la posteriormente.
Desvantagens da Criação Centralizada
Requer investimento significativo em tempo e recursos para construir e manter plataformas de desenvolvedor dedicadas.
É necessário manter bibliotecas de caminhos de ouro apropriados para os casos de uso da organização, o que pode ser inviável dependendo do tamanho.
Os caminhos de ouro precisam acompanhar novas features dos serviços subjacentes. Se um serviço recebe uma atualização importante, os desenvolvedores precisam esperar pela inclusão dessa feature nos templates existentes.
Criação Descentralizada de Segredos
Em um modelo descentralizado, as equipes de aplicação são donas dos templates IaC e mecanismos de implantação em suas próprias contas. Cada equipe opera de forma independente, o que pode dificultar a aplicação de padrões padronizados como código.
Velocidade: Desenvolvedores conseguem se mover rapidamente com maior autonomia, já que não dependem de uma função central para criar novos segredos.
Flexibilidade: As equipes ainda podem utilizar recursos como a API check-no-new-access, mas fica a critério delas implementar essas verificações em seus pipelines.
Desvantagens da Criação Descentralizada
Falta de padronização: Sem mecanismos centrais de criação templizada, fica mais difícil aplicar convenções consistentes de nomenclatura e tagging.
Inconsistência em controles de acesso: Políticas de recurso e controles de acesso podem variar significativamente entre equipes.
Maior carga nos desenvolvedores: Equipes precisam gerenciar uma maior parte da infraestrutura e dos pipelines de implantação por conta própria.
Armazenamento Centralizado de Segredos
Algumas organizações optam por manter todos os segredos em uma conta central, enquanto outras preferem armazenar segredos nas mesmas contas onde os workloads operam. A escolha dessa estratégia depende dos tradeoffs operacionais e de segurança envolvidos.
Monitoramento e observabilidade simplificados: Manter todos os segredos em uma única conta facilita o monitoramento centralizado, com uma equipe dedicada controlando o acesso a esses recursos sensíveis.
Desvantagens do Armazenamento Centralizado
Overhead operacional adicional: Ao compartilhar segredos entre contas, é necessário configurar políticas de recurso em cada segredo que será compartilhado.
Custo adicional do AWS KMS: Para compartilhar segredos entre contas, é obrigatório usar chaves gerenciadas pelo cliente do AWS Key Management Service (AWS KMS). Embora isso forneça um nível adicional de controle de acesso, isso aumentará os custos segundo a precificação do AWS KMS, além de exigir políticas adicionais de manutenção.
Concentração elevada de dados sensíveis: Centralizar segredos aumenta o potencial de impacto em caso de acesso indevido ou erro de configuração.
Limites de quota: Antes de optar por centralizar segredos, é importante revisar as quotas de serviço da AWS para garantir que a organização não atingirá limites em produção.
Segredos gerenciados por serviços: Serviços como o Amazon Relational Database Service (Amazon RDS) e Amazon Redshift gerenciam segredos automaticamente, armazenando-os na mesma conta do recurso. Para manter uma estratégia centralizada usando esses segredos gerenciados, seria necessário centralizar também os recursos.
Muitas organizações já utilizam serviços nativos da AWS como AWS Security Hub, IAM Access Analyzer, AWS Config e Amazon CloudWatch para obter observabilidade centralizada em ambientes multi-conta, sem necessidade de manter todos os segredos em um único local.
Armazenamento Descentralizado de Segredos
Na abordagem descentralizada, os segredos vivem nas mesmas contas que os workloads que precisam acessá-los, criando uma separação natural entre diferentes aplicações e equipes.
Limites de conta como segmentação natural: As contas AWS fornecem isolamento por padrão. Acessar segredos de outra conta não é possível automaticamente, exigindo aprovação explícita tanto da política de recurso na conta de origem quanto da política IAM na conta de destino. Políticas de controle de recurso podem impedir completamente o compartilhamento de segredos entre contas.
Flexibilidade na escolha de chaves KMS: Se segredos não são compartilhados entre contas, as organizações podem optar entre usar chaves gerenciadas pelo cliente ou chaves gerenciadas pela AWS para criptografia.
Delegação de gerenciamento de permissões: Quando segredos estão na mesma conta das aplicações que os consomem, os donos das aplicações podem definir permissões granulares nas políticas de recurso dos segredos.
Desvantagens do Armazenamento Descentralizado
Auditoria e monitoramento complexos: Ferramentas de monitoramento precisam operar entre múltiplas contas para apresentar uma visão consolidada de conformidade.
Workflows de remediação automática mais complexos: Controles de detecção podem alertar sobre misconfigurations ou riscos relacionados a segredos, como quando um segredo é compartilhado fora dos limites organizacionais. Esses workflows são mais complexos em ambientes multi-conta, embora a AWS ofereça soluções como Automated Security Response on AWS.
Rotação Centralizada de Segredos
Quando a rotação é centralizada, uma equipe central gerencia e mantém as funções do AWS Lambda responsáveis pela rotação de segredos, oferecendo bibliotecas reutilizáveis para diferentes cenários.
Reutilização de funções de rotação: Equipes de aplicação podem reutilizar funções comuns desenvolvidas pela equipe central para diferentes tipos de banco de dados e aplicações SaaS, sem precisar desenvolver suas próprias soluções customizadas.
Logs gerenciados centralmente: Os logs das funções de rotação podem ser armazenados e acessados a partir de um local único, facilitando investigações e auditorias.
Desvantagens da Rotação Centralizada
Cenários adicionais de acesso entre contas: Funções Lambda na conta central precisam de permissões para criar, atualizar, deletar e ler segredos nas contas das aplicações, aumentando o overhead operacional.
Limites de quota: Ao centralizar essa função em escala, é importante verificar as quotas de serviço do Lambda para evitar gargalos em produção.
Rotação Descentralizada de Segredos
A rotação descentralizada é a abordagem mais comum, onde as funções de rotação vivem na mesma conta que o segredo que gerenciam.
Templização com customização: Desenvolvedores podem reutilizar templates de rotação, mas adaptá-los conforme necessário para seus casos de uso específicos.
Sem acesso entre contas: A rotação acontece integralmente dentro de uma única conta, eliminando complexidades de acesso cross-account.
Desvantagens da Rotação Descentralizada
Acesso centralizado aos logs: É necessário fornecer acesso centralizado ou federado aos logs das funções de rotação distribuídas em diferentes contas. Por padrão, Lambda envia automaticamente logs para CloudWatch Logs, que oferece diferentes formas de centralizar logs, cada uma com seus tradeoffs específicos.
Auditoria e Monitoramento Centralizados
Independentemente do modelo escolhido para criação, armazenamento e rotação, é altamente recomendado centralizar auditoria e monitoramento em ambientes multi-conta. A AWS oferece capacidades robustas para isso através da AWS Security Hub, que se integra com AWS Organizations para centralizar:
Descobertas das melhores práticas de segurança fundamentais relacionadas ao Secrets Manager
Descobertas do IAM Access Analyzer sobre acesso externo aos secrets
Descobertas do AWS Config sobre configurações de Secrets Manager
Descobertas de comportamento anômalo do Amazon GuardDuty
Nesse modelo, funções centralizadas ganham visibilidade organizacional, enquanto equipes individuais conseguem visualizar sua própria postura em nível de conta sem precisar ver a organização inteira. Além disso, usar trilhas organizacionais do AWS CloudTrail permite enviar todas as chamadas de API do Secrets Manager para uma conta de administração delegada centralizada.
Para organizações que não requerem auditoria centralizada, é possível configurar o acesso de forma que equipes individuais determinem quais logs coletar, alertas configurar e verificações implementar relacionadas aos seus segredos.
Vantagens da Abordagem Descentralizada
Flexibilidade: Equipes de desenvolvimento têm liberdade para escolher ferramentas de monitoramento, auditoria e logging que melhor se ajustem às suas necessidades.
Menos dependências: Equipes não precisam depender de funções centralizadas para implementar alertas e monitoramento.
Desvantagens da Abordagem Descentralizada
Overhead operacional: Diferentes equipes podem acabar implementando soluções similares de forma redundante.
Dificuldade em investigações multi-conta: Quando logs e monitoramento estão descentralizados, investigações que afetam múltiplas contas se tornam mais complexas.
Combinando Abordagens: O Caso do Serviço Financeiro
A maioria das organizações, na prática, escolhe uma combinação dessas abordagens para atender suas necessidades específicas. Um exemplo seria uma empresa de serviços financeiros com uma equipe central de segurança operando centenas de contas AWS, com centenas de aplicações isoladas em nível de conta:
Centraliza a criação de segredos, aplicando padrões corporativos de nomenclatura, tagging e controle de acesso
Descentraliza o armazenamento, usando contas AWS como limite natural de acesso e delegando controle aos donos das aplicações
Descentraliza o gerenciamento de ciclo de vida, permitindo que donos das aplicações gerenciem suas próprias funções de rotação
Centraliza a auditoria, utilizando AWS Config, Security Hub e IAM Access Analyzer para dar visibilidade à equipe central de segurança enquanto mantém controle descentralizado
Conclusão
Não existe uma estratégia única de gestão de segredos que funcione para todas as organizações. A arquitetura ideal depende dos requisitos específicos de segurança, modelo operacional e capacidades técnicas de cada empresa.
Os pontos principais a considerar são:
Escolha sua arquitetura baseado nos requisitos específicos de sua organização
Use automação e infraestrutura como código para reforçar controles de segurança, independentemente da abordagem escolhida
Implemente capacidades robustas de monitoramento e auditoria através dos serviços AWS para manter visibilidade em seu ambiente
Para aprofundar seus conhecimentos sobre o AWS Secrets Manager, considere explorar os recursos adicionais disponibilizados pela AWS, incluindo guias de migração, melhores práticas e templates de referência que facilitam a implementação de soluções seguras e bem-estruturadas.
A AWS reafirma conformidade com os padrões europeus de segurança C5
A AWS completou com sucesso o ciclo de auditoria de 2025 do Catálogo de Critérios de Conformidade em Computação em Nuvem (C5), com 183 serviços cobertos pelo escopo de conformidade. Este resultado reforça o alinhamento contínuo da empresa com os requisitos de segurança estabelecidos para provedores de nuvem, oferecendo aos clientes europeus maior confiança ao executar aplicações em suas regiões.
O programa C5 é um esquema de certificação respaldado pelo governo alemão, desenvolvido pelo C5. Desde sua introdução em 2016, a AWS tem mantido conformidade com seus requisitos. O C5 auxilia organizações a demonstrar segurança operacional contra ameaças cibernéticas comuns ao utilizar serviços em nuvem.
Escopo da auditoria e novos serviços incorporados
Auditores independentes de terceiros avaliaram a AWS no período entre 1º de outubro de 2024 e 30 de setembro de 2025. O relatório de conformidade C5 detalha o status de alinhamento tanto para critérios básicos quanto adicionais do programa.
Cinco novos serviços foram adicionados ao escopo C5 da AWS neste ciclo:
O relatório de 2025 abrange as seguintes regiões da AWS: Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Milão), Europa (Paris), Europa (Estocolmo), Europa (Espanha), Europa (Zurique) e Ásia-Pacífico (Singapura).
Acessando o relatório de conformidade
Os clientes podem fazer download do relatório C5 completo através do AWS Artifact no Console de Gerenciamento da AWS, um portal de autoatendimento que oferece acesso sob demanda a relatórios de conformidade. Para quem está começando, a AWS disponibiliza um guia de início com AWS Artifact.
A segurança e conformidade na nuvem funcionam sob um modelo de responsabilidade compartilhada entre a AWS e seus clientes. Quando organizações transferem seus sistemas e dados para a nuvem, as responsabilidades de segurança são divididas entre o cliente e o provedor de nuvem. Compreender este modelo é essencial para implementar estratégias eficazes de proteção. Mais detalhes estão disponíveis no Modelo de Responsabilidade Compartilhada de Segurança da AWS.
Clientes com dúvidas ou feedback sobre o relatório C5 podem entrar em contato com seu time de contas da AWS. A equipe de conformidade da AWS também está disponível através da página de contato para consultas adicionais.
A Amazon Web Services (AWS) expandiu sua certificação GSMA Scheme de Acreditação de Segurança para Gerenciamento de Assinaturas (SAS-SM) para quatro novas regiões globais. Simultaneamente, duas regiões que já possuíam essa certificação passaram pelo processo de renovação.
As quatro regiões que receberam a certificação GSMA SAS-SM pela primeira vez são: US West (Oregon), Europe (Frankfurt), Asia Pacific (Tokyo) e Asia Pacific (Singapore). Além disso, a AWS renovou as certificações das regiões US East (Ohio) e Europe (Paris). Todas essas certificações têm escopo em Operações e Gerenciamento de Data Center (DCOM) e foram validadas por auditores independentes selecionados pela GSM Association (GSMA), com validade até outubro de 2026.
O Significado da Certificação SAS-SM para o Mercado
Rastreabilidade e Conformidade
A certificação GSMA SAS-SM representa um marco importante na conformidade de segurança para provedores de nuvem. O escopo DCOM (Operações e Gerenciamento de Data Center) garante que os ambientes foram avaliados segundo critérios rigorosos de segurança estabelecidos globalmente. O certificado de conformidade, que comprova que a AWS atende aos padrões GSMA, está disponível nos sites tanto da GSMA quanto da AWS.
Herança de Controles para ISVs
Desde que o US East (Ohio) obteve a certificação GSMA em setembro de 2021 e o Europe (Paris) em outubro de 2021, diversos fornecedores independentes de software (ISVs) têm se beneficiado da herança dos controles de conformidade SAS-SM DCOM da AWS. Isso permite que essas empresas construam serviços de gerenciamento de assinaturas ou eSIM (módulo de identidade de assinante incorporado) compatíveis com GSMA.
Para líderes de mercado consolidados, essa abordagem reduz a dívida técnica enquanto mantém a escalabilidade e o desempenho esperados pelos clientes. Para startups que inovam com soluções de eSIM, a oportunidade é ainda mais valiosa: podem acelerar seu tempo de entrada no mercado em vários meses em comparação com modelos de implantação locais.
A Revolução do eSIM no Mercado de Telecomunicações
Evolução Tecnológica
Até 2023, a transição de módulos de identidade de assinante físicos (SIMs) para eSIMs (módulos incorporados) era impulsionada principalmente por fabricantes de automóveis, wearables conectados à rede celular e dispositivos complementares como tablets. No entanto, o cenário está mudando rapidamente.
A GSMA promove as especificações SGP.31 e SGP.32, que padronizam protocolos e garantem compatibilidade e experiência de usuário consistente em todos os dispositivos eSIM. Com essas especificações, o escopo de aplicação do eSIM agora abrange smartphones, Internet das Coisas (IoT), casas inteligentes, IoT industrial e muito mais.
Demanda por Plataformas em Nuvem
Conforme mais fabricantes de dispositivos lançam modelos exclusivamente com eSIM, os clientes da AWS demandam soluções robustas e centradas em nuvem para gerenciamento de eSIM. Atualmente, mais de 400 operadoras de telecomunicações em todo o mundo oferecem suporte a serviços de eSIM para seus assinantes.
Hospedar plataformas de eSIM na nuvem permite que essas operadoras se integrem de forma eficiente com seus novos sistemas de suporte operacional (OSS) e sistemas de suporte comercial (BSS) baseados em nuvem. Essa integração é fundamental para modelos de operação modernos.
Cobertura Global e Resiliência
A expansão da AWS para certificar quatro novas regiões GSMA em novembro de 2025 demonstra seu compromisso contínuo com as expectativas elevadas estabelecidas para provedores de serviços em nuvem. Essa expansão também estende significativamente a cobertura global de infraestrutura certificada GSMA.
Com duas regiões certificadas GSMA em cada uma das três áreas geográficas principais — Estados Unidos, União Europeia e Ásia — os clientes podem agora construir soluções de eSIM com redundância geográfica. Essa abordagem melhora tanto a recuperação de desastres quanto a postura geral de resiliência dos sistemas.
A AWS mantém um canal aberto com sua comunidade de clientes e parceiros. Dúvidas técnicas ou feedback sobre conformidade GSMA podem ser direcionadas à equipe de conformidade por meio da página de contato.
A inteligência artificial agentica tornou-se fundamental para implantar aplicações de IA prontas para produção. Contudo, desenvolvedores enfrentam dificuldades significativas ao configurar manualmente a infraestrutura de agentes em múltiplos ambientes.
Aqui entra um conceito crítico: Infraestrutura como Código (IaC). Essa abordagem proporciona infraestrutura consistente, segura e escalável — exatamente o que sistemas de IA autônomos necessitam. A IaC minimiza erros de configuração manual através da automação de gerenciamento de recursos e templates declarativos, reduzindo o tempo de deployment de horas para minutos. Ao mesmo tempo, garante consistência de infraestrutura entre ambientes, prevenindo comportamentos impredizíveis dos agentes.
Adicionalmente, a IaC oferece controle de versão e capacidades de rollback para recuperação rápida de problemas — essencial para manter a disponibilidade de sistemas agenticos. Ela também viabiliza escalonamento automatizado e otimização de recursos através de templates parametrizados que se adaptam desde deployments leves em desenvolvimento até configurações de produção robustas.
Suporte Expandido para Infraestrutura como Código
Para aplicações agenticas que operam com intervenção humana mínima, a confiabilidade da IaC, validação automatizada de padrões de segurança e integração perfeita em workflows DevOps são essenciais para operações autônomas robustas.
Com essa visão, o Amazon Bedrock AgentCore passou a ser suportado por diversos frameworks de IaC, incluindo AWS Cloud Development Kit (AWS CDK), Terraform e AWS CloudFormation Templates. Essa integração leva o poder da IaC diretamente ao AgentCore, permitindo que desenvolvedores provisionar, configurar e gerenciar infraestrutura de agentes de IA de forma declarativa e reproduzível.
Caso de Uso Prático: Planejador de Atividades Baseado em Clima
O exemplo apresentado demonstra um planejador de atividades em tempo real que processa dados meteorológicos para fornecer recomendações personalizadas de atividades baseadas na localização do usuário e condições climáticas.
Componentes da Aplicação
A arquitetura integra múltiplos componentes especializados:
Coleta de dados meteorológicos em tempo real — A aplicação recupera condições climáticas atuais de fontes meteorológicas autorizadas, como weather.gov, capturando dados essenciais: leituras de temperatura, previsões de probabilidade de precipitação, medições de velocidade do vento e outras condições atmosféricas relevantes que influenciam a adequação de atividades ao ar livre.
Motor de análise meteorológica — O sistema processa dados brutos através de lógica customizada para avaliar a adequação de um dia para atividades ao ar livre baseado em múltiplos fatores:
Pontuação de conforto de temperatura — Atividades recebem pontuações reduzidas quando temperaturas caem abaixo de 50°F
Avaliação de risco de precipitação — Probabilidades de chuva acima de 30% disparam ajustes nas recomendações
Avaliação do impacto de condições de vento — Velocidades de vento acima de 15 mph afetam pontuações gerais de conforto e segurança
Sistema de recomendação personalizada — A aplicação processa resultados da análise meteorológica juntamente com preferências do usuário e consciência de localização para gerar sugestões de atividades adaptadas.
Implementação com AgentCore
A solução aproveita componentes especializados do AgentCore:
AgentCore Browser — Para navegação automatizada de dados meteorológicos de fontes como weather.gov
AgentCore Code Interpreter — Para executar código Python que processa dados meteorológicos, realiza cálculos e implementa algoritmos de pontuação
AgentCore Runtime — Para hospedar um agente que orquestra o fluxo da aplicação, gerencia pipelines de processamento de dados e coordena componentes
AgentCore Memory — Para armazenar preferências do usuário como memória de longo prazo
Deployment com CloudFormation
O processo de deployment segue uma sequência clara e estruturada:
Faça download do template do CloudFormation — Obtenha o arquivo End-to-End-Weather-Agent.yaml do repositório e salve localmente
Acesse o CloudFormation — Abra o serviço a partir do console AWS
Crie uma nova stack — Selecione “Criar stack” com recursos novos (padrão)
Escolha a fonte do template — Faça upload do arquivo que você baixou
Defina parâmetros — Insira o nome da stack e ajuste parâmetros conforme necessário
Revise e confirme — Analise a configuração e confirme as capacidades de IAM
Monitore o deployment — Acompanhe o progresso através da aba de eventos
Observabilidade e Monitoramento
O AgentCore Observability oferece vantagens significativas para confiabilidade operacional. Fornece qualidade e confiança através de visualizações detalhadas de workflows e monitoramento de desempenho em tempo real.
A integração com Amazon CloudWatch em dashboards powered oferece aceleração no time-to-market, reduzindo integração manual de dados de múltiplas fontes e permitindo ações corretivas baseadas em insights acionáveis.
O serviço oferece rastreabilidade fim-a-fim entre frameworks e modelos de fundação (FMs), capturando métricas críticas como uso de tokens e padrões de seleção de ferramentas. Suporta instrumentação automática para agentes hospedados em AgentCore Runtime e monitoramento configurável para agentes deployados em outros serviços.
Essa abordagem abrangente de observabilidade ajuda organizações a alcançar ciclos de desenvolvimento mais rápidos, comportamento de agentes mais confiável e visibilidade operacional aprimorada ao construir agentes de IA confiáveis em escala.
Adaptação para Seus Casos de Uso
O template do CloudFormation para o planejador de atividades meteorológicas foi projetado com componentes modulares que se adaptam facilmente a diversos contextos. Exemplos de customização incluem:
AgentCore Browser — Customizar para coletar informações de diferentes aplicações web, como websites financeiros para orientação de investimentos, feeds de mídia social para monitoramento de sentimento ou sites de e-commerce para rastreamento de preços
AgentCore Code Interpreter — Modificar algoritmos para processar lógica de negócio específica, como modelagem preditiva para previsão de vendas, avaliação de risco para seguros ou controle de qualidade para manufatura
AgentCore Memory — Ajustar para armazenar preferências do usuário ou contexto de negócio relevante, como perfis de cliente, níveis de inventário ou requisitos de projeto
Strands Agents — Reconfigurar tarefas para orquestrar workflows específicos do seu domínio, como otimização de cadeia de suprimentos, automação de atendimento ao cliente ou monitoramento de conformidade
Melhores Práticas para Deployments
Para implementações robustas e mantíveis, recomenda-se:
Arquitetura de componentes modulares — Estruture templates do CloudFormation com seções separadas para cada serviço AWS, facilitando manutenção e reutilização.
Design de template parametrizado — Utilize parâmetros do CloudFormation para elementos configuráveis, permitindo reutilização de templates entre ambientes. Isso facilita associar o mesmo container base com múltiplos deployments de agentes, apontar para diferentes configurações de build ou parametrizar o modelo de linguagem que alimenta seus agentes.
Monitoramento e observabilidade abrangentes — Ative logging do CloudWatch, métricas customizadas, rastreamento distribuído do AWS X-Ray e alertas entre componentes.
Controle de versão e integração CI/CD — Mantenha templates no GitHub com validação automatizada, testes abrangentes e AWS CloudFormation StackSets para deployments consistentes entre regiões. Consulte melhores práticas de CloudFormation para um conjunto mais completo de recomendações.
Limpeza de Recursos
Para evitar incurrir em cobranças futuras, delete os recursos utilizados nesta solução:
No console do Amazon S3, delete manualmente o conteúdo dentro do bucket criado para o deployment do template e então delete o bucket
No console do CloudFormation, escolha Stacks na navegação, selecione a stack principal e escolha Delete
Conclusão
A integração do Amazon Bedrock AgentCore com frameworks de Infraestrutura como Código representa um avanço significativo na simplificação do deployment de sistemas de IA autônomos. Os templates pré-configurados viabilizam deployment rápido de poderosos sistemas agenticos sem a complexidade de configuração manual de componentes.
Essa abordagem automatizada economiza tempo e facilita deployments consistentes e reproduzíveis, permitindo que organizações foquem em construir workflows de IA agentica que impulsionem crescimento de negócio.
Para explorar mais exemplos de Infraestrutura como Código, repositórios de amostra estão disponíveis para Terraform, CloudFormation e CDK.
A AWS expandiu a disponibilidade do Amazon Neptune Analytics para sete novas regiões geográficas. O serviço agora está acessível em US West (N. California), Asia Pacific (Seoul), Asia Pacific (Osaka), Asia Pacific (Hong Kong), Europe (Stockholm), Europe (Paris) e South America (São Paulo). Essa expansão permite que desenvolvedores e empresas em diferentes continentes criem e gerenciem gráficos do Neptune Analytics, executando análises avançadas de dados conectados com menor latência.
O que é Amazon Neptune
O Amazon Neptune é um banco de dados de grafos serverless projetado para trabalhar com dados conectados. Seu propósito principal é melhorar a precisão de aplicações de inteligência artificial, simultaneamente reduzindo a complexidade operacional e os custos associados à gestão de infraestrutura. O serviço escala automaticamente as cargas de trabalho de grafos, eliminando a necessidade de gerenciar capacidade de forma manual.
Benefícios para aplicações de IA
Ao modelar dados em formato de grafo, o Neptune captura contexto que melhora significativamente a precisão e a explicabilidade de aplicações de IA generativa. A AWS oferece integração completa com GraphRAG (Graph Retrieval-Augmented Generation) totalmente gerenciado através do Amazon Bedrock Knowledge Bases. O serviço também se integra com o Strands AI Agents SDK e com ferramentas populares de memória para agentes autônomos.
Capacidades analíticas
Uma das características mais destacadas do Neptune é sua capacidade de analisar dezenas de bilhões de relacionamentos em dados estruturados e não estruturados em questão de segundos. Essa velocidade de processamento permite extrair insights estratégicos rapidamente, algo essencial para organizações que precisam tomar decisões baseadas em dados complexos e altamente conectados.
A AWS posiciona o Neptune como o único banco de dados e mecanismo de análise que oferece o poder de dados conectados com as capacidades empresariais e o valor agregado dos serviços AWS.
A AWS anunciou o lançamento de 13 novas regras gerenciadas para o serviço AWS Config, ampliando as capacidades de conformidade e governança para ambientes em nuvem. Essas regras cobrem diferentes cenários de uso, desde validação de segurança até verificações operacionais e de durabilidade dos recursos.
Com essa expansão, os usuários agora conseguem pesquisar, descobrir, ativar e gerenciar essas novas regras diretamente pela interface do AWS Config. O grande diferencial é a possibilidade de implantar esses controles em toda a conta ou até mesmo em múltiplas contas da organização, facilitando a governança centralizada.
Principais capacidades das novas regras
Validação de conformidade em diferentes serviços
As 13 novas regras permitem avaliar a postura de segurança em diversos recursos AWS. Alguns exemplos incluem validações em Amazon Cognito User Pools, Amazon EBS Snapshots, AWS CloudFormation Stacks e outros serviços críticos da plataforma.
Cada regra foi desenhada para verificar configurações específicas que impactam a segurança, a disponibilidade e a conformidade regulatória dos ambientes.
Governança com Conformance Packs
Uma vantagem importante é a possibilidade de usar Conformance Packs — agrupamentos de regras que podem ser implantados em conta única ou em múltiplas contas da organização. Isso simplifica significativamente a governança multi-conta, permitindo padronização de políticas em toda a estrutura organizacional.
Lista de regras lançadas
As 13 novas regras gerenciadas disponibilizadas são:
Extensões de navegador personalizadas no AgentCore Browser
A AWS expandiu as capacidades do Amazon Bedrock AgentCore Browser com suporte a extensões personalizadas do Chrome. Este novo recurso permite que desenvolvedores corporativos, engenheiros de automação e organizações de diversos setores implementem funcionalidades especializadas de navegador em um ambiente seguro, indo além do que a automação padrão consegue fazer isoladamente.
Como funciona o novo recurso
O suporte a extensões personalizadas se baseia nos recursos já existentes de navegador seguro do AgentCore. O fluxo é direto: os usuários fazem upload de extensões compatíveis com Chrome para o Amazon S3 e o sistema as instala automaticamente durante as sessões do navegador. Essa abordagem garante que as extensões funcionem de forma integrada dentro do ambiente controlado do AgentCore Browser, sem comprometer a segurança.
Casos de uso práticos
O novo recurso abre possibilidades significativas para automação empresarial. Destacam-se:
Fluxos de autenticação customizados: Implementação de processos de autenticação específicos que exigem lógica não padrão
Testes automatizados avançados: Execução de cenários de teste que requerem funcionalidades além da automação de navegador convencional
Otimização de navegação: Melhorias em performance e experiência, como bloqueio de anúncios e outras otimizações
Integração de ferramentas de terceiros: Possibilidade de conectar ferramentas externas que funcionam como extensões de navegador, eliminando processos manuais
Disponibilidade geográfica
O suporte a extensões personalizadas está disponível em todos os nove Regiões da AWS onde o Amazon Bedrock AgentCore Browser já opera: US East (N. Virginia), US East (Ohio), US West (Oregon), Ásia Pacífico (Mumbai), Ásia Pacífico (Singapura), Ásia Pacífico (Sydney), Ásia Pacífico (Tóquio), Europa (Frankfurt) e Europa (Irlanda).
Próximos passos
Organizações interessadas em implementar extensões de navegador personalizadas no Amazon Bedrock AgentCore devem consultar a documentação do navegador para orientações técnicas detalhadas e práticas recomendadas.
Por que arquiteturas multi-agente estão transformando a inteligência artificial
Soluções que envolvem redes de agentes colaborando, coordenando e raciocinando juntos estão mudando a forma como organizações enfrentam desafios reais. Em ambientes corporativos complexos, gerenciar múltiplas fontes de dados, objetivos em constante mudança e diversas restrições operacionais é uma realidade. É justamente nesse contexto que as arquiteturas multi-agente se destacam.
Quando múltiplos agentes — cada um com suas ferramentas especializadas, memória ou perspectivas únicas — interagem e raciocinam coletivamente, as organizações desbloqueiam capacidades poderosas:
Escalabilidade: Frameworks multi-agente conseguem lidar com tarefas de crescente complexidade, distribuindo cargas de trabalho inteligentemente e se adaptando em tempo real.
Resiliência: Quando agentes trabalham em conjunto, falhas em um podem ser compensadas por outros, criando sistemas robustos e tolerantes a falhas.
Especialização: Agentes individuais se destacam em domínios específicos — como finanças, transformação de dados ou suporte ao usuário — mas conseguem colaborar perfeitamente para resolver problemas multidisciplinares.
Resolução dinâmica de problemas: Sistemas multi-agente podem se reconfigurar rapidamente, mudar de direção e responder a mudanças, essencial em ambientes voláteis de negócios, segurança e operações.
Frameworks de IA agentica facilitam a construção de soluções inteligentes
Lançamentos recentes em frameworks de IA agentica, como Strands Agents, estão facilitando para desenvolvedores a participação na criação e implementação de soluções multi-agente acionadas por modelos de linguagem. Em vez de depender de fluxos de trabalho manuais e frágeis, esses frameworks permitem que modelos robustos de linguagem raciocinem, planejem e invoquem ferramentas de forma autônoma.
Em ambiente de produção, serviços como Amazon Bedrock AgentCore oferecem implementação segura e escalável, com recursos como memória persistente, integração de identidade e observabilidade em nível empresarial. Essa mudança em direção a soluções colaborativas e multi-agente de IA está revolucionando arquiteturas de software, tornando-as mais autônomas, resilientes e adaptáveis.
De resolução de problemas em tempo real em infraestruturas de nuvem até automação entre equipes em serviços financeiros e assistentes baseados em chat coordenando processos comerciais complexos e multietapas, organizações que adotam soluções multi-agente estão se posicionando para maior agilidade e inovação. Agora, com frameworks abertos como Strands, qualquer pessoa pode começar a construir sistemas inteligentes que pensam, interagem e evoluem juntos.
Processamento automático de vídeos com agentes especializados
Este artigo explora como construir um fluxo de trabalho multi-agente de processamento de vídeos usando Strands Agents SDK, modelos Llama 4 da Meta com suas capacidades multimodais, e Amazon Bedrock para analisar e compreender automaticamente conteúdo de vídeo através de agentes especializados trabalhando em coordenação. A demonstração da solução usa Amazon SageMaker AI para guiar através do código.
Llama 4: Janelas de contexto de 1 milhão de tokens e além
Llama 4 é a mais recente família de modelos de linguagem grandes (LLMs) da Meta, se destacando por suas capacidades de janela de contexto e inteligência multimodal. Ambos os modelos utilizam arquitetura de mistura de especialistas (MoE) para eficiência, foram projetados para entradas multimodais e são otimizados para alimentar sistemas agenticos e fluxos de trabalho complexos.
A variante principal, Llama 4 Scout, suporta uma janela de contexto de 10 milhões de tokens — uma primeira na indústria — permitindo que o modelo processe e reflita sobre grandes volumes de dados em um único prompt. Isso viabiliza aplicações como resumir bibliotecas inteiras de livros, analisar bases de código massivas, conduzir pesquisas abrangentes em milhares de documentos e manter contexto de conversa profundo e persistente em interações prolongadas.
A variante Llama 4 Maverick oferece também uma janela de 1 milhão de tokens, adequada para tarefas exigentes de linguagem, visão e análise entre documentos. Essas janelas de contexto ultralong abrem novas possibilidades para sumarização avançada, retenção de memória e fluxos de trabalho complexos e multietapas.
Nome do Modelo
Janela de Contexto
Capacidades e Casos de Uso
Llama 4 Scout
10M tokens (até 3,5M no Amazon Bedrock)
Processamento ultralong de documentos, ingestão de livros ou bases de código completas, sumarização em larga escala, memória de diálogo extensiva, pesquisa avançada
Llama 4 Maverick
1M tokens
Tarefas multimodais com contexto grande, compreensão avançada de documentos e imagens, análise de código, Q&A abrangente, sumarização robusta
Arquitetura da solução: orquestração inteligente de agentes
A solução demonstra como construir um fluxo de trabalho multi-agente de processamento de vídeos usando a integração incorporada do Strands Agents com Amazon Web Services (AWS) e a infraestrutura de IA gerenciada do Amazon Bedrock. Embora o foco seja principalmente em agentes especializados para análise de vídeo, as práticas de criação de fluxos multi-agente podem ser aplicadas para construir soluções adaptáveis e automatizadas em nível empresarial.
Para escalabilidade, essa abordagem se estende naturalmente para lidar com cargas de trabalho maiores e mais diversas — desde processamento de streams de vídeo de milhões de dispositivos conectados em cidades inteligentes até automação industrial para manutenção preditiva através de análise contínua de vídeo e dados de sensores, sistemas de vigilância em tempo real em múltiplas localidades ou empresas de mídia gerenciando grandes bibliotecas para indexação e recuperação de conteúdo.
Seis agentes especializados trabalhando em tandem
O fluxo de trabalho implementa seis agentes especializados. Cada um desempenha um papel específico, passando sua saída para o próximo agente completar tarefas multietapas. Isso é conduzido através da mesma análise de uma arquitetura de pesquisa profunda, onde existe um agente orquestrador que coordena o processo dos outros agentes trabalhando juntos. Esse conceito em Strands Agents é chamado Agents as Tools (Agentes como Ferramentas).
Os agentes especializados são:
Llama4_coordinator_agent: Tem acesso aos outros agentes e inicia o processo desde o agente de extração de frames até geração de resumo.
s3_frame_extraction_agent: Usa a biblioteca OpenCV para extrair frames significativos de vídeos, lidando com a complexidade de operações com arquivos de vídeo.
s3_visual_analysis_agent: Possui ferramentas necessárias para processar os frames analisando cada imagem e armazenando como arquivo JSON no bucket Amazon Simple Storage Service (Amazon S3).
retrieve_json_agent: Recupera a análise dos frames em forma de arquivo JSON.
c_temporal_analysis_agent: Agente de IA especializado em sequências temporais em frames de vídeo, analisando imagens cronologicamente.
summary_generation_agent: Especializado em criar resumo da análise temporal das imagens.
O processo começa com o agente orquestrador, implementado usando Llama 4 da Meta, que coordena comunicação e delegação de tarefas entre agentes especializados. Esse agente central inicia e monitora cada passo do pipeline de processamento de vídeo. Usando o padrão Agents as Tools em Strands Agents, cada agente especializado é encapsulado como uma função chamável (ferramenta), permitindo comunicação inter-agente perfeita e orquestração modular. Esse padrão de delegação hierárquica reflete como equipes humanas colaborativas funcionam.
Os benefícios dessa abordagem incluem:
Customização: O prompt do sistema de cada agente pode ser ajustado independentemente para desempenho ótimo em sua tarefa especializada.
Separação de responsabilidades: Agentes focam no que fazem melhor, tornando o sistema mais direto de desenvolver e manter.
Flexibilidade de fluxo: O agente coordenador pode orquestrar componentes em diferentes sequências para vários casos de uso.
Escalabilidade: Componentes podem ser otimizados individualmente baseado em seus requisitos de desempenho específicos.
Extensibilidade: Novas capacidades podem ser adicionadas introduzindo novos agentes especializados sem desestabilizar existentes.
Fluxo de operação: da extração ao resumo
O agente coordenador inicia acionando o agente de extração de frames. Esse agente especializado possui as ferramentas necessárias para extrair frames-chave do vídeo de entrada usando OpenCV, fazer upload dos frames para Amazon S3 e identificar o caminho da pasta a passar para o agente de análise visual.
Após os frames serem armazenados no Amazon S3, o agente de análise visual tem acesso a ferramentas que listam os frames da pasta S3, usam Meta’s Llama no Amazon Bedrock para processar as imagens e fazem upload da análise como arquivo JSON para Amazon S3.
O arquivo JSON é então recuperado por um agente especializado que processa e extrai o texto da análise. Essa saída é então alimentada ao agente de análise temporal para ganhar consciência temporal das sequências nos frames de vídeo. Após a análise temporal ser gerada, o agente de geração de resumo é acionado para fornecer o resumo final.
No terminal, instale as dependências: pip install -r requirements.txt
Implantação com Gradio
Para implantar o aplicativo de processamento de vídeo usando Gradio:
Abra sua interface de linha de comando Python3
Execute: python3 gradio_app.py
Acesse o link hospedado gerado no terminal
Faça upload de seu arquivo de vídeo e selecione Executar
Execução no Jupyter Notebook
Após importar as bibliotecas necessárias, você precisa fazer upload manual de seu vídeo para seu bucket S3. O código fornecido no repositório guia através desse processo. Após o vídeo ser carregado, inicie o fluxo de trabalho do agente instanciando um novo agente com histórico de conversa fresco:
agent = new_llama4_coordinator_agent()
video_instruction = f"Process a video from {s3_video_uri}. Use tools in this order: run_frame_extraction, run_visual_analysis, retrieve_json_from_s3, run_temporal_reasoning, run_summary_generation, upload_analysis_results"
response = agent(video_instruction)
print(response)
Exemplo de saída: análise de conteúdo de vídeo
Quando processado através da solução, um vídeo de exemplo produz análise estruturada em múltiplas camadas:
O que acontece no vídeo: O vídeo segue personagens navegando através de uma série de eventos, começando de comportamento cauteloso em um cenário natural, buscando ajuda ou comunicação, participação em discussão crucial, e finalmente tomando ação com o grupo.
Sequência cronológica de eventos: A sequência começa com cautela perto de um cenário natural, seguida de aproximação de um grupo, participação em discussão significativa, e conclui com o grupo tomando ação juntos.
Elementos visuais-chave: Incluem postura inicial cautelosa, interação com outros personagens, discussões e cenas de ação final, destacando progressão de solitude para ação coletiva.
Narrativa geral: O arco segue jornada de cautela e busca por ajuda para participação em discussão crucial e finalmente ação com um grupo, sugerindo progressão, planejamento e ação coletiva.
Limpeza e próximos passos
Para evitar incorrer em cobranças futuras desnecessárias, limpe os recursos criados. Acesse AWS Management Console, navegue para Amazon S3, encontre seu bucket Amazon SageMaker, selecione os arquivos de vídeo carregados e delete-os. Para parar e remover o notebook SageMaker, acesse Amazon SageMaker AI no AWS Management Console, escolha Notebook instances, selecione seu notebook e delete após parar.
Conclusão: arquitetura robusta para IA autônoma
Combinar o SDK Strands Agents com modelos Llama 4 da Meta e infraestrutura Amazon Bedrock viabiliza a construção de fluxos de trabalho avançados de processamento de vídeo multi-agente. Através de agentes altamente especializados que comunicam e colaboram utilizando o padrão Agents as Tools, desenvolvedores conseguem modularizar tarefas complexas como extração de frames, análise visual, raciocínio temporal e sumarização.
Essa separação de responsabilidades aprimora manutenibilidade, customização e escalabilidade enquanto permite integração perfeita entre serviços AWS. Desenvolvedores são encorajados a explorar e estender essa arquitetura adicionando novos agentes especializados e adaptando fluxos para casos de uso diversos — de cidades inteligentes e automação industrial até gestão de conteúdo em mídia.
