İçeriğe atla

Claude Code Nerede Çalışmalı? Devcontainer, Codespaces ve MicroVM

Bir kodlama ajanının evi olarak devcontainer, Codespaces ve AWS Lambda MicroVM: her basamak ne katıyor ve ajanı laptoptan çıkarmak ne zaman kazandırıyor.

Ayhan Sipahi Ayhan Sipahi

Kodlama ajanı, geliştirme ortamının ne işe yaradığını değiştiriyor. Uzun bir oturum paket kuruyor, test koşuyor, sunucu başlatıyor ve her adımı bir insan onaylamadan ağa yüzlerce kez uzanıyor. Bu noktada üç soru teorik olmaktan çıkıyor: her geliştiricinin ajanının aynı toolchain’i görüp görmediği, ortamı ters gittiği anda atıp yenisini kurup kuramayacağınız ve ajanın içeriden gerçekte neye erişebildiği. Devcontainer birinciyi cevaplıyor. Codespaces ilk ikisini cevaplıyor. Hiçbiri kimlik bilgilerinizi sizin kontrol ettiğiniz bir hesaba taşımıyor ve inceleyebileceğiniz bir çıkış yolu vermiyor; geliştirici başına bulut sandbox’larının kapattığı boşluk da tam olarak burası. Yani öneri bir merdiven: bugün Claude Code’un yerleşik sandbox’ını açın, tekrarlanabilirlik sorunları size pahalıya mal olmaya başlayınca devcontainer ekleyin ve tüm ortamı kendi bulutunuza ancak son iki özellik bir gereksinim hâline geldiğinde taşıyın. Son basamağın somut örneği AWS’nin Lambda MicroVM referans uygulaması.

Claude Code’un yerleşik sandbox’ı#

Ucuz cevap bugün hazır. Claude Code, Bash komutlarını işletim sisteminin zorladığı bir sınır içinde çalıştırıyor: macOS’ta Seatbelt, Linux ve WSL2’de bubblewrap. Ağ çıkışı ise alan adı allowlist’ini uygulayan bir proxy üzerinden geçiyor. Sınır bir işletim sistemi primitifi olduğu için, komutun başlattığı her alt sürece uygulanıyor; modelin hiç yazmadığı süreçler dahil.

Bariz açıkları kapatan bir managed settings yapılandırması şöyle görünür:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "strictAllowlist": true,
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Ağırlığı dört anahtar taşıyor. failIfUnavailable, eksik bir bubblewrap kurulumunu sessizce sandbox’sız çalışmaya düşmek yerine başlangıç hatasına çeviriyor. allowUnsandboxedCommands: false, modelin başarısız bir komutu sınırın dışında tekrar denemesine izin veren kaçış yolunu kapatıyor. strictAllowlist allowlist dışındaki bir hostu doğrudan reddediyor; o anahtar olmadan istek yalnızca bir onay sorusu çıkarıyor. Bu ayar Claude Code v2.1.219 veya üstünü gerektiriyor. credentials bloğu ise atlanması en kolay kısım; ajanı ~/.aws ve ~/.ssh dosyalarından uzak tutan tek parça da bu.

Takas şu: bu, aynı makine üzerinde duran bir sınır. Proxy izin kararını istemcinin verdiği host adına bakarak veriyor ve varsayılan olarak TLS’i sonlandırmıyor veya incelemiyor. Dokümantasyon, github.com gibi geniş girdilerin domain fronting yoluyla veri sızdırma yolu açabileceği konusunda doğrudan uyarıyor. Deneysel network.tlsTerminate ayarı (v2.1.199 ve üstü) proxy’nin TLS’i sonlandırmasını sağlıyor, ancak aynı dokümanlar bunun içerik filtreleme eklemediğini belirtiyor. Yani yerleşik sandbox etki alanını daraltıyor. Kimlik bilgilerini makineden kaldırmıyor ve size trafiği izleyebileceğiniz bir nokta vermiyor.

Ajanları yalnızca bir repoya ve bir paket registry’sine dokunan bir ekip için bu yeterli. Dürüst öneri orada durmak.

Devcontainer ve Codespaces neyi çözüyor#

Toolchain sorununun en ucuz çözümü devcontainer ve sürüm kayması ajanlarla birlikte insanlarla olduğundan daha çok önem taşıyor. Ajanın planı keşfettiği CLI sürümlerine bağlı; bir makinede Node 20, diğerinde Node 22 farklı ajan davranışı üretiyor. devcontainer.json bu yüzeyi sabitliyor ve editörler arasında taşınıyor. Değiştirmediği şey ise container’ın nerede çalıştığı. Docker daemon’ı sizin laptopunuzda, çıkış hâlâ kendi ağınızdan gidiyor ve içeri bağladığınız her şey (yönlendirilmiş bir SSH agent soketi, bind edilmiş bir ~/.aws) container’ın içinden de dışından olduğu kadar erişilebilir.

