데브옵스
AWS에서 AI 에이전트 실행 환경 격리하기 2부: Amazon EKS와 Agent Sandbox, 개념과 구성
두줄요약
EKS Agent Sandbox와 gVisor를 결합한 AI 에이전트 코드 실행 격리 구조와 운영 검증 결과를 다뤘습니다. NetworkPolicy·DNS·Warm Pool·router 보안을 함께 설계해야 함을 제시했습니다.
구조와 흐름
- Amazon EKS의 Agent Sandbox에 gVisor 전용 노드 그룹, VPC CNI NetworkPolicy, IMDSv2 홉 제한을 결합한 다계층 격리 구조
- SandboxTemplate, Warm Pool, SandboxClaim 기반의 샌드박스 생성·할당·만료·일시 중지 선언형 관리
- 에이전트의 Bedrock 모델 호출과 gVisor 샌드박스 내 코드 실행 경로 분리
성능/운영 포인트
- Warm Pool 사용 시 Claim Ready 중앙값 약 57ms로 Cold Start 대비 약 34~36배 단축
- gVisor의 시스템 콜·파일 작업·프로세스 생성 비용 증가와 RuntimeClass 오버헤드 반영 필요
- Pod IP cooldown에 따른 burst 지연 완화를 위한 Prefix Delegation, WARM_IP_TARGET, 피크 기준 Pool 크기 설정
주의할 점
- VPC CNI의 NetworkPolicy 활성화 없이는 정책 객체가 있어도 IMDS·Kubernetes API 접근 가능
- 기본 Egress 정책의 공용 인터넷 허용에 따른 목적지 허용 목록, egress 프록시·AWS Network Firewall 추가 설계 필요
- 기본 DNS의 공용 리졸버 주입 문제와 Route 53 Resolver·VPC 엔드포인트 사설 IP 허용 규칙 검토
적용해볼 점
- router의 allow-all 기본 인가 대신 Ingress NetworkPolicy, port-forward RBAC 제한, scoped-token 검토
- 일시 중지 후 작업 상태 보존용 PVC와 가용 영역별 gVisor 노드 용량 확보
- 클러스터 내 에이전트의 Direct 연결로 router Ingress 정책 적용
