AWS EKS에서 AI 에이전트 격리 운영 가이드: NetworkPolicy, Warm Pool 및 gVisor 성능 분석

·2026.10.18 12:28

핵심 내용

Warm Pool 활용 시 gVisor 샌드박스 기동 시간을 약 57ms로 단축하고 런타임 차이를 제거한다.

1 / 4

자세히 보기

NetworkPolicy 활성화와 DNS 경로 제어

Agent Sandbox의 기본 NetworkPolicy는 VPC CNI에서 enableNetworkPolicy: "true"로 활성화해야 정상 동작한다. 활성화 전에는 정책 객체가 존재해도 메타데이터 서비스(IMDS)와 Kubernetes API 연결이 차단되지 않았다. 활성화 후에는 사설 대역과 링크 로컬 대역이 차단되지만, 인터넷으로 나가는 Egress는 허용되므로 데이터 유출 방지를 위해 목적지 허용 목록이나 AWS Network Firewall 같은 추가 통제가 필요하다.

기본 템플릿은 DNS를 Google(8.8.8.8)과 Cloudflare(1.1.1.1)로 고정하지만, AWS 환경에서는 Route 53 Resolver를 거치도록 사용자 정의 networkPolicy와 dnsPolicy: None을 설정해야 DNS Firewall 및 쿼리 로깅이 적용된다. VPC 엔드포인트를 사용하는 경우 사설 IP 경로가 Egress 규칙에 막힐 수 있으므로, AWS API 호출이 필요하면 해당 서브넷의 443 포트를 명시적으로 열어야 한다.

Warm Pool을 통한 기동 지연 최소화

Warm Pool을 사용하면 SandboxClaim 생성부터 Ready까지 걸리는 시간이 Cold Start 대비 극적으로 단축된다. 측정 결과 gVisor Cold Start는 중앙값 2,046.6ms인 반면, Warm Pool을 활용하면 57.2ms로 약 35.8배 빨라진다. runc 역시 Cold Start 1,822.0ms에서 Warm Pool 53.3ms로 개선되어, Warm Pool 환경에서는 런타임 간 성능 차이가 사실상 사라진다.

동시 요청이 Warm Pool 크기를 초과하면 VPC CNI의 IP 재사용 대기 시간(IP_COOLDOWN_PERIOD, 기본 30초)으로 인해 기동 지연이 발생할 수 있다. 이를 방지하려면 Prefix Delegation으로 IP 할당 단위를 키우거나 WARM_IP_TARGET으로 여유 IP를 확보하고, Warm Pool 크기는 평균이 아닌 피크 동시 요청 수에 맞춰 설정해야 한다.

gVisor 격리 비용과 상태 보존 전략

gVisor의 성능 비용은 시스템 콜 횟수에 비례한다. 순수 CPU 연산은 runc와 차이가 없으나, 파일 작업과 프로세스 생성은 4.7~6.5배 느리다. 메모리 사용량도 kubelet 지표 기준 runc 43 Mi 대비 gVisor 57 Mi로 높으며, 호스트 RSS 기준으로는 약 120 MiB가 소요되어 스케줄러 오버헤드 반영이 필요하다.

에이전트 세션의 유휴 상태 관리를 위해 operatingMode: Suspended를 사용할 수 있으나, emptyDir을 사용하면 재개 시 데이터가 소실된다. 작업 디렉터리를 보존하려면 volumeClaimTemplates로 EBS gp3 PVC를 연결해야 하며, EBS 볼륨의 가용 영역(AZ) 제약으로 인해 재개되는 Pod는 볼륨과 같은 AZ의 gVisor 노드로만 배치될 수 있다.

에이전트 연동과 router 보안 강화

Amazon Bedrock의 Claude 모델과 샌드박스를 연동할 때, 역할 분리는 네트워크가 아닌 자격 증명 계층에서 성립한다. 샌드박스에는 ServiceAccount 토큰이 마운트되지 않고 IMDS 홉 제한으로 노드 자격 증명 접근이 차단되므로, 샌드박스가 Bedrock API를 직접 호출하지 못한다. 네트워크 계층에서도 차단하려면 Egress 목적지를 제한하거나 egress 프록시를 사용해야 한다.

sandbox-router의 기본 인가 모드는 allow-all이므로, TokenReview 모드 활성화 시에도 SDK v1.0.5는 인증 헤더를 전송하지 않아 수동 헤더 추가가 필요하다. 또한 kubectl port-forward는 NetworkPolicy를 우회하므로, router 접근을 제한하려면 RBAC로 pods/portforward 권한을 제어하고 클러스터 내부 에이전트는 Direct 연결을 사용해야 한다.

이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.

AI 처리 방식을 확인하거나, 요약 오류와 출처 표기 문제, 삭제 요청을 문의 · 건의로 알려주세요.