Codespaces aynı tanımı alıp barındırılan hesaplama üzerinde çalıştırıyor. Bu gerçek şeyler kazandırıyor: dakikalar içinde silip yeniden kurabildiğiniz bir workspace, susan bir laptop fanı ve soğuk başlangıcı katlanılır kılan prebuild’ler. Kimlik bilgisi sorusunu ise kapatmıyor, yerini değiştiriyor. Secret’lar diskiniz yerine GitHub’da duruyor, hesaplama GitHub’ın ve ajanın trafiği GitHub’ın ağından çıkıyor.

O yüzden basamakları her birinin kattığına göre sıralayın ve hiçbirinin katmadığını fark edin. Ortam sizin kontrol ettiğiniz bir altyapıda çalışmadıkça iki özellik erişilemez kalıyor. Birincisi, uygun bir yere park edilmiş uzun ömürlü anahtarlar yerine kendi hesabınızda duran ve dakikalarla ölçülen kimlik bilgileri. İkincisi, akış kayıtlarını tutup önüne firewall koyabildiğiniz, sahibi olduğunuz bir çıkış darboğazı. Ajan sürecinin içinde host adına göre filtrelemek bunların hiçbirini vermiyor. Üçüncüsü ikisinden çıkıyor: kendi hesabınızda, oturum başına sonlandırılabilir tek bir nesne; böylece “o workspace’i iptal et” disk, keychain ve shell geçmişi arasında bir kazı çalışması değil tek bir API çağrısı oluyor.

Hesaplama izolasyonu guardrail katmanının yerine geçmez, altında durur. Prompt injection savunması ve çıktı filtreleme AI ajan güvenliği yazısının konusu. Ajanın repo seviyesinde ne okuduğu ise bambaşka bir eksen; onu da model-agnostik AI kodlama kurulumu işliyor. Buradaki soru daha dar: süreç nerede çalışıyor.

Kısaca Lambda MicroVM’ler#

AWS Lambda MicroVM’ler 22 Haziran 2026’da beş bölgede genel kullanıma açıldı: us-east-1, us-east-2, us-west-2, eu-west-1 ve ap-northeast-1. Her MicroVM, Amazon Linux 2023 çalıştıran ve oturum başına bir tane ayrılan, Firecracker ile izole edilmiş bir sanal makine. AWS bunu kullanıcıların sağladığı veya yapay zekânın ürettiği kod için konumlandırıyor.

Servisin şekli, tanıtım metninden daha önemli. Lansmanda yalnızca ARM64 destekleniyor. Tek bir MicroVM’in tavanı 16 vCPU, 32 GB bellek ve 32 GB disk. Baz boyutlar 0,5 GB ile 8 GB arasında, CPU 2:1 GB-vCPU oranıyla tahsis ediliyor ve dikey ölçekleme baz değerin 4 katına kadar otomatik çıkıyor. Dağıtım modeli önce imaj, sonra çalıştırma: Dockerfile içeren bir ZIP’i S3’e yüklüyor ve Lambda’nın yayımladığı bir baz imajı referans veriyorsunuz. Servis onu derliyor, uygulamanızı başlatıyor, /ready hook’unu bekliyor ve ardından çalışan süreçler dahil olmak üzere diskin ve belleğin Firecracker anlık görüntüsünü alıyor. Dağıtım yolunda yerel bir Docker daemon’ı yok. Yaşam döngüsü hook’ları uygulamanızın sunduğu düz HTTP uç noktaları; örnekte run, resume, suspend ve terminate çağrıları HOOK_PREFIX = "/aws/lambda-microvms/runtime/v1" altında kaydediliyor.

Sonraki her tasarım kararını iki kısıt şekillendiriyor. maximumDurationInSeconds 1 ile 28.800 saniye arasında değer alıyor. Dokümantasyondaki tanım, MicroVM’in Lambda tarafından sonlandırılmadan önce çalışır veya askıya alınmış durumda kalabileceği azami süre; yani askıda geçen zaman da sayılıyor. Ayrıca TERMINATED nihai bir durum: sonlandırılmış bir MicroVM devam ettirilemiyor. Aidan Steele, RunMicrovm çağrısından RUNNING durumuna yaklaşık 2 saniye, askıya alma ve devam ettirme için ise yaklaşık birer saniye raporladı. Primitif hızlı ama kalıcı değil.

