AWS Lambda MicroVMs untuk Sandbox AI Agent: Hook dan Batas

Pertanyaan saya sempit saja. Kalau setiap user produk AI agent mendapat sandbox sendiri, batas isolasi termurah apa yang masih mengingat apa yang sedang dikerjakan user itu ketika ia kembali besok pagi? Container murah tetapi berbagi kernel. Virtual machine mengisolasi dengan benar tetapi butuh hitungan menit. Lambda function melupakan semuanya di antara pemanggilan.

Lambda MicroVMs adalah jawaban AWS, dan post peluncurannya sama sekali tidak membandingkan dengan Fargate. Jadi saya membaca pengumuman bertanggal 22 Juni 2026, lalu halaman developer guide tentang lifecycle, image, snapshot, networking dan quota, serta halaman storage dan security Fargate untuk sisi pembandingnya. Saya belum men-deploy-nya. Setiap angka di bawah berasal dari halaman yang saya baca, dan saat halaman-halaman itu berbeda atau diam, saya katakan.

Apa yang dirilis, dan satu ide di baliknya

Post AWS News Blog yang terbit 22 Juni 2026 menggambarkan Lambda MicroVMs sebagai primitif serverless baru untuk menjalankan kode buatan user atau buatan AI di lingkungan terisolasi yang stateful. Setiap MicroVM melayani satu tenant, sesi atau job, menjalankan Amazon Linux 2023, punya endpoint HTTPS khusus, dan dibangun di atas Firecracker, yang menurut post itu menopang lebih dari 15 triliun invokasi Lambda function per bulan. Bagian paling berguna adalah cara post itu membingkai alternatifnya: virtual machine mengisolasi kuat tetapi butuh menit untuk start, container start dalam hitungan detik tetapi berbagi kernel dan perlu hardening signifikan untuk kode tak tepercaya, dan function cocok untuk kerja event-driven request-response, bukan sesi interaktif panjang yang menyimpan state.

Idenya: MicroVM tidak di-boot, melainkan di-restore. Saat Anda membuat image, Lambda menjalankan Dockerfile, menyalakan aplikasi, menunggu sampai aplikasi menyatakan siap, lalu mengambil snapshot Firecracker dari disk dan memory termasuk semua proses yang berjalan. Setiap MicroVM yang Anda jalankan dari versi image itu resume dari snapshot yang sama, sehingga biaya inisialisasi dibayar sekali saat build. Ukuran dipilih per image sebagai baseline dengan scaling vertikal otomatis hingga empat kali baseline, ditagih per detik untuk bagian di atas baseline. Dokumentasi mencantumkan baseline berikut.

Tabel itu menjelaskan batas utama di post peluncuran, yaitu 16 vCPU, 32 GB memory dan 32 GB disk: itu adalah peak dari baseline terbesar, bukan yang Anda dapat secara default. Post peluncuran juga menyebut MicroVMs hanya ARM64, dan saat peluncuran tersedia di US East (N. Virginia dan Ohio), US West (Oregon), Europe (Ireland) dan Asia Pacific (Tokyo). Saya tidak memverifikasi ulang daftar region setelah peluncuran, jadi cek dulu sebelum merencanakan di sekitar sebuah region.

Membangun image: Dockerfile Anda menjadi snapshot memory

Image adalah file zip di Amazon S3 berisi Dockerfile dan artefak Anda, dibangun di atas base image terkelola Lambda yang dipilih dengan base-image-arn. Lambda menyalakan MicroVM baru dari base, mengeksekusi Dockerfile, menjalankan ENTRYPOINT atau CMD Anda, opsional menunggu ready hook mengembalikan HTTP 200, lalu mengambil snapshot. Sketsa di bawah mengikuti bentuk contoh Flask di pengumuman, dengan path ready hook dan container base image dari dokumentasi.

# Dockerfile, packaged with app.py and requirements.txt into agent-image.zip
FROM public.ecr.aws/lambda/microvms:al2023-minimal
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
# Whatever this process holds in memory when /ready returns 200
# is frozen into the snapshot and shared by every MicroVM from this version.
CMD ["python", "app.py"]

