AWS Lambda MicroVM으로 AI 생성 코드를 격리할 때 확인할 보안 경계

AWS Lambda MicroVM AI 코드 격리를 검토할 때 가장 먼저 나눠 봐야 할 게 있어요. Firecracker/KVM 경계는 비신뢰 코드를 호스트와 다른 MicroVM에서 분리하지만, 코드가 인터넷이나 AWS 리소스에 접근하는 것까지 자동으로 막아 주지는 않습니다. 테넌트 또는 작업마다 MicroVM을 하나씩 두는 건 출발점이고, 네트워크·IAM·스냅샷·종료 정책까지 붙어야 샌드박스에 가까워짐.

이 글은 2026년 7월 31일 기준 AWS 출시 공지와 개발자 문서, 가격 문서, Firecracker 설계를 대조해 정리했습니다. 실제 AWS 계정에서 침투나 데이터 폐기, 비용을 직접 측정한 결과는 아니에요. 공식 설명의 경계를 배포 승인 질문으로 바꿔 본 분석입니다.

MicroVM이 막는 범위부터 정확히 잡기

AWS가 설명하는 기본 격리 단위는 단일 테넌트, 사용자 세션 또는 작업을 위한 별도 MicroVM입니다. 각 환경은 Amazon Linux 2023과 전용 HTTPS 엔드포인트를 가지며, Firecracker가 KVM과 VMM을 이용해 호스트 및 다른 MicroVM과의 1차 경계를 만듭니다. Firecracker 설계에는 seccomp, cgroup·namespace, 권한을 낮춘 jailer 같은 방어 계층도 나와 있어요. 다만 Lambda MicroVMs에서는 이 하부 설정을 AWS가 관리합니다. 사용자가 jailer를 직접 조립하는 서비스는 아님.

여기서 자주 미끄러지는 부분. 같은 MicroVM 안의 프로세스는 게스트 OS, 파일시스템과 실행 역할의 영향을 함께 받습니다. 악성 코드가 게스트 내부의 다른 프로세스나 토큰을 읽는 위험까지 VM 경계가 지워 주지는 않아요. 그래서 “AI 모델 하나당”보다 신뢰 경계가 같은 “테넌트 또는 작업 하나당” 할당하는 편이 맞습니다. 여러 고객의 코드를 한 MicroVM에 넣으면 테넌트 분리를 애플리케이션이 다시 구현해야 하니 갑자기 일이 커짐.

additionalOsCapabilities=["ALL"]도 비슷합니다. AWS 설명상 파일시스템 마운트, 네트워크 namespace 생성, eBPF 같은 권한 작업의 영향은 VM 경계 안에 머뭅니다. 그래도 게스트 내부 공격 표면은 넓어지므로 생성 코드에 분명한 이유가 없다면 기본 capability 집합을 유지하는 게 안전해요. AWS 핵심 개념과 Firecracker 설계를 같이 봐야 이 차이가 선명합니다.

기본 인터넷 송신은 별도로 닫아야 한다

가장 먼저 확인할 기본값은 public internet egress입니다. 공식 네트워킹 문서에 따르면 Lambda MicroVM은 기본적으로 공용 인터넷으로 나갈 수 있어요. VM 격리가 제대로 작동해도 생성 코드가 프롬프트, 소스, 환경 변수나 AWS 응답을 외부로 보내면 데이터 경계는 이미 깨진 셈입니다. 패키지 설치를 열어 두면 악성 설치 스크립트나 외부 통신 경로도 함께 살펴야 하고요. VM이 있으니 마음 편-안, 여기서는 아직 이릅니다.

민감한 작업은 런타임 egress connector를 VPC에 연결하고 보안 그룹, NACL, 라우팅으로 필요한 목적지만 허용하는 방식이 안전한 기본값에 가깝습니다. 단, VPC connector를 붙였다는 사실만으로 도메인 허용 목록이나 TLS 내용 검사가 생기는 건 아니에요. 인터넷이 필요한 설치 과정은 승인된 내부 미러나 프록시를 통하게 하고, AWS 서비스 접근은 가능한 경우 private endpoint와 리소스 정책을 함께 검토해야 합니다.

이미지 빌드와 런타임 connector는 다르게 설정할 수 있습니다. 빌드할 때만 승인된 저장소를 열고 생성 코드가 도는 런타임은 더 좁게 막는 구성이 가능하다는 뜻이에요. 빌드가 인터넷을 썼다고 런타임까지 열 필요는 없음. 세부 동작은 AWS 네트워킹 문서에서 확인할 수 있습니다.

인바운드는 전용 HTTPS 엔드포인트와 TLS, JWE 토큰으로 제한됩니다. 토큰은 특정 MicroVM, 허용 포트, 만료 시간에 묶이고 인증 없는 옵션은 없어요. 하지만 JWE는 AWS 프록시를 통과할 자격 증명이지 애플리케이션 사용자 권한 모델은 아닙니다. 토큰 발급 제어면에서 사용자와 microvmId 소유권을 확인하고, 필요한 단일 포트와 15~30분짜리 단기 토큰을 쓰는 게 AWS 모범 사례입니다. 외부 연결이 전혀 필요 없다면 NO_INGRESS를 선택합니다.