aws-samples/anthropic-on-aws içindeki AWS örneği bunu çalışan bir geliştirici platformuna bağlıyor. Genel şekil:

shell WebSocket

presigned URL ile

Geliştirici tarayıcısı

Özel bağlantı

Private API Gateway

Kontrol Lambda

DynamoDB oturumları

Claude Code çalıştıran MicroVM

VPC egress connector

VPC endpointleri

NAT Gateway

Checkpoint bucket

Varsayılan olarak MicroVM’ler AWS tarafından yönetilen bir konektör üzerinden düz public çıkış alıyor. Örnek bunu müşteri tarafından yönetilen bir VPC egress connector ile değiştiriyor. Böylece özel AWS trafiği logs, execute-api ve Bedrock için açılan interface endpointlere gidiyor, public HTTPS bir NAT Gateway üzerinden çıkıyor ve konektörün security group’u yalnızca TCP 443’e izin veriyor. Kontrol API’si private bir API Gateway REST API’si. Resource policy’si, aws:SourceVpce yığının kendi endpointiyle eşleştiğinde execute-api:Invoke çağrısına izin veriyor; eşleşmediğinde ise açıkça reddediyor. Bu açık deny, politikayı dar olmaktan çıkarıp sızdırmaz hâle getiriyor.

Desen 1: SSH yerine kısa ömürlü shell token’ları#

Örnekte hiçbir yerde SSH daemon’ı, bastion, public IP veya gelen bağlantı dinleyen bir uygulama portu yok. Etkileşimli erişim üretilen bir kimlik bilgisine dayanıyor.

1. Tarayıcı Cognito ile private kontrol API'sini çağırır

2. Kontrol Lambda CreateMicrovmShellAuthToken çağırır

3. Servis bir X-aws-proxy-auth token döndürür

4. Tarayıcı doğrudan SHELL_INGRESS üzerinde WebSocket açar

5. Token JS bellekte kalır, yeniden bağlanmada yenilenir

Servis iki ayrı token API’si sunuyor. CreateMicrovmAuthToken, genel HTTPS uç noktası için token üretiyor; kapsamı tek bir MicroVM, belirli bir port kümesi ve bir son kullanma zamanıyla sınırlı. CreateMicrovmShellAuthToken ise etkileşimli PTY erişimi için token üretiyor. Bu ikincisi, MicroVM’in SHELL_INGRESS konektörü bağlanarak başlatılmış olmasını gerektiriyor; örnek bunu control-plane/src/service.ts içinde network-connector:aws-network-connector:SHELL_INGRESS ile biten yönetilen ARN’yi geçerek yapıyor.

Kopyalanmaya değer ayrıntı bir servis özelliğinden çok bir sertleştirme kararı. AWS, genel CreateMicrovmAuthToken API’si için azami 60 dakikalık TTL belgeliyor; örnekteki dağıtım rehberi ise portalın beş dakikalık bir shell kimlik bilgisi istediğini ve yeniden bağlanmada yenilediğini anlatıyor. Bu, çok daha küçük bir maruz kalma penceresi için biraz erişilebilirlikten vazgeçen bilinçli bir tercih. Token hiçbir zaman localStorage’a, URL’ye veya indirilen bir dosyaya düşmüyor; Cognito ID token’ı ise sekmeye kapsanmış sessionStorage içinde duruyor.

Bu desen MicroVM’lerin ötesine de taşınıyor. Tek bir kaynak için dar kapsamlı ve dakikalarla ölçülen bir kimlik bilgisi üreten, bunu istemciye veren ve hiçbir yerde saklamayan bir kontrol düzlemi düşünün. Arkasında hangi hesaplama olursa olsun, bu yapı uzun ömürlü herhangi bir bastion’dan daha iyi.

Desen 2: Execution role ile çıkarım#

MicroVM içindeki Claude Code, Bedrock’a execution role’ün geçici kimlik bilgileriyle kimlik doğruluyor; bunları http://169.254.170.2 adresindeki container credentials uç noktasından alıyor. Claude Code standart AWS SDK kimlik bilgisi zincirini kullandığı için hiçbir şeyi yamalamak gerekmiyor. Etkileşimli oturum açma yok, hiçbir geliştirici cihazında API anahtarı yok. Ajan yalnızca sağlayıcı bayraklarını ayarlıyor:

def claude_provider_environment(session: Session) -> dict[str, str]:
    if session.inference_mode == "bedrock":
        model_id = session.bedrock_model_id or ""
        model = bedrock_model_selection(model_id)
        environment = {
            "CLAUDE_CODE_USE_BEDROCK": "1",
            "ANTHROPIC_MODEL": model,
        }
        if model != model_id:
            environment[
                f"ANTHROPIC_DEFAULT_{model.upper()}_MODEL"
            ] = model_id
        if model_id.startswith("anthropic."):
            environment["CLAUDE_CODE_USE_MANTLE"] = "1"
        return environment
    # ... remaining provider branches omitted

