View a markdown version of this page

게이트웨이에 규칙 추가 - Amazon Bedrock AgentCore
게이트웨이 규칙 작동 방식규칙 해결조건작업한도

게이트웨이에 규칙 추가

게이트웨이 규칙을 사용하면 대상을 재배포하지 않고도 게이트웨이의 트래픽 라우팅을 제어하고 대상 구성을 재정의할 수 있습니다. 대상의 동작을 재정의하는 구성 번들을 생성한 다음 규칙을 사용하여 어떤 번들 버전이 어떤 트래픽에 적용되는지 제어합니다. 또한 규칙은 요청 경로 또는 호출자 자격 증명을 기반으로 다른 대상으로 요청을 라우팅하는 것도 지원합니다.

게이트웨이 규칙을 사용하여 다음 목표를 달성합니다.

  • A/B 테스트를 통해 구성 번들 버전 실험

  • 디버깅을 위해 특정 보안 주체를 구성 번들 버전에 고정

  • 요청 경로 또는 발신자 자격 증명을 기반으로 트래픽을 특정 대상으로 라우팅

  • 모든 트래픽에 대한 기본 구성 번들 또는 대상 설정

게이트웨이 규칙 작동 방식

각 게이트웨이 규칙에는 다음 구성 요소가 포함되어 있습니다.

구성 요소 설명

우선순위

1~1,000,000 사이의 정수입니다. 숫자가 작을수록 우선 순위가 높음을 나타냅니다. 각 우선 순위 값은 게이트웨이 내에서 고유해야 합니다.

조건(선택 사항)

규칙이 요청과 일치하는지 여부를 결정하는 기준입니다. 조건이 없는 규칙은 모든 트래픽과 일치하는 catch-all 역할을 합니다.

작업(필수)

규칙이 일치할 때 수행할 작업입니다. 구성 번들을 재정의하거나, 특정 대상으로 라우팅하거나, 둘 다 할 수 있습니다.

설명(선택 사항)

규칙의 용도에 대한 텍스트 설명입니다.

규칙 해결

게이트웨이는 우선 순위 오름차순(먼저 낮은 숫자)으로 규칙을 평가합니다. 게이트웨이는 첫 번째 일치 시맨틱을 사용하여 각 작업 유형을 독립적으로 확인합니다.

다음 표는 게이트웨이가 샘플 요청에 대한 규칙을 해결하는 방법을 보여줍니다. 이 예제에서는 QA 역할이에 요청을 보냅니다/my-target-canary/chat.

우선순위 조건 작업 요청을 일치시킵니까? 결과

100

QA 역할

configurationBundle: 번들 버전 A

예

버전 AconfigurationBundle로 확인

200

경로 /my-target-canary/*

routeToTarget: my-target-canary

예

routeToTarget 로 확인 my-target-canary

1000000

없음(catch-all)

configurationBundle: 번들 버전 B, routeToTarget: my-target-primary

예

두 작업 유형 모두 이미 해결되었습니다. 건너뜀.

최종 결과: 요청은 번들 버전 A를 사용하고 로 라우팅합니다my-target-canary.

작은 정보

기존 규칙의 번호를 다시 매기지 않고 나중에 규칙을 삽입할 수 있도록 우선 순위 번호(예: 100, 200, 300) 사이에 간격을 둡니다.

조건

조건에 따라 규칙이 일치하는 요청이 결정됩니다. 규칙은 최대 2개의 조건을 가질 수 있습니다. 조건이 없는 규칙은 모든 트래픽과 일치합니다.

게이트웨이는 다음 조건 유형을 지원합니다.

matchPrincipals

호출자의 IAM 보안 주체를 기반으로 요청을 일치시킵니다. anyOf 목록에는 1~100개의 항목이 포함되어 있습니다. 각 항목은 다음 필드를 iamPrincipal 사용하여를 지정합니다.

  • arn - 일치시킬 IAM 보안 주체 ARN입니다.

  • operator (선택 사항)  - 비교 연산자입니다. 유효한 값은 StringEquals(기본값) 및 StringLike입니다. 와일드카드 일치StringLike에를 사용합니다.

matchPaths

요청 경로를 기반으로 요청을 일치시킵니다. anyOf 목록에는 1~10개의 항목이 포함됩니다. 각 항목은 형식을 사용해야 합니다. /<targetName>/*여기서는 게이트웨이에 있는 기존 HTTP 대상의 이름과 <targetName> 일치합니다. 대상은 Ready 상태여야 합니다. matchPaths 조건은 HTTP 대상이 있는 게이트웨이에서만 지원됩니다. , /mcp, , /a2a, 등 예약 경로 접두사는 허용되지 않습니다/responses/converse/.well-known.

조건 평가 로직

  • 조건 유형 내: 게이트웨이는 OR 로직을 사용합니다. 요청이 anyOf 목록의 항목을 충족하는 경우 요청이 일치합니다.

  • 조건 유형 간: 게이트웨이는 AND 로직을 사용합니다. 규칙에 matchPrincipals 및가 모두 있는 경우 matchPaths요청은 각 조건 유형에서 하나 이상의 항목과 일치해야 합니다.

작업

작업은 규칙이 일치할 때 게이트웨이가 수행하는 작업을 정의합니다. 규칙은 최대 2개의 작업을 가질 수 있습니다.

게이트웨이는 다음 작업 유형을 지원합니다.

구성 번들 재정의(configurationBundle)

일치하는 트래픽에 적용된 구성 번들을 재정의합니다.

  • staticOverride - 일치하는 모든 트래픽을 특정 구성 번들 버전에 고정합니다. 번들 ARN 및 버전 ID를 지정합니다.

  • weightedOverride - 두 구성 번들 버전 간에 트래픽을 분할합니다. trafficSplit 목록에는 가중치가 100이 되는 정확히 2개의 항목이 포함되어야 합니다. 구성 번들은 게이트웨이와 동일한 계정에 있어야 합니다.

대상 라우팅(routeToTarget)

일치하는 트래픽을 특정 대상으로 라우팅합니다. 대상은 HTTP 프로토콜을 사용하고 Ready 상태여야 합니다.

  • staticRoute - 일치하는 모든 트래픽을 이름으로 특정 대상으로 라우팅합니다.

  • weightedRoute - 두 대상 간에 트래픽을 분할합니다. trafficSplit 목록에는 가중치가 100이 되는 정확히 2개의 항목이 포함되어야 합니다. 트래픽 분할 항목 이름은 고유해야 합니다.

한도

다음 표에는 게이트웨이 규칙의 제한이 나열되어 있습니다.

Resource Limit

게이트웨이당 규칙

20

우선 순위 범위

1~1,000,000

규칙당 최대 조건

2

규칙당 최대 작업 수

2

matchPrincipals.anyOf 최대 항목 수

100

matchPaths.anyOf 최대 항목 수

10

trafficSplit 항목

정확히 2개

trafficSplit 가중치 범위

1~99
주제