🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AgentCore Runtime 앞단에 AWS WAF를 적용할 때 ALB와 VPC Interface Endpoint를 중심으로 구성하는 두 가지 패턴, 즉 Lambda 프록시 방식과 VPC Endpoint ENI 직접 타깃 방식을 설명한다.

📌 핵심 요약

• 이 글은 Amazon Bedrock AgentCore Runtime을 프로덕션 API 엔드포인트로 배포할 때 AWS WAF를 통해 방화벽 정책, rate limiting, 일반적인 웹 위협 방어, 감사 제어를 적용하려는 상황을 다룬다.
• CloudFront는 캐싱과 콘텐츠 전달에 맞춰져 있고, API Gateway는 자체 인증 및 요청 변환 계층 때문에 AgentCore의 SigV4·OAuth 처리와 중복 인증 문제가 생길 수 있어, 원문은 인터넷-facing ALB를 주요 통합 지점으로 제시한다.
• 핵심 난점은 ALB가 백엔드 상태 확인을 위해 unauthenticated health check를 보내지만, AgentCore Runtime은 SigV4 또는 OAuth 인증을 요구하므로 기본 health check가 그대로는 실패한다는 점이다.
• Pattern 1은 ALB 뒤에 Lambda 프록시를 두어 요청 변환, 인증 방식 간 변환, 커스텀 로깅을 가능하게 하며, OAuth는 Authorization 헤더를 그대로 전달하고 SigV4는 프록시에서 재서명이 필요하다고 설명한다.
• Pattern 2는 Lambda 없이 ALB가 VPC Endpoint ENI의 private IP를 HTTPS 443 타깃으로 직접 바라보게 하여 구성요소와 지연을 줄이고, 인증 헤더는 클라이언트가 처리한 뒤 AgentCore까지 투명하게 전달되도록 한다.

🧩 주요 포인트

1. 이 글은 Amazon Bedrock AgentCore Runtime을 프로덕션 API 엔드포인트로 배포할 때 AWS WAF를 통해 방화벽 정책, rate limiting, 일반적인 웹 위협 방어, 감사 제어를 적용하려는 상황을 다룬다.
2. CloudFront는 캐싱과 콘텐츠 전달에 맞춰져 있고, API Gateway는 자체 인증 및 요청 변환 계층 때문에 AgentCore의 SigV4·OAuth 처리와 중복 인증 문제가 생길 수 있어, 원문은 인터넷-facing ALB를 주요 통합 지점으로 제시한다.
3. 핵심 난점은 ALB가 백엔드 상태 확인을 위해 unauthenticated health check를 보내지만, AgentCore Runtime은 SigV4 또는 OAuth 인증을 요구하므로 기본 health check가 그대로는 실패한다는 점이다.
4. Pattern 1은 ALB 뒤에 Lambda 프록시를 두어 요청 변환, 인증 방식 간 변환, 커스텀 로깅을 가능하게 하며, OAuth는 Authorization 헤더를 그대로 전달하고 SigV4는 프록시에서 재서명이 필요하다고 설명한다.
5. Pattern 2는 Lambda 없이 ALB가 VPC Endpoint ENI의 private IP를 HTTPS 443 타깃으로 직접 바라보게 하여 구성요소와 지연을 줄이고, 인증 헤더는 클라이언트가 처리한 뒤 AgentCore까지 투명하게 전달되도록 한다.

🧠 상세 정리

1. 문제 설정: AgentCore Runtime 앞단에 WAF를 두려는 이유

원문은 Amazon Bedrock AgentCore를 사용해 생성형 AI agent를 프로덕션 API 엔드포인트로 배포할 때 생기는 보안 요구에서 출발한다. 운영 환경에서는 웹 애플리케이션 방화벽 정책, 요청 빈도 제한, 일반적인 웹 위협 방어, 감사 제어가 필요할 수 있고, 이를 위해 AWS WAF를 적용하려는 상황을 전제한다. AWS WAF는 ALB, CloudFront, API Gateway REST API와 통합될 수 있지만, AgentCore Runtime 호출의 특성 때문에 어떤 통합 지점을 고를지 신중히 판단해야 한다. 따라서 글의 중심 질문은 AgentCore의 인증 흐름을 깨뜨리지 않으면서 WAF 검사를 반드시 거치도록 만드는 아키텍처를 어떻게 구성하느냐에 있다.

