Cursor Cloud Agents용 샌드박스로 Lambda MicroVMs 사용

Cursor Cloud Agents용 샌드박스로 Lambda MicroVMs 사용 (Using Lambda MicroVMs as a sandbox for Cursor Cloud Agents)

AWS Lambda MicroVMs를 Cursor Cloud Agents용 자체 호스팅 머신으로 사용해 리포지토리, 도구 실행, 네트워크 액세스를 사용자가 제어하는 인프라에 유지할 수 있습니다. Cursor는 에이전트 루프와 모델을 호스팅하고, Lambda MicroVM은 워커가 풀 요청을 클레임하고 도구 호출을 실행하는 곳입니다. 이 패턴으로 실행 환경, 즉 이미지에 설치된 것, 사용 가능한 네트워크 액세스, 워커의 IAM 역할이 도달할 수 있는 AWS 리소스를 제어할 수 있습니다.

각 MicroVM은 스냅샷 기반 시작을 사용하는 Firecracker 격리 가상 머신으로, 최대 8시간 동안 실행되며 세션이 끝나면 종료됩니다. 세션은 상태를 절대 공유하지 않습니다. VM의 보안 경계와 서버리스의 운영 모델(관리할 클러스터 없음, 지불할 유휴 풀 용량 없음)을 모두 얻을 수 있습니다. 예약된 컨트롤러 Lambda 함수로 MicroVM을 오케스트레이션해 보류 중인 풀 요청에 응답합니다. 더 자세한 내용은 AWS Lambda MicroVMs에서 Cursor Cloud Agents용 자체 호스팅 머신 실행 참조 템플릿을 검토하세요.

출처: AWS Lambda 개발자 안내서

본문

작동 방식

예약된 컨트롤러가 각 보류 중인 풀 요청에 대해 하나의 MicroVM을 시작합니다:

  1. cursor.com/agents에서 자체 호스팅 머신을 대상으로 클라우드 에이전트를 시작합니다. 워커가 클레임할 때까지 요청은 보류 상태로 유지됩니다.
  2. 컨트롤러 Lambda 함수가 5분간의 Server-Sent Events(SSE) 폴링 창 동안 agent worker controller --spawn ./spawn.sh를 실행합니다. 일치하는 요청을 보면 spawn.sh를 실행합니다.
  3. spawn.sh는 RunMicrovm(aws lambda-microvms run-microvm)을 호출하고 기다리지 않고 반환합니다. 클레임의 CURSOR_* 환경을 --run-hook-payload를 통해 게스트로 전달합니다.
  4. MicroVM /run 훅(hook.py)은 그 페이로드를 적용하고 entrypoint.sh를 시작하며, 이 스크립트는 cursor-agent worker --pool … start를 실행합니다. 워커는 계정에서 도구 호출을 실행합니다.
  5. 세션이 릴리스 타임아웃을 지나 유휴 상태가 되면 워커가 릴리스하고 MicroVM이 종료됩니다.

Cursor 서비스 계정 API 키는 AWS Systems Manager Parameter Store에 SecureString으로 저장됩니다. 컨트롤러와 MicroVM은 런타임에 ssm:GetParameter로 그 키를 읽습니다. 키는 이미지에 절대 굽지 않습니다.

주요 속성

속성 이점
Firecracker 격리 세션마다 하드웨어 가상화 경계
스냅샷 부팅 Lambda가 이미지의 Firecracker 스냅샷에서 게스트를 복원
실행 역할을 통한 IAM 게스트가 MicroVmExecutionRoleArn의 단기 자격 증명 사용
상태 저장 기간 각 MicroVM은 최대 8시간 실행 가능(--maximum-duration-in-seconds 28800)
세션당 과금 MicroVM의 런타임에 대해서만 지불, 유휴 풀 용량용 아님

사전 조건

  • Lambda MicroVMs가 활성화된 AWS 계정과 Amazon S3, IAM, CloudFormation, Systems Manager Parameter Store 사용 권한
  • Cursor Enterprise 계정
  • 자체 호스팅 머신이 활성화된 Cursor 팀
  • 풀 워커용 서비스 계정 API 키
  • 최신 안정 버전으로 업데이트된 AWS CLI와 Docker(배포 스크립트가 컨트롤러 이미지를 빌드)

참조 구현 배포

anysphere/aws-lambda-workers 리포지토리는 최소한의 동작하는 배포를 제공합니다. 여기에는 다음이 포함됩니다:

  • CloudFormation 스택(cloudformation.yaml): 예약된 컨트롤러 Lambda 함수, EventBridge rate(1 minute) 규칙, Amazon S3 아티팩트 버킷, 데드 레터 큐, IAM 역할(MicroVmExecutionRole, BuildRole, SpawnRole, ControllerRole)
  • 컨트롤러 이미지(controller/Dockerfile, controller/handler.py) — 호출당 하나의 SSE 폴링 창 실행
  • MicroVM 이미지(microvm-image/: Dockerfile, hook.py, entrypoint.sh)
  • 스폰 훅(spawn.sh)과 배포 스크립트(deploy.sh)

배포 단계:

  1. 서비스 계정 API 키를 SSM에 저장합니다.
aws ssm put-parameter --type SecureString \
  --name /cursor-lambda-workers/cursor-api-key \
  --value "YOUR_SERVICE_ACCOUNT_KEY"
  1. 스택을 배포합니다. deploy.sh가 컨트롤러 이미지를 빌드하고 aws cloudformation deploy를 실행합니다.
