Bedrock AgentCore와 AWS WAF 연동의 필요성과 제약

ChatGPT 같은 AI 에이전트를 실제 서비스 API로 배포할 때 가장 먼저 마주하는 고민은 보안이다. 인증되지 않은 외부 요청이 내부 인프라에 직접 닿게 두는 것은 위험하므로 보통 웹 방화벽을 세우지만, Amazon Bedrock AgentCore를 사용할 때는 기술적 충돌이 발생한다.

운영 환경에서 AgentCore를 보호하려면 AWS WAF(웹 애플리케이션 방화벽)를 연동해야 한다. WAF는 보통 인터넷 연결 ALB(애플리케이션 로드 밸런서)에 부착하여 트래픽을 제어하며, 트래픽은 `com.amazonaws.<region>.bedrock-agentcore` 데이터 평면 엔드포인트를 통해 AgentCore 런타임으로 전달된다. AgentCore는 런타임과 메모리, 도구를 담당하는 데이터 평면 외에도 제어 평면인 bedrock-agentcore-control과 게이트웨이 전용인 bedrock-agentcore.gateway로 나뉘어 있어 정확한 엔드포인트 선택이 필수적이다.

연동 과정에서 API Gateway를 고려할 수 있으나, 이는 자체 인증 및 요청 변환 계층을 가지고 있어 AgentCore 내부의 SigV4(AWS 요청 서명 프로토콜) 및 OAuth(개방형 인증 표준) 처리 체계와 충돌하는 이중 인증 문제를 일으킨다. 따라서 헤더를 투명하게 전달하고 VPC 내부 라우팅을 지원하며 WAF WebACL(웹 액세스 제어 목록)을 직접 연결할 수 있는 ALB가 최적의 통합 지점이 된다.

문제는 ALB가 백엔드 대상의 상태를 확인하는 무인증 상태 확인(Health Check) 과정에서 발생한다. ALB는 대상 서버가 응답 가능한지 확인하기 위해 인증 정보 없이 요청을 보내지만, AgentCore 런타임은 모든 API 호출에 SigV4 또는 OAuth 인증을 필수적으로 요구한다. 결국 ALB의 무인증 상태 확인 요청은 AgentCore의 인증 체계에 막혀 실패로 처리된다.

상태 확인이 실패하면 ALB는 해당 타겟을 비정상으로 판단해 트래픽 전송을 중단하므로 정상적인 서비스 운영이 불가능해진다. 이를 해결하기 위해 람다 프록시를 통한 요청 변환 방식과 VPC 엔드포인트의 ENI IP(가상 네트워크 인터페이스 IP)를 ALB가 직접 타겟팅하는 두 가지 경로를 설계할 수 있다.

Pattern 1: 람다 프록시를 통한 요청 제어와 변환

API 요청 내용을 실시간으로 수정하거나 세밀한 로그를 남겨야 하는 경우 ALB와 VPC 엔드포인트 사이에 람다 함수를 배치한다. 전체 흐름은 클라이언트 요청이 AWS WAF를 거쳐 ALB로 들어오고, 다시 람다 프록시를 통해 VPC 엔드포인트로 전달되어 AgentCore 런타임에 도달하는 순서로 이뤄진다. ALB는 TLS 종료를 처리하여 복호화된 요청을 람다 함수로 전달하며, 람다 프록시는 요청을 가공하고 인증 방식을 변환하는 연산 계층 역할을 수행한다.

인증 처리 방식은 프로토콜에 따라 나뉜다. OAuth를 사용하는 경우 람다는 Authorization 헤더의 Bearer 토큰을 수정 없이 전달하여 JWT(JSON 웹 토큰)가 AgentCore에 도달하게 한다. 반면 SigV4 인증은 요청의 호스트 정보에 서명이 묶여 있어, 람다가 요청을 전달하는 과정에서 호스트 정보가 변경되면 기존 서명이 무효화된다. 이를 해결하기 위해 람다 프록시는 자신의 실행 역할 자격 증명을 사용하여 요청을 다시 서명하는 재서명 과정을 거친다.

