AWS proje harcama limitleri kontrolsüz faturaları durduruyor ama 90 gün sonra verileri siliyor

AWS, 16 Eylül'de duyurulan sadeleştirilmiş builder deneyimine proje düzeyinde harcama limitleri ekledi; belgelerdeki bir koşul, yapay zeka ajanlarının cloud kaynakları oluşturmasına izin veren herkesin dikkatini hak ediyor: bir proje limiti aştığı için duraklatıldığında, 90 gün içinde harekete geçilmezse AWS proje verilerini kalıcı olarak siliyor. AWS belgelerini adım adım inceleyen bir dev.to yazısına göre, limit gözetimsiz deneyler için otomatik bir durma noktası olarak konumlandırılıyor — tam da bir coding agent'ın ayağa kaldırıp çalışır bırakabileceği türden bir iş yükü.

Tabanı olan bir tavan

Belgelere göre limit, projenin aylık vergiler öncesi ücretlerine uygulanıyor ve credit'leri kapsamıyor. Özellik sınırlı sayıda müşteriye sunuluyor ve limit oluşturmak ücretli bir plan gerektiriyor; değer proje sahipleri belirlerken, projeye erişimi olan herkes görebiliyor.

İzin verilen en düşük limit, 20 dolar ile AWS'nin olası harcama konusunda kendi muhafazakâr tahmini arasından büyük olan değer. Bu tahmin, aybaşından bugüne aktiviteden, o an çalışan kaynaklardan ve önceki ayın kullanımından hesaplanıyor. Yani dağınık bir ortam bu tabanı yukarı çekiyor; AWS, daha düşük bir sayı istiyorsanız önce kaynakları durdurmanızı öneriyor. Bildirimler limitin %50, %75 ve %90'ında ya da tahmin limitin on gün içinde aşılacağını söylediğinde geliyor. Limitin kendisine gelindiğinde AWS projeyi duraklatıyor ve kaynaklarını durduruyor.

dev.to yazısı bu özelliği varsayılanlarla ilgili daha geniş bir tartışmaya bağlamlandırıyor. 3 Ekim'de Simon Willison, kullanım bazlı fiyatlandırılan hizmetlerin varsayılan olarak etkin katı bütçe limitleriyle gelmesi gerektiğini savundu; gece yarısı düşen bir bütçe uyarısına rağmen bir insan müdahale edene kadar harcamanın sürdüğü o tanıdık başarısızlık senaryosunu anlattı. Coding agent'lar sorunu keskinleştiriyor: başarılı bir dağıtım, ortaya çıkan uygulamanın ne kadar harcama yapmasına izin verildiği konusunda hiçbir şey söylemiyor ve bu soruyu hesap sahibi devralıyor. Willison'ın önerisi sınırsız harcamayı varsayılan değil, açık bir tercih haline getiriyor.

Tavana vurmadan önce devreye giren kontroller

Katı limitle karşılaşmadan önce tahmini harcamaya üç isteğe bağlı kontrol etki ediyor. Yeni kaynak oluşturmayı engelleme yaklaşık yedi gün önceden devreye giriyor; mevcut kaynaklar çalışmaya devam ediyor ama autoscaling eklemeleri dahil yeni başlatmalar başarısız oluyor. Boşta duran kaynakları duraklatma yaklaşık beş gün önceden geliyor ve boşta kalma tanımı servise göre değişiyor; önceki 14 günde sıfır çağrı alan bir SageMaker endpoint'i bu tanıma uyuyor. En büyük maliyet sürücülerini duraklatma ise yaklaşık dört gün önceden devreye giriyor, açıkça kesintiye yol açabiliyor ve EC2, RDS, Lambda, Bedrock ve SageMaker'ı hedefleyebiliyor. dev.to yazarı, hangi kontrollerin etkinleştirildiğini, hangi servislere etki edebildiklerini ve bildirimleri kimin aldığını belgelemeyi öneriyor; çünkü bir bütçenin varlığına dair belirsiz bir his operasyonel bir plan değildir.

Silme saati

Belgelerin rahatlatıcı yarısı, duraklatılmış bir projenin verilerini koruduğunu söylüyor. Kurtarma, AWS Settings içinde limitin yükseltilmesiyle yapılıyor ve bazı kaynakların ardından elle yeniden başlatılması gerekebilir. Ama işin pürüzü şurada: duraklatmadan sonra 90 günlük hareketsizlik, proje verilerinin kalıcı olarak silinmesi anlamına geliyor. Saat, limit aşıldığı anda değil, duraklatma anında başlıyor ve bu her hareketsiz hesaba uygulanan genel bir politika değil — ancak bir harcama kontrolünü bir veri saklama son tarihine bağlıyor. Önerilen kurulum, bildirimlerin sahibi olan bir insanı, bir yeniden başlatma kontrol listesiyle ve duraklatılan ortamın dışında, ona ihtiyaç duymadan erişilebilen bir yedekle eşleştiriyor; çünkü aynı ortamın içindeki bir kopya aynı sorunu devralabilir.

Google'ın daha dar kapsamlı sürümü

Google, Temmuz'da benzer kontrolleri genel önizlemede duyurdu; bunlar tek bir proje içindeki tek bir servise kapsamlı: Gemini API, Agent Platform, Cloud Run ve Cloud Run Functions. Google, yapay zeka servisi limitlerinin eşiği aşmanın ardından dakikalar içinde devreye girdiğini, kısıtlamanın verileri ve kaynakları koruduğunu ve limitin kapsamı dışındaki hizmetlerin etkilenmediğini söylüyor.

Neden önemli

Katı limitler faturalandırma riskini bir erişilebilirlik riskine dönüştürüyor ve AWS'nin sürümü bunun üstüne bir veri kaybı son tarihi ekliyor. Limitini aşan bir ajan tarafından dağıtılan sandbox artık, tek bir gözden kaçan e-postayla kalıcı silmeye dönüşebilecek 90 günlük bir sayaç taşıyor; tavan öncesi kontrollerse üretim andıran her şeyde autoscaling'i sessizce zayıflatabiliyor. Otonom ajanları bir cloud hesabına yönlendiren herkes onları limitli bir projede izole etmeli, bir hata yanıtının sürpriz bir faturaya tercih edilip edilmeyeceğine önceden karar vermeli ve duraklatılmış bir projeyi sahibi olan bir olay olarak görmeli — sessiz bir dinlenme hali olarak değil.