EC2 대신 AWS Lambda MicroVMs에서 code-server로 Strands Decider 핸즈온을 완료한 경험
요약
EC2 기반의 'Strands Decider 핸즈온' 실습 환경을 AWS Lambda MicroVMs로 이식하여 성능 및 비용 효율성을 검증했습니다. 그 결과, 판정 처리 레이턴시가 크게 단축되었고, 메모리 스냅샷 기능을 통해 모델 재로드 없이 추론을 빠르게 재개할 수 있음을 확인했습니다.
핵심 포인트
- Lambda MicroVMs는 EC2 대비 낮은 지연 시간과 높은 성능 버스트를 제공합니다.
- 메모리 스냅샷 및 suspend/resume 기능으로 모델 재로드 없이 빠른 추론 재개가 가능합니다.
- 자동 종료 기능(8시간)을 통해 장기 방치 시에도 비용 상한선을 유지할 수 있습니다.
- 임시 검증 환경 구축에 최적화되어, 빠르고 안전하게 리소스를 관리할 수 있습니다.
Amazon EC2 (t4g.xlarge)용으로 공개된 'Strands Decider 핸즈온'을 AWS Lambda MicroVMs 기반의 자체 제작 code-server 환경으로 이식하여 일련의 실습 단계를 완주했습니다.
검증을 통해 확인된 주요 결과는 다음 3가지입니다.
- 최대 16 vCPU의 버스트 성능 덕분에, 판정 처리 레이턴시가 EC2 (4 vCPU)의 약 3000
5400 ms에서 7831328 ms(약 1초)로 단축되었습니다. - 약 8.4 GB의 메모리를 확보한 추론 서버를 중단시키지 않고, suspend 상태에서 resume함으로써 수 초 만에 모델 재로드 없이 추론을 재개할 수 있었습니다.
- 일반적인 사용(1.5시간)에서는 EC2 (약 39엔)가 MicroVM (약 114엔)보다 저렴하지만, MicroVM에는 8시간의 자동 종료 기능이 있어 24시간 방치하는 것을 잊었을 때도 비용 상한선(약 606엔)을 유지할 수 있습니다.
수 GB 모델을 다루는 임시 검증 환경으로, 몇 초 만에 부팅하고 상태를 유지한 채 중지할 수 있는 Lambda MicroVMs는 실용적인 선택지가 됩니다.
이번 검증을 시도한 동기는 2가지가 있습니다.
첫 번째는 최근 참가했던 Kiro University Challenge에서 제작한 code-server on Lambda MicroVMs를 모델 로딩이 필요한 본격적인 핸즈온에 실전 투입하고 싶었기 때문입니다.
두 번째는 1~2시간 정도의 검증을 위해 EC2를 프로비저닝하고 싶지 않다는 체감입니다. EC2는 환경 구축이나 CloudFormation 배포에 몇 분을 기다려야 할 뿐만 아니라, 검증 종료 후 리소스를 삭제하는 것을 잊으면 과금이 계속됩니다. 필요한 때만 수 초 만에 가동되고, 작업 중단 시에는 메모리째 일시 정지할 수 있는 환경에서 구동하고 싶었습니다.
다루게 된 주제는 fukuchi님(@har1101)이 공개한 핸즈온 아티클입니다.
본 핸즈온은 JAWS-UG 도쿄 지부가 개최한 이벤트 'JAWS-UG Tokyo Strands Decider 핸즈온'의 소재이기도 합니다.
정성스러운 핸즈온을 공개해 주신 @har1101님께 감사드립니다!
이번 검증에서 조합한 두 가지 기술에 대해 개요를 정리합니다.
AWS가 2026년 10월 1일에 발표한 결정/판정 전용의 2B 경량 언어 모델입니다.
일반적인 대규모 언어 모델(LLM)처럼 자유 문장의 텍스트 생성을 하지는 않습니다. 미리 정의된 선택지 선정(choice), Yes / No의 이진 판정(noul), 채점(score) 등 의사 결정이나 라우팅 판정에 특화되어 있습니다.
이벤트 캐치프레이즈에서도 언급되었듯이, AWS제 Jev 같은 것으로 소개되었던 것처럼, 판정 특화형 모델로 알려진 TypeSafe Jev와 유사한 기술입니다. 문장을 토큰 단위로 생성하지 않기 때문에 파싱 오류가 발생하지 않고, 신뢰도(confidence)와 함께 고속으로 판정을 반환합니다.
클라우드의 관리형 API 형태로 제공되는 서비스와 달리, Strands Decider는 모델 가중치(베이스 모델 Qwen3.5-2B + LoRA 어댑터)가 공개되어 있습니다. 자체 환경 내에서 완결하여 구동할 수 있기 때문에 외부로 데이터를 전송할 수 없는 요구 사항에도 처리하기 쉬운 장점이 있습니다.
AWS Lambda의 가상화 기반인 'Firecracker'를 경량 가상 머신으로 온디맨드(on-demand)로 구동할 수 있는 것입니다. 일반적인 Lambda 함수와 달리 '최대 8시간' 동안 구동하는 것이 가능합니다.
AMI에서 구동하는 EC2와는 달리, 메모리와 vCPU의 스냅샷으로부터 몇 초 만에 인스턴스가 복구됩니다. 가상 머신이 RUNNING 상태인 시간에 대해서만 과금되는 초 단위 종량제나, 실행 중 프로세스를 메모리째 퇴거하여 복구할 수 있는 suspend/resume 기능을 갖추고 있습니다. 또한, 베이스라인 지정 리소스(메모리·vCPU)에 대해 부하에 따라 최대 4배까지 자동 버스트합니다.
원문에서 지정된 EC2 t4g.xlarge와 이번에 꾸민 Lambda MicroVMs 환경의 대비는 다음과 같습니다.
| 항목 | 원문 환경 (EC2 t4g.xlarge) | 이번 환경 (Lambda MicroVMs sdh-code-server ) |
|---|---|---|
| vCPU | 4 | baseline 4 / peak 16 |
| ... | executionRoleArn (IMDSv2 경유로 획득) |
검증일은 2026년 10월 8일, 리전은 도쿄(ap-northeast-1)입니다.

