Blog

O que é essa novidade?

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.

Fonte

Amazon Connect Chat now supports agent-initiated workflows (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-connect-chat-agent-initiated-workflows)

Desafios na análise de risco em seguros

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.

Fluxo de operação

O fluxo começa quando um usuário autenticado do Quick Suite acessa o agente de conversa do Quick Suite e submete uma pergunta através da interface do assistente. Um exemplo seria: “Avalie o risco para o solicitante APP-0900”.

O agente de conversa está integrado com as Integrações de Ações MCP do Amazon Quick Suite para invocar ações em um servidor MCP implantado no AgentCore Runtime. O agente analisa a pergunta para entender a intenção, identifica entidades-chave como identificadores de solicitantes e números de sinistros, e decide quais ferramentas MCP devem ser acionadas.

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:

• Uma conta AWS
• 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:

python -m venv smart_insurance_agent_venv
source smart_insurance_agent_venv/bin/activate
pip install -r deployment/requirements.txt

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.

Fonte

Create an intelligent insurance underwriter agent powered by Amazon Nova 2 Lite and Amazon Quick Suite (https://aws.amazon.com/blogs/machine-learning/create-an-intelligent-insurance-underwriter-agent-powered-by-amazon-nova-2-lite-and-amazon-quick-suite/)

Expansão global do SES Mail Manager

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.

Fonte

SES Mail Manager is now available in 10 additional AWS Regions, 27 total (https://aws.amazon.com/about-aws/whats-new/2025/12/ses-mail-manager-10-regions/)

Expansão Global do Pegasus 1.2 no Amazon Bedrock

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.

Fonte

TwelveLabs’ Pegasus 1.2 model now in 23 new AWS regions via Global cross-region inference (https://aws.amazon.com/about-aws/whats-new/2025/12/twelvelabs-pegasus-available-with-global-cross-region-inference/)

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.

Estratégias de mitigação padrã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:

{
  "Action": {
    "Block": {}
  },
  "Name": "more-sensitive-ddos-mitigation-outside-of-core-countries",
  "Priority": 1,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "NotStatement": {
            "Statement": {
              "GeoMatchStatement": {
                "CountryCodes": [
                  "AE",
                  "SA"
                ]
              }
            }
          }
        },
        {
          "OrStatement": {
            "Statements": [
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              },
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              }
            ]
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "more-sensitive-ddos-mitigation-outside-of-core-countries",
    "SampledRequestsEnabled": true
  }
}

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:

{
  "Action": {
    "Block": {}
  },
  "Name": "ip-rate-limit-10-10mins-under-ddos",
  "Priority": 2,
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 600,
      "Limit": 10,
      "ScopeDownStatement": {
        "AndStatement": {
          "Statements": [
            {
              "ByteMatchStatement": {
                "FieldToMatch": {
                  "UriPath": {}
                },
                "PositionalConstraint": "EXACTLY",
                "SearchString": "/sensitive-url",
                "TextTransformations": [
                  {
                    "Priority": 0,
                    "Type": "LOWERCASE"
                  }
                ]
              }
            },
            {
              "LabelMatchStatement": {
                "Key": "awswaf:managed:aws:anti-ddos:event-detected",
                "Scope": "LABEL"
              }
            }
          ]
        }
      }
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ip-rate-limit-10-10mins-under-ddos",
    "SampledRequestsEnabled": true
  }
}

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:

{
  "Action": {
    "Count": {}
  },
  "Name": "capacity-exceeded-detection",
  "Priority": 7,
  "RuleLabels": [
    {
      "Name": "mycompany:capacityexceeded"
    }
  ],
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 120,
      "Limit": 10000
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "capacity-exceeded-detection",
    "SampledRequestsEnabled": true
  }
}

Finalmente, crie a regra de desafio usando a seguinte definição JSON:

{
  "Action": {
    "Challenge": {}
  },
  "Name": "challenge-if-ddos-and-capacity-exceeded",
  "Priority": 2,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "LabelMatchStatement": {
            "Key": "mycompany:capacityexceeded",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:ddos-request",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:challengeable-request",
            "Scope": "LABEL"
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "challenge-if-ddos-and-capacity-exceeded",
    "SampledRequestsEnabled": true
  }
}

Conclusão

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.

Fonte

How to customize your response to layer 7 DDoS attacks using AWS WAF Anti-DDoS AMR (https://aws.amazon.com/blogs/security/how-to-customize-your-response-to-layer-7-ddos-attacks-using-aws-waf-anti-ddos-amr/)