2. CloudFront와 API Gateway 대신 ALB를 선택하는 흐름

원문은 AWS WAF가 여러 서비스와 통합되지만, AgentCore Runtime 호출에는 인터넷-facing ALB가 적합한 통합 지점이라고 설명한다. CloudFront는 캐싱과 콘텐츠 전송을 위해 설계되었는데, agent invocation은 실시간이고 동적이므로 캐싱의 장점이 적용되지 않는다고 본다. API Gateway는 자체 인증과 요청 변환 계층을 추가하기 때문에, AgentCore가 기본적으로 처리하는 SigV4와 OAuth 인증과 겹쳐 double-authentication 문제가 생길 수 있다. 이에 비해 ALB는 헤더를 투명하게 전달하고, VPC 내부 라우팅을 지원하며, AWS WAF WebACL을 직접 연결할 수 있는 지점으로 제시된다.

3. 핵심 난점: ALB health check와 AgentCore 인증 요구의 충돌

ALB를 통합 지점으로 선택하면 다음 문제는 health check에서 발생한다. ALB는 백엔드 target이 응답 가능한지 확인하기 위해 health check를 수행해야 하지만, AgentCore Runtime은 API 호출에 SigV4 또는 OAuth 인증을 요구하며 health check 요청도 예외로 두지 않는다고 원문은 설명한다. 표준 ALB health check는 인증 정보 없이 요청을 보내므로, AgentCore를 직접 대상으로 삼으면 기본 구성에서는 실패한다. 따라서 인증되지 않은 health check는 통과시키면서도 실제 운영 트래픽은 인증된 상태로 AgentCore에 전달하는 방법이 필요하다.

4. 공통 기반 아키텍처: WAF, ALB, VPC Endpoint, AgentCore Runtime

두 패턴은 공통적으로 클라이언트가 SigV4 서명 또는 OAuth Bearer token을 포함한 인증 요청을 인터넷-facing ALB로 보내는 구조를 사용한다. AWS WAF는 ALB 앞에서 요청을 검사하고, ALB는 HTTPS 443 포트로 VPC Endpoint ENI에 트래픽을 전달한다. 이후 AgentCore는 인증을 검증한 뒤 내부 포트 8080에서 동작하는 runtime container로 요청을 라우팅한다. 구성요소는 AWS WAF, ALB, VPC Interface Endpoint, AgentCore Runtime으로 나뉘며, 원문은 Runtime 호출에는 data plane 서비스인 com.amazonaws.<region>.bedrock-agentcore endpoint를 사용해야 한다고 강조한다.

5. 사전 조건과 패턴 선택 기준

원문은 실습을 위해 AgentCore가 활성화된 AWS 계정, 배포된 AgentCore Runtime, 최소 두 Availability Zone에 걸친 public·private subnet이 있는 VPC, ALB HTTPS listener용 ACM 인증서가 필요하다고 정리한다. 또한 OAuth 방식을 쓰려면 Amazon Cognito User Pool이 필요하고, SigV4 방식을 쓰려면 AWS credentials가 필요하다고 설명한다. ALB, VPC Endpoint, AWS WAF에 대한 기본 이해도 전제된다. 선택 기준은 비교적 명확한데, 요청 변환이나 커스텀 로깅, 인증 변환이 필요하면 Pattern 1을 먼저 보고, 지연과 구성요소를 최소화하려면 Pattern 2를 선택하라는 흐름이다.

6. Pattern 1: Lambda 프록시를 둔 ALB 구성

Pattern 1은 ALB 뒤에 Lambda function을 두고, 이 Lambda가 VPC Endpoint를 통해 AgentCore로 요청을 전달하는 방식이다. 이 구조의 장점은 AgentCore에 도달하기 전에 요청 변환, 헤더 조작, payload 변경, protocol translation, custom logging, audit trail을 구현할 수 있다는 점이다. OAuth의 경우 Lambda는 Authorization 헤더의 Bearer token, 원래 path, body를 그대로 전달하여 JWT가 AgentCore에 도달하게 한다. SigV4의 경우 서명이 원래 request host에 묶여 있기 때문에 VPC Endpoint로 전달되면 무효가 될 수 있어, 프록시가 자신의 execution-role credentials로 요청을 다시 서명해야 한다고 원문은 설명한다.

7. Pattern 1의 구현 요소와 운영상 trade-off