Uç noktayı model kimliği belirliyor. anthropic.claude-sonnet-5 gibi doğrudan bir kimlik, Claude modellerini Anthropic Messages API’sinin kendi biçiminde sunan Mantle uç noktasına yönleniyor. us., eu., au. veya global. önekli coğrafi ya da global bir inference profile kimliği ise Bedrock Runtime’a gidiyor. CDK yığını değeri /^(?:(?:us|eu|au|global)\.)?anthropic\.claude-[A-Za-z0-9._:-]{1,180}$/ düzenli ifadesine karşı doğruluyor; bu ifade yalnızca Claude kimliklerini kabul ediyor.

Tüm yığındaki en kopyalanabilir satır, aynı ifadelerin iki kez geçmesi: bir kez IAM rolünde, bir kez VPC endpoint policy’sinde.

const invokeMantle = new iam.PolicyStatement({
  actions: ['bedrock-mantle:CreateInference'],
  resources: [mantleProjectArn],
});
microvmExecutionRole.addToPolicy(invokeMantle);
bedrockMantleEndpoint.addToPolicy(
  new iam.PolicyStatement({
    actions: ['bedrock-mantle:CreateInference'],
    principals: [microvmExecutionRole],
    resources: [mantleProjectArn],
  }),
);

Endpoint policy kısıtı tekrarladığı için, ele geçirilmiş veya fazla genişletilmiş bir rol bile o yoldan farklı bir modele ulaşamıyor. Aynı içgüdü, yani erişimi en dar katmanda kapsamak, MCP katmanını atlayıp dar kapsamlı API erişimi yazısının da savunduğu şey.

Bir tuzağı herhangi bir dağıtımdan önce çözmekte fayda var. Mantle’ın kendi model listesi ve kendi hesap seviyesindeki erişim izinleri var. Claude Code’un Bedrock dokümantasyonu, geçerli kimlik bilgileriyle alınan bir 403 hatasının AWS hesabına istenen model için erişim verilmediği anlamına geldiğini yazıyor. Şu anda üç resmi kaynak üç farklı yöne işaret ediyor: örnek varsayılan olarak anthropic.claude-sonnet-5 kullanıyor, Claude Code’un kendi Bedrock dokümanları birincil varsayılan olarak us.anthropic.claude-opus-5 veriyor ve sonnet takma adının Sonnet 4.5’e çözümlendiğini söylüyor, Serverless Land’in eşdeğer deseni (yeni sekmede açılır) ise Sonnet 4.6’yı önceden yapılandırıyor. Dağıtımdan önce modeli kendi hesabınızda doğrulayın ve bir varsayılanı devralmak yerine açıkça sabitleyin.

Desen 3: Sekiz saatlik tavana karşı checkpoint ve restore#

Bu sistemde iki farklı şeye checkpoint deniyor ve ikisini karıştırmak iş kaybettiriyor.

Birincisi servisin aldığı Firecracker anlık görüntüsü. Misafir belleği, vCPU ve cihaz durumunu serileştiriyor, sonra bellek dosyasının copy-on-write eşlemesiyle geri yüklüyor. Askıya alma ve devam ettirme, çalışan süreçleri ve açık tamponları koruyor. AWS geri yüklenen workspace’i, yeniden hesaplama gerekmeden bırakıldığı gibi dönen bir ortam olarak tarif ediyor.

İkincisi, örnekteki ajanın S3’e yüklediği bir /workspace tar arşivi. Var olmasının nedeni yukarıdaki tavan: askıda geçen süre dahil sekiz saat ve TERMINATED olduktan sonra geri dönüş yok. AWS’nin iki ifadesi de doğru ve ayırmadıkça çelişkili okunuyor. Platform size sekiz saate kadar durumlu hesaplama veriyor; kalıcılığın başka bir yerden gelmesi gerekiyor. Bir iş gününü aşması beklenen her workspace’in üstüne dosya seviyesinde checkpoint eklenmesi gerekiyor.

Örnek tam olarak bunu kuruyor. Bir dakikalık EventBridge zamanlamasıyla çalışan bir reconciler, süre dolmadan DEFAULT_EXPIRATION_LEAD_SECONDS = 45 * 60 kadar önce yönetilen bir sonlandırma başlatıyor ve /terminate hook’una yüklemeyi bitirmesi için yer bırakıyor. VM içindeki ajan /workspace dizinini askıya alma, yeniden başlatma ve sonlandırma öncesinde arşivliyor; CHECKPOINT_TIMEOUT_SECONDS = 50 bir arşivleme bütçesi gibi görünse de checkpoint HTTP istemcisinin zaman aşımı. Arşiv, 90 günlük eski sürüm ömrüne sahip, versiyonlanmış ve KMS ile şifrelenmiş bir bucket’a düşüyor.

