Lambda Managed Instances'ta Min=0/Max=0 ayarı fonksiyon sürümünü devre dışı bırakır

Sıfır ölçeklendirme yapılandırması gerçekte ne yapar

Lambda fonksiyonlarını hesabınızdaki EC2 kapasitesinde, Lambda programlama modelini koruyarak çalıştıran dağıtım modu olan AWS Lambda Managed Instances (LMI), ölçeklendirme ayarları sıfıra çekildiğinde standart Lambda'dan çok farklı davranıyor. dev.to'daki uygulamalı bir yazıya göre, re:Invent 2025'ten bu yana yapılan haberleşmeler çoğunlukla kaldırılan bellek sınırına ve Savings Plans ile Reserved Instance'ları kabul eden EC2 destekli fiyata odaklandı. Ölçeklendirme yapılandırması ise büyük ölçüde incelenmeden kaldı — ve yazarın temel bulgusu, çoğu mühendisin varsaydığının tam tersini ortaya koyuyor.

Yavaş bir cold start değil, sert bir hata

AWS bir eşleşme kuralı uygular: minimum sıfır yalnızca maksimum da sıfır olduğunda kabul edilir. Ve ikisi de sıfır olduğunda Lambda fonksiyonu bekleme moduna alıp trafiği beklemek yerine sürümü devre dışı bırakır. Yazıya göre, sürümü destekleyen tüm EC2 Managed Instance'lar sonlandırılıyor ve ücretlendirme, yapılandırma kaydedildiği anda değil, sonlandırma fiilen tamamlanana kadar devam ediyor. Sürümün durumu Deactivated olarak değişiyor ve ona yapılan her çağrı açık bir hata döndürüyor — cold start yok, kuyruğa alma yok, yeniden deneme yok.

Yeniden etkinleştirme kendiliğinden asla gerçekleşmiyor. Console'dan, PutFunctionScalingConfig API'sinden veya zamanlanmış bir eylemle sıfırdan farklı değerlere sahip yeni bir ölçeklendirme yapılandırması göndermeniz gerekiyor. Yazar, bunun ReservedConcurrentExecutions=0 veya standart Lambda eşzamanlılık sınırlandırmasından nasıl davrandığının tersi olduğunu belirtiyor ve bunu, sürekli olmayan iş yükleri çalıştıran herkes için LMI ile sıradan Lambda arasındaki en önemli operasyonel fark olarak tanımlıyor.

Dokümanlarda yer almayan kurulum sürtünmesi

LMI, bir Capacity Provider gerektirir; bu ayrı kaynak, instance'ların başlatıldığı VPC'yi, subnet'leri ve security group'ları, uygun mimariyi (x86_64 veya arm64) ve instance türlerini, ölçeklendirme modunu (Auto veya Manual) ve Lambda'nın sizin adınıza EC2'yi yönetmek için kullandığı IAM "Operator Role"ü tanımlar. Fonksiyonlar oluşturulurken bir provider'a bağlanır ve EC2 kapasitesini yalnızca yayınlanmış sürümler alır — $LATEST asla almaz.

Canlı bir AWS hesabına karşı doğrulanan yazı, birkaç çıkmaz sokak belgeliyor:

• Console'daki bağlantı noktası taşındı. Eski dokümantasyon bir "Compute type" ayarından bahsediyor, ancak mevcut console Custom settings altında bir EC2 capacity provider anahtarını ortaya koyuyor. Bellek boyutu ve vCPU başına bellek oranı (2:1, 4:1 veya 8:1), provider üzerinde değil, o panelde fonksiyon başına yapılandırılıyor.

• Mimari tam olarak eşleşmeli. Mimari, provider'ınkinden farklı olan bir fonksiyon — ki bu provider oluşturulurken sabitleniyor — kaydetme anında "You cannot use a Lambda Managed Instances function with a capacity provider that does not support the architecture of the function." hatasıyla reddediliyor. Zorlamaya, geri dönüşe veya çapraz mimarili provider'a dair bir şey yok.

• Yayınlama asla ölçeklendirme değerleri sormuyor. Bunlar Configuration → Function scaling configuration altında ayrı bir yerde duruyor. Açıkça düzenlenene kadar, AWS'nin varsayılan davranışı bir sürüm Active olarak işaretlenmeden önce kullanılabilirlik alanlarına yayılmış üç Managed Instance hazırlıyor — ve bu varsayılan, düzenleme için açana kadar panelde görünmez.

Sürümleme ters çalışıyor

LMI'daki $LATEST, ActiveNonInvocable durumunu bildirir; bu, instance çalıştıramayacağı anlamına gelen belgelenmiş bir değerdir. LMI, $LATEST.PUBLISHED adını taşıyan, kapasite alan ve console'un otomatik olarak ürettiği yeniden yayınlanabilir bir sözde sürüm getiriyor. Fonksiyonu nitelenmemiş ARN'si üzerinden çağırmak dolaylı olarak $LATEST.PUBLISHED'ı hedefler — standart Lambda'daki tersine, orada nitelenmemiş çağrılar $LATEST'a çözümlenir.

Çalışıyor, faturalanıyor, görünmez

Bir sürüm Active olsa bile, onu destekleyen instance'lar EC2 console'da görünmez ve capacity-provider etiketlerine göre filtrelenen describe-instances hiçbir şey döndürmez. Yazıya göre nedeni, Nisan 2026'da kullanıma sunulan ve LMI, EKS Auto Mode ve ECS Managed Instances gibi servislerin hazırladığı EC2 kaynaklarını, ayardan önce yönetilen kaynağı olmayan hesaplar için console'dan ve Describe* API'lerinden gizleyen hesap geneli bir EC2 ayarı olan managed resource visibility. Instance'lar durumdan bağımsız olarak çalışıyor ve faturalandırılıyor; ayar salt bir görüntüleme filtresi ve yazı, onu değiştirmek için gereken CLI komutunu içeriyor.

Neden önemli

Para tasarrufu için minimumu sıfıra ayarlama içgüdüsü — standart Lambda'da makul olan — LMI'da tamamen çağrı hatalarına yol açıyor ve bu da ölçeklendirme yapılandırmasını bir ince ayar düğmesi değil, yük taşıyan bir altyapı parçası haline getiriyor. Maliyetler ayrıca, ayarlara kimse dokunmadan önce, sürüm başına üç instance olarak varsayılan şekilde birikmeye başlıyor ve EC2 görünürlük filtresi tam da bu maliyetlere yol açan kaynakları gizleyebiliyor. Fiyatlandırma avantajları için LMI'yı benimseyen ekipler, ölçeklendirme değerlerini kod olarak ele almalı, bunlara bel bağlamadan önce sürüm durumlarını doğrulamalı ve EC2 harcamasının gerçekten denetlenebilmesi için görünürlük ayarını düzenlemelidir.