실제 구현 단계에서는 람다 함수가 ALB 이벤트 객체에서 인증 헤더를 읽고, VPC 엔드포인트의 DNS 이름을 기반으로 대상 URL을 동적으로 생성하여 포워딩한다. 아래 코드는 OAuth Bearer 토큰을 그대로 전달하는 핵심 로직을 보여준다.

import urllib3
import json

http = urllib3.PoolManager()

def lambda_handler(event, context):

ALB 이벤트에서 헤더 및 본문 추출

headers = event.get('headers', {})

body = event.get('body', '')

VPC 엔드포인트 대상 URL 설정

target_url = "https://com.amazonaws.<region>.bedrock-agentcore.vpce.amazonaws.com"

요청 포워딩 (OAuth Bearer 토큰의 경우 그대로 전달)

response = http.request(

'POST',

target_url,

body=body,

headers=headers

)

return {

'statusCode': response.status,

'body': response.data.decode('utf-8')

}

이 구조를 도입하면 ALB-람다-VPC 엔드포인트로 이어지는 홉(Hop)이 추가되어 요청당 약 50~200ms의 추가 지연시간이 발생하며, 람다의 콜드 스타트 현상 시 지연이 더 늘어날 수 있다. 하지만 요청 변환이 필수적이거나 커스텀 로깅을 통한 상세 감사 추적이 필요한 환경에서는 이 패턴이 유일한 해결책이 된다.

Pattern 2: ENI 직접 연결을 통한 저지연 구조

람다 프록시에서 발생하는 네트워크 홉과 연산 오버헤드를 제거하기 위해 ALB가 대상 서버에 직접 연결하는 방식을 사용한다. 데이터가 이동하는 물리적 경로를 단축하여 응답 속도를 높이고 인프라 구조를 단순화하는 것이 목적이다.

전체 트래픽 흐름은 클라이언트에서 AWS WAF를 거쳐 ALB로 들어온 뒤, VPC 엔드포인트의 ENI(Elastic Network Interface) IP 주소로 직접 전달된다. ALB는 HTTPS 443 포트를 통해 AgentCore 런타임으로 요청을 보내며, 중간 변환 단계 없이 데이터가 흐른다.

이 구조의 핵심은 IP 유형의 타겟 그룹 설정에 있다. VPC 엔드포인트가 생성한 ENI의 사설 IP 주소를 직접 타겟으로 등록한다. 이때 앞서 언급한 ALB의 무인증 상태 확인과 AgentCore의 인증 필수 요구 간의 충돌을 해결하기 위해, 인증이 필요 없는 상태 확인 전용 설정을 구성하여 서비스 가용성을 확보한다.

ALB는 클라이언트가 보낸 SigV4 서명이나 OAuth Bearer 토큰 같은 인증 헤더를 수정하지 않고 AgentCore로 투명하게 전달한다. 람다에서 수행하던 요청 변환, 커스텀 로깅, 재서명 과정이 모두 생략되므로, 요청을 가공할 필요가 없는 단순 전달 구조에서 가장 효율적이다. 제어권보다 응답 속도와 단순한 관리를 우선하는 환경에 적합하다.

리소스 정책을 통한 보안 강화와 WAF 규칙 적용

모든 트래픽이 반드시 AWS WAF를 거쳐 흐르도록 리소스 정책을 설정한다. 이는 외부 네트워크에서 VPC 엔드포인트로 직접 연결하여 WAF 검사를 우회하려는 경로를 차단하고 진입점을 단일화하는 조치다. 단일 진입점 구조는 보안 감사 시 트래픽 로그를 한곳에서 집중 분석하고 비정상 접근 시도를 빠르게 식별하게 한다.

