🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore 게이트웨이의 속도 제한 기능은 사용자·그룹·대상별로 요청량, 토큰 사용량, 연결 수를 통제해 AI 트래픽의 공정한 사용과 하위 서비스의 가용성을 보호한다.

📌 핵심 요약

• AgentCore 게이트웨이는 관리형 웹 검색, 지식 기반, MCP 서버, 추론 모델, 에이전트 및 HTTP 엔드포인트로 향하는 AI 트래픽에 대해 세밀한 속도 제한을 지원한다.
• 모든 대상에는 초당·분당 요청 수와 초당 연결 수를 제한할 수 있으며, 추론 대상에는 입력과 출력 토큰을 합산한 분당 토큰 제한도 적용할 수 있다.
• 속도 제한은 대상명, 도구명, 모델 식별자, JWT 클레임, IAM 보안 주체 및 소스 자격 증명 등의 차원 키와 처리량을 정의하는 항목으로 구성된다.
• 고객이 정의한 제한을 먼저 평가한 뒤 서비스 관리 할당량을 평가하며, 실제 적용 한도는 두 제한 가운데 더 낮은 값이다.
• Basic·Advanced·Beta 그룹의 공유 한도와 JWT의 사용자 식별자 기반 개별 한도를 함께 적용하면 그룹 간 용량 독점과 그룹 내부의 사용자 독점을 동시에 억제할 수 있다.

🧩 주요 포인트

1. 요청 제한은 처리 시간과 관계없이 요청 한 건을 한 단위로 계산하지만 연결 제한은 연결 유지 시간을 추적한다 → 짧은 호출의 유입량과 장시간 스트리밍의 동시 점유를 서로 다른 기준으로 보호한다.
2. 추론 요청의 입력 토큰은 전송 전에 추정해 한도에서 차감하고 응답 후 실제 입력·출력 사용량으로 조정한다 → 호출 전 보호와 실제 소비량 기반 정산을 함께 수행한다.
3. 역할별 공유 버킷과 역할·사용자별 독립 버킷은 AND 조건으로 평가된다 → 그룹 전체와 개별 사용자 중 어느 한쪽이라도 한도에 도달하면 요청이 제한된다.

🧠 상세 정리

1. 게이트웨이와 속도 제한의 목적

Amazon Bedrock AgentCore 게이트웨이는 AI 트래픽에 단일하고 안전한 진입점을 제공하는 완전관리형 서버리스 게이트웨이다. 관리형 웹 검색, 관리형 지식 기반, MCP 서버, 추론 모델, A2A 및 도구형 에이전트, HTTP 엔드포인트 등 여러 종류의 하위 대상으로 요청을 라우팅한다. 새로 지원되는 속도 제한 기능은 개별 사용자나 사용자 그룹이 도구, 모델, 에이전트를 얼마나 사용할 수 있는지 세밀하게 통제한다. OAuth 또는 IAM 기반 규칙으로 분당 요청 수, 연결 수, 토큰 처리량을 제한함으로써 트래픽이 급증하는 상황에서도 하위 서비스의 가용성을 유지하도록 설계됐다.

2. 대상 유형과 요청량 제한

게이트웨이의 대상은 MCP 대상, 추론 대상, HTTP 패스스루 대상의 세 종류이며, 초당 요청 수인 RPS와 분당 요청 수인 RPM은 모든 대상 유형에 적용된다. 각 제한은 정해진 시간 구간에 허용할 최대 요청 건수를 정의하고, 게이트웨이는 들어오는 모든 요청을 해당 버킷에 반영한다. 요청 한 건은 실행 시간이나 응답 방식과 무관하게 정확히 한 단위로 계산된다. 따라서 50밀리초 만에 끝나는 요청과 90초 동안 스트리밍되는 요청도 RPS 또는 RPM 기준에서는 똑같이 한 건을 소비한다. 이 방식은 요청 도착량을 통제하지만, 요청이 연결을 얼마나 오래 점유하는지는 별도의 연결 제한으로 다룬다.

3. 토큰 및 연결 제한의 계산 방식