실행 역할은 생성 코드의 권한으로 봐야 한다

이미지 생성용 build role과 런타임 execution role은 역할이 다릅니다. build role은 S3 artifact 조회, 빌드 로그와 필요할 때 private ECR 인증에 쓰이고, execution role은 런타임 로그와 다른 AWS 서비스 접근에 쓰여요. 두 역할은 선택 사항이며 execution role을 생략하면 런타임 CloudWatch 로그도, 다른 AWS 서비스 접근도 없습니다. 관측성을 얻는 대신 권한도 같이 들어오는 구조라 그냥 로그용이라고 가볍게 보면 곤란함.

보안 검토 질문은 “역할이 붙었나?”가 아니라 “비신뢰 코드가 이 역할로 무엇을 할 수 있나?”여야 합니다.

build role과 execution role을 분리했는가
execution role은 필요한 리소스 ARN과 API만 허용하는가
권한 변경, 새 역할 전달, 비밀 목록 조회 같은 제어면 권한을 제외했는가
같은 버킷이나 DB의 테넌트 데이터는 리소스 정책과 애플리케이션 조건으로도 나뉘는가
로그에는 비밀 마스킹을 적용하고 업무 API 권한과 따로 검토했는가
재개 시 만료되거나 범위가 달라진 자격 증명을 /resume에서 갱신하는가

스냅샷은 초기 상태를 복제하고 suspend는 상태를 보존한다

Lambda는 Dockerfile을 실행하고 애플리케이션을 시작한 뒤 Firecracker snapshot을 만듭니다. AWS 문서상 이 스냅샷에는 프로세스 메모리와 루트 파일시스템뿐 아니라 백그라운드 프로세스, 열린 네트워크 연결, 파일 핸들, pipe까지 들어가요. 같은 이미지에서 시작한 MicroVM들이 동일한 초기 상태를 공유하는 구조입니다.

그러니 빌드 중 API 키, 세션 토큰, tenant ID, UUID, 임시키나 nonce를 만들면 그 값도 공통 초기 상태에 들어갈 수 있습니다. 빌드 시 설정한 환경 변수 역시 같은 이미지의 MicroVM에 공통이에요. 테넌트별 값은 최대 16KB인 runHookPayload에 최소 정보나 비밀의 참조만 넘기고 /run에서 단기 값으로 가져오는 식으로 분리합니다. payload 자체를 비밀 저장소처럼 쓰지는 말아야 하고요. 난수도 /run 이후 CSPRNG로 다시 생성해야 합니다. AWS 스냅샷 문서가 이 부분의 핵심 근거입니다.

상태 전환마다 책임도 달라집니다.

전환	보존되는 상태	운영자가 확인할 일
이미지 → run	공통 이미지 snapshot에서 복원	테넌트별 상태·난수·단기 자격 증명을 `/run`에서 초기화
running → suspend	메모리와 디스크를 checkpoint	pending write를 비우고 재개하면 안 될 연결·자격 증명을 정리
suspended → resume	메모리와 디스크를 그대로 복원	토큰·연결을 갱신하고 테넌트와 정책 변경을 재검증
running/suspended → terminate	`/terminate` 뒤 compute resource release	필요한 결과만 보존하고 제어면에서 `TERMINATED`를 확인

핵심은 suspend가 삭제가 아니라는 점입니다. 메모리와 디스크가 남고 재개하면 그대로 돌아와요. 종료 상한은 maximumDurationInSeconds로 1~28,800초 범위에서 정하고 suspendedDurationSeconds도 설정해 자동 종료 조건을 둬야 합니다. endpoint traffic만 idle activity로 판단하므로 endpoint를 쓰지 않는 비동기 작업은 자동 suspend가 실행 중인 일을 끊을 수도 있어요. 이건 꽤 현실적인 함정.

폐기 완료 기준은 TERMINATED 상태 확인, 실행 역할·JWE·외부 임시 자격 증명의 만료 또는 철회, 승인된 결과만 외부 저장소에 보존한 상태로 잡는 편이 안전합니다. /terminate hook은 정리 기회이지 유일한 통제가 아니에요. hook 실패나 강제 종료에도 짧은 TTL로 외부 자격 증명이 무효화돼야 합니다. AWS 공개 문서에서는 물리 저장 매체의 삭제 방식이나 즉시 복구 불가능성을 구체적으로 확인할 수 없었으므로, terminate가 곧 물리 데이터 완전 삭제라고 단정하면 안 됩니다.

배포 승인은 비용과 종료 조건까지 묶어서 본다