İlginç kısım erişim yolu. MicroVM execution role’ünün o bucket üzerinde hiçbir doğrudan S3 izni yok. Ajan private kontrol API’sinde POST /sessions/{id}/checkpoint-urls çağırıp presigned URL’ler alıyor; bunlar REFRESH_URLS_AFTER_SECONDS = 15 * 60 aralığıyla yenileniyor. Rolün execute-api:Invoke izni ise yalnızca o tek rotayla sınırlı:

microvmExecutionRole.addToPolicy(
  new iam.PolicyStatement({
    actions: ['execute-api:Invoke'],
    resources: [
      api.arnForExecuteApi(
        'POST',
        '/sessions/*/checkpoint-urls',
        api.deploymentStage.stageName,
      ),
    ],
  }),
);

Geri yükleme yeni bir MicroVM’e yapılıyor. Arşiv açma MAX_ARCHIVE_MEMBERS = 200_000 ile bayt üst sınırlarına bağlı; aynen kopyalanmaya değer bir zip bomb koruması. Geri gelmeyenler: çalışan süreçler, bellek, açık terminaller, geçici kimlik bilgileri, VS Code Server ikilileri, tünel kimliği ve /home/developer. Bunlar sıfırdan yeniden oluşturuluyor. Kaydın asıl kaynağı Git olarak kalıyor.

Sekiz saatlik tavan kâğıt üstünde bir kısıt; pratikte ekibi disipline eden bir mekanizma gibi çalışıyor. Bir günü aşamayan workspace, commit edilmemiş işi belirsiz bir riskten çıkarıp bilinen ve tarihi belli bir riske çeviriyor. Bu, aylardır kirli bir çalışma ağacıyla ayakta duran bir dev box’tan daha sağlıklı bir varsayılan.

Desen 4: Platform deploy’u olmadan toolchain güncellemesi#

Araç sürümleri SHA-256 sağlama toplamlarıyla sabitleniyor:

{
  "claudeCode": {
    "version": "2.1.215",
    "sha256": "2b43a3d5b0787217e5d7381fad42c7314292546fe9db9eb8b9b379de90509b30"
  },
  "vscodeCli": {
    "version": "1.129.1",
    "commit": "8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8",
    "sha256": "abd6e9ef317be8ecbbe255954bb76e5c174f15e1b37cf99d82a3d59b798812a6"
  }
}

Bir provisioning betiği yeni bir kaynak arşivi yüklüyor, yeni imaj sürümünün ACTIVE durumuna gelmesini bekliyor ve imaj ARN’si ile network connector ARN’sini tutan iki SSM parametresini güncelliyor. Çalışan veya askıdaki mevcut ortamlar başladıkları sürümde kalıyor. Yeni ortamlar aktif sürümü alıyor, Restart ise mevcut bir workspace’in checkpoint’ini alıp aktif imajdan yeniden kuruyor.

Asıl mesele bu ayrım: “platform değişti” bir CDK deploy’u, “toolchain değişti” ise bir imaj provizyonu. İkisini birleştirmek, bir CLI sürümü yükseltmeyi altyapı yeniden dağıtımına çeviren şey. Aynı içgüdü tek kullanımlık CI runner’larının da arkasında; bunun CI tarafındaki karşılığı Claude Code PR reviewer kurulumu.

İki kısıt bunu göründüğünden daha az esnek yapıyor. Ortam değişkenleri Lambda fonksiyonlarının aksine imaja gömülüyor, dolayısıyla birini değiştirmek yeniden derleme demek. MicroVM başına değişen her şeyin 16 KB ile sınırlı run hook payload’ı üzerinden gitmesi gerekiyor. Steele, imaj derlemelerinin iki ila üç dakika sürdüğünü ve derleme sırasında yaklaşık 7,2 GB boş disk bulunduğunu bildiriyor. Bu da ne kadar toolchain gömebileceğinize dair belgelenmemiş bir tavan. Not etmeye değer: örnek Claude Code 2.1.215’i sabitliyor, oysa strictAllowlist 2.1.219 gerektiriyor; imaj tazeliği bu yüzden operasyonel bir metrik.

Karar çerçevesi#

Her basamak bir alttakinden daha pahalı, o yüzden gereksinimleriniz sizi ne kadar iterse o kadar tırmanın. Buradaki en üst basamak, geliştirici başına ayrılan, yalnızca terminal modunda çalışan ve Bedrock ile beslenen Lambda MicroVM sandbox’ları.