AWS WAF의 WebACL에는 `AWSManagedRulesCommonRuleSet`을 적용해 SQL 인젝션이나 교차 사이트 스크립팅 같은 보편적인 웹 위협을 방어한다. 브라우저 기반 클라이언트 봇 제어가 필요한 경우 `AWSManagedRulesBotControlRuleSet`을 추가하여 봇의 동작 패턴과 HTTP 헤더를 분석해 비정상 자동화 요청을 차단한다. 이는 AI 에이전트의 API 자원 낭비를 막고 운영 비용을 최적화하는 수단이 된다.

또한 소스 IP당 일정 시간 동안 허용되는 최대 요청 수를 제한하는 비율 기반 규칙(Rate-based rule)을 도입한다. 특정 사용자의 악의적인 요청 폭주나 클라이언트 소프트웨어의 무한 루프 오류로 인한 트래픽 급증이 전체 시스템 장애로 이어지는 상황을 방지한다. 요청 임계치를 초과하는 트래픽을 즉시 차단함으로써 백엔드 리소스를 보호하고 서비스 거부 공격(DoS) 상황을 사전에 차단한다.

결과적으로 리소스 정책으로 접근 경로를 제한하고, WAF 규칙으로 데이터 내용을 검사하며, 비율 기반 규칙으로 트래픽 양을 조절하는 3단계 방어 체계를 통해 외부 노출 지점을 최소화하고 검증된 트래픽만 AgentCore 런타임에 도달하게 한다.

실무 도입 시 고려해야 할 비용과 성능 판단 기준

인프라 설계는 서비스가 요구하는 제어권 수준과 지연시간 기준에 따라 결정된다. 요청 데이터 변경, 커스텀 로깅, 인증 방식 변환이 필요한 기업용 서비스는 Pattern 1을, 최저 지연시간과 단순한 아키텍처가 중요한 소비자향 서비스는 Pattern 2를 선택한다.

운영 비용은 공통 비용과 선택적 구성 비용으로 나뉜다. AWS WAF는 WebACL당 월 요금, 규칙당 요금, 요청 100만 건당 요금을 부과하며, ALB는 시간당 기본 요금과 LCU(로드 밸런서 용량 단위) 요금이 발생한다. 보안 정책을 세분화하여 관리형 규칙을 늘리거나 트래픽이 급증할수록 이 비용은 정비례하여 증가한다.

컴퓨팅 비용의 경우, Pattern 1은 AWS Lambda의 요청 횟수와 실행 시간(GB-초) 비용이 추가된다. 두 패턴 모두 VPC 인터페이스 엔드포인트를 사용하므로 가용 영역(AZ)당 시간당 요금과 GB당 데이터 처리 비용이 발생한다. 특히 대규모 토큰을 주고받는 생성형 AI 서비스 특성상 엔드포인트 데이터 처리량이 전체 비용의 핵심 변수가 된다.

성능 측면에서는 네트워크 홉의 유무가 결정적이다. Pattern 1은 람다 프록시로 인해 앞서 언급한 추가 지연시간이 발생하지만, Pattern 2는 ALB가 ENI IP로 직접 요청을 전달하므로 람다 오버헤드가 완전히 제거된다. 0.1초의 응답 차이가 사용자 경험에 영향을 주는 실시간 AI 에이전트 환경에서는 단순 구조가 성능 최적화의 정답이 된다.

AI 에이전트를 API 서비스로 배포할 때 ALB의 무인증 상태 확인과 AgentCore의 필수 인증 체계 사이의 충돌은 람다 프록시를 통한 제어권 확보와 ENI 직접 연결을 통한 저지연성 중 무엇을 우선하느냐에 따라 해결 경로가 결정된다.

인프라 설계의 정답은 서비스가 허용하는 지연시간과 요구하는 보안 감사 수준의 대비에 있다. 현재 서비스의 응답 속도 기준과 제어권 필요 범위를 대조하여 적합한 아키텍처 패턴을 선택하고 WAF 규칙을 적용하는 것으로 설계를 마무리하면 된다.