A AWS anunciou nesta semana a disponibilidade em prévia das novas instâncias M9g do Amazon EC2, equipadas com os processadores AWS Graviton5. Trata-se da evolução mais recente da linha de processadores Graviton, desenvolvidos especificamente pela AWS para entregar o melhor custo-benefício em cargas de trabalho rodando no Amazon EC2.
Melhorias de desempenho
As instâncias M9g trazem ganhos significativos em relação à geração anterior (M8g, baseada em Graviton4). Segundo a empresa, os novos processadores oferecem até 25% melhor desempenho de computação. Além disso, proporcionam maior largura de banda tanto para rede quanto para o Amazon EBS (Elastic Block Store, o serviço de armazenamento em blocos da AWS).
Em cenários específicos, os ganhos são ainda mais expressivos: as instâncias M9g apresentam até 35% de velocidade maior para aplicações web e até 35% de aceleração para cargas de machine learning. Para bancos de dados, o ganho chega a 30%.
Arquitetura e recursos
Essas instâncias foram construídas sobre o AWS Nitro System, um conjunto de inovações em hardware e software desenvolvidas pela AWS. O Nitro System é projetado para viabilizar serviços em nuvem eficientes, flexíveis e seguros, com suporte a multitenância isolada, redes privadas e armazenamento local de rápido acesso.
Casos de uso
De acordo com a AWS, as instâncias Amazon EC2 M9g são ideais para uma variedade de cargas de trabalho, incluindo servidores de aplicação, microsserviços, servidores de gaming, armazenamentos de dados de médio porte e frotas de cache.
Próximos passos
Quem deseja explorar essas novas instâncias pode solicitar acesso à prévia através da página de instâncias M9g. Para quem está começando sua jornada com processadores Graviton, a AWS disponibiliza recursos complementares sobre como potencializar seu compute com AWS Graviton.
A conferência re:Invent 2025 trouxe consigo um importante reconhecimento sobre a evolução das despesas em segurança corporativa. Conforme apontam dados de pesquisa do mercado, as organizações devem aumentar seus investimentos em segurança de forma substancial nos próximos anos. O panorama de investimentos reflete uma preocupação crescente das empresas em proteger suas implementações de inteligência artificial generativa enquanto expandem suas operações digitais. Esse direcionamento de recursos demonstra como a segurança permanece como prioritária nas estratégias de transformação digital, especialmente em um cenário onde as tecnologias de IA se tornam cada vez mais centrais nos negócios.
A AWS respondeu a essa demanda apresentando uma abordagem integrada que combina inteligência artificial, machine learning e automação para fortalecer a segurança de forma proativa. As inovações anunciadas cobrem múltiplas camadas de proteção — desde aplicações até infraestrutura, passando por redes e dados — criando uma defesa em profundidade capaz de enfrentar ameaças sofisticadas, vulnerabilidades emergentes e configurações incorretas que possam interromper operações.
Agentes de segurança com IA integrados aos fluxos de trabalho
Uma das principais novidades apresentadas foi a incorporação de agentes de IA diretamente nos processos de segurança corporativa. Esses agentes executam tarefas especializadas como revisões de código, consolidação de sinais de resposta a incidentes e proteção de acesso para outros agentes autônomos.
AWS Security Agent — segurança desde o design
O AWS Security Agent funciona como um agente de fronteira que atua de forma proativa durante todo o ciclo de desenvolvimento das aplicações. Sua função inclui realizar revisões automatizadas de segurança adaptadas aos requisitos específicos de cada organização, além de oferecer testes de penetração sob demanda com contexto específico do ambiente. Ao validar continuamente a segurança desde a fase de design até o lançamento em produção, esse agente contribui para prevenir vulnerabilidades nos estágios iniciais do desenvolvimento, reduzindo riscos e custos de remediação posterior.
Resposta a incidentes com capacidades agentic
O AWS Security Incident Response traz capacidades de investigação potencializadas por IA agentic, projetadas para aprimorar e acelerar a resposta a eventos de segurança, bem como o tempo de recuperação. A automação nesse nível permite que equipes de segurança se dediquem a tarefas estratégicas enquanto o sistema executa investigações em paralelo.
Controle de identidade para agentes IA
O AgentCore Identity agora oferece autenticação melhorada que proporciona controles de acesso específicos para agentes IA. Esses controles determinam precisamente com quais serviços e dados os agentes podem interagir, respeitando permissões e atributos do usuário. Estabelecer limites granulares sobre como agentes autônomos interagem com aplicações corporativas diminui significativamente os riscos de acesso não autorizado ou exposição de dados.
Detecção de ameaças impulsionada por machine learning e automação
Os modelos de machine learning e processos automatizados agora aceleram a detecção de ameaças em mais ambientes da AWS. Essa capacidade permite identificar correlações que seriam difíceis de discernir manualmente, especialmente em ataques sofisticados com múltiplas etapas coordenadas, operando em escala.
Detecção estendida para EC2 e ECS
O GuardDuty extended threat detection para EC2 e ECS utiliza algoritmos avançados de IA e machine learning para identificar ataques sofisticados em múltiplas etapas direcionados a contas AWS, cargas de trabalho e dados em máquinas virtuais, contêineres e ambientes sem servidor. A automatização reduz o tempo necessário ao correlacionar sinais de diferentes fontes em sequências consolidadas, facilitando a análise de investigadores.
Proteção contra malware em backups
O GuardDuty malware protection para AWS Backup realiza varreduras automáticas de backups de EC2, EBS e S3 em busca de malware. Esse serviço ajuda as organizações a identificar seu último backup conhecido como limpo, minimizando interrupções durante o processo de recuperação. Adicionalmente, suporta varredura incremental de novos dados entre execuções de backup, otimizando tempo e recursos.
Análise em tempo quase real da postura de segurança
Gerenciamento de identidades e acesso centrado em agentes
Os controles de acesso inteligente estão redefinindo a forma como as organizações gerenciam identidades e permissões. Essas soluções automatizam a geração de políticas e elevam o nível de maturidade em modelos de confiança zero, tornando mais acessível o uso dos serviços AWS.
Geração automática de políticas de IAM
O IAM policy autopilot permite que assistentes de código com IA criem rapidamente políticas de IAM (Gerenciamento de Identidades e Acesso) de linha de base, que as equipes podem refinar conforme a aplicação evolui. Essa abordagem acelera o processo de desenvolvimento sem comprometer os padrões de segurança.
Federação de identidades para serviços externos
O Outbound identity Federation permite que clientes de IAM façam federação segura de suas identidades AWS com serviços externos. Essa capacidade facilita a autenticação de cargas de trabalho AWS com provedores de nuvem, plataformas SaaS e aplicações hospedadas internamente, ampliando a interoperabilidade.
Acesso privado ao console AWS
O Private access sign-in roteia 100% do tráfego do console através de endpoints de VPC em vez de internet pública, utilizando roteamento inteligente para manter a segurança sem prejudicar o desempenho. Essa abordagem fornece camada adicional de proteção para acessos administrativos.
Acesso programático para desenvolvimento local
O Login para desenvolvimento local AWS permite que desenvolvedores utilizem suas credenciais de console existentes para acessar programaticamente a AWS em ambientes de desenvolvimento local. Essa simplificação reduz a complexidade de gerenciamento de credenciais sem sacrificar a segurança.
Transformação da segurança através de IA e automação
Coletivamente, esses avanços em IA e machine learning transformam a segurança de um modelo reativo e manual para um modelo proativo e escalável. As organizações conseguem agora operacionalizar a busca de ameaças e avançar sua postura de segurança mesmo enquanto expandem sua pegada digital. A confiança que as organizações depositam em segurança nativa de nuvem valida essa abordagem. Pesquisa com 2.800 profissionais de segurança e TI tomadores de decisão patrocinada pela AWS revelou dados significativos sobre essa percepção: 81% concordam que as capacidades nativas de segurança e conformidade de seu provedor de nuvem primário superam o que suas equipes conseguiriam entregar de forma independente. Adicionalmente, 56% responderam que nuvem pública está melhor posicionada para entregar segurança em comparação com 37% que selecionaram infraestrutura local, e 51% acreditam que nuvem pública está melhor preparada para atender regulamentações versus 41% que selecionaram ambientes on-premises.
A nuvem permanece como fundação sobre a qual organizações constroem seus negócios, e a AWS segue ampliando seu portfólio de inovações em segurança que reforçam essa fundação. As capacidades apresentadas na re:Invent 2025 refletem essa trajetória contínua de evolução, especialmente no contexto de organizações que buscam proteger suas investidas em inteligência artificial enquanto escalam suas operações digitais.
O desafio de levar dados corporativos para contexto de requisições a modelos de linguagem grandes (LLMs) mantém organizações atentas à segurança e conformidade com políticas empresariais. Para padronizar e proteger essas interações, muitas empresas adotam o Model Context Protocol (MCP), uma especificação que define como aplicações agentic se conectam seguramente a fontes de dados e ferramentas.
Embora o MCP tenha se mostrado vantajoso para novos casos de uso, organizações enfrentam desafios ao trazer seus ecossistemas de API existentes para a era agentic. Enquanto o MCP consegue envolver APIs existentes, isso exige trabalho adicional: tradução de requisições de MCP para REST, garantia de segurança em todo o fluxo e aplicação de observabilidade necessária para ambientes de produção.
A AWS anunciou que o Amazon Bedrock AgentCore Gateway agora suporta o Amazon API Gateway como alvo, traduzindo requisições MCP para o AgentCore Gateway em chamadas REST para o API Gateway. Isso permite expor endpoints de API novos e existentes a aplicações agentic usando MCP, com segurança e observabilidade já integradas.
O que mudou: Suporte a API Gateway no AgentCore Gateway
O AgentCore Gateway agora suporta tipos de alvo existentes ampliados com API Gateway, além de funções Lambda, esquemas OpenAPI, modelos Smithy e servidores MCP. Muitos clientes AWS construíram ecossistemas extensos de APIs usando API Gateway, conectando backends em diversas aplicações. Conforme as empresas evoluem para aplicações agentic de próxima geração, a evolução natural é expor essas APIs existentes e ferramentas de backend para sistemas alimentados por inteligência artificial, permitindo integração perfeita entre infraestrutura estabelecida e agentes inteligentes modernos.
Essa integração entre AgentCore Gateway e API Gateway simplifica a conexão entre os dois serviços. Permite direcionar diretamente o API Gateway, sem necessidade de exportar APIs do API Gateway como especificação OpenAPI 3 e depois adicioná-las ao AgentCore Gateway como alvo OpenAPI. Com essa integração, um novo tipo de alvo API_GATEWAY é adicionado ao AgentCore Gateway, eliminando o processo manual de exportação e importação.
Proprietários de APIs REST podem adicionar sua API como alvo do AgentCore Gateway com poucas interações no console ou um único comando CLI, expondo sua API REST existente como ferramentas MCP através do AgentCore Gateway. Consumidores de API podem então conectar agentes de IA a essas APIs REST via Model Context Protocol (MCP) e potencializar seus fluxos de trabalho com integração de IA.
A integração entre AgentCore Gateway e API Gateway oferece suporte a autorização por IAM e chave de API. Tanto AgentCore Gateway quanto API Gateway possuem integrações com Amazon CloudWatch Logs, AWS CloudTrail e AWS X-Ray para observabilidade. Desenvolvedores de agentes que usam essa nova capacidade entre AgentCore Gateway e API Gateway podem aproveitar essas ferramentas de observabilidade.
Configuração e implementação
Este tópico apresenta como configurar uma API REST existente no API Gateway como alvo para AgentCore Gateway, permitindo usar APIs REST existentes como ferramentas para aplicações agentic expostas através do AgentCore Gateway.
Pré-requisitos
Para este exemplo, você precisa de:
Uma conta AWS com uma API REST existente no API Gateway
Uma função ou usuário Identity and Access Management (IAM) com permissões suficientes para criar um AgentCore Gateway e configurar um alvo API Gateway
Gateways e alvos podem ser criados de múltiplas formas:
Este artigo utiliza Boto3 para configurar a integração entre AgentCore Gateway e API Gateway. Para um guia interativo, você pode usar o exemplo de Jupyter Notebook no GitHub.
Configuração de autorização de entrada e saída
Configure os pré-requisitos para autorização de entrada e saída. Autorização de entrada autentica requisições de usuários recebidas. Autorização de saída ajuda AgentCore Gateway a conectar-se seguramente a alvos de gateway, como API Gateway, em nome do usuário autenticado.
Para API Gateway como alvo, AgentCore Gateway oferece suporte aos seguintes tipos de autorização de saída:
Sem autorização (não recomendado) — Alguns tipos de alvo oferecem a opção de contornar autorização de saída. Essa opção menos segura não é recomendada.
Autorização baseada em IAM — Use a função de serviço do gateway para autorizar acesso ao alvo de gateway com AWS Signature Version 4 (Sig V4).
Chave de API — Use a chave de API configurada usando AgentCore Identity para autorizar acesso ao alvo API Gateway. Chaves de API criadas usando um API Gateway mapeado com planos de uso API Gateway ajudam a monitorar e controlar o uso da API.
Criar um papel IAM
Crie uma função IAM com a política de confiança da documentação. Para autorização de saída com autorização baseada em IAM, a política deve incluir a permissão execute-api:Invoke.
Para autorização por chave de API, crie uma chave de API e associe-a ao seu plano de uso API Gateway. Depois, crie um provedor de credencial de chave de API com AgentCore Identity. Uma vez feito isso, atualize a política conforme descrito na documentação do AgentCore Gateway.
Criar um AgentCore Gateway
Ao usar o kit de ferramentas AgentCore starter, você pode criar um gateway com uma configuração de autorização padrão usando Amazon Cognito para autorização de entrada baseada em JWT.
Isso retorna um GATEWAY_ID que você precisará para criar o alvo do gateway.
Criar um alvo do AgentCore Gateway
Para criar um alvo API Gateway, você precisa especificar o seguinte como parte da configuração de alvo:
toolFilters — Use para determinar quais recursos da API REST serão expostos como ferramenta no gateway. Os filtros também suportam wildcards no caminho de filtro.
toolOverrides (opcional) — Permite que usuários substituam nomes e descrições de ferramentas. Você deve especificar caminhos e métodos explícitos.
restApiId — Use para passar a ID do API Gateway.
Abaixo estão exemplos de configurações de alvo:
Exemplo 1 — Expõe GET e POST em /pets, GET em /pets/{petId} para o gateway e substitui seus nomes e descrições de ferramentas:
{
"mcp": {
"apiGateway": {
"restApiId": "",
"stage": "",
"apiGatewayToolConfiguration": {
"toolFilters": [
{
"filterPath": "/pets",
"methods": ["GET","POST"]
},
{
"filterPath": "/pets/{petId}",
"methods": ["GET"]
}
],
"toolOverrides" : [
{
"name": "ListPets",
"path": "/pets",
"method": "GET",
"description":"Retrieves all the available Pets."
},
{
"name": "AddPet",
"path": "/pets",
"method": "POST",
"description":"Add a new pet to the available Pets."
},
{
"path": "/pets/{petId}",
"method": "GET",
"name": "GetPetById",
"description": "Retrieve a specific pet by its ID"
}
]
}
}
}
}
Exemplo 2 — Expõe GET em /pets e também GET em /pets/{petId} ou qualquer coisa sob /pets. Como toolOverrides não está especificado, usará a descrição de recurso do API Gateway:
Ao criar um alvo, você também precisa especificar a autorização de saída do alvo usando uma configuração de provedor de credencial. Existem três tipos de provedores de credencial:
GATEWAY_IAM_ROLE — Usa a ROLE_ARN especificada ao criar o gateway:
Teste o gateway com o framework Strands Agents para listar e chamar as ferramentas disponíveis do servidor MCP. Você também pode usar outros agentes compatíveis com MCP construídos com diferentes frameworks agentic.
def create_streamable_http_transport():
return streamablehttp_client(
gatewayURL,
headers={"Authorization": f"Bearer {}"}
)
client = MCPClient(create_streamable_http_transport)
with client:
tools = client.list_tools_sync()
agent = Agent(model=yourModel, tools=tools)
agent("Hi, can you list all tools available to you")
agent("List all the available pets")
agent("Tell me about the pet with petId 3")
agent("When my order will be delivered? My order id is 2")
Você observará uma saída como a seguinte:
I have access to the following tools:
1. **x_amz_bedrock_agentcore_search** - A search tool that returns a trimmed down list of tools based on a provided context/query
2. **api-gateway-target-1___Add_Pet** - Add a new pet to the available Pets
3. **api-gateway-target-1___GetPetById** - Retrieve a specific pet by its ID (requires petId parameter)
4. **api-gateway-target-1___List_Pets** - Retrieves all the available Pets (optional parameters: page, type)
5. **api-gateway-target-2___GetOrderById** - Retrieve a specific order by its ID (requires orderId parameter)
I'll retrieve all the available pets for you.
Tool #1: api-gateway-target-1___List_Pets
"HTTP/1.1 200 OK"
Here are all the available pets:
1. **Pet ID 1** - Dog - $249.99
2. **Pet ID 2** - Cat - $124.99
3. **Pet ID 3** - Fish - $0.99
I'll retrieve the details for pet ID 3.
Tool #2: api-gateway-target-1___GetPetById
"HTTP/1.1 200 OK"
Here are the details for pet ID 3:
- **Pet ID**: 3
- **Type**: Fish
- **Price**: $0.99
I'll check the details of your order with ID 2 to see the delivery information.
Tool #3: api-gateway-target-2___GetOrderById
"HTTP/1.1 200 OK"
Based on your order details:
- **Order ID**: 2
- **Pet Category**: Cat
- **Price**: $124.99
- **Delivery Date**: 02-12-2025 (December 2nd, 2025)
Your cat order will be delivered on **December 2nd, 2025**.
Observabilidade
Ative logs de aplicação e rastreamento para seu recurso AgentCore Gateway. Você verá logs detalhados que ajudam a monitorar e solucionar problemas do seu recurso AgentCore Gateway. Isso inclui as chamadas de ferramenta realizadas pela sua aplicação agentic, parâmetros de requisição, respostas e erros, se houver.
O AgentCore Gateway oferece métricas detalhadas do CloudWatch incluindo métricas de uso (TargetType, IngressAuthType, EgressAuthType, RequestsPerSession), métricas de invocação (Invocations, ConcurrentExecutions, Sessions), métricas de desempenho (Latency, Duration, TargetExecutionTime) e taxas de erro (Throttles, SystemErrors, UserErrors).
O AgentCore Gateway também suporta AWS X-Ray e spans conformes a OTEL que clientes podem usar para rastrear invocações em diferentes primitivas sendo utilizadas. Para saber mais, consulte a documentação de observabilidade do AgentCore Gateway.
O AgentCore Gateway agora oferece suporte ao Amazon API Gateway como alvo, expondo APIs REST como endpoints compatíveis com MCP. Você pode trazer sua infraestrutura de API existente para casos de uso agentic enquanto utiliza suas ferramentas de segurança e observabilidade atuais.
A AWS anunciou suporte a ajuste fino com aprendizado por reforço no Amazon Bedrock, democratizando uma técnica avançada de customização de modelos que antes era acessível apenas a especialistas. O recurso elimina barreiras como a necessidade de expertise profunda em aprendizado de máquina ou grandes volumes de dados rotulados.
A plataforma automatiza todo o fluxo de trabalho, permitindo que equipes de desenvolvimento comum implementem esta abordagem sofisticada. Os modelos aprendem através de feedback sobre múltiplas respostas possíveis para o mesmo prompt, refinando o seu julgamento sobre o que constitui uma boa resposta. Este método requer apenas um pequeno conjunto de prompts, em contraste com os volumes massivos necessários para métodos tradicionais de ajuste fino.
Impacto em precisão e custo
O ajuste fino com aprendizado por reforço no Amazon Bedrock entrega ganhos médios de 66% em precisão quando comparado aos modelos base. Este ganho significativo permite que as organizações utilizem variantes de modelos menores, mais rápidos e economicamente mais eficientes, mantendo qualidade elevada.
Resolvendo o dilema das empresas
Muitas organizações enfrentam um dilema ao tentar adaptar modelos de IA às suas necessidades específicas: escolher entre modelos genéricos com desempenho médio ou investir em customizações complexas que demandam talento especializado, infraestrutura dedicada e movimento arriscado de dados.
O ajuste fino com aprendizado por reforço no Amazon Bedrock simplifica este cenário ao tornar a customização avançada rápida, automatizada e segura. Os dados proprietários nunca deixam o ambiente seguro e governado da AWS durante todo o processo de customização, mitigando preocupações de segurança e conformidade.
Como começar
O fluxo de trabalho é flexível: você pode enviar dados de treinamento diretamente do seu computador ou utilizar datasets já armazenados no Amazon S3, eliminando a necessidade de datasets rotulados previamente.
A definição de funções de recompensa oferece duas abordagens: verificadores baseados em regras ou juízes alimentados por IA, além de templates integrados. Esta flexibilidade permite otimizar modelos tanto para tarefas objetivas — como geração de código ou raciocínio matemático — quanto para tarefas subjetivas, como seguimento de instruções ou interações de chatbot.
Você pode começar com ajuste fino por reforço no Amazon Bedrock através do console do Amazon Bedrock ou via APIs do Amazon Bedrock. No lançamento inicial, o recurso está disponível com o Amazon Nova 2 Lite, com suporte para modelos adicionais previsto em breve.
A AWS anunciou que o Amazon Connect Chat agora oferece suporte a fluxos de trabalho iniciados por agentes. Essa funcionalidade permite que os atendentes (agentes de suporte) enviem formulários interativos diretamente aos clientes durante uma conversa de chat, sem interrupções no diálogo.
Esses formulários podem ser usados para coletar informações sensíveis ou compartilhar políticas e divulgações de forma segura e organizada, tudo dentro do contexto da conversa. Isso representa uma evolução importante para plataformas de atendimento ao cliente que buscam equilibrar segurança, conformidade e experiência do usuário.
Como funciona na prática?
Uso em tempo real
Os agentes agora podem disparar esses fluxos a qualquer momento durante uma conversa, tornando as interações mais dinâmicas e responsivas às necessidades específicas do cliente. Por exemplo: quando um cliente precisa atualizar seu endereço cadastrado, o agente pode enviar um formulário que o cliente preenche sem sair da interface de chat.
Manutenção de segurança e conformidade
Como tudo ocorre dentro da própria conversa de chat, as empresas conseguem manter padrões de segurança e conformidade regulatória, ao mesmo tempo que oferecem soluções mais rápidas ao cliente. Essa abordagem elimina a necessidade de redirecionar o usuário para outras interfaces ou plataformas.
Disponibilidade regional
Essa nova funcionalidade já está disponível nos seguintes pontos de presença da AWS:
Regiões da América do Norte: US East (N. Virginia) e US West (Oregon)
Regiões da Ásia-Pacífico: Seoul, Singapore, Sydney e Tokyo
Regiões da América do Norte: Canada (Central)
Regiões da Europa: Frankfurt e London
Regiões da África: Cape Town
Para explorar mais
Quem deseja implementar essa funcionalidade pode consultar a documentação oficial do Amazon Connect para obter detalhes técnicos e práticas recomendadas.
A análise de risco em seguros enfrenta um cenário complexo: os analistas precisam examinar múltiplas fontes de dados, avaliar riscos e tomar decisões que atendam a requisitos regulatórios cada vez mais rigorosos. Esse processo se torna ainda mais desafiador quando a organização enfrenta três problemas críticos.
Primeiro, os dados estão fragmentados. Informações de clientes residem em sistemas de Gestão de Relacionamento com Clientes (Sistemas de CRM), repositórios de documentos e bases de dados transacionais, criando silos que dificultam uma análise integrada e confiável.
Segundo, há pressão regulatória. As autoridades exigem decisões que sejam explicáveis e auditáveis — propriedades que abordagens tradicionais baseadas em modelos de “caixa preta” não conseguem fornecer adequadamente.
Terceiro, há necessidade de escala. As organizações precisam manter regras de análise consistentes e automatizadas em todo o portfólio, com capacidade de identificar proativamente sinais de fraude e comportamentos suspeitos.
Uma solução integrada com inteligência artificial
A AWS apresenta uma arquitetura que combina diferentes componentes para resolver esses desafios. O pilar técnico dessa solução é o Amazon Nova 2 Lite, um modelo de linguagem que fornece raciocínio transparente e explicável para cada decisão tomada.
Como funciona a arquitetura
A solução utiliza o Protocolo de Contexto de Modelo (MCP) para criar ferramentas especializadas em três tarefas: detecção de fraude em seguros, avaliação de risco de um solicitante e tomada de decisão sobre cobertura. Quando uma ferramenta é acionada a partir de uma consulta, ela acessa dados de fontes específicas — repositórios de documentos como Amazon Simple Storage Service (S3) e bases de dados como Amazon DynamoDB — e invoca o Amazon Nova 2 Lite para análise e geração de recomendações.
Depois de recuperar as instruções de sistema e o contexto necessário, o modelo retorna uma resposta estruturada conforme esperado pela ferramenta. O servidor MCP é hospedado no Amazon Bedrock AgentCore Runtime com autorização de entrada via OAuth 2.0. Já o cliente MCP do Amazon Quick Suite é configurado com autenticação de serviço para permitir conexões de entrada ao servidor MCP.
A interação do usuário ocorre de forma natural: o agente de conversa processa consultas em linguagem natural, invoca as ferramentas MCP necessárias e mantém diálogos interativos com múltiplas trocas de mensagens.
O cliente MCP do Quick Suite solicita um token de acesso do Amazon Cognito usando credenciais de cliente OAuth. O Cognito valida as credenciais e emite um token de curta duração. O Quick Suite inclui esse token na requisição ao AgentCore Runtime, que valida o token contra o Cognito.
O AgentCore Runtime possui uma tradução integrada que transforma a requisição de entrada no formato JSON-RPC 2.0 do MCP e invoca as ferramentas apropriadas. O registro de eventos pode ser habilitado para registrar tudo no Amazon CloudWatch.
O servidor MCP executa a lógica das ferramentas, recupera dados do DynamoDB e S3, e invoca o Amazon Nova 2 Lite através da API Converse do Amazon Bedrock para gerar uma resposta com um processo detalhado de raciocínio. A resposta é transformada novamente para corresponder ao protocolo do Quick Suite e retornada ao usuário através da interface do assistente.
O Amazon Nova 2 Lite oferece capacidades importantes nesse cenário: consegue solicitar ferramentas e compreender seus esquemas, realiza raciocínio para determinar quais ferramentas são necessárias baseado nas perguntas do usuário, e então gera requisições de ferramentas com parâmetros validados que o servidor MCP executa.
Implementação prática da solução
Pré-requisitos
Para colocar em prática essa solução, você precisará de:
Amazon Quick Suite configurado com assinatura Author Pro
Permissão para criar funções e políticas de AWS Identity and Access Management (IAM) e recursos AWS, incluindo tabela DynamoDB, bucket S3, pool de usuários Cognito e AgentCore Runtime
Acesso a um ambiente de linha de comando com AWS SDK e Python instalados
Hospedagem do servidor MCP
A implementação começa clonando o repositório de código correspondente. Em seguida, você edita o arquivo de configuração config/enterprise_config.yaml para fornecer o nome do servidor MCP, o pool de usuários Cognito, as tabelas DynamoDB contendo solicitantes e sinistros, e o bucket S3 para registros médicos.
Depois, configura um ambiente virtual Python com as dependências necessárias:
Opcionalmente, você pode gerar dados sintéticos de solicitantes, registros médicos e sinistros. A geração de dados sintéticos utiliza a biblioteca faker para criar registros de solicitantes e sinistros que são persistidos no DynamoDB e registros médicos que são persistidos no S3 em formato JSON. Você pode modificar o esquema ou formatos de registro personalizando o script de carregamento conforme suas necessidades.
Com tudo preparado, você implanta o servidor MCP no Amazon Bedrock AgentCore executando o script de implantação. Este passo cria um pool de usuários Cognito, constrói uma imagem Docker, a implanta no AgentCore, configura permissões IAM, e gera a documentação com a URL do endpoint do servidor MCP e configuração OAuth necessária para integração com o Quick Suite.
Para validar que tudo funcionou corretamente, executa o teste de funcionalidade das ferramentas MCP. A execução bem-sucedida fornecerá uma saída confirmando que o servidor foi implantado e operacional.
Integração com Quick Suite
Depois, você estabelece uma conexão OAuth de serviço a serviço do Quick Suite para o endpoint hospedado no Amazon Bedrock AgentCore. Essa conexão permite que seu agente de conversa do Quick Suite invoque ações do servidor MCP para cumprir solicitações dos usuários.
No console do Quick Suite, você navega até Integrações e cria uma nova integração MCP. Na página de configuração de conexão, fornece os detalhes do servidor MCP: um nome (por exemplo, “Especialista em Análise de Seguros”), uma descrição opcional e a URL do endpoint do servidor MCP.
Na página de autenticação, você seleciona autenticação de serviço, escolhe OAuth de serviço a serviço como tipo de autenticação, e fornece o ID de cliente, segredo do cliente e URL do token. Depois de revisar e confirmar, a integração está pronta.
Para testar, você acessa a seção de Integrações no console, verifica que o status está “Disponível”, seleciona a integração criada e testa as APIs de ação para confirmar que estão funcionando corretamente.
Criando o agente de conversa personalizado
Agora você cria um agente de conversa customizado no Quick Suite. Você fornece um nome para identificar o agente e uma descrição opcional que ajude os usuários a entender seu propósito.
Na configuração do agente, você define sua identidade. Um exemplo seria: “Você é Nova, um Analista de Seguros baseado em IA com expertise profunda em avaliação de risco explicável e detecção de fraude. Você tem acesso a dados empresariais de seguros incluindo mais de 1000 perfis de solicitantes, registros médicos e histórico de sinistros através de capacidades avançadas de raciocínio”.
Você também fornece instruções de persona que definem como o agente interage com usuários durante a conversa. Por exemplo, instruções que enfatizam transparência, explicam o nível de confiança nas recomendações, decompõem decisões complexas em passos lógicos claros, referenciam perfis específicos de solicitantes quando disponível, fornecem pontuações de risco com explicações detalhadas dos fatores contribuintes, incluem considerações de conformidade regulatória, e oferecem perguntas de acompanhamento para aprofundar a análise quando apropriado.
Na seção de Ações, você vincula o conector de ação que criou, lançando o agente. Após alguns minutos, o agente estará operacional e pronto para conversar.
Você pode começar pedindo ao agente uma avaliação de risco específica — por exemplo, “Avalie o risco para o solicitante APP-0900”. O agente processará a requisição, invocará as ações necessárias, e retornará uma análise detalhada. A interface da conversa pode solicitar informações adicionais para algumas ações antes de proceder, garantindo precisão na análise.
Benefícios da abordagem
Essa arquitetura soluciona os três desafios centrais mencionados no início. Primeiro, unifica dados de DynamoDB e S3, permitindo que o sistema acesse informações completas sobre solicitantes, registros e histórico de sinistros em uma única consulta. Segundo, entrega raciocínio passo a passo transparente para cada decisão, atendendo requisitos regulatórios de explicabilidade e auditoria. Terceiro, mantém trilhas de auditoria completas no CloudWatch para conformidade regulatória, e permite que investigadores façam perguntas como “Mostre-me todos os sinistros registrados dentro de 30 dias do início da apólice” para identificar padrões suspeitos.
Com essa solução em operação, você consegue escalar análises de risco — líderes de negócios ganham inteligência de portfólio em tempo real através de interações em linguagem natural, e todo o processo de análise é rastreável e auditável do início ao fim.
Limpeza de recursos
Após experimentar a solução, você pode remover todos os recursos AWS criados para evitar cobranças contínuas usando o script fornecido na documentação de implantação.
A AWS anunciou a disponibilidade do SES Mail Manager em 10 regiões comerciais adicionais. Esta expansão leva o serviço de um total de 17 regiões para 27 regiões, consolidando uma cobertura significativa. A novidade marca um passo importante: o Mail Manager agora está disponível em todas as regiões comerciais onde o SES oferece seu serviço principal de envio de emails (Outbound).
O que é o SES Mail Manager
O SES Mail Manager é um serviço da AWS que permite aos clientes configurar mecanismos de roteamento e entrega de emails para seus domínios. Mais que isso, oferece uma visualização única de governança de emails, gerenciamento de riscos e soluções de conformidade para todos os trabalhos relacionados a emails na organização.
Na prática, as empresas implantam o Mail Manager para substituir soluções legadas de retransmissão de emails hospedados ou para simplificar a integração com provedores de caixas de correio terceirizados e soluções de segurança de email. O serviço também oferece funcionalidades complementares:
Integração com caixas de correio WorkMail
Arquivamento integrado com capacidades de busca e exportação
Integração com complementos de segurança terceirizados diretamente no console
As 10 novas regiões
As regiões recém-adicionadas incluem:
Oriente Médio (Bahrein)
Ásia Pacífico (Jacarta)
África (Cidade do Cabo)
Oriente Médio (Emirados Árabes Unidos)
Ásia Pacífico (Hyderabad)
Ásia Pacífico (Malásia)
Europa (Milão)
Israel (Tel Aviv)
Canadá Oeste (Calgary)
Europa (Zurique)
Como começar
Para ter acesso à lista completa de regiões onde o Mail Manager está disponível, consulte a documentação de disponibilidade de regiões. Para aprender mais detalhes sobre o serviço, visite a página do produto Amazon SES Mail Manager e a documentação completa. Você pode começar a usar o Mail Manager nessas novas regiões imediatamente através do console da Amazon SES.
A AWS anunciou uma expansão significativa na disponibilidade do modelo Pegasus 1.2, desenvolvido pela TwelveLabs, através do Amazon Bedrock. Com a introdução de inferência global entre regiões, o modelo agora está acessível em 23 novas regiões, complementando as sete regiões onde já estava disponível anteriormente. Além disso, o Bedrock passou a oferecer acesso ao modelo em todas as regiões da União Europeia utilizando inferência geográfica entre regiões.
Diferenças nas Estratégias de Inferência
A AWS disponibiliza duas estratégias distintas de processamento para esse modelo. A inferência geográfica entre regiões é ideal para cargas de trabalho que apresentam requisitos específicos de residência de dados ou conformidade regulatória dentro de limites geográficos definidos. Por outro lado, a inferência global entre regiões é recomendada para aplicações que priorizam disponibilidade e performance em múltiplas geografias, permitindo que o processamento aconteça onde houver melhor desempenho.
Capacidades do Modelo Pegasus 1.2
O Pegasus 1.2 é um modelo de linguagem orientado para processamento de vídeos que consegue gerar texto baseado no conteúdo visual, áudio e textual dentro de vídeos. Desenvolvido especificamente para vídeos de longa duração, o modelo se destaca na geração de texto a partir de vídeos e na compreensão temporal, permitindo análises sofisticadas de conteúdo videográfico.
Benefícios da Maior Disponibilidade Regional
Com a expansão do Pegasus 1.2 para essas regiões adicionais, desenvolvedores podem construir aplicações de inteligência em vídeo mais próximas aos seus dados e usuários finais. Essa proximidade reduz a latência das requisições e simplifica a arquitetura geral das soluções, permitindo processamento mais rápido e eficiente.
Próximos Passos
Para obter a lista completa de perfis de inferência suportados e regiões disponíveis para o Pegasus 1.2, consulte a documentação de inferência entre regiões. Para começar a trabalhar com o Pegasus 1.2, acesse o console do Amazon Bedrock. Mais detalhes técnicos e informações adicionais estão disponíveis na página do produto e na documentação do Amazon Bedrock.
Proteção aprimorada contra ataques DDoS na camada de aplicação
Nos primeiros meses deste ano, a AWS implementou novas camadas de proteção para aplicações, respondendo ao crescimento de ataques de negação de serviço distribuído (DDoS) de curta duração e alto volume na camada 7 (L7). Essas proteções são oferecidas através do grupo de regras gerenciadas Anti-DDoS AMR (Regras Gerenciadas Anti-DDoS da AWS). Embora a configuração padrão seja eficaz para a maioria dos cenários, você pode personalizar a resposta para se adequar à tolerância ao risco da sua aplicação.
Neste artigo, exploraremos como o Anti-DDoS AMR funciona internamente e como você pode ajustar seu comportamento utilizando rótulos e regras adicionais do AWS WAF. Você acompanhará três cenários práticos, cada um demonstrando uma técnica diferente de personalização.
Como o Anti-DDoS AMR funciona
Detecção de anomalias e aplicação de rótulos
O Anti-DDoS AMR estabelece uma linha de base do seu tráfego e a utiliza para detectar anomalias em questão de segundos. Quando um ataque DDoS é identificado, o serviço adiciona metadados às requisições — aquilo que o AWS WAF chama de rótulos. Especificamente, todas as requisições recebem o rótulo event-detected, enquanto as requisições suspeitas de contribuir para o ataque recebem o rótulo ddos-request.
Além disso, rótulos adicionais baseados em confiança são aplicados, como high-suspicion-ddos-request, quando existe alta suspeita de que a requisição faz parte do ataque. Em termos técnicos, um rótulo é um metadado adicionado a uma requisição por uma regra quando ela é correspondida. Após ser adicionado, o rótulo fica disponível para as regras subsequentes, que podem utilizá-lo para enriquecer sua lógica de avaliação.
As mitigações padrão combinam dois tipos de ação: bloqueio direto e desafio JavaScript. O desafio funciona apenas com clientes que esperam conteúdo HTML. Por esse motivo, você precisa excluir requisições que não podem ser desafiadas — como chamadas de API — nas configurações do Anti-DDoS AMR. O serviço aplica o rótulo challengeable-request às requisições que não correspondem às exclusões configuradas.
As regras de mitigação padrão são avaliadas na seguinte sequência:
ChallengeAllDuringEvent: Equivalente à lógica: SE event-detected E challengeable-request, ENTÃO desafiar. Esta regra ativa desafios para todas as requisições elegíveis durante um evento detectado.
ChallengeDDoSRequests: Equivalente à lógica: SE (high-suspicion-ddos-request OU medium-suspicion-ddos-request OU low-suspicion-ddos-request) E challengeable-request, ENTÃO desafiar. A sensibilidade pode ser ajustada para desafiar apenas requisições de média e alta suspeita.
DDoSRequests: Equivalente à lógica: SE high-suspicion-ddos-request, ENTÃO bloquear. A sensibilidade pode ser aumentada para bloquear também requisições de média suspeita, por exemplo.
Personalizando sua resposta aos ataques DDoS
Duas abordagens de personalização
Existem dois caminhos principais para personalizar como você responde a ataques DDoS na camada 7. Na primeira abordagem, você configura o Anti-DDoS AMR para a ação desejada e, em seguida, adiciona regras subsequentes para enrijecer ainda mais sua resposta sob condições específicas. Na segunda abordagem, você converte algumas ou todas as regras do Anti-DDoS AMR para modo de contagem e cria regras adicionais que definem sua resposta personalizada.
Em ambas as abordagens, as regras subsequentes são configuradas utilizando condições que você define, combinadas com condições baseadas em rótulos aplicados pelo Anti-DDoS AMR. Para configurar regras com lógica complexa, você precisará usar o editor JSON do AWS WAF ou ferramentas de infraestrutura como código, como AWS CloudFormation ou Terraform.
Exemplo 1: Mitigação mais sensível fora de países principais
Suponha que sua operação ocorra principalmente em dois países: Emirados Árabes Unidos e Arábia Saudita. Você está satisfeito com o comportamento padrão do Anti-DDoS AMR nesses países, mas deseja bloquear mais agressivamente fora deles. Você pode implementar isso com as seguintes regras:
Anti-DDoS AMR com configurações padrão
Uma regra customizada que bloqueia se: a requisição vier de fora dos Emirados Árabes Unidos ou Arábia Saudita E a requisição tiver os rótulos high-suspicion-ddos-request ou medium-suspicion-ddos-request
Após adicionar o Anti-DDoS AMR com configuração padrão, crie uma regra customizada subsequente com a seguinte definição JSON:
De forma similar, durante um ataque, você pode mitigar de forma mais agressiva requisições de fontes incomuns, como aquelas identificadas pelo grupo de regras gerenciadas de reputação de IP como provenientes de provedores de hospedagem e nuvem.
Exemplo 2: Redução de limites de taxa durante ataques DDoS
Imaginemos que sua aplicação possui URLs sensíveis que são computacionalmente intensivas. Para proteger a disponibilidade, você aplicou uma regra de limitação de taxa configurada com um limite de 100 requisições a cada 2 minutos. Você pode enrijecer essa resposta durante um ataque DDoS aplicando um limite mais agressivo. Você pode implementar isso com:
Anti-DDoS AMR com configurações padrão
Uma regra de limitação de taxa, restrita às URLs sensíveis, configurada com limite de 100 requisições em janela de 2 minutos
Uma segunda regra de limitação de taxa, restrita às URLs sensíveis E ao rótulo event-detected, configurada com limite de 10 requisições em janela de 10 minutos
Após adicionar o Anti-DDoS AMR com configuração padrão e sua regra de limitação de taxa para URLs sensíveis, crie uma nova regra de limitação com a seguinte definição JSON:
Exemplo 3: Resposta adaptativa conforme escalabilidade da aplicação
Considere uma aplicação legada que pode escalar com segurança até um certo limite de volume de tráfego, além do qual degrada. Se o volume total de tráfego, incluindo ataque DDoS, estiver abaixo desse limite, você decide não desafiar todas as requisições durante um ataque para evitar impactar a experiência do usuário. Neste cenário, você depende apenas da ação de bloqueio padrão para requisições de alta suspeita. Porém, se o volume total exceder o limite seguro, você ativa a mitigação equivalente a ChallengeDDoSRequests.
Você pode implementar isso com:
Anti-DDoS AMR com as regras ChallengeAllDuringEvent e ChallengeDDoSRequests configuradas em modo de contagem
Uma regra de limitação de taxa que conta seu tráfego, configurada com um limite correspondente à capacidade da sua aplicação, que aplica um rótulo customizado — como CapacityExceeded — quando o limite é atingido
Uma regra que replica ChallengeDDoSRequests, mas apenas quando o rótulo CapacityExceeded está presente: desafiar se os rótulos ddos-request, CapacityExceeded e challengeable-request estão todos presentes
Primeiro, atualize seu Anti-DDoS AMR alterando as ações Challenge para Count.
Em seguida, crie a regra de detecção de capacidade excedida em modo de contagem, usando a seguinte definição JSON:
Ao combinar as proteções integradas do Anti-DDoS AMR com lógica customizada, você consegue adaptar suas defesas para corresponder ao seu perfil de risco único, padrões de tráfego e escalabilidade da aplicação. Os exemplos apresentados ilustram como você pode ajustar a sensibilidade, aplicar mitigações mais fortes sob condições específicas e até construir defesas adaptativas que respondem dinamicamente à capacidade do seu sistema.
O sistema dinâmico de rótulos no AWS WAF permite implementar essas personalizações de forma granular. Você pode também utilizar rótulos do AWS WAF para excluir o registro custoso de tráfego de ataque DDoS, otimizando sua observabilidade sem sacrificar a segurança.
Nova Camada de Armazenamento Aquecido para Kinesis Video Streams
A AWS ampliou as capacidades de armazenamento do Amazon Kinesis Video Streams com a introdução de uma nova camada de armazenamento econômica, designada como “warm tier”. Essa novidade oferece aos desenvolvedores uma opção mais eficiente em custos para manter vídeos e mídia por períodos prolongados, sem sacrificar a performance.
Entendendo as Duas Camadas de Armazenamento
Anteriormente, o Amazon Kinesis Video Streams operava com uma única camada de armazenamento, agora renomeada como “hot tier”. Essa camada permanece otimizada para acesso em tempo real e armazenamento de curta duração, mantendo todas as suas características de baixa latência.
A nova camada “warm” foi projetada especificamente para cenários que exigem retenção de longa duração de mídia. O diferencial está na manutenção de acesso em sub-segundo — mesmo com custos de armazenamento significativamente reduzidos — tornando-a ideal para aplicações que precisam preservar dados históricos sem manter infraestrutura de acesso instantâneo.
Casos de Uso Práticos
A solução beneficia especialmente dois segmentos:
Segurança residencial: Desenvolvedoras de soluções de monitoramento residencial podem agora oferecer retenção estendida de vídeo, armazenando semanas ou meses de gravações com custos operacionais reduzidos.
Monitoramento empresarial: Organizações com múltiplas câmeras de vigilância conseguem manter históricos longos para auditoria, conformidade regulatória e análise de incidentes, equilibrando retenção com custos.
Maior Flexibilidade na Configuração
Além das duas camadas de armazenamento, a AWS adicionou controle granular sobre o tamanho dos fragmentos de dados. Desenvolvedores podem agora escolher entre:
Fragmentos menores: Para casos de uso que exigem latência ultra-baixa e responsividade imediata.
Fragmentos maiores: Para reduzir custos de ingestão, ideal quando a prioridade é economia de processamento em vez de latência extrema.
Integração com Serviços de IA e Análise
Ambas as camadas (hot e warm) funcionam nativamente com os serviços de visão computacional da AWS. A integração com Amazon Rekognition Video e Amazon SageMaker permite que desenvolvedores construam pipelines contínuos de processamento de vídeo e análise, independente de qual camada de armazenamento estejam utilizando.
Disponibilidade Global
A nova camada warm do Amazon Kinesis Video Streams está disponível em todas as regiões onde o serviço já opera, com a exceção das AWS GovCloud (US) Regions.