분당 토큰 수인 TPM 제한은 추론 대상에만 적용되며, 요청의 입력 토큰과 응답의 출력 토큰을 모두 합산한 전체 왕복 비용을 계산한다. 게이트웨이는 범용 토크나이저로 들어오는 요청의 입력 토큰을 먼저 추정하고, 추론 호출을 전달하기 전에 그 수량을 속도 제한 버킷에서 차감한다. 응답이 돌아오면 모델 제공자가 보고한 실제 입력·출력 토큰 사용량을 바탕으로 버킷을 다시 조정해 실제 소비량을 반영한다. 초당 연결 수인 CPS 제한은 모든 대상에 적용되며, 각 요청이 열린 연결을 유지하는 시간을 추적한다. 예를 들어 스트리밍 추론 호출이 100초 동안 실행되면 그 요청은 전체 실행 시간 동안 연결 슬롯 하나를 차지하므로, CPS는 장시간 세션이 동시에 과도하게 누적되는 상황을 통제하는 데 사용된다.

4. 사용자 그룹과 인증·권한 구성

예시 구성은 Basic, Advanced, Beta라는 세 사용자 그룹을 전제로 한다. AgentCore Identity는 Microsoft Entra ID를 자격 증명 공급자로 사용하는 JWT를 통해 인바운드 인증을 처리하고, 아웃바운드 대상에 필요한 토큰을 발급하는 역할도 맡는다. AgentCore의 정책 기능은 역할 기반 접근 제어를 적용해 각 그룹이 사용할 수 있는 대상과 모델의 범위를 제한한다. Basic 사용자는 Advanced 사용자보다 낮은 속도 한도를 부여받으며, Beta 사용자는 제한된 모델에 대해 더 높은 한도를 받는다. Beta 그룹의 높은 한도는 해당 모델을 조직 전체에 배포하기 전에 성능과 적합성을 벤치마킹하는 워크로드를 지원하기 위한 구성이다.

5. 차원 키와 항목으로 구성되는 제한 구조

하나의 속도 제한 구성은 트래픽을 어떤 버킷으로 묶을지 정하는 차원 키와 각 버킷의 허용 처리량을 정하는 항목으로 이루어진다. 예시에서는 AWS CLI로 targetName을 차원 키로 지정하고, 트래픽이 많은 Booking MCP 대상에는 초당 100건을 허용하는 명시적 항목을 설정한다. 나머지 대상에는 와일드카드 항목으로 초당 10건을 적용하지만, 모든 대상이 하나의 버킷을 공유하는 것이 아니라 각 대상이 독립된 10 RPS 버킷을 갖는다. 지원되는 차원 키에는 targetName, toolName, qualifiedModelId, JWT 클레임, IAM 보안 주체, IAM 소스 자격 증명이 포함된다. 요청이 도착하면 게이트웨이는 요청 문맥에서 각 차원 키의 값을 해석하고, 그 값들의 조합을 사용해 요청을 알맞은 속도 제한 버킷에 배정한다.

6. 명시적 항목과 와일드카드의 우선순위

각 항목은 일치시킬 차원 값과 그 값에 허용할 처리량을 정의하며, 별표로 표현하는 와일드카드는 명시되지 않은 각각의 값에 독립 버킷을 제공한다. 게이트웨이는 먼저 이름이 명시된 항목이 요청과 일치하는지 확인하고, 일치 항목이 없을 때만 와일드카드로 대체한다. Booking 대상은 이름으로 지정된 100 RPS 항목이 와일드카드보다 구체적이므로 해당 항목이 우선 적용된다. Docs, BedrockMantle, CustomPlatform, awsdocsagent처럼 별도 이름 항목이 없는 대상은 각각 독립된 10 RPS 버킷을 받는다. 또한 targetName과 JWT의 role 클레임처럼 여러 차원 키를 결합하면 같은 대상에 대해서도 Basic, Advanced, Beta 그룹별로 서로 다른 독립 버킷을 만들 수 있다.

7. 서비스 할당량과 역할별 공유 한도

