A AWS anunciou recursos avançados de políticas de segurança de rede para o Amazon Elastic Kubernetes Service (EKS), capacitando organizações a fortalecer sua postura de segurança em cargas Kubernetes. Essas melhorias visam tanto o tráfego entre componentes internos do cluster quanto as conexões com ambientes externos.
A expansão das capacidades de segmentação de rede consolida investimentos anteriores da AWS nessa área, oferecendo aos administradores ferramentas mais robustas para controlar e monitorar fluxos de dados em arquiteturas containerizadas cada vez mais complexas.
Isolamento centralizado de tráfego de rede
O isolamento de tráfego de rede tornou-se essencial conforme organizações ampliam seus ambientes de aplicações no EKS. A incapacidade de segmentar corretamente o tráfego aumenta os riscos de acessos não autorizados, tanto dentro quanto fora do cluster.
Agora, as organizações podem ir além: gerenciar centralmente filtros de rede para todo o cluster, oferecendo controle mais granular e uma visão unificada da segurança em toda a infraestrutura Kubernetes.
Políticas baseadas em nomes de domínio (FQDN)
Outro avanço significativo envolve as regras de saída — egress rules — que agora filtram o tráfego destinado a recursos externos com base em nomes de domínio totalmente qualificados (FQDN). Essa abordagem oferece aos administradores de cluster uma estratégia mais estável e previsível para bloquear acessos não autorizados a recursos na nuvem ou em ambientes locais (on-premises).
Em vez de gerenciar manualmente listas de endereços IP (que podem mudar frequentemente), administradores podem definir políticas baseadas em nomes de domínio, simplificando a manutenção e reduzindo erros de configuração.
Disponibilidade e compatibilidade
Esses recursos de segurança estão disponíveis em todas as regiões comerciais da AWS. A ClusterNetworkPolicy funciona em todos os modos de execução de clusters EKS que utilizam a versão 1.21.0 ou superior do VPC CNI.
As políticas baseadas em DNS estão disponíveis especificamente para instâncias EC2 iniciadas via EKS Auto Mode. Novos clusters com Kubernetes versão 1.29 ou posterior já têm acesso a essas capacidades, enquanto suporte para clusters existentes será implementado nas próximas semanas.
O Desafio da Segurança Distribuída em Arquiteturas AWS
Aplicações web modernas construídas na AWS frequentemente combinam múltiplos serviços para oferecer soluções escaláveis e performáticas. Porém, essa arquitetura distribuída apresenta um desafio significativo: implementar uma estratégia coerente de segurança em camada de transporte entre todos esses componentes.
O principal obstáculo é que diferentes serviços AWS exigem abordagens distintas para configuração de HTTP Strict Transport Security (HSTS). Quando uma aplicação utiliza API Gateway para APIs, CloudFront para distribuição de conteúdo e Application Load Balancers para tráfego web, a ausência de políticas HSTS unificadas resulta em postura de segurança inconsistente. Ferramentas de auditoria de segurança frequentemente identificam headers HSTS faltantes, mas as orientações para remediar o problema estão dispersas em documentações específicas de cada serviço, criando lacunas de conformidade.
Entendendo HSTS e Seus Benefícios de Segurança
HTTP Strict Transport Security é um mecanismo de política de segurança web que protege websites contra ataques de rebaixamento de protocolo e roubo de cookies. Quando um servidor web declara política HSTS através do header Strict-Transport-Security, navegadores compatíveis convertem automaticamente solicitações HTTP para HTTPS para o domínio especificado.
Por Que HSTS Importa Além de Redirecionamentos HTTP→HTTPS
A maioria dos servidores web já implementa redirecionamento de HTTP para HTTPS. Porém, essa abordagem deixa uma janela de vulnerabilidade durante a primeira solicitação do navegador:
Usuário digita exemplo.com.br no navegador
Navegador envia requisição HTTP para http://exemplo.com.br
Servidor responde com redirecionamento 301/302 para https://exemplo.com.br
Navegador segue o redirecionamento e estabelece conexão HTTPS
A solicitação HTTP inicial (etapa 2) cria uma oportunidade para ataques. Uma parte não autorizada posicionada entre o usuário e a infraestrutura pode interceptar essa requisição e responder com conteúdo aparentemente legítimo mantendo uma conexão não segura. Essa técnica, conhecida como SSL stripping, pode ocorrer mesmo quando sua infraestrutura AWS está corretamente configurada com redirecionamentos HTTPS.
HSTS resolve essa vulnerabilidade movendo a imposição de segurança para o nível do navegador. Após receber uma política HSTS, o navegador converte automaticamente requisições HTTP para HTTPS antes de enviá-las pela rede:
Usuário digita exemplo.com.br no navegador
Navegador converte automaticamente para HTTPS graças à política HSTS armazenada
Navegador envia requisição HTTPS diretamente para https://exemplo.com.br
Nenhuma requisição HTTP inicial elimina a oportunidade de interceptação
Essa imposição no nível do navegador fornece proteção que complementa as configurações de segurança da infraestrutura AWS, criando defesa em profundidade contra problemas de rebaixamento de protocolo. HSTS também ajuda a prevenir acesso não autorizado a sessões, protegendo contra roubo de credenciais.
Casos de Uso Principais para HSTS
HSTS protege cenários que redirecionamentos HTTP simples não cobrem. Por exemplo, quando sistemas legados servem conteúdo misto, ou quando fluxos de SSO redirecionam usuários entre provedores, HSTS mantém as conexões criptografadas ao longo de todo o processo.
Em arquiteturas de microsserviços usando API Gateway com comunicação entre serviços, HSTS protege endpoints de API contra rebaixamento de protocolo durante conexões iniciais de clientes. Aplicações com CloudFront e múltiplos servidores de origem também se beneficiam, pois HSTS previne que navegadores façam fallback para HTTP durante cenários de failover.
Configurando HSTS no Amazon API Gateway
O Amazon API Gateway oferece múltiplas formas para adicionar headers HSTS em respostas de API.
HTTP APIs com Parameter Mapping
Para HTTP APIs, é possível configurar mapeamento de parâmetros de resposta para definir headers HSTS quando invocado via endpoint padrão ou domínio customizado:
Navegue até a configuração de rota da sua HTTP API no console do API Gateway
Acesse as configurações de integração na aba “Manage integrations”
Na seção de Response, insira 200 como código de status
Selecione “Append” como tipo de modificação
Em “Parameter to modify”, digite header.Strict-Transport-Security
Em Value, insira max-age=31536000; includeSubDomains; preload
REST APIs com Proxy e Non-Proxy Integration
REST APIs no API Gateway oferecem controle mais granular sobre implementação de HSTS através de padrões de integração proxy e non-proxy.
Para integrações proxy (como AWS Lambda), o serviço backend assume responsabilidade por gerar headers HSTS. Exemplo com Lambda:
Para integrações non-proxy, os headers HSTS devem ser retornados pelo API Gateway através de templates de mapeamento ou resposta de método. Usando templates de mapeamento com Velocity Template Language (VTL), é possível configurar geração dinâmica de headers:
Alternativamente, a aba “Method response” oferece configuração declarativa mapeando explicitamente o header strict-transport-security, seguido da aba “Integration response” onde você mapeia o valor como max-age=31536000; includeSubDomains; preload.
Os Application Load Balancers agora oferecem suporte integrado para modificação de headers de resposta HTTP, incluindo headers HSTS. Isso permite impor políticas de segurança consistentes em todos os seus serviços a partir de um único ponto, reduzindo esforço de desenvolvimento e garantindo proteção uniforme independentemente das tecnologias backend utilizadas.
Pré-requisitos e Configuração Inicial
Antes de implementar HSTS com load balancers, verifique se sua infraestrutura atende aos requisitos:
Recurso de modificação de headers habilitado para o listener (desabilitado por padrão)
Ativando Modificação de Headers de Resposta
Application Load Balancers suportam injeção direta de headers HSTS através do recurso de modificação de headers de resposta, fornecendo imposição centralizada de políticas de segurança sem necessidade de configuração em aplicações individuais.
Abra o console Amazon EC2 e navegue até Load Balancers
Selecione seu Application Load Balancer
Na aba “Listeners and rules”, selecione o listener HTTPS
Na aba “Attributes”, escolha “Edit”
Expanda a seção “Add response headers”
Selecione “Add HTTP Strict Transport Security (HSTS) header”
Configure o valor do header como max-age=31536000; includeSubDomains; preload
Clique em “Save changes”
Quando a modificação de headers é habilitada no ALB, a aplicação automática segue padrão consistente: se a resposta do backend não incluir o header especificado, o ALB o adiciona com o valor configurado; se a resposta já o contiver, o ALB substitui o valor existente pelo configurado. Isso garante imposição de política consistente em todas as respostas através do load balancer.
O Amazon CloudFront oferece suporte integrado para headers de segurança HTTP, incluindo HSTS, através de políticas de headers de resposta. Esse recurso possibilita gerenciamento centralizado de headers de segurança na borda da CDN, garantindo imposição consistente de política em conteúdo cacheado e não-cacheado.
Criando Política de Headers de Resposta
É possível utilizar o recurso de política de headers de resposta do CloudFront para configurar headers de segurança automaticamente adicionados às respostas servidas por sua distribuição. O CloudFront oferece políticas de headers de resposta gerenciadas com valores pré-definidos para headers de segurança HTTP mais comuns, ou você pode criar uma política customizada.
No console CloudFront, navegue até “Policies” e depois “Response headers”
Escolha “Create response headers policy”
Configure as definições:
Name: HSTS-Security-Policy
Description: HSTS e headers de segurança para aplicações web
Sob “Security headers”, configure:
Strict Transport Security: ative e defina Max age como 31.536.000 segundos (1 ano)
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-xss-protection: 1; mode=block
x-cache: Hit from cloudfront
Considerações de Segurança e Boas Práticas
Configuração de Max-Age
A diretiva max-age determina por quanto tempo navegadores aplicarão política HTTPS-only. As recomendações de duração são:
300 segundos (5 minutos): Seguro para experiências durante fase de teste inicial
86.400 segundos (1 dia): Compromisso de curto prazo, como ambientes de desenvolvimento
2.592.000 segundos (30 dias): Validação de médio prazo, como ambientes staging
31.536.000 segundos (1 ano): Compromisso de longo prazo, como ambientes produção
Recomenda-se começar com valores menores de max-age durante implementação inicial e aumentá-los gradualmente conforme você ganha confiança na estabilidade da infraestrutura HTTPS.
Diretiva includeSubDomains
A diretiva includeSubDomains estende imposição HSTS a todos os subdomínios. Oferece proteção abrangente em toda hierarquia de domínio e previne ataques baseados em subdomínios, porém requer que todos os subdomínios suportem HTTPS com certificados SSL válidos e mantenham política de segurança consistente na hierarquia de domínio.
Preload para Máxima Cobertura
Considerar implementar HSTS preload para cobertura máxima de segurança:
Preload fornece proteção para visitantes pela primeira vez através de imposição no nível do navegador antes de requisições de rede, mas requer submissão a listas de preload do navegador e é difícil de reverter, exigindo compromisso de longo prazo com infraestrutura HTTPS.
Novo recurso de gerenciamento centralizado de segurança de rede
A AWS anunciou, em dezembro de 2025, a expansão do AWS Shield Network Security Director com suporte a análise de segurança em múltiplas contas. Esta capacidade, que se encontra em fase de preview, permite que organizações gerenciem a segurança de rede de forma centralizada em toda sua estrutura na nuvem.
Como funciona o Network Security Director
O AWS Shield Network Security Director é uma ferramenta de visibilidade que oferece insights detalhados sobre os recursos AWS em sua organização. Seu principal objetivo é identificar lacunas na segurança e detectar serviços de segurança de rede que estão ausentes ou mal configurados, oferecendo ao mesmo tempo recomendações específicas para correção.
Análise centralizada em múltiplas contas
Com o novo recurso de análise multi-contas, é possível designar uma conta de administrador delegado para coordenar a análise contínua de segurança de rede. A partir dessa conta central, você consegue monitorar múltiplas contas ou unidades organizacionais em toda a sua AWS Organization.
A visão centralizada permite acompanhar a topologia de rede de cada conta, visualizar as descobertas de segurança identificadas e acessar as recomendações de remediação de forma agregada. Tudo isso sem precisar alternar entre diferentes contas ou consoles.
Integração com Amazon Q Developer
Uma das funcionalidades interessantes é a capacidade de gerar resumos e relatórios sobre as lacunas de segurança de rede identificadas. Esses relatórios podem ser solicitados e visualizados diretamente através do Amazon Q Developer, tanto dentro do AWS Management Console quanto em aplicativos de chat, simplificando o acesso às informações para equipes de segurança.
Expansão geográfica do serviço
Além do suporte a múltiplas contas, a AWS expandiu a disponibilidade geográfica do AWS Shield Network Security Director. O serviço agora está disponível em cinco regiões adicionais:
Europe (Ireland)
Europe (Frankfurt)
Asia Pacific (Hong Kong)
Asia Pacific (Singapore)
Australia (Sydney)
Essa expansão permite que organizações em diferentes regiões do mundo desfrutem das mesmas capacidades de gerenciamento de segurança de rede, mantendo dados próximos de suas operações locais.
Próximos passos
Para organizações interessadas em explorar esta nova funcionalidade, a AWS recomenda consultar a página de visão geral do AWS Shield para obter mais detalhes técnicos e iniciar a avaliação da solução durante a fase de preview.
Transformando Gerenciamento de Nuvem com Interfaces de Voz
À medida que infraestruturas em nuvem se tornam cada vez mais sofisticadas, a demanda por interfaces de gerenciamento intuitivas e eficientes cresce proporcionalmente. Interfaces de linha de comando (CLI) e consoles web tradicionais, embora poderosos, frequentemente criam barreiras que ralentizam a tomada de decisões e comprometem a eficiência operacional. E se fosse possível conversar diretamente com sua infraestrutura AWS e receber respostas inteligentes de forma imediata?
A AWS apresenta uma abordagem inovadora que combina Amazon Nova Sonic para processamento de voz com Strands Agents para orquestração de múltiplos agentes especializados. Esta solução demonstra como interações naturais por voz podem revolucionar operações em nuvem, tornando serviços AWS mais acessíveis e operações significativamente mais eficientes.
A arquitetura multi-agente apresentada vai além de simples operações AWS, estendendo-se para casos de uso diversos como automação de atendimento ao cliente, gerenciamento de dispositivos de Internet das Coisas (IoT), análise de dados financeiros e orquestração de fluxos de trabalho corporativos. Este padrão fundamental pode ser adaptado para qualquer domínio que exija roteamento inteligente de tarefas e interação baseada em linguagem natural.
Explorando a Arquitetura Técnica
A solução emprega uma arquitetura sofisticada onde Amazon Nova Sonic se integra perfeitamente com Strands Agents, criando um sistema multi-agente que processa comandos de voz e executa operações AWS em tempo real.
Componentes Principais
A arquitetura multi-agente é composta por diversos componentes especializados que trabalham em conjunto:
Agente Supervisor: Funciona como coordenador central, analisando consultas de voz recebidas e as direcionando para o agente especializado apropriado, com base no contexto e intenção da solicitação
Agentes Especializados:
Agente EC2: Responsável por gerenciamento de instâncias, monitoramento de status e operações de computação
Agente SSM: Gerencia operações do Systems Manager, execução de comandos e gerenciamento de patches
Agente de Backup: Supervisiona configurações de AWS Backup, monitoramento de trabalhos e operações de restauração
Camada de Integração de Voz: Utiliza Amazon Nova Sonic para processamento bidirecional de voz, convertendo fala em texto para processamento e texto em fala para respostas
Visão Geral da Solução
O Assistente Nova Voice de Strands Agents demonstra um novo paradigma para gerenciamento de infraestrutura AWS através de inteligência artificial conversacional. Em vez de navegar por consoles complexos ou memorizar comandos CLI, usuários podem simplesmente expressar suas intenções por voz e receber respostas instantâneas. Esta solução coloca a comunicação humana natural no centro das operações técnicas AWS, democratizando o gerenciamento de nuvem para equipes técnicas e não-técnicas.
Stack Tecnológico
A solução utiliza tecnologias modernas e nativas de nuvem para entregar uma interface de voz robusta e escalável:
Backend: Python 3.12+ com framework Strands Agents para orquestração de agentes
Modelos de IA:Amazon Bedrock e Claude 3 Haiku para compreensão e geração de linguagem natural
Processamento de voz:Amazon Nova Sonic para síntese e reconhecimento de fala de alta qualidade
Comunicação: Servidor WebSocket para comunicação bidirecional em tempo real
Recursos e Capacidades Principais
O assistente de voz oferece funcionalidades avançadas que tornam operações AWS mais intuitivas e eficientes. O sistema compreende consultas naturais de voz e as converte em chamadas apropriadas às APIs AWS. Por exemplo:
“Mostrar todas as instâncias EC2 em execução em us-east-1”
“Instalar o agente Amazon CloudWatch usando SSM nas minhas instâncias Dev”
“Verificar o status dos trabalhos de backup de ontem à noite”
As respostas são especificamente otimizadas para entrega por voz, com resumos concisos limitados a 800 caracteres, informações estruturadas claras e fraseado conversacional que soa natural quando sintetizado em fala, evitando jargão técnico e utilizando sentenças completas adequadas para síntese de voz.
Colocando em Prática
Começar com o assistente de voz envolve três etapas principais:
Configuração do Ambiente
Configurar credenciais AWS com acesso a Bedrock, Nova Sonic e serviços AWS alvo
Preparar ambiente backend Python 3.12+ e frontend React
“Verificar essas instâncias quanto a patches usando SSM”
Exemplos de Implementação
Os exemplos de código demonstram padrões-chave de integração e práticas recomendadas para implementar o assistente de voz. Eles mostram como integrar Amazon Nova Sonic para processamento de voz e configurar o agente supervisor para roteamento inteligente de tarefas.
Configuração de Strands Agents
A implementação utiliza um padrão de orquestrador multi-agente com agentes especializados:
from strands import Agent
from config.conversation_config import ConversationConfig
from config.config import create_bedrock_model
class SupervisorAgent(Agent):
def __init__(self, specialized_agents, config=None):
bedrock_model = create_bedrock_model(config)
conversation_manager = ConversationConfig.create_conversation_manager("supervisor")
super().__init__(
model=bedrock_model,
system_prompt=self._get_routing_instructions(),
tools=[], # No tools for pure router
conversation_manager=conversation_manager,
)
self.specialized_agents = specialized_agents
Integração com Nova Sonic
A implementação utiliza um servidor WebSocket com gerenciamento de sessão para processamento de voz em tempo real:
class S2sSessionManager:
def __init__(self, model_id='amazon.nova-sonic-v1:0', region='us-east-1', config=None):
self.model_id = model_id
self.region = region
self.audio_input_queue = asyncio.Queue()
self.output_queue = asyncio.Queue()
self.supervisor_agent = SupervisorAgentIntegration(config)
async def processToolUse(self, toolName, toolUseContent):
if toolName == "supervisoragent":
result = await self.supervisor_agent.query(content)
if len(result) > 800:
result = result[:800] + "... (truncated for voice)"
return {"result": result}
Considerações de Segurança
Esta solução foi projetada para fins de desenvolvimento e testes. Antes de implantar em ambientes produtivos, implemente controles de segurança apropriados incluindo:
Mecanismos de autenticação e autorização
Controles de segurança de rede e restrições de acesso
Monitoramento e logging para conformidade de auditoria
Controles de custo e monitoramento de uso
Sempre siga as práticas recomendadas de segurança da AWS e o princípio do menor privilégio ao configurar permissões IAM.
Considerações para Produção
Embora esta solução demonstre capacidades de Strands Agents usando uma abordagem de implantação focada em desenvolvimento, organizações planejando implementações produtivas devem considerar o Amazon Bedrock AgentCoreRuntime para hospedagem e gerenciamento em nível corporativo.
Benefícios do Amazon Bedrock AgentCore para Implantação Produtiva
Runtime Serverless: Propositadamente construído para implantar e dimensionar agentes de IA dinâmicos sem gerenciar infraestrutura
Isolamento de Sessão: Isolamento completo de sessão com microVMs dedicadas para cada sessão de usuário, fundamental para agentes que executam operações privilegiadas
Auto-dimensionamento: Dimensionar para milhares de sessões de agente em segundos com precificação por uso
Segurança Corporativa: Controles de segurança integrados com integração perfeita a provedores de identidade (Amazon Cognito, Microsoft Entra ID, Okta)
Observabilidade: Rastreamento distribuído integrado, métricas e capacidades de depuração através da integração CloudWatch
Persistência de Sessão: Altamente confiável com persistência de sessão para interações de agentes de longa duração
Para organizações prontas para avançar além de desenvolvimento e testes, o Amazon Bedrock AgentCore Runtime oferece a base pronta para produção necessária para implantar assistentes AWS baseados em voz em escala corporativa.
Extensão para Serviços AWS Adicionais
O sistema pode ser estendido para suportar serviços AWS adicionais:
AWS Lambda: Executar funções serverless através de comandos de voz
Amazon CloudWatch: Consultar métricas e logs através de linguagem natural
O Assistente Nova Voice de Strands Agents demonstra o potencial significativo de combinar interfaces de voz com orquestração inteligente de agentes em diversos domínios. Ao aproveitar Amazon Nova Sonic para processamento de fala e Strands Agents para coordenação multi-agente, organizações podem criar formas mais intuitivas e eficientes de interagir com sistemas e fluxos de trabalho complexos.
Esta arquitetura fundamental estende-se muito além de operações em nuvem, habilitando soluções baseadas em voz para automação de atendimento ao cliente, análise financeira, gerenciamento de IoT, fluxos de trabalho em saúde, otimização de cadeia de suprimentos e inúmeras outras aplicações corporativas. A combinação de processamento de linguagem natural, roteamento inteligente e conhecimento especializado de domínio cria uma plataforma versátil para transformar como usuários interagem com qualquer sistema complexo.
A arquitetura modular garante escalabilidade e extensibilidade, permitindo que organizações personalizem a solução para seus domínios e casos de uso específicos. À medida que interfaces de voz continuam evoluindo e capacidades de IA avançam, soluções como esta tendem a se tornar cada vez mais importantes para gerenciar ambientes complexos em todas as indústrias.
Começando
Pronto para construir seu próprio assistente de operações AWS alimentado por voz? O código-fonte completo e documentação estão disponíveis no repositório GitHub. Siga este guia de implementação para começar e não hesite em personalizar a solução para seus casos de uso específicos. Para dúvidas, feedback ou contribuições, consulte o repositório do projeto ou procure nos fóruns da comunidade AWS.
Nova capacidade de transferência com desempenho ampliado
A AWS anunciou uma expansão significativa do AWS DataSync, serviço seguro e de alta velocidade para otimizar o movimento de dados pela rede. O Modo Aprimorado agora suporta transferências de dados entre servidores de arquivos on-premises e Amazon S3, permitindo que clientes transfiram datasets que escalam para números praticamente ilimitados de arquivos com níveis mais altos de desempenho em comparação ao Modo Básico do DataSync.
Como funciona o Modo Aprimorado
O Modo Aprimorado utiliza processamento paralelo para entregar maior desempenho e escalabilidade para datasets de qualquer tamanho. Seus benefícios principais incluem:
Remoção de limitações de quantidade de arquivos
Métricas detalhadas de transferência para melhor monitoramento e gerenciamento
Processamento paralelo otimizado para performance superior
Suporte a datasets de escala praticamente ilimitada
Anteriormente, o Modo Aprimorado estava disponível apenas para transferências entre localizações do Amazon S3 e para transferências multicloud. Este lançamento estende essas capacidades para suportar transferências entre servidores de arquivos NFS (Network File System) ou SMB (Server Message Block) on-premises e o Amazon S3.
Casos de uso habilitados
A expansão do DataSync abre possibilidades práticas para diversos cenários empresariais:
Workloads de IA generativa: clientes podem acelerar essas cargas de trabalho movendo rapidamente datasets de treinamento para a AWS
Análise de data lakes: sincronizar dados on-premises com pipelines baseados em nuvem potencializa análises em escala
Migrações em larga escala: dirigir migrações para arquivamento e modernização de aplicações na nuvem
Disponibilidade e próximos passos
A nova capacidade está disponível em todas as regiões AWS onde o DataSync é oferecido. Para começar, clientes podem acessar o console do AWS DataSync. Informações técnicas detalhadas estão disponíveis na documentação do AWS DataSync.
O Amazon WorkSpaces Secure Browser recebeu uma atualização significativa com a introdução da Filtragem de Conteúdo Web, um recurso abrangente de segurança e conformidade que permite que as organizações exerçam controle detalhado sobre o acesso aos conteúdos da web. Essa capacidade se apresenta como uma solução robusta para empresas que buscam fortalecer as políticas de acesso remoto sem comprometer a experiência do usuário.
Capacidades Principais da Filtragem de Conteúdo Web
Políticas Granulares e Categorização
O recurso permite que os administradores definam políticas de acesso muito específicas, com a possibilidade de bloquear URLs individuais ou categorias completas de domínios. Com mais de 25 categorias predefinidas à disposição, as equipes de TI ganham flexibilidade para estruturar as regras de forma alinhada às necessidades empresariais, mantendo a facilidade de gerenciamento centralizado que se adapta ao crescimento da organização.
Integração e Monitoramento Aprimorado
A Filtragem de Conteúdo Web se integra perfeitamente com o Session Logger (Registro de Sessão), ampliando as capacidades de monitoramento e geração de relatórios de conformidade. Enquanto as políticas existentes do Chrome para controle de domínios continuam funcionando, essa nova abordagem oferece um caminho mais abrangente para gerenciar acessos web através da filtragem por categorias e de capacidades de registro aprimoradas.
Flexibilidade e Conformidade
O recurso mantém a flexibilidade necessária para adaptações específicas ao negócio, permitindo políticas customizadas e exceções conforme as demandas particulares. Equipes de segurança em TI podem implementar políticas de negação padrão para ambientes de alta segurança, enquanto oficiais de conformidade aproveitam as capacidades detalhadas de registro e monitoramento para atender aos requisitos regulatórios.
Disponibilidade e Acesso
O recurso está disponível sem custo adicional em 10 regiões da AWS, incluindo US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt, London, Ireland) e Asia Pacific (Tokyo, Mumbai, Sydney, Singapore). O Amazon WorkSpaces Secure Browser oferece modelo de preços pay-as-you-go (pague conforme o uso).
Para começar com o WorkSpaces Secure Browser, consulte a documentação de introdução ao Amazon WorkSpaces Secure Browser. É possível ativar o recurso diretamente no console da AWS e migrar automaticamente qualquer política de navegador existente para listas de bloqueio ou permissão de URLs. Para aprofundar-se nas funcionalidades, consulte a documentação completa do recurso.
Uma nova forma de provisionar bancos de dados na AWS
A AWS anunciou uma importante melhoria no Amazon Aurora DSQL: a plataforma agora oferece a capacidade de criar clusters de banco de dados em questão de segundos, reduzindo drasticamente o tempo de configuração que anteriormente levava minutos. Essa otimização representa um avanço significativo para organizações que buscam agilidade no desenvolvimento e prototipagem de aplicações em nuvem.
O que mudou com essa melhoria
A redução no tempo de criação de clusters traz benefícios práticos imediatos para desenvolvedoras e desenvolvedores. Com a possibilidade de provisionar bancos de dados Aurora DSQL em segundos, é possível colocar novas ideias em produção muito mais rapidamente, sem aguardar processos de configuração longos e complexos.
A experiência foi ainda potencializada com a integração do editor de consultas direto no console da AWS. Isso significa que os desenvolvedores podem começar a trabalhar imediatamente, construindo aplicações sem necessidade de configurar clientes externos ou conectar-se através do servidor Model Context Protocol (MCP) do Aurora DSQL para ativar ferramentas de desenvolvimento com inteligência artificial.
Capacidades principais do Aurora DSQL
Independentemente do cenário — seja prototipagem rápida ou carga de produção em larga escala — o Aurora DSQL oferece um conjunto robusto de características:
Escalabilidade virtualmente ilimitada para acompanhar o crescimento da sua aplicação
Alta disponibilidade ativa-ativa, garantindo continuidade de operação
Zero necessidade de gerenciamento de infraestrutura
Modelo de preço por consumo: você paga apenas pelo que usa
Essa combinação de recursos garante que o banco de dados escala de forma automática conforme as demandas da aplicação aumentam, sem comprometer performance ou disponibilidade.
Disponibilidade e como começar
A melhoria de criação de clusters em segundos está disponível em todas as regiões onde o Aurora DSQL é oferecido. Para aqueles que desejam explorar a plataforma sem investimento inicial, a AWS disponibiliza o AWS Free Tier com acesso gratuito ao Aurora DSQL.
Para aprofundar seus conhecimentos sobre o serviço, é possível consultar a página oficial do Aurora DSQL e sua documentação técnica, onde você encontrará guias detalhados e exemplos práticos de implementação.
Nova funcionalidade de conectividade privada no Amazon Cognito
A AWS anunciou suporte para AWS PrivateLink no Amazon Cognito identity pools, uma adição significativa para organizações que buscam maior segurança em seus fluxos de autenticação. Com essa novidade, agora é possível trocar identidades federadas por credenciais da AWS através de conectividade privada entre sua nuvem privada virtual (Virtual Private Cloud — VPC) e o Cognito.
A principal vantagem dessa funcionalidade é eliminar a necessidade de rotear tráfego de autenticação pela internet pública. Isso resulta em uma postura de segurança aprimorada para cargas de trabalho que exigem isolamento de rede rigoroso.
Como funciona a integração com identity pools
Os identity pools do Cognito têm a função de mapear identidades autenticadas e de convidado para papéis (roles) do AWS Identity and Access Management (IAM) e fornecer credenciais temporárias da AWS. Com o suporte ao PrivateLink, esse mapeamento agora pode ocorrer através de uma conexão segura e privada, mantendo o tráfego completamente isolado dentro da infraestrutura da AWS.
Disponibilidade e cobertura geográfica
Você pode utilizar conexões PrivateLink em todas as regiões da AWS onde o Amazon Cognito identity pools está disponível, com exceção da região AWS China (Beijing), operada pela Sinnet, e das regiões AWS GovCloud (US).
É importante observar que a criação de endpoints VPC no AWS PrivateLink gera custos adicionais. Para conhecer os detalhes de precificação, consulte a página de preços do AWS PrivateLink.
Como começar
Para iniciar o uso dessa funcionalidade, você pode criar um endpoint de interface VPC do AWS PrivateLink para o Amazon Cognito identity pools utilizando qualquer uma das seguintes ferramentas:
MLflow para empresas: nova era de escalabilidade automática
A AWS anunciou recentemente Amazon SageMaker AI com MLflow, agora incluindo uma capacidade serverless que gerencia dinamicamente provisionamento de infraestrutura, escalabilidade e operações para tarefas de desenvolvimento em inteligência artificial e aprendizado de máquina (IA/ML). O destaque principal é que os recursos aumentam durante experimentos intensivos e reduzem a zero quando não estão em uso, diminuindo significativamente o overhead operacional.
A nova versão traz funcionalidades de nível empresarial como controle de acesso simplificado com compartilhamento entre contas, atualizações automáticas de versões e integração com capacidades do SageMaker AI, como customização de modelos e pipelines. O melhor: não exige configuração de administrador e não tem custo adicional, permitindo que cientistas de dados comecem imediatamente a rastrear experimentos, implementar observabilidade e avaliar desempenho de modelos sem delays relacionados a infraestrutura.
A terminologia mudou: “MLflow Apps” agora substitui a designação anterior de “servidores de rastreamento MLflow”, refletindo uma abordagem simplificada e focada em aplicações. Cientistas de dados acessam a nova página MLflow Apps no Amazon SageMaker Studio.
Um MLflow App padrão é provisionado automaticamente ao criar um domínio SageMaker Studio, simplificando todo o processo de configuração. Já sai pronto para uso empresarial, sem exigir provisionamento ou configuração adicional. O MLflow App escala elasticamente conforme o uso, eliminando a necessidade de planejamento manual de capacidade. Cargas de trabalho de treinamento, rastreamento e experimentação recebem automaticamente os recursos necessários, simplificando operações enquanto mantém desempenho.
Atualizações automatizadas e versionamento
Administradores podem definir uma janela de manutenção durante a criação do MLflow App, período no qual ocorrem atualizações in-place da versão. Isso garante que o MLflow App permaneça padronizado, seguro e constantemente atualizado, minimizando overhead de manutenção manual. A versão 3.4 do MLflow é suportada neste lançamento, estendendo a plataforma para aplicações de IA generativa e cargas de trabalho com agentes.
Controle de identidades simplificado com MLflow Apps
A AWS simplificou o controle de acesso e permissões IAM para equipes de aprendizado de máquina com o novo MLflow App. Um conjunto de permissões racionalizado, como sagemaker:CallMlflowAppApi, agora cobre operações comuns — desde criar e buscar experimentos até atualizar informações de rastreamento — tornando o controle de acesso muito mais direto de aplicar.
Ao ativar limites de permissões IAM simplificados, usuários e administradores de plataforma podem padronizar papéis IAM entre equipes, personas e projetos, facilitando acesso consistente e auditável a experimentos e metadados do MLflow. Para configurações completas de permissão e políticas IAM, a documentação disponibiliza detalhes em Set up IAM permissions for MLflow Apps.
Compartilhamento entre contas AWS usando AWS RAM
Administradores frequentemente desejam gerenciar centralmente sua infraestrutura MLflow enquanto provisionam acesso em diferentes contas AWS. Os MLflow Apps suportam compartilhamento entre contas para desenvolvimento empresarial colaborativo em IA. Usando AWS RAM, essa funcionalidade permite que administradores de plataforma de IA compartilhem um MLflow App perfeitamente entre cientistas de dados em contas consumidoras separadas.
Administradores de plataforma mantêm um domínio SageMaker centralizado e governado que provisiona e gerencia o MLflow App, enquanto cientistas de dados em contas consumidoras separadas podem iniciar e interagir com o MLflow App com segurança. Combinado com as novas permissões IAM simplificadas, empresas podem iniciar e gerenciar um MLflow App a partir de uma conta AWS administrativa centralizada. Usando o MLflow App compartilhado, um cientista de dados consumidor downstream pode registrar suas experimentações MLflow e cargas de trabalho de IA generativa mantendo governança, auditabilidade e conformidade a partir de um único plano de controle do administrador de plataforma. Para saber mais sobre compartilhamento entre contas, consulte Getting Started with AWS RAM.
Integração entre SageMaker Pipelines e MLflow
Amazon SageMaker Pipelines está integrado ao MLflow. Trata-se de um serviço serverless de orquestração de fluxo de trabalho construído especificamente para automação de MLOps (operações de aprendizado de máquina) e LLMOps (operações com modelos de linguagem grande). Você pode construir, executar e monitorar fluxos de trabalho ML repetíveis de ponta a ponta de forma perfeita, usando interface arrastar-e-soltar intuitiva ou SDK Python.
A partir de um pipeline SageMaker, um MLflow App padrão é criado automaticamente se não existir, um nome de experimento MLflow pode ser definido, e métricas, parâmetros e artefatos são registrados no MLflow App conforme definido no código do pipeline SageMaker.
Customização de modelos SageMaker e integração com MLflow
A customização de modelos SageMaker integra-se com MLflow por padrão, oferecendo vinculação automática entre trabalhos de customização de modelos e experimentos MLflow. Ao executar trabalhos de fine-tuning (ajuste fino) de customização de modelos, o MLflow App padrão é utilizado, um experimento é selecionado, e métricas, parâmetros e artefatos são registrados automaticamente.
Na página de trabalho de customização de modelos do SageMaker, você pode visualizar métricas provenientes do MLflow e acessar métricas adicionais na interface do MLflow.
Essas funcionalidades preparam os novos MLflow Apps no SageMaker AI para cargas de trabalho ML e IA generativa em escala empresarial com mínimo peso administrativo. Para começar, existem exemplos disponíveis no repositório de exemplos no GitHub e em workshop AWS.
O surgimento de agentes de inteligência artificial marca uma mudança profunda no desenvolvimento de software e na forma como as aplicações tomam decisões e interagem com usuários. Enquanto sistemas tradicionais seguem caminhos previsíveis, agentes de IA realizam raciocínios complexos que frequentemente permanecem ocultos à visão. Essa invisibilidade cria um desafio para as organizações: como confiar em algo que não conseguem visualizar completamente?
É nesse contexto que entra a observabilidade de agentes, oferecendo visibilidade profunda sobre como aplicações acionárias funcionam, interagem e executam suas tarefas. A capacidade de compreender cada etapa da execução de um agente não é apenas uma conveniência — é essencial para garantir confiabilidade, otimizar desempenho e controlar custos em produção.
Integrando Langfuse com Amazon Bedrock AgentCore
A Langfuse é uma plataforma de observabilidade e avaliação para aplicações que utilizam modelos de linguagem. Quando integrada com o Amazon Bedrock AgentCore, ela oferece visibilidade detalhada sobre o desempenho de agentes de IA, facilitando a depuração rápida de problemas e permitindo otimizações baseadas em dados reais.
O Amazon Bedrock AgentCore é uma plataforma abrangente que permite implantar e operar agentes de IA altamente capazes, de forma segura e em escala. Oferece infraestrutura propositalmente construída para cargas de trabalho dinâmicas de agentes, ferramentas poderosas para aprimorá-los e controles essenciais para implantação em ambientes reais. A plataforma funciona com diversos frameworks — incluindo CrewAI, LangGraph, LlamaIndex e Strands Agents — e com qualquer modelo de fundação, dentro ou fora do Bedrock, oferecendo flexibilidade e confiabilidade.
Visão geral da arquitetura de integração entre código de agente, Amazon ECR Repository e AgentCore Runtime Endpoint
Como Funciona o Rastreamento com Langfuse
A Langfuse utiliza OpenTelemetry (OTEL) para rastrear e monitorar agentes implantados no Amazon Bedrock AgentCore. OpenTelemetry é um projeto da Cloud Native Computing Foundation (CNCF) que fornece especificações, APIs e bibliotecas para definir uma forma padrão de coletar traces distribuídos e métricas de uma aplicação.
Com essa integração, desenvolvedores conseguem acompanhar métricas de desempenho cruciais, incluindo uso de tokens, latência e durações de execução em diferentes fases de processamento. O sistema cria estruturas hierárquicas de rastreamento que capturam tanto respostas em streaming quanto não-streaming, com atributos detalhados de operações e estados de erro.
Através do endpoint `/api/public/otel`, a Langfuse funciona como um Backend OpenTelemetry, mapeando traces para seu modelo de dados usando convenções de IA generativa. Isso é particularmente valioso para aplicações complexas de modelos de linguagem que utilizam cadeias e agentes com ferramentas, onde traces aninhados ajudam desenvolvedores a identificar e resolver problemas rapidamente.
Além da observabilidade de agentes, a Langfuse oferece um conjunto integrado de ferramentas que abrangem todo o ciclo de vida do desenvolvimento de aplicações com IA: execução de avaliadores automatizados, organização de dados para análise de causa raiz, rastreamento de experimentos, iteração interativa em promptas e controle de versão através de gerenciamento de prompts.
Visão Geral da Solução
A solução demonstrada implanta um agente Strands no AgentCore Runtime com observabilidade Langfuse. A implementação utiliza modelos Anthropic Claude acessados através do Amazon Bedrock. Os dados de telemetria fluem do agente Strands através de exportadores OTEL até a Langfuse para monitoramento e depuração.
Os componentes-chave utilizados na solução incluem:
Strands Agents: Framework Python para construir agentes acionários com suporte de telemetria integrado
Amazon Bedrock AgentCore Runtime: Serviço de runtime gerenciado para hospedagem e dimensionamento de agentes na AWS
Langfuse: Plataforma de observabilidade e avaliação de código aberto para aplicações com modelos de linguagem
OpenTelemetry: Protocolo padrão do setor para coleta e exportação de dados de telemetria
Guia de Implementação Técnica
Pré-requisitos
Antes de começar, certifique-se de ter em mãos:
Uma conta AWS com credenciais configuradas corretamente através do AWS CLI ou variáveis de ambiente
Acesso a modelos Anthropic Claude 3.7 na região us-west-2
O arquivo do agente (strands_claude.py) implementa um agente de viagens com capacidades de busca na web. Aqui está a estrutura principal:
import os
import logging
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
from strands.models import BedrockModel
from strands.telemetry import StrandsTelemetry
from ddgs import DDGS
logging.basicConfig(level=logging.ERROR, format="[%(levelname)s] %(message)s")
logger = logging.getLogger(__name__)
logger.setLevel(os.getenv("AGENT_RUNTIME_LOG_LEVEL", "INFO").upper())
@tool
def web_search(query: str) -> str:
"""
Search the web for information using DuckDuckGo.
Args:
query: The search query
Returns:
A string containing the search results
"""
try:
ddgs = DDGS()
results = ddgs.text(query, max_results=5)
formatted_results = []
for i, result in enumerate(results, 1):
formatted_results.append(
f"{i}. {result.get('title', 'No title')}\n"
f" {result.get('body', 'No summary')}\n"
f" Source: {result.get('href', 'No URL')}\n"
)
return "\n".join(formatted_results) if formatted_results else "No results found."
except Exception as e:
return f"Error searching the web: {str(e)}"
def get_bedrock_model():
region = os.getenv("AWS_DEFAULT_REGION", "us-west-2")
model_id = os.getenv("BEDROCK_MODEL_ID", "us.anthropic.claude-3-7-sonnet-20250219-v1:0")
bedrock_model = BedrockModel(
model_id=model_id,
region_name=region,
temperature=0.0,
max_tokens=1024
)
return bedrock_model
bedrock_model = get_bedrock_model()
system_prompt = """You are an experienced travel agent specializing in personalized travel recommendations with access to real-time web information. Your role is to find dream destinations matching user preferences using web search for current information. You should provide comprehensive recommendations with current information, brief descriptions, and practical travel details."""
app = BedrockAgentCoreApp()
def initialize_agent():
"""Initialize the agent with proper telemetry configuration."""
strands_telemetry = StrandsTelemetry()
strands_telemetry.setup_otlp_exporter()
agent = Agent(
model=bedrock_model,
system_prompt=system_prompt,
tools=[web_search]
)
return agent
@app.entrypoint
def strands_agent_bedrock(payload, context=None):
"""
Invoke the agent with a payload
"""
user_input = payload.get("prompt")
logger.info("[%s] User input: %s", context.session_id, user_input)
agent = initialize_agent()
response = agent(user_input)
return response.message['content'][0]['text']
if __name__ == "__main__":
app.run()
Passo 3: Configuração do AgentCore Runtime
Utilize o kit de iniciação para configurar a implantação do AgentCore Runtime com o ponto de entrada, a função de execução e o arquivo de requisitos. O kit de iniciação também cria automaticamente o repositório Amazon Elastic Container Registry (ECR). Durante a etapa de configuração, o dockerfile é gerado com base no código da aplicação.
Configuração do AgentCore Runtime com decorador e arquivo Docker
Importante: ao configurar o agente com o kit de iniciação, o AgentCore Observability é ativado por padrão. Para usar Langfuse, desative OTEL definindo o sinalizador de configuração como “True”:
Após gerar o dockerfile, inicie o agente no AgentCore Runtime. Configure as chaves e endpoints da Langfuse no AWS Systems Manager Parameter Store para armazenamento seguro e hierárquico de dados de configuração:
Aguarde até que o runtime esteja pronto antes de invocar:
import time
status_response = agentcore_runtime.status()
status = status_response.endpoint['status']
end_status = ['READY', 'CREATE_FAILED', 'DELETE_FAILED', 'UPDATE_FAILED']
while status not in end_status:
time.sleep(10)
status_response = agentcore_runtime.status()
status = status_response.endpoint['status']
print(status)
status
Uma implantação bem-sucedida exibe o status "READY" para o agente runtime.
Passo 6: Invocação do AgentCore Runtime
Com o runtime pronto, invoque-o com uma carga útil de teste:
invoke_response = agentcore_runtime.invoke({"prompt": "I'm planning a weekend trip to london. What are the must-visit places and local food I should try?"})
Visualizando Traces na Langfuse
Após executar o agente, acesse o painel do projeto Langfuse para visualizar os traces detalhados. Os traces incluem:
Detalhes de invocação do agente
Chamadas de ferramentas (buscas na web)
Interações com modelos, incluindo latência e uso de tokens
Payloads de requisição e resposta
Hierarquia completa de traces
A Langfuse captura todas as interações, desde requisições de usuários até chamadas individuais de modelos. Cada trace captura o caminho de execução completo, incluindo chamadas de API, invocações de funções e respostas de modelos, criando uma linha do tempo abrangente das atividades do agente. A estrutura aninhada de traces permite aos desenvolvedores investigar interações específicas e identificar gargalos de desempenho ou padrões de erro em qualquer nível da cadeia de execução.
Visualização de traces hierárquicos na Langfuse mostrando execução completa do agente
Análise Hierárquica de Desempenho
A combinação de traces hierárquicos com marcação estratégica fornece insights profundos sobre operações de agentes, possibilitando otimizações orientadas por dados e experiências de usuário superiores. Ao investigar a hierarquia detalhada, você consegue visualizar o tempo preciso de cada operação dentro do fluxo de execução do agente. Por exemplo, uma requisição completa pode levar 26,57 segundos, com detalhamentos individuais para ciclo de evento, chamadas de ferramentas e outros componentes. Use essas informações de tempo para identificar gargalos de desempenho e reduzir tempos de resposta. Certas operações de IA podem levar mais tempo que o esperado, ou pode haver oportunidades para paralelizar ações específicas e reduzir a latência geral.
Hierarquia detalhada de trace mostrando timings de cada operação do agente
Dashboards de Monitoramento da Langfuse
A Langfuse oferece três dashboards diferentes para monitoramento: Custo, Latência e Gerenciamento de Uso. Cada um fornece perspectivas específicas sobre o desempenho e eficiência das aplicações com agentes.
Visão geral dos três dashboards disponíveis na Langfuse para monitoramento
Monitoramento de Custos
O monitoramento de custos ajuda a acompanhar despesas tanto em nível agregado quanto em requisições individuais, mantendo o controle sobre despesas de infraestrutura de IA. A plataforma fornece detalhamentos de custo granulares por modelo, usuário e chamada de função, permitindo que equipes identifiquem operações que consomem mais recursos e otimizem suas implementações. Essa visibilidade granular de custos facilita tomadas de decisão baseadas em dados sobre seleção de modelos, engenharia de prompts e alocação de recursos, mantendo restrições orçamentárias.
Dashboard de custos da Langfuse mostrando custos totais, por modelo e por ambiente
Dashboard de Latência
Métricas de latência podem ser monitoradas através de traces e gerações para otimização de desempenho. O dashboard exibe por padrão métricas como latência P95 por nível, latência máxima por ID de usuário, tempo médio até primeiro token por nome de prompt, latência P95 por modelo e tokens de saída médios por segundo por modelo. É possível criar gráficos e dashboards customizados conforme necessário.
Dashboard de latência da Langfuse com métricas de desempenho por modelo
Gerenciamento de Uso
Este dashboard apresenta métricas através de traces, observações e pontuações para gerenciar alocação de recursos. Oferece visibilidade completa sobre como os recursos estão sendo consumidos pela aplicação, ajudando equipes a otimizar a utilização e garantir eficiência operacional.
Dashboard de gerenciamento de uso da Langfuse com contagens de traces e observações
Conclusão
A integração entre Langfuse e Amazon Bedrock AgentCore oferece um caminho sólido para alcançar observabilidade completa em aplicações com agentes de IA. Com essas ferramentas, equipes conseguem rastrear desempenho em detalhes, depurar interações complexas e otimizar custos de forma contínua.
Ao implementar Langfuse com AgentCore hoje, você ganha visibilidade profunda no desempenho de seus agentes, consegue rastrear fluxos de conversação e otimizar aplicações de IA para oferecer melhor valor a seus usuários. A capacidade de compreender cada etapa da execução de um agente transforma-se em vantagem competitiva no desenvolvimento de sistemas de IA confiáveis e eficientes.