# Upload, then build. base-image-arn and build-role-arn are required
# on create, and on every update-microvm-image that triggers a build.
aws s3 cp agent-image.zip s3://my-bucket/agent-image.zip
aws lambda-microvms create-microvm-image \
  --name agent-sandbox \
  --code-artifact uri=s3://my-bucket/agent-image.zip \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/MicrovmBuildRole

# Build logs land in CloudWatch under /aws/lambda/microvms/agent-sandbox
# (per the announcement); the image becomes CREATED when the snapshot is done.

Dua detail penting untuk produk agent. Pertama, image memuat runtime, kode dan proses background Anda, sehingga interpreter yang sudah hangat, client model yang sudah dimuat atau checkout repositori yang sudah diindeks bisa hidup di snapshot dan tidak memakan waktu saat sesi mulai. Kedua, build hook bernama validate menjalankan request terhadap MicroVM yang dinyalakan dari image jadi, dan guide menyebut Lambda mencatat bagian snapshot mana yang disentuh request itu agar bisa di-prefetch saat run time. Jadi menjalankan mock request agent di validate adalah optimasi latency, bukan sekadar tes.

Lifecycle: enam state dan jam yang harus Anda atur

Sebuah MicroVM berpindah melalui PENDING, RUNNING, SUSPENDING, SUSPENDED, TERMINATING dan TERMINATED. Transisi inilah yang membuatnya primitif sesi, bukan sekadar job runner, jadi lebih baik dibaca sebagai tabel daripada diagram.

Tiga jam mengatur umur MicroVM, dan mudah tertukar. maxIdleDurationSeconds adalah berapa lama endpoint boleh tanpa traffic sebelum MicroVM di-suspend, dengan maksimum 28.800. suspendedDurationSeconds adalah berapa lama ia boleh tetap suspended sebelum Lambda menghentikannya. maximumDurationInSeconds, dari 1 sampai 28.800, membatasi total umur termasuk waktu suspended, dan dari sinilah 8 jam di post peluncuran berasal. Ini perintah peluncuran yang akan saya pakai untuk memulai sesi agent, dengan nilai dari contoh dokumentasi.

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:agent-sandbox \
  --execution-role-arn arn:aws:iam::123456789012:role/MicroVMExecutionRole \
  --ingress-network-connectors arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:ALL_INGRESS \
  --egress-network-connectors arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS \
  --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800}' \
  --maximum-duration-in-seconds 14400 \
  --run-hook-payload 'tenant-4711'

# The response carries microvmId and an endpoint URL. One endpoint, one MicroVM:
# there is no load balancing across MicroVMs behind a single endpoint.

Idle policy punya jebakan khusus untuk agent. Aktivitas didefinisikan sebagai traffic lewat endpoint, dan guide mencatat bahwa untuk aplikasi asynchronous yang tidak aktif mengirim atau menerima traffic lewat endpoint, Anda sebaiknya menonaktifkan suspend otomatis atau memilih durasi idle yang pas. Agent yang menghabiskan dua puluh menit meng-compile proyek di dalam MicroVM tanpa request yang terbuka tampak idle bagi Lambda. Karena maksimum idle adalah 28.800 detik, mengisi nilai itu adalah cara praktis mematikan suspend untuk job panjang.

Hook: kode yang membuat snapshot aman dibagi

Lambda memanggil empat HTTP hook pada aplikasi Anda di setiap event lifecycle: run setelah MicroVM start dari snapshot, suspend sebelum suspend, resume setelah kembali, dan terminate sebelum hilang, semuanya request POST di bawah /aws/lambda-microvms/runtime/v1. Traffic baru mulai setelah run mengembalikan HTTP 200, dan MicroVM tetap SUSPENDED sampai resume hook selesai. Run hook menerima body JSON berisi microvmId dan runHookPayload yang Anda kirim, itulah cara nilai per-tenant sampai ke VM tanpa dibakukan di image. Berikut runtime agent minimal dengan keempatnya, ditambah satu route yang saya pakai untuk membuktikan keunikan.