AgentCore 게이트웨이는 고객 정의 속도 제한과 AWS 계정 단위의 서비스 관리 할당량이라는 두 계층을 적용한다. 고객이 설정한 제한을 먼저 평가하고 이를 통과한 요청에 서비스 할당량을 평가하며, 유효 처리량은 두 한도 중 더 낮은 값으로 결정된다. 역할별 예시에서 Basic 그룹은 100 RPM과 50 CPS, Advanced 그룹은 300 RPM과 150 CPS, Advanced와 Beta 역할을 함께 가진 그룹은 300 RPM과 200 CPS의 공유 버킷을 받는다. 그 밖의 역할 조합에는 와일드카드로 80 RPM과 10 CPS가 설정되며, JWT의 role 클레임이 배열이기 때문에 각 고유한 역할 조합을 별도 항목으로 표현한다. 이 버킷은 그룹 구성원이 공동으로 사용하므로 Basic 사용자 한 명이 한 분에 80건을 보내면 같은 시간 구간에 다른 Basic 사용자들이 사용할 수 있는 그룹 용량은 20건만 남는다.

8. 개별 사용자 제한과 AND 방식의 이중 통제

역할별 공유 버킷만 사용하면 한 사용자가 그룹 전체 용량을 소진해 같은 그룹의 다른 사용자를 제한할 수 있으므로, role과 JWT의 sub 클레임을 결합한 두 번째 구성을 추가한다. sub는 사용자를 고유하게 식별하며, 와일드카드를 사용해 각 사용자가 독립적인 버킷을 갖도록 한다. 예시의 개별 한도는 Basic 사용자당 20 RPM과 10 CPS, Advanced 사용자당 60 RPM과 30 CPS, Advanced·Beta 사용자당 60 RPM과 50 CPS이며, 그 밖의 조합에는 20 RPM과 20 CPS가 적용된다. 그룹 한도와 사용자 한도는 서로 독립적으로 평가되지만 요청 승인에는 AND 조건이 사용되므로 두 검사를 모두 통과해야 한다. Basic 사용자 Arnav가 개인 한도인 20 RPM을 소진하면 그룹에 80 RPM이 남아 있어도 다음 요청은 거부되며, 반대로 Basic 그룹이 공동으로 100 RPM을 소진하면 개별 잔여량과 관계없이 해당 그룹의 사용자들이 제한된다. 결과적으로 그룹 상한은 한 그룹이 다른 그룹의 용량을 잠식하는 것을 막고, 사용자 상한은 한 개인이 같은 그룹 구성원의 용량을 독점하는 것을 막는다.

🧾 핵심 주장 / 시사점

• RPS·RPM과 CPS는 같은 트래픽을 다른 관점에서 측정하므로, 요청 도착 빈도만 제한해서는 장시간 스트리밍 연결의 점유를 충분히 통제할 수 없다.
• 와일드카드 항목은 일치하는 모든 값을 하나의 공유 버킷으로 합치는 것이 아니라 각 고유 값에 동일한 크기의 독립 버킷을 생성한다.
• 역할별 한도만으로는 그룹 내부의 공정성이 보장되지 않으며, 고유 사용자 식별자를 차원에 추가해야 개인별 소비량을 별도로 제한할 수 있다.

✅ 액션 아이템

• 대상명·도구명·모델 식별자·JWT 클레임·IAM 주체 등 차원 키별로 요청·연결·토큰 한도를 정의한다.
• Basic·Advanced·Beta 공유 한도와 JWT 사용자 식별자 개별 한도를 함께 걸어 그룹·사용자 독점을 동시에 억제한다.
• 고객 정의 한도와 서비스 관리 할당량 중 더 낮은 값이 실제 적용됨을 기준으로 추론 대상 분당 토큰 한도를 점검한다.

❓ 열린 질문

• 요청 제한과 연결 제한을 어떤 비율로 두면 짧은 호출 유입과 장시간 스트리밍 점유를 균형 있게 막을 수 있는가?
• 입력 토큰 사전 추정 차감과 응답 후 실제 사용량 조정 사이 오차는 한도 설계에 어떤 여유를 요구하는가?
• 역할 공유 버킷과 역할·사용자 독립 버킷의 AND 평가에서 그룹 한도와 개인 한도의 상대 비율은 어떻게 정할 것인가?