AWS DevOps Agent, enjekte edilen AWS arızalarını dakikalar içinde izledi ancak sohbet cevapları kendi bulgularıyla çelişti

dev.to'da yayınlanan uygulamalı bir deneyim, Amazon'un otomatik nöbetçi mühendis yaklaşımı olan AWS DevOps Agent'ı bilinçli olarak bozulmuş üç AWS ortamında test ediyor — ve operatörlerin bilmesi gereken uyarılarla birlikte, ajanın gerçek kök neden analizi yapabildiğini ortaya koyuyor.

Dmitriy Trunov'un yazısına göre laboratuvarlar, AWS User Group 3City topluluğunun AWS ile birlikte organize ettiği bir olay incelemesi atölyesinden geliyordu ve yazar bunu 3 Ekim 2026'da yürüttü: bir kurulum laboratuvarı, ardından önceden hata enjekte edilmiş üç ortam. AWS, DevOps Agent'ı hem olayları çözen hem de önleyen bir "frontier agent" olarak konumlandırıyor; CloudWatch metrikleri, CloudTrail verileri, VPC Flow Logs, RDS Performance Insights ve infrastructure-as-code stack'lerini kullanarak kök neden analizi ve bir düzeltme planı sunuyor.

Üç enjekte edilmiş hata, üç kök neden

İlk senaryoda yazar, bir Auto Scaling grubundaki t3.micro instance'ını SSM Run Command ile %100 CPU'ya çıkardı. Yaklaşık bir dakika 48 saniye sonra ajanın ilk bulgusu ortaya çıktı: alarm doğru tetiklenmişti ancak alarm aksiyonu yoktu ve grubun scaling policy'si bulunmuyordu, dolayısıyla hiçbir zaman scale-out yapamayacaktı. Ajan CPU credit throttling'i eledi, trafiğin kullanıcı yükü olmadığını göstermek için ALB trafiğinin sıfıra yakın olduğunu belirtti, yüklenmenin arkasındaki tam SSM komutunu adlandırdı ve engellenen CloudTrail'in bir IAM principal'a atfetmesini engellediğini açıkça söyledi. Kök neden yaklaşık on dakikada bulundu.

İkinci laboratuvar yazarın dizüstü bilgisayarından bir saldırıyı simüle etti: port taraması, SSH giriş denemeleri ve bir HTTP flood. Ajan olayı yüksek şiddetli derecelendirdi, kaynak IP'yi ve taranan portları tespit etmek için VPC Flow Logs'u kullandı ve 80 numaralı porttaki 2.764 kabul edilen paketi gerçek saldırı olarak doğruladı. Ayrıca stack oluşturulmasından bu yana 22, 80, 443 ve 8080 portlarında 0.0.0.0/0'a açık bir security group buldu — ve istenmeden, aynı alarmın önceki dört tetiklenmesinden üçünün zararsız S3 dönüş trafiği olduğunu, yani alarmın kendisinin ayarlanması gerektiğini belirledi. Bu, kabaca 20–25 dakikayla en yavaş vaka oldu.

Üçüncü senaryo, bir Cartesian join CPU'yu zorlarken bir RDS MySQL instance'ını 150 bağlantı limitine karşı yaklaşık 140 bağlantıyla tüketti. Ajan, Performance Insights'ı kullanarak yükü 108 boşta bekleyen oturum ve pahalı sorgudaki 38 ortalama aktif oturuma ayırdı, hepsini tek bir host ve veritabanı kullanıcısına kadar izledi ve bu arada bozuk bir CloudWatch log export'u fark etti. Kök neden yaklaşık 16 dakika sürdü.

Takıldığı yerler

O RDS incelemesi aynı zamanda ajanın kendisiyle çeliştiği yerdi. Sohbetteki takip soruları, kendi düzeltme planıyla iki konuda anlaşmazlık üretti — 150'nin MySQL'in varsayılan max_connections değerinin üzerinde mi altında mı olduğu ve wait_timeout'un yardımcı olup olmayacağı konusunda. Yazarın sonucu: yapılandırılmış bulgular sohbet cevaplarından daha özenliydi, bu yüzden sohbet yanıtları raporla karşılandırarak doğrulanmalı.

Diğer sınırlamalar: ajan yalnızca IAM rolünün ve service control policy'lerinin izin verdiklerini görebiliyor (CloudTrail, GuardDuty ve RDS logları atölye hesabında engelliydi ve bu boşluklar çıktıda ortaya çıktı); incelemeler 8–16 dakika sürüyor; ve atölyeye göre spurious bir "Unable to describe support level" hatası beklenen bir davranış.

İşe yarayan yanlar

Hiçbir sonuç alarmı sadece tekrarlamadı; her biri eksik bağlantıyı tespit etti — bağlanmamış bir alarm, dünyaya açık bir security group, bağlantı limiti olmayan bir host. Her düzeltme planı, yalnızca API ile yapılan bir düzeltmenin CloudFormation stack'inden sapacağı konusunda uyardı ve template için beş aşamalı (hazırlık, ön doğrulama, uygulama, son doğrulama, geri alma) yapılandırılmış bir kod değişikliği spesifikasyonu ile kopyala-yapıştır CLI komutları içeriyordu. Her rapor inceleme boşluklarını listeledi, güvenli dağıtım politikası yıkıcı security group değişikliklerini otomatik çalıştırmayı reddetti ve bunları bir insana işaretledi, ayrıca düzeltme bir coding agent için spesifikasyon olarak dışa aktarılabiliyor.

Gönderiye göre kurulum yaklaşık beş dakika sürüyor: bir Agent Space ajanın neleri görebileceğini ve yapabileceğini tanımlıyor, otomatik oluşturulan bir okuma rolü ve her değişiklik için açık onay gerektiren isteğe bağlı bir yazma aksiyonları rolü ile birlikte. Yetenekler ikincil AWS hesaplarına, Azure, GitHub, GitLab ve Azure DevOps pipeline'larına, Datadog, Dynatrace, New Relic, Splunk ve Grafana'dan telemetriye, Slack, ServiceNow ve PagerDuty'ye, herhangi bir MCP server'a ve A2A protokolü üzerinden uzak ajanlara kadar uzanıyor.

Yazarın kararı: on-call akışında bir insana önceden hazırlanmış bir zaman çizelgesi teslim eden ilk müdahaleci olarak çalıştırın — özerk bir tamirci olarak değil, henüz değil.

Neden önemli

Gece 2'deki bir olayın ilk saati çoğunlukla beş konsol sekmesi arasında bir zaman çizelgesini yeniden oluşturmaktan ibarettir. Bir ajan bunu dakikalara indirgerken onay kapılarına, IaC drift'ine ve yıkıcı değişiklikler etrafındaki koruma rail'lerine saygı göstermeyi başarabiliyorsa, on-call ekonomisi belirgin şekilde değişir. Sohbet çelişkileri ise uyarı niteliğinde: konuşma katmanı sistemin en az güvenilir kısmı olmaya devam ediyor, bu yüzden yapılandırılmış bulgular gerçek kaynak olarak ele alınmalı. Bu bir kıyaslama değil, geçici bir hesappta yapılmış tek bir atölye çalışması — ancak agentic cloud operations'ın nereye gittiğine dair somut bir sinyal.