# app.py - the process that gets frozen into the snapshot
import hashlib, os, secrets, subprocess
from flask import Flask, jsonify, request

app = Flask(__name__)
HOOKS = "/aws/lambda-microvms/runtime/v1"

# Wrong: generated at import time, so it exists BEFORE the snapshot is taken
# and every MicroVM from this image version wakes up holding the same value.
BUILD_NONCE = secrets.token_hex(8)

# Right: filled in by the run hook, after this MicroVM has started.
SESSION = {"microvm_id": None, "tenant": None, "run_nonce": None}

@app.post(HOOKS + "/ready")
def ready():
    return "", 200  # build time only; answer 503 immediately if not ready

@app.post(HOOKS + "/run")
def run():
    body = request.get_json(silent=True) or {}
    SESSION["microvm_id"] = body.get("microvmId")
    SESSION["tenant"] = body.get("runHookPayload")
    SESSION["run_nonce"] = secrets.token_hex(8)  # CSPRNG, reads /dev/urandom
    return "", 200  # traffic is forwarded only after this returns 200

@app.post(HOOKS + "/suspend")
def suspend():
    os.sync()  # flush workspace writes before the checkpoint
    return "", 200

@app.post(HOOKS + "/resume")
def resume():
    # Re-open upstream connections and refresh short-lived credentials here.
    # The MicroVM stays SUSPENDED until this returns 200.
    return "", 200

@app.post(HOOKS + "/terminate")
def terminate():
    os.sync()  # runs on final termination only, not on suspend
    return "", 200

@app.get("/whoami")
def whoami():
    fp = hashlib.sha256(BUILD_NONCE.encode()).hexdigest()[:8]
    return jsonify(SESSION, build_nonce_fp=fp)

@app.post("/exec")
def exec_cmd():
    argv = request.get_json()["argv"]
    out = subprocess.run(argv, capture_output=True, text=True, timeout=60, cwd="/work")
    return jsonify(code=out.returncode, stdout=out.stdout, stderr=out.stderr)

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)  # 8080 is the default inbound port

Dokumentasi memberi alasan untuk memperlakukan randomness sebagai hal utama: ID unik, secret dan entropy yang dibuat saat build dipakai bersama oleh semua MicroVM dari versi image itu. Ia merekomendasikan CSPRNG bahasa yang membaca dari /dev/random atau /dev/urandom, menyebut Java 11 ke atas, Node.js crypto.randomBytes, Python 3.12 ke atas dan .NET 8 ke atas sudah benar secara default, dan menyuruh memakai base image AWS untuk OpenSSL karena berisi build OpenSSL yang di-patch AWS dan kompatibel dengan snapshot. Satu hal yang tidak saya temukan: halaman yang saya baca menyebut image harus mendeklarasikan port listener hook, tetapi nama flag-nya tidak ada di sana, jadi ambil dari referensi create-microvm-image.

Menjalankannya dari orchestrator, satu sesi per MicroVM

Setiap request ke endpoint MicroVM butuh token JWE di header X-aws-proxy-auth, tanpa opsi akses tanpa autentikasi. create-microvm-auth-token membuat token yang dibatasi pada satu MicroVM, sekumpulan port dan masa berlaku, dan request menuju port 8080 kecuali X-aws-proxy-port menyebut port lain yang diizinkan token. Ini memberi pola yang bersih: control plane Anda memegang kredensial AWS, sedangkan browser atau client agent hanya memegang token berumur pendek untuk tepat satu sesi. Nama panggilan di bawah adalah yang dipakai contoh SDK di guide; suspend dan terminate mengikuti penamaan yang sama dengan perintah CLI-nya.

import boto3, requests

client = boto3.client("lambda-microvms")
IMAGE = "arn:aws:lambda:us-east-1:123456789012:microvm-image:agent-sandbox"
PORT = 8080