Pattern 1에서는 먼저 private subnet에 AgentCore data plane용 VPC Interface Endpoint를 만들고, VPC Endpoint security group이 ALB security group에서 오는 HTTPS 443 트래픽만 허용하도록 설정한다. Lambda proxy는 ALB event에서 path, headers, body, method를 읽고 VPC Endpoint DNS 이름을 사용해 target URL을 구성한 뒤 요청을 전달한다. 원문에 나온 코드 조각은 OAuth Bearer token 전달 중심의 핵심 로직을 보여주며, SigV4 signing, query string 처리, ALB health check 응답, 구조화된 오류 처리는 별도 repository의 완성 구현에 포함된다고 설명한다. trade-off로는 Lambda cold start로 요청당 약 50~200ms 지연이 추가될 수 있고, 요청 및 실행 시간 비용과 별도 배포·모니터링 대상이 생기지만, 변환과 로깅의 유연성은 높아진다.

8. Pattern 2: ALB가 VPC Endpoint ENI를 직접 타깃으로 삼는 구성

Pattern 2는 Lambda function이나 Network Load Balancer 없이 ALB가 VPC Endpoint ENI의 private IP 주소를 HTTPS 443 target으로 직접 바라보는 방식이다. 이 구조에서는 ALB가 인증 헤더를 AgentCore로 투명하게 전달하고, 클라이언트 애플리케이션이 SigV4 또는 OAuth signing을 직접 처리한다. 구성요소가 적고 추가 hop이 없기 때문에 지연을 줄일 수 있으며, 요청 변환이 필요 없는 경우에 적합하다고 원문은 설명한다. 구현은 VPC Interface Endpoint를 만든 뒤 해당 endpoint가 생성한 ENI ID와 private IP를 조회하고, 이를 IP-type target group에 등록하는 흐름으로 이어진다.

9. Pattern 2의 health check 구성과 보안상 주의점

Pattern 2에서 핵심 설정은 인증을 요구하지 않는 방식으로 ALB target group health check를 구성하는 것이다. 원문은 HTTPS 443 포트의 IP-type target group을 만들고, health-check protocol과 port를 HTTPS 443으로 지정하며, health-check path를 /로 두고 matcher를 HttpCode=200-499로 설정하는 예시를 제시한다. 이렇게 하면 ALB health check가 AgentCore의 인증 요구와 직접 충돌하지 않도록 target 상태 확인을 구성할 수 있다. 또한 글의 앞부분은 두 패턴 모두 VPC Interface Endpoint를 통해 AgentCore Runtime으로 라우팅하며, direct-access backdoor를 resource policy로 닫아 트래픽이 AWS WAF를 통과하도록 해야 한다는 점을 함께 언급한다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 WAF 적용 자체보다, ALB health check가 인증 없이 동작한다는 인프라 요구와 AgentCore Runtime의 인증 필수 조건을 어떻게 동시에 만족시키느냐에 있다.
• Pattern 1은 보안·감사·변환 요구가 강한 환경에 맞고, Pattern 2는 클라이언트가 인증을 직접 처리하며 낮은 지연과 단순성을 우선할 때 적합하다는 대비가 분명하다.
• VPC Endpoint service 이름, security group 범위, health check matcher, resource policy 같은 세부 설정이 잘못되면 WAF 앞단 구성은 되어 있어도 Runtime 라우팅이나 우회 차단이 의도대로 작동하지 않을 수 있다.

✅ 액션 아이템

• 인터넷-facing ALB를 핵심 통합 지점으로 택하고 CloudFront·API Gateway 병행 시 중복 인증·요청 변환 경로를 배제한다.
• Pattern 1에서 ALB 뒤 Lambda 프록시를 두는 경우 OAuth Authorization 헤더는 그대로 전달하고 SigV4는 프록시에서 재서명 처리한다.
• Pattern 2에서는 ALB 대상을 VPC Endpoint ENI의 private IP(HTTPS 443)로 설정해 구성요소 수를 줄이고 지연을 낮춘다.

❓ 열린 질문

• ALB 기본 health check의 unauthenticated 동작을 AgentCore의 SigV4/OAuth 요구와 어떻게 정합시킬 것인가?
• OAuth는 헤더 전달만으로 충분한가, 아니면 추가 위변조 탐지 기준이 필요한가?
• Pattern 2에서 클라이언트 직접 인증 전달 구조의 감사·방화벽 통제가 기존 프록시 경로와 동등하게 검증 가능한가?