▲ AWS Lambda 콘솔의 「MicroVM Images」 화면. 생성한 sdh-code-server 이미지 (8 GB memory / 4 vCPU)와 Running 상태의 MicroVM 인스턴스

▲ 브라우저로 연 code-server. 워크스페이스 내에 핸즈온 자산이 배치되어 있음
EC2 환경에서 MicroVM 환경으로 이식하는 과정에서, 다음 3가지 사항을 염두에 두고 컨테이너 이미지와 설정을 구성했습니다.
1번째는 32 GB 디스크 확보입니다. Lambda MicroVMs의 디스크 용량은 베이스라인 메모리에 연동됩니다 (2 GiB로 8 GB, 8 GiB로 32 GB). PyTorch나 가상 환경, 약 4.4 GB의 모델 가중치를 수용하기 위해 minimumMemoryInMiB를 8192에 설정했습니다.
2번째는 CPU용 PyTorch Wheel 선정입니다. Graviton 환경에서의 행렬 연산 멈춤(hanging)을 회피하기 위해 공식 CPU용 Wheel (download.pytorch.org/whl/cpu의 2.14.1+cpu)를 채택했습니다. CUDA 포함 Wheel에 포함된 NVPL BLAS 의존성을 제거했습니다.
3번째는 인증 및 환경 변수 설정입니다. MicroVM 실행 역할(execution role)에 Amazon Bedrock 권한을 부여하고, IMDSv2 경유로 자격 증명(credential)을 획득하게 했습니다. 또한, Strands의 기본 리전이 us-west-2이기 때문에 컨테이너 환경 변수로 도쿄 리전(AWS_DEFAULT_REGION=ap-northeast-1)을 명시했습니다.
이식 코드는 공개 리포지토리에 정리했습니다. 외부 툴에 의존하지 않는 자립형 구성입니다.
사전 도구(Node.js 22, pnpm, uv)가 갖춰져 있다면, 다음 명령어로 인프라 구축부터 이미지 생성, VM 기동까지 진행할 수 있습니다.
pnpm install && pnpm -C infra install
pnpm -C infra exec cdk deploy --outputs-file cdk-outputs.json --require-approval never
...
node scripts/proxy.mjs를 실행하면 발행되는 원타임 URL을 브라우저에서 열기만 하면, 연습 파일 일식이 배치된 code-server에 연결할 수 있습니다. 상세한 명령어 체계나 6번째 항목의 동작 검증 스크립트(verify.mjs)에 대해서는 리포지토리의 README를 참조해 주십시오.
code-server 내 터미널에서 핸즈온의 각 단계(Step 1~7)를 실행하여, 판정 결과, 처리 속도, 메모리 유지, 비용을 측정했습니다.
원문 기사의 EC2 환경에서의 판정 결과와 MicroVM 환경에서의 실측값을 비교한 결과입니다.
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
| Step | 내용 | MicroVM 실측값 | 원 기사(EC2) 값 | 판정 결과의 일관성 |
|---|---|---|---|---|
| 1 | ask (choice) | 청구 0.599 / 기술 0.265 / 영업 0.136, confidence 0.398 | 청구 0.599 / 기술 0.265 / 영업 0.136, confidence 0.398 | 완전 일치 |
| 1 | ask (noul) | 0.789 | 0.789 | 완전 일치 |
| 1 | ask (score) | 1.17 (0.139 / 0.552 / 0.310), confidence 0.516 | 1.17 (0.139 / 0.552 / 0.310), confidence 0.516 | 완전 일치 |
| 2 | serve + curl | {"긴급한가":{"noul":0.7894}}, 레이턴시 783 ms | 값 일치, 레이턴시 약 3000 ms | 값 일치 (속도는 MicroVM이 우위) |
| 3 | tool call intervention | args_grounded 0.16 / premature 0.65 → Guide | args_grounded 0.16 / premature 0.65 → Guide | 완전 일치 |
| 4 | escalation gate | p_human: 0.523 / 0.862 / 0.764 / 0.853 | 5 건 모두 같은 분류 | 완전 일치 |
| ... | ||||
| Step 5에서는 계정 측에서 Anthropic Sonnet 4.6의 Marketplace 구독 신청이 미완료였기 때문에, 호출 대상을 이미 신청된 Haiku 4.5로 변경하여 검증했습니다. Decider에 의한 라우팅 판정 자체는 올바르게 이루어지고 있습니다. |
여러 번 실행해도 점수가 흔들리지 않았으며, 원 기사의 각 클래스 확률이나 긴급도 판정 값들이 그대로 재현되었습니다. 출력 포맷의 깨짐도 없이 에이전트의 분기 판정으로서 높은 결정성을 확인할 수 있었습니다.
뚜렷한 차이가 나타난 것은 판정 처리 속도였습니다.
원 기사의 EC2 t4g.xlarge (고정 4 vCPU)에서는 Decider의 각 판정에 약 43005400 ms, HTTP 서버 경유 추론(Step 2)에 약 3000 ms가 소요되었습니다. 이에 반해, Lambda MicroVMs 상에서는 Step 2의 추론이 783 ms였고, 각 단계의 판정 역시 **7831328 ms** 범위에 머물렀습니다.
Lambda MicroVMs는 8 GiB baseline 설정으로 최대 16 vCPU까지 버스트합니다. 텍스트 생성을 수행하지 않는 CPU 판정 모델에 대해, 버스트된 CPU 리소스가 직접적으로 기여하여 EC2 대비 약 3~4배의 속도로 응답이 돌아오는 결과를 얻었습니다.
Lambda MicroVMs의 특징인 메모리 상태를 스냅샷으로 퇴거하여 일시 중지하는 suspend와, 거기서 복귀(resume)를 검증했습니다.
포트 8099에서 strands-decider serve를 구동하고, 모델 가중치를 유지한 상태(RSS 약 8.4 GB, 프로세스 ID 988)로 일시 중지 및 재개를 수행했습니다.
# 터미널에서 일시 중지
node scripts/mvm.mjs suspend
# 재개
...
가상 머신을 재개하자, strands-decider serve는 정지 전과 동일한 프로세스 ID(988)로 생존하고 있었습니다. 서버의 재시작이나 가중치 재적재는 전혀 발생하지 않았습니다.
재개 직후 첫 번째 추론 요청은 메모리 페이지 인을 수반했기 때문에 7300 ms가 소요되었으나, 두 번째 요청부터는 일반적인 약 1000 ms로 복귀했습니다.
EC2 인스턴스의 정지 및 시작 시에는 OS 재부팅에 따라 메모리상의 프로세스가 사라집니다. Lambda MicroVMs에서는 수 GB의 가중치를 상주시키는 프로세스 자체를 대기시키고, 필요할 때 몇 초 만에 추론 가능한 상태로 되돌릴 수 있는 실용성을 확인할 수 있었습니다.
핸즈온을 예상 소요 시간 1.5시간으로 진행했을 경우와 종료 후 삭제를 잊었을 경우의 비용 비교입니다 (1 달러 = 150 엔 환산).
시간당 단가를 비교해 보면, Lambda MicroVMs는 EC2보다 약 3배의 비용이 발생합니다. 일반적으로 사용하는 범위(1.5시간)라면, EC2가 약 39엔, MicroVM이 약 114엔으로, 둘 다 수십 엔에서 백여 원대에 머무릅니다.
주목할 점은 '잊어버리는' 시나리오입니다. EC2는 자동 종료 메커니즘이 없기 때문에, 중지하거나 삭제하는 것을 잊고 방치하면 24시간 동안 약 622엔($4.15)까지 과금이 늘어납니다. 반면, Lambda MicroVMs는 최대 실행 시간(8시간 후)으로 인해 자동으로 종료됩니다. 따라서, 만약 하루 종일 방치하더라도 8시간 시점에 자동 중지하여, 최대 약 606엔($4.04)에 그칩니다!
또한, 작업 중간에 suspend를 거치는 간헐적 이용이라면 컴퓨팅 과금(초 단위 과금)을 완전히 막을 수 있습니다. SUSPENDED 상태 유지 비용은 스냅샷 보관료($0.08 / GB·월)만 발생하므로, 실제 가동 시간이 짧은 검증일수록 비용 효율이 높아집니다.
검증 완료 후에는 VM을 즉시 terminate하여 컴퓨팅 과금을 중단했습니다. 남아있는 이미지 버전이나 CDK 스택도 추가 검증이 필요 없게 되면 삭제하는 운영 방식을 취하고 있습니다.
EC2용 핸즈온을 직접 만든 Lambda MicroVMs 환경으로 이식하면서, 얻은 성과와 운영 시 주의할 점 모두를 파악할 수 있었습니다.
장점 중 하나는 몇 GB급 모델 상주 환경을 온디맨드로 다룰 수 있다는 점입니다. 약 8.4GB의 메모리를 확보한 프로세스를 몇 초 만에 시작/중단/재개할 수 있어, 항상 켜져 있는 비용을 지불하지 않고도 모델을 대기시킬 수 있습니다.
두 번째는 CPU 판별 모델과의 궁합이 좋다는 점입니다. 최대 16 vCPU의 버스트로 인해 경량 판별 모델이 1초 내외로 가볍게 작동했습니다.
세 번째는 일회용 환경으로서 다루기 쉽다는 점입니다. EC2처럼 리소스를 잊어버려 장기간 과금될 위험을 줄이기 쉬웠고, 불필요해진 시점에 정리하기가 용이했습니다.
운영 시 주의점 및 전제 조건
- 초기 계정의 메모리 쿼터: 개설 직후 AWS 계정에서는 기본 메모리 한도가 8GB로 제한되어 있어, 8 GiB 베이스라인 VM은 동시에 1대까지만 시작할 수 있습니다(2대는
ServiceQuotaExceededException). 여러 대를 구동하려면 사전에 쿼터 상향 신청이 필요합니다. -
지속 가동 비용의 높음: 장시간 연속으로 계속 켜두는 용도에서는 EC2가 명확하게 저렴합니다. MicroVM의 강점을 활용하기 위해서는 작업 중간에suspend를 거치는 운영 설계가 필수적입니다. -
Bedrock의 Marketplace 신청: Step 5에서 다루는 Claude Sonnet 같은 모델 호출에는 IAM 권한 외에 계정 차원에서 AWS Marketplace 구독 신청이 필요합니다(미신청 시AccessDeniedException).
Strands Decider와 같은 몇 GB급 모델을 구동하는 핸즈온이나 검증에서, Lambda MicroVMs는 '빠른 시작과 추론', '상태 유지를 통한 중단', '안전한 비용 관리'를 모두 갖춘 실용적인 기반이었습니다.
이번 환경을 직접 경험해보고 싶은 분들은 공개 리포지토리의 절차에 따라 실행해보세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기