POOL_NAMES=default ./deploy.sh
# POOL_NAMES=gpu,default ./deploy.sh
# ALL_POOLS=true ./deploy.sh
  1. 스택 출력을 사용해 microvm-image/에서 MicroVM 이미지를 빌드합니다. ready 및 validate 이미지 훅과 run MicroVM 훅을 활성화해 스냅샷 경로에 캡처되게 합니다.
BUCKET=$(aws cloudformation describe-stacks --stack-name cursor-lambda-workers \
  --query "Stacks[0].Outputs[?OutputKey=='ArtifactBucketName'].OutputValue" --output text)
BUILD_ROLE=$(aws cloudformation describe-stacks --stack-name cursor-lambda-workers \
  --query "Stacks[0].Outputs[?OutputKey=='BuildRoleArn'].OutputValue" --output text)
BASE=$(aws lambda-microvms list-managed-microvm-images --query "items[0].imageArn" --output text)
( cd microvm-image && zip -r /tmp/app.zip . )
aws s3 cp /tmp/app.zip "s3://${BUCKET}/app.zip"
aws lambda-microvms create-microvm-image \
  --code-artifact "uri=s3://${BUCKET}/app.zip" \
  --name cursor-pool-worker \
  --base-image-arn "${BASE}" \
  --build-role-arn "${BUILD_ROLE}" \
  --environment-variables "POOL_NAME=default,CURSOR_API_KEY_PARAM_NAME=/cursor-lambda-workers/cursor-api-key" \
  --hooks '{"port":9000,"microvmImageHooks":{"ready":"ENABLED","readyTimeoutInSeconds":60,"validate":"ENABLED","validateTimeoutInSeconds":60},"microvmHooks":{"run":"ENABLED","runTimeoutInSeconds":60}}'
  1. 검증하려면 cursor.com/agents에서 풀을 대상으로(또는 repo-바운드 모드에서 리포지토리를 대상으로) 클라우드 에이전트를 시작합니다.

자세한 지침은 리포지토리 README를 참조하세요.

풀 및 리포 모드

스택의 PoolNames와 이미지의 POOL_NAME을 일치시켜 컨트롤러와 게스트가 같은 풀을 서비스하게 하세요.

  • Any-repo 모드 — 라우팅은 git 원격이 아니라 풀 이름으로 수행됩니다. 게스트는 git 원격이 없는 워크스페이스에서 워커를 시작하므로 워커는 repo= 라벨을 생략합니다. 사용자는 에이전트를 시작할 때 Any repo 그룹과 풀 이름을 선택합니다.
  • Repo-bound 모드 — 워커가 하나 이상의 특정 git 원격을 서비스합니다. 클론을 MicroVM 이미지에 구우거나 CURSOR_REPO_URL을 설정해 entrypoint.sh가 시작 시 클론하게 합니다. 워커는 git 원격에서 repo= 라벨을 파생합니다. 비공개 리포지토리에는 워커의 git 자격 증명이 필요합니다.

네트워킹

참조 spawn.sh는 워커가 Cursor의 컨트롤 플레인에 도달할 수 있도록 관리형 INTERNET_EGRESS 커넥터와 이미지 훅용 ALL_INGRESS를 연결합니다. 아웃바운드 전용 워커는 부팅 후 인바운드 HTTPS를 절대 받지 않습니다.

비공개 리소스(예: Amazon Aurora 데이터베이스나 Amazon ElastiCache 클러스터)에 도달하거나 자체 제한을 적용하려면 시작 시 INTERNET_EGRESS 대신 VPC 이그레스 커넥터를 연결하세요. 이그레스 네트워크 커넥터 작업을 참조하세요.

모니터링

게스트 로그 — MicroVM 로그는 CloudWatch Logs로 이동합니다:

aws logs tail /aws/lambda/microvms/cursor-pool-worker --follow

컨트롤러 로그 — 컨트롤러 Lambda 함수는 /aws/lambda/cursor-lambda-workers-controller에 기록합니다.

실행 중인 MicroVM — 이미지의 실행 중인 MicroVM을 나열합니다:

aws lambda-microvms list-microvms --image-identifier cursor-pool-worker

문제 해결

증상 원인
이미지 빌드 실패 (S3 또는 IAM) 스택 출력 ArtifactBucketName과 BuildRoleArn 확인; zip이 그 버킷에 있어야 하고 빌드 역할이 그것을 읽을 수 있어야 함
MicroVM이 시작되지 않음 컨트롤러가 실행 중이 아니거나 RunMicrovm 호출 불가; cursor-pool-worker 이미지가 존재하는지, (로컬 컨트롤러의 경우) SpawnRoleArn이 수임되는지 확인
워커가 즉시 종료 게스트에 CURSOR_API_KEY(SSM /cursor-lambda-workers/cursor-api-key)가 없거나 /run 훅이 cursor-agent worker … start를 시작하지 않음
node에서 Exec format error 이미지가 잘못된 CLI 아키텍처를 설치함; 여기서 MicroVM은 aarch64(arm64)
서비스 계정 키가 유효하지 않다고 보고 CURSOR_API_ENDPOINT / CURSOR_API_URL이 게스트로 전달됨; worker start가 기본 인증 호스트를 사용하도록 이는 설정되지 않은 채로 있어야 함
훅 활성화 전에 이미지 빌드 MicroVM 이미지를 다시 빌드해 ready, validate, run 훅이 스냅샷 경로에 있게 함

관련 리소스

  • AWS Lambda MicroVMs
  • RunMicrovm CLI 참조
  • Cursor 자체 호스팅 머신 Quickstart
  • 참조 템플릿: anysphere/aws-lambda-workers

더 알아보기 (Learn more)

  • Lambda MicroVMs
  • Lambda MicroVMs 네트워킹
  • Lambda 실행 환경