비신뢰 코드의 무한 루프, 과도한 컴파일이나 자원 생성은 격리 안에서도 가용성과 비용 문제가 됩니다. 실행 중 baseline compute는 초 단위로 과금되고, workload는 baseline의 최대 4배이면서 최대 8GB·4vCPU까지 수직 확장될 수 있어요. 최소 baseline, 작업 timeout, 전체 실행 상한, 계정 quota, 동시 MicroVM 수, 외부 API rate limit를 한 묶음으로 봐야 합니다.

suspend 중 compute 요금은 없지만 완전 무료 상태는 아닙니다. snapshot 저장, 시작·재개 read, suspend write, 데이터 전송에 요금이 붙고 MicroVM image storage에는 1주 최소 보존 기간이 있어요. 리전별 단가는 이 조사에 옮기지 않았습니다. 가격과 지원 리전은 바뀔 수 있으니 배포 직전에 AWS Lambda 가격표와 출시 공지를 다시 확인하는 게 맞습니다.

마지막 승인표는 이 정도면 됩니다.

테넌트 또는 신뢰 경계가 같은 단일 작업에 MicroVM 하나를 할당했는가
불필요한 additionalOsCapabilities=["ALL"]을 제거했는가
ingress가 필요 없으면 NO_INGRESS, 필요하면 소유권 검증과 포트·시간 제한 JWE를 적용했는가
기본 public egress를 그대로 두지 않고 목적지를 제한했는가
build role과 execution role을 분리하고 런타임 권한을 최소화했는가
빌드 snapshot에 비밀, 테넌트 ID, 고정 UUID·nonce가 들어가지 않는가
/run, /resume, /suspend에서 고유 상태와 자격 증명, 연결을 맞게 처리하는가
실행 시간과 suspended 상태에 강제 종료 상한이 있는가
TERMINATED를 확인하고 hook 실패에도 외부 자격 증명이 만료되는가
snapshot I/O·저장·전송·동시 quota까지 비용 경보에 포함했는가
관리형 base image의 DEPRECATED 또는 RECALLED 상태에 재빌드할 절차가 있는가

Lambda MicroVM은 AI 생성 코드가 호스트와 다른 테넌트로 번지는 위험을 줄이는 강한 실행 경계입니다. 하지만 인터넷 송신, AWS 권한, 복제되는 초기 상태와 종료 후 자격 증명까지 대신 결정해 주는 완성형 정책은 아니에요. VM 하나 만들고 끝이 아니라 격리 대상 → 남는 경로 → 안전한 기본값 → 폐기 확인까지 이어져야 비로소 배포 승인 가능.

상위 제어면의 권한이 어떻게 별도 사고 경로가 되는지도 함께 보려면 AI 모델 평가 인프라 권한 격리 글을 이어서 확인해 보세요.

제휴·협찬 없음. AWS 가격과 지원 범위는 2026년 7월 31일 기준 공식 자료를 바탕으로 했으며 게시 전 최신 문서를 다시 확인해야 합니다.

FAQ

Lambda MicroVM이면 AI 생성 코드를 아무 제한 없이 실행해도 안전한가요?

아니요. Firecracker/KVM은 호스트와 다른 MicroVM에 대한 VM 수준 격리를 제공하지만 기본 public egress, 실행 역할의 AWS 권한, 같은 게스트 내부 상태, 스냅샷과 자격 증명 수명주기는 별도 통제가 필요합니다.

MicroVM 하나를 여러 테넌트가 공유해도 되나요?

AWS가 설명하는 격리 단위는 단일 테넌트, 사용자 세션 또는 작업입니다. 여러 고객을 한 MicroVM에 넣으면 게스트 OS·파일시스템·실행 역할 안에서 테넌트 분리를 애플리케이션이 다시 구현해야 하므로 피하는 편이 안전합니다.

VPC egress connector를 붙이면 인터넷 접근이 자동으로 차단되나요?

아닙니다. VPC outbound traffic에는 보안 그룹과 NACL이 적용되지만 connector 자체가 도메인 허용 목록이나 TLS 내용 검사를 의미하지는 않습니다. 라우팅, 프록시, 허용 목적지와 private endpoint를 워크로드에 맞게 설계해야 해요.

JWE 토큰만 있으면 애플리케이션 인증을 생략해도 되나요?

안 됩니다. JWE는 특정 MicroVM과 포트, 만료 시간에 묶인 AWS 프록시 접근 자격 증명입니다. 사용자와 테넌트 권한은 토큰 발급 제어면과 애플리케이션에서 따로 검증해야 합니다.

suspend 중에도 데이터와 비용이 남나요?

메모리와 디스크 상태는 보존됩니다. compute 요금은 없지만 snapshot 저장과 read/write, 데이터 전송에는 요금이 생길 수 있어요. 삭제 완료 기준은 suspend가 아니라 TERMINATED 확인과 관련 자격 증명 만료 또는 철회입니다.