def start_session(tenant_id):
    r = client.run_microvm(
        imageIdentifier=IMAGE,
        runHookPayload=tenant_id,  # reaches the run hook, never the snapshot
        idlePolicy={
            "autoResumeEnabled": True,
            "maxIdleDurationSeconds": 900,
            "suspendedDurationSeconds": 1800,
        },
        maximumDurationInSeconds=14400,
    )
    return r["microvmId"], r["endpoint"]

def session_token(microvm_id):
    r = client.create_microvm_auth_token(
        microvmIdentifier=microvm_id,
        expirationInMinutes=30,
        allowedPorts=[{"port": PORT}],  # one port, not allPorts
    )
    return r["authToken"]["X-aws-proxy-auth"]

def run_in_sandbox(endpoint, token, argv):
    # The first call after an idle suspend is held while Lambda auto-resumes
    # the VM, so allow a generous timeout. A failed resume returns 502.
    resp = requests.post(
        "https://" + endpoint + "/exec",
        headers={"X-aws-proxy-auth": token},
        json={"argv": argv},
        timeout=120,
    )
    resp.raise_for_status()
    return resp.json()

def end_session(microvm_id):
    client.terminate_microvm(microvmIdentifier=microvm_id)  # stops all charges

Throttling adalah bagian dari desain, bukan kasus pinggir: default terdokumentasi untuk RunMicrovm adalah 5 panggilan per detik dengan burst 5, dan contoh retry di guide memakai exponential backoff dengan jitter pada ThrottlingException. Produk yang menyalakan sandbox di setiap page load akan menabrak batas itu sebelum batas memory quota, jadi mulai sesi saat agent pertama kali dipakai, bukan saat sign-in.

MicroVM atau Fargate: di mana beda sebenarnya

Perbandingan yang menggoda adalah isolasi, dan itu yang lebih lemah. Post AWS Open Source Blog tahun 2018 menyebut task Fargate pindah dari satu VM EC2 khusus per task ke microVM Firecracker tanpa melemahkan isolasi tingkat kernel antar task. Jadi keduanya terisolasi VM. Perbedaan yang saya temukan di dokumentasi adalah apa yang terjadi pada sesi saat tak ada yang mengajaknya bicara, dan seberapa banyak dari mesin itu boleh Anda kuasai.

Itulah seluruh argumennya. Kalau sandbox Anda adalah worker baru berumur pendek yang menjalankan satu tool call lalu hilang, Fargate atau container biasa dengan runtime yang di-hardening lebih sederhana dan punya lebih banyak disk. Kalau sandbox adalah workspace berumur panjang dengan shell history, toolchain terpasang dan edit setengah jadi yang akan dilanjutkan user, suspend-and-resume adalah fitur yang kalau tidak ada harus Anda bangun sendiri dengan volume dan state machine. Lambda function tetap tempat yang tepat untuk kode orkestrasi di depannya, yang direkomendasikan post peluncuran sendiri: sebuah function bisa memanggil MicroVM untuk langkah yang menjalankan kode tak tepercaya.

Di mana ia menggigit: quota, terminasi diam-diam dan snapshot bersama

Halaman quota adalah tempat ekonominya terlihat. Default memory yang dialokasikan di semua MicroVM adalah 400 GB per akun per Region, yang diterjemahkan halaman itu sebagai 200 MicroVM berukuran 2 GB, dengan 1.024 GB di US East (N. Virginia), US West (Oregon), US East (Ohio) dan Asia Pacific (Tokyo), bisa burst sampai empat kali quota. Halaman itu juga menyebut akun baru mendapat quota concurrency dan memory yang lebih rendah yang dinaikkan AWS otomatis berdasarkan penggunaan, jadi proof of concept di akun baru akan meremehkan apa yang didapat production, dan hari peluncuran tidak.

Batas per MicroVM lebih ketat daripada kelihatannya dan tak ada yang bisa disesuaikan. Koneksi bersamaan adalah 8 untuk MicroVM 1 vCPU dan 128 untuk 16 vCPU, request per detik 40 pada 4 vCPU dan 160 pada 16 vCPU, dan bandwidth endpoint naik sesuai ukuran, 4 MB/s untuk default 2 GB dan 16 MB/s untuk 8 GB. Agent yang men-stream artefak build atau diff file besar lewat endpoint akan merasakannya jauh sebelum merasakan CPU.

