View a markdown version of this page

Adicionar regras a um gateway - Base da Amazônia AgentCore
Como as regras de gateway funcionamResolução de regrasCondiçõesAçõesLimites

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Adicionar regras a um gateway

As regras de gateway permitem que você controle o roteamento de tráfego e substitua as configurações de destino em seu gateway sem reimplantar alvos. Você cria pacotes de configuração que substituem o comportamento de um alvo e, em seguida, usa regras para controlar qual versão do pacote se aplica a qual tráfego. As regras também oferecem suporte ao roteamento de solicitações para destinos diferentes com base no caminho da solicitação ou na identidade do chamador.

Use as regras de gateway para atingir as seguintes metas:

  • Experimente as versões do pacote de configuração por meio de A/B testes

  • Fixar princípios específicos em uma versão do pacote de configuração para depuração

  • Encaminhe o tráfego para alvos específicos com base no caminho da solicitação ou na identidade do chamador

  • Defina um pacote ou destino de configuração padrão para todo o tráfego

Como as regras de gateway funcionam

Cada regra de gateway contém os seguintes componentes:

Componente Description

Prioridade

Um número inteiro de 1 a 1.000.000. Números mais baixos indicam maior precedência. Cada valor de prioridade deve ser exclusivo em um gateway.

Condições (opcional)

Critérios que determinam se a regra corresponde a uma solicitação. Uma regra sem condições funciona como uma regra geral que corresponde a todo o tráfego.

Ações (obrigatórias)

A ação a ser tomada quando a regra coincide. Você pode substituir pacotes de configuração, rotear para destinos específicos ou ambos.

Descrição (opcional)

Uma descrição em texto do propósito da regra.

Resolução de regras

O gateway avalia as regras em ordem crescente de prioridade (primeiro diminua os números). O gateway resolve cada tipo de ação de forma independente usando a semântica da primeira partida.

A tabela a seguir mostra como o gateway resolve as regras para uma solicitação de amostra. Neste exemplo, a função de controle de qualidade envia uma solicitação para /my-target-canary/chat o.

Prioridade Condições Ações Solicitação de partidas? Resultado

100

Papel de QA

configurationBundle: pacote versão A

Sim

Resolve configurationBundle para a versão A

200

Caminho /my-target-canary/*

routeToTarget: my-target-canary

Sim

Resolve para routeToTarget my-target-canary

1000000

Nenhum (abrangente)

configurationBundle: pacote versão B,: routeToTarget my-target-primary

Sim

Ambos os tipos de ação já foram resolvidos. Ignorado.

Resultado final: a solicitação usa a versão A do pacote e roteia para o. my-target-canary

dica

Deixe espaços entre os números prioritários (por exemplo, 100, 200, 300) para que você possa inserir regras posteriormente sem renumerar as regras existentes.

Condições

As condições determinam quais solicitações uma regra corresponde. Uma regra pode ter no máximo 2 condições. Uma regra sem condições corresponde a todo o tráfego.

O gateway oferece suporte aos seguintes tipos de condição:

Diretores da partida

Combina as solicitações com base no principal IAM do chamador. A anyOf lista contém de 1 a 100 entradas. Cada entrada especifica um iamPrincipal com os seguintes campos:

  • arn— O ARN principal do IAM correspondente.

  • operator(opcional) — O operador de comparação. Os valores válidos são StringEquals (padrão) e StringLike. Use StringLike para correspondência de curingas.

Caminhos de correspondência

Corresponde às solicitações com base no caminho da solicitação. A anyOf lista contém de 1 a 10 entradas. Cada entrada deve usar o formato/<targetName>/*, onde <targetName> corresponde ao nome de um destino HTTP existente no gateway. O alvo deve estar no Ready estado. A matchPaths condição é suportada somente para gateways com destinos HTTP. Os seguintes prefixos de caminho reservado não são permitidos:/mcp,,, /a2a/responses,/converse. /.well-known

Lógica de avaliação de condições

  • Dentro de um tipo de condição: o gateway usa a lógica OR. Uma solicitação corresponderá se atender a qualquer entrada na anyOf lista.

  • Em todos os tipos de condição: o gateway usa a lógica AND. Se uma regra tiver ambos matchPrincipals ematchPaths, a solicitação deverá corresponder a pelo menos uma entrada de cada tipo de condição.

Ações

As ações definem o que o gateway faz quando uma regra corresponde. Uma regra pode ter no máximo 2 ações.

O gateway oferece suporte aos seguintes tipos de ação:

Substituições do pacote de configuração () configurationBundle

Substitua o pacote de configuração aplicado ao tráfego correspondente.

  • staticOverride— Fixa todo o tráfego correspondente a uma versão específica do pacote de configuração. Especifique o ARN do pacote e o ID da versão.

  • weightedOverride— Divide o tráfego entre duas versões do pacote de configuração. A trafficSplit lista deve conter exatamente 2 entradas com pesos que somam 100. O pacote de configuração deve estar na mesma conta do gateway.

Roteamento de destino () routeToTarget

Rotas que combinam o tráfego com um alvo específico. O alvo deve usar o protocolo HTTP e estar no Ready estado.

  • staticRoute— Encaminha todo o tráfego correspondente a um alvo específico pelo nome.

  • weightedRoute— Divide o tráfego entre dois alvos. A trafficSplit lista deve conter exatamente 2 entradas com pesos que somam 100. Os nomes das entradas divididas de tráfego devem ser exclusivos.

Limites

A tabela a seguir lista os limites das regras de gateway.

Recurso Limite

Regras por gateway

20

Faixa de prioridade

1 a 1.000.000

Condições máximas por regra

2

Máximo de ações por regra

2

matchPrincipals.anyOfmáximo de entradas

100

matchPaths.anyOfmáximo de entradas

10

trafficSplitentradas

Exatamente 2

trafficSplitfaixa de peso

1 a 99
Tópicos