
AWS에서 AI 에이전트 실행 환경 격리하기 1부: Amazon EKS와 Agent Sandbox, 개념과 구성
두줄요약
EKS에서 Agent Sandbox와 gVisor로 AI 에이전트 코드 실행 환경을 분리하는 구성을 정리했습니다. Pod 보안 설정과 런타임 격리의 역할 차이 및 운영 시 점검점을 설명했습니다.
문제 상황
- AI 에이전트 생성 코드가 공용 EKS 노드와 IAM 자격 증명 인접 환경에서 실행되는 위험
- 신뢰할 수 없는 코드의 호스트 커널·클러스터 내부 서비스 접근 제한과 샌드박스 비용 관리 요구
구조와 흐름
- Sandbox, SandboxTemplate, SandboxWarmPool, SandboxClaim CRD 기반 샌드박스 수명 주기 관리
- Python SDK의 Claim 생성과 sandbox-router 경유 명령·파일 입출력 경로
- gVisor 전용 노드 그룹, RuntimeClass, NetworkPolicy를 결합한 실행 환경 구성
선택 이유
- gVisor Sentry의 시스템 콜 중재와 Gofer 기반 파일 시스템 분리로 호스트 커널 직접 노출 축소
- Warm Pool과 replicas: 0 풀을 통한 대기 샌드박스·Cold Start 비교 기반 마련
- Managed Node Group의 사용자 데이터로 runsc 등록 가능한 EKS 구성
주의할 점
- runc와 gVisor 모두 PodSpec의 비루트 실행·capability 제거·토큰 자동 마운트 비활성화 필요
- gVisor 내부 seccomp 경계와 kubectl port-forward 실패 특성 인지 필요
- 전용 노드 강제를 위한 admission 정책, NetworkPolicy 실제 적용 상태, IMDSv2 홉 제한 점검 필요