Ada juga inkonsistensi dokumentasi yang tidak mau saya tutupi. Guide RunMicrovm menyebut run hook payload bisa sampai 16 KB, sementara API reference mencantumkan panjang 0 sampai 4096 untuk field yang sama dan sendiri menandai konfliknya. Anggap 4096 karakter sebagai batas aman dan kirim petunjuk, seperti path secret, bukan secret-nya.

Yang dikerjakan hari Senin

Saya tidak akan memindahkan agent production ke ini hanya berdasarkan pengumuman, tetapi saya akan menghabiskan satu sore untuk membuktikan empat hal. Pemeriksaan di bawah murah dan masing-masing menjawab pertanyaan yang tak bisa dijawab dokumentasi untuk workload Anda.

1. Bangun image di atas di akun sandbox dan pastikan /whoami menunjukkan build_nonce_fp yang sama di dua MicroVM dan run_nonce yang berbeda di masing-masing; itu tanda kontrak keunikan bekerja.
2. Ukur auto-resume pada state Anda sendiri: isi workspace sampai ukuran realistis, suspend, lalu catat waktu request pertama. Guide menyebut latency resume bergantung pada ukuran state yang di-restore dan resume hook Anda, dan tidak menerbitkan angka.
3. Atur maxIdleDurationSeconds dengan mengamati run agent yang nyata. Jika satu langkah bisa sunyi lebih lama dari nilai idle Anda, naikkan menuju 28.800 atau tambahkan request keepalive.
4. Ajukan kenaikan quota untuk memory dan rate RunMicrovm sebelum peluncuran, dan ingat akun baru mulai lebih rendah.
5. Tulis jalur terminate lebih dulu. MicroVM suspended menahan snapshot storage dan dihitung ke quota memory, jadi ledger sesi dan sweeper itu wajib.

# 1. Uniqueness check: same image, two MicroVMs.
for i in 1 2; do
  ID=$(aws lambda-microvms run-microvm --image-identifier "$IMAGE_ARN" \
        --query microvmId --output text)
  EP=$(aws lambda-microvms get-microvm --microvm-identifier "$ID" \
        --query endpoint --output text)
  TOK=$(aws lambda-microvms create-microvm-auth-token \
        --microvm-identifier "$ID" --expiration-in-minutes 10 \
        --allowed-ports '[{"port":8080}]' \
        --query 'authToken."X-aws-proxy-auth"' --output text)
  curl -s "https://$EP/whoami" -H "X-aws-proxy-auth: $TOK"; echo
done
# Expect: identical build_nonce_fp, different run_nonce.

# 2. Suspend, then time the first request back.
aws lambda-microvms suspend-microvm --microvm-identifier "$ID"
time curl -s "https://$EP/whoami" -H "X-aws-proxy-auth: $TOK"

# 3. Always finish by terminating.
aws lambda-microvms terminate-microvm --microvm-identifier "$ID"

Dua dari perintah itu, get-microvm dan path query JMESPath, adalah pembacaan saya atas API reference, bukan sesuatu yang saya jalankan, jadi jalankan skrip dulu di akun throwaway. Kalau waktu resume di langkah dua lebih lama dari yang mau ditunggu user Anda, itulah jawaban Anda soal Lambda MicroVMs untuk sesi bergaya chat, dan harganya hanya satu sore, bukan sebuah migrasi.

Pilih sandbox berdasarkan apa yang dilakukannya saat tak ada yang melihat. MicroVM layak dengan batasannya, hanya ARM64, maksimum 8 jam, batas koneksi dan bandwidth per VM, ketika sesi punya state yang layak disimpan dan kode yang tidak Anda percaya. Untuk semua yang stateless, pakai alat yang lebih murah dan gunakan Lambda function untuk orkestrasi. Dan apa pun pilihan Anda, buat secret setelah sandbox start, jangan sebelum ia dibekukan.