Hayir

Evet

Hayir

Evet

Hayir

Evet

Evet

Hayir

Hayir

Evet

Her ajanın aynı sabitlenmiş toolchain'i görmesi gerekiyor mu?

Laptop ve Claude Code sandbox

Devcontainer ve Claude Code sandbox

Kimlik bilgileri ve çıkış sizin hesabınızda mı kalmalı?

GitHub Codespaces

AWS hesabı, MicroVM bölgesi ve model erişimi hazır mı?

Kendi bölgenizde EC2 dev box

GPU, yoğun iç içe Docker veya 8 saatten uzun süreklilik gerekiyor mu?

SSM Session Manager ile EC2 dev box

Lambda MicroVM sandbox, sadece terminal

Üçüncü taraf relay kaynak trafiği için onaylandı mı?

Terminal modunda kalın

VS Code Remote Tunnels modunu ekleyin

BoyutLambda MicroVMEC2 dev boxECS/FargateGitHub CodespacesYerel devcontainerClaude Code sandbox
İzolasyon sınırıServis yönetimli Firecracker VMTam VMYönetilen VM üzerinde containerBarındırılan VM üzerinde containerLaptop’unuzda containerİşletim sistemi primitifleri, aynı makine
Host’u kim yamalarAWSSizAWSGitHubSizSiz
Azami kesintisiz süre8 saat, sonra checkpoint ve değişimSınırsızSınırsızBoşta kalma süresine bağlıSınırsızSınırsız
Kimlik bilgisi modeliExecution role, geçiciInstance profileTask roleRepo secret’ları / OIDCLaptop’tan mount edilenLaptop’unuzun kimlik bilgileri
Çıkış kontrol noktasıVPC’nize giden egress connectorKendi VPC’nizKendi VPC’nizGitHub’ın ağıKendi yerel ağınızSüreç içi proxy allowlist
MimariYalnızca ARM64HepsiHepsiHepsiHepsiHepsi
BölgelerLansmanda 5HepsiHepsiSağlayıcı yönetimliyokyok
Derleme için yerel DockerHayır, servis tarafında derlemeAMI hattıEvetEvetEvetyok
Veri yolunda üçüncü tarafTerminal modunda yokYokYokMicrosoft/GitHubYokYok

Sınırı açıkça söyleyin, çünkü AWS söylüyor: örnek reponun README’si sandbox’ın “hâlâ açık IAM, ağ ve veri kontrollerine ihtiyaç duyduğunu” ve “MicroVM sınırını en az yetki veya çıkış politikasının yerine koymadığını” yazıyor. İzolasyon sınırı güvenlik kontrolü değil. Tek bir log grubu, tek bir model ARN’si ve tek bir API rotası olan rol, güvenlik kontrolü.

Maliyet hesabı#

us-east-1’de ARM üzerinde Lambda MicroVM hesaplaması saniye bazında faturalanıyor: vCPU-saniye başına 0,0000276944 dolar ve GB-saniye başına 0,0000036667 dolar. Örnek her workspace’i 4 GB olarak boyutlandırıyor; kısaltılmış deployment.example.json:

{
  "region": "us-east-1",
  "vpcCidr": "10.42.0.0/16",
  "projectName": "claude-microvm",
  "trustedClientCidr": "10.100.0.0/22",
  "inferenceMode": "bedrock",
  "bedrockModelId": "anthropic.claude-sonnet-5",
  "idleAfterSeconds": 900,
  "suspendedRetentionSeconds": 3600,
  "microvmMemoryMib": 4096
}

2:1 oranıyla 4 GB, 2 vCPU veriyor. Saniyede 2 × 0,0000276944 + 4 × 0,0000036667 eder, yani saatte yaklaşık 0,252 dolar; ayda 120 aktif saatte geliştirici başına yaklaşık 30 dolar. Yoğunluk anlarındaki dikey ölçekleme daha fazlasına mal oluyor. Anlık görüntü depolaması GB-ay başına 0,08 dolar ekliyor, bir askıya alma yazılan GB başına 0,0038 dolar, bir devam ettirme veya başlatma ise okunan GB başına 0,00155 dolar. Faturalama milisaniye yerine saniye bazında; Yan Cui’nin belirttiği gibi bu, fiyatlandırma modelini Lambda’dan çok Fargate’e yaklaştırıyor.

Karşılaştırma için, GitHub Codespaces 2 çekirdekli bir makineyi saatte 0,18 dolar, 4 çekirdekliyi 0,36 dolar ve depolamayı GB-ay başına 0,07 dolar faturalandırıyor. 2 vCPU’luk bir MicroVM yalnızca hesaplama tarafında bu ikisinin arasında duruyor.

Sürpriz, hesaplama ücretlerinde değil. Paylaşılan platform bir NAT Gateway ile veri işleme ücretini ve erişilebilirlik bölgesi başına saatlik faturalanan üç ila beş interface VPC endpointini ekliyor. Bunlar, platformu kaç geliştiricinin kullandığından bağımsız sabit maliyetler. İş gerekçesi hazırlamadan önce ikisini de güncel VPC fiyatlandırma sayfasından doğrulayın.

En büyük gizli maliyet hiçbir fiyat listesinde yok. Kontrol API’si private olduğu için ona ulaşmak kurum tarafından yönetilen özel bağlantı gerektiriyor: Client VPN, Direct Connect, Transit Gateway veya yönlendirilmiş bir VDI, ayrıca execute-api endpointine private DNS. Yığın bunların hiçbirini oluşturmuyor. Mevcut özel yönlendirmesi olmayan küçük bir ekip için bu ön koşul diğer tüm kalemleri gölgede bırakıyor.

Varsayılanı geçersiz kılan durumlar#

Ajanın GPU’ya, x86 derlemeye, sürekli iç içe Docker’a veya sekiz saatten uzun kesintisiz hesaplamaya ihtiyacı olduğunda EC2 dev box’a geçin. SSM Session Manager zaten SSH’sız ve CloudTrail’e kaydedilen erişim veriyor, dolayısıyla erişim yolu argümanı büyük ölçüde ortadan kalkıyor. Karşılığında AMI hattını, yamalamayı ve kaçmaya çalıştığınız sürüm kaymasını geri alıyorsunuz; üstüne durdur/başlat otomasyonu kurmadıkça boşta geçen süreyi de ödüyorsunuz.

Zaten bir container platformu işletiyorsanız ve zamanlama kontrolü istiyorsanız ECS veya Fargate’e geçin. VPC’nizi ve çıkış duruşunuzu koruyorsunuz; oturum başına VM sınırından ve servis yönetimli anlık görüntü davranışından vazgeçiyorsunuz.

Repo GitHub’daysa ve veri yerleşimi duruşunuz barındırılan hesaplamayı zaten kabul ediyorsa Codespaces’e geçin. Buradaki en düşük ek yüklü seçenek açık ara bu: VPC yok, özel bağlantı yok, imaj hattı yok ve yazdığınız devcontainer tanımı sonradan taşınmak isterseniz sizinle geliyor. Zayıf noktası net: hesaplama ve kaynak kod AWS hesabınızın ve çıkış kontrollerinizin dışında kalıyor, ki MicroVM basamağı tam olarak bu özelliği elde etmek için seçilmişti. Tek sorununuz tekrarlanabilirlikse yerel devcontainer’da kalın; üstündeki her şey artık işlettiğiniz bir altyapı demek.

Özel çekirdek veya cihaz davranışına ihtiyacınız varsa ve bunu sahiplenecek biri varsa yalnızca o zaman EC2 üzerinde kendi yönettiğiniz Firecracker’a geçin.

VS Code Desktop modunu ayrıca ele almak gerekiyor, çünkü bu bir arayüz tercihinden öte mimari bir çatallanma. Terminal modu VS Code Server’ı veya bir tüneli hiç başlatmıyor. Desktop modu kaynak kodu, terminali ve editör protokol trafiğini Microsoft tarafından işletilen bir dev tunnels relay’i üzerinden geçiriyor. Ayrıca geliştirici başına, Cognito’ya bilinçli olarak bağlanmamış ikinci bir kimlik ekliyor. Microsoft relay’i kimliği doğrulanmış ve şifrelenmiş olarak belgeliyor; VS Code’un tünel dokümantasyonu da uçtan uca şifreleme için tünel üzerinde bir SSH bağlantısı kurulduğunu ekliyor. Güvenlik araştırmacıları ise, SentinelOne’ın Operation Digital Eye analizi (yeni sekmede açılır) dahil, aynı yeteneği kalıcılık ve komuta-kontrol tekniği olarak belgeliyor; tam da trafik meşru Microsoft altyapısı gibi göründüğü için. İki tarif de doğru. Kurumsal karar, global.rel.tunnels.api.visualstudio.com üzerinde tek bir izin ver ya da reddet çağrısı; örnek de relay onayını bir dağıtım ön koşulu saymakta haklı. MCP araçları da kapsamdaysa AgentCore Gateway uç noktası opsiyonel bir yol; o katmanı AgentCore production ele alıyor.

Daha şimdiden belgelenmiş tuzaklar#

  • VM sınırını güvenlik kontrolü sanmak. MicroVM güvenilmeyen kodu içeriyor; o kodun neyi çağırabileceğine karar vermiyor. Execution role’de en az yetkiyi koruyun ve NAT’ın önüne bir çıkış politikası koyun.
  • Açık bir NAT Gateway’e “çıkış kontrolü” demek. Örnekteki konektör security group’u 443’ü 0.0.0.0/0 için açıyor. Çıkışı VPC’nizden geçirmek size bir darboğaz ve akış kayıtları kazandırır; kısıtlama kendiliğinden gelmez. Alan adı listeli kurallarla AWS Network Firewall veya inceleme VPC’si üzerinden merkezi çıkış, hâlâ sizin kurmanız gereken kısım.
  • İç içe container’larda DNS’in çalıştığını varsaymak. Tüm giden UDP varsayılan olarak engelli, container’lar public çözümleyicilere düşüyor ve sessizce başarısız oluyor. Steele’in çözümü onları Lambda’nın çözümleyicisine yönlendirmek: docker run --dns 169.254.169.253.
  • Askıda geçen sürenin sayıldığını unutmak. Gece boyunca askıda kalan bir workspace maximumDurationInSeconds bütçesini yakmaya devam ediyor. Uzun aralar için askıya almak yerine sonlandırıp checkpoint ve restore’a güvenin.
  • “Checkpoint”i “kaydet” diye okumak. Uçuştaki durum kayboluyor. Geliştiricilere kaydın asıl kaynağının Git olduğunu söyleyin ve reconciler’ın 45 dakikalık penceresi açılmadan önce bir scratch dalına commit atan bir ajan hook’unu değerlendirin.
  • Örnekteki varsayılan model kimliğine güvenmek. Geçerli kimlik bilgileriyle Mantle’dan gelen 403 eksik hesap izni demek; IAM tarafında vakit kaybetmeyin. Modeli doğrulayın, sonra sabitleyin.
  • Ortam değişkeni değişikliğinin ucuz olmasını beklemek. Birini değiştirmek imajı yeniden derlemek ve workspace’leri yeniden başlatmak demek. MicroVM başına değişen her şey için run hook payload’ını kullanın.
  • ENI envanterinizin tam olduğunu varsaymak. Steele, DescribeNetworkInterfaces çağrısının IncludeManagedResources=true geçilmedikçe konektör ENI’lerini atladığını buldu; düzeltene kadar ağ denetimleriniz eksik rapor verir.
  • Tek NAT Gateway ile üretime çıkmak. Örnek maliyeti düşük tutmak için natGateways: 1 dağıtıyor. Üretim, erişilebilirlik bölgesi başına bir tane veya merkezi çıkış ister.
  • x86 ya da altıncı bir bölge planlamak. Lansmanda yalnızca ARM64 ve beş bölge var. Yol haritası taahhüt etmeden önce ikisini de kontrol edin.

Hangi basamak#

Claude Code’un yerleşik sandbox’ını bugün her geliştirici için açın; strictAllowlist ve açık credentials deny girdileriyle birlikte. Ajanlar farklı makinelerde farklı davranmaya başlayınca devcontainer ekleyin. Laptopun kendisi darboğaz hâline geldiyse ve barındırılan hesaplama kurumunuz için kabul edilebilirse Codespaces’e geçin. Sizi Codespaces’in ötesine iten gereksinimler dar ve gerçek: kendi hesabınızda duran kimlik bilgileri, inceleyebileceğiniz bir çıkış yolu ve oturum başına sahibi olduğunuz, iptal edilebilir tek bir nesne. Bunlar geçerliyse ve AWS’de bir lansman bölgesinde doğrulanmış model erişiminizle birlikteyseniz, geliştirici başına terminal modunda Lambda MicroVM sandbox’ları doğru cevap; GPU veya uzun süren işler için EC2 dev box geçersiz kılma seçeneği olarak kalıyor. Sıradaki somut adım aynı zamanda en ucuz doğrulama: sabitleyeceğiniz model kimliğinin hedef hesaba tanımlı olduğunu doğrulayın. aws bedrock list-inference-profiles bunu yalnızca inference profile kimlikleri için yanıtlıyor; örnekteki gibi Mantle biçimli bir kimlik o listede hiç görünmüyor, dolayısıyla kontrol AWS hesap ekibinize sorulacak bir soru ve geçerli kimlik bilgileriyle gelen 403, iznin olmadığı anlamına geliyor. Bu tek kontrol, platformun geri kalanını planlamaya değip değmeyeceğini belirliyor.

Kaynaklar#

İlgili yazılar