AWS, geçtiğimiz Mart sonunda DevOps Agent'ı genel kullanıma açtığında, duyurunun arkasında pek konuşulmayan bir detay vardı: Amazon bu ürünü "yeni bir SaaS aracı" olarak değil, kendi deyimiyle bir frontier agent olarak konumlandırdı. Yani SaaS, observability platformu, hatta AIOps bile değil. Operasyon takımının yanına oturup işin bir kısmını üstlenmek üzere tasarlanmış, otonom çalışan bir iş arkadaşı.
Bu ayrımı önemli buluyoruz çünkü ürünün ne yaptığını anlamak için önce ne olmaya çalışmadığını anlamak gerekiyor. DevOps Agent bir dashboard değil. Bir alarm motoru değil. "Şu metric şu eşiği geçti, şu kuralı çalıştır" diyen bir runbook otomasyonu hiç değil. AWS'nin tarif ettiği şey, alarm geldiğinde — sabahın ikisi olsun, peak saat olsun fark etmez — kendi başına araştırmayı başlatan, bağımlılıkları çıkaran, kod değişikliklerini deployment kayıtlarıyla ilişkilendiren, hipotez kuran ve mitigation planı yazan bir sistem. AWS bunu "deneyimli bir DevOps mühendisi gibi" yapıyor diyor, ki abartılı bir cümle olarak duyulabilir. Ancak preview'da yayınlanan rakamlara bakınca işin biraz daha ciddi olduğu anlaşılıyor.
Rakamlar gerçekten ne diyor
Preview döneminde DevOps Agent kullanan müşteriler, AWS'nin paylaştığı verilere göre MTTR'da %75'e varan düşüş, investigation süresinde %80'e varan hızlanma ve %94 kök neden doğruluğu bildirdi. Bunlar pazarlama kopyasında durduğu zaman kolayca göz ardı edilen rakamlar, ama somut müşteri vakalarına bakınca daha anlamlı oturuyorlar.
Western Governors University'nin SRE ekibi, normalde iki saat süreceğini tahmin ettikleri bir Lambda konfigürasyon problemini 28 dakikada çözdü. Olayda ilginç olan hız değil aslında — ilginç olan, ajanın "smoking gun"ı, daha önce hiç gün yüzüne çıkmamış bir internal dokümantasyon parçasının içinden bulması. Yani sadece daha hızlı değil, takımın kendi kurumsal bilgisine erişimde de daha iyi. Bu tür bir hikaye, "AI olayı çözdü" hikayesinden farklı bir şey anlatıyor: tribal knowledge'ı arayüze taşıyan bir araç.
Zenchef'in vakası bambaşka bir açıdan ilginç. Restoran teknolojisi şirketinin küçük DevOps takımı, hackathon sırasında bir müşteri sorunuyla karşılaşmış. Engineer çekecek bandwidth yok. Sorunu DevOps Agent'a yapıştırmışlar. Ajan önce authentication'ı elemiş, ECS deployment'larına geçmiş, sonunda GitHub'ı host eden EC2 instance'ındaki bir IAM yanlış konfigürasyonuna inmiş. 20-30 dakikada iş bitmiş; bulgular ilgili mühendise temiz bir handoff ile aktarılmış. Burada dikkat çekici olan, ajanın "araştırma yolunu" insan gibi yürümüş olması — yanlış bir hipotezi eleyip doğrusuna pivotlamış. Karar ağacı gibi davranan klasik AIOps sistemleriyle aradaki en somut fark belki de bu.
Commonwealth Bank of Australia daha aşırı bir örnek paylaşıyor: bir kıdemli DevOps mühendisinin saatlerce uğraşacağı kompleks bir network ve identity management problemi, 15 dakikadan kısa sürede kök nedene indirgenmiş. Banka 1.700'den fazla AWS hesabı yönetiyor; bu büyüklükte bir ortamda "bağımlılıkları zihninde tutabilen" bir mühendis bulmak zaten mümkün değil. Ajanın değer önerisi orada netleşiyor.
Asıl iş application topology'de
Bu rakamların altında yatan teknik karar, pazarlama sayfasında belki en az anlatılan kısım. DevOps Agent her Agent Space için otomatik olarak bir application topology inşa ediyor — yani uygulamanın kaynaklarını ve aralarındaki ilişkileri bir graph olarak çıkarıyor. Hangi Lambda hangi RDS'i çağırıyor, hangi ECS service hangi DynamoDB tablosunu okuyor, hangi deployment hangi commit'ten geliyor, hangi alarm hangi resource'a bağlı. Bu graph, ajanın investigation sırasında "şu serviste sorun varsa, neyi kontrol etmeliyim?" sorusunu yapay zekaya değil, gerçek bir veri yapısına sorduğu yer.
Bu çok önemli bir mimari tercih. Çünkü LLM'leri operasyonel araştırmada kullanırken karşılaşılan klasik tuzak, modelin "her şeyi context window'a doldur, sonra düşünmesini iste" yaklaşımıdır. Bu büyük altyapılarda hızla çöker — token bütçesi yetmez, bağımlılıklar kaybolur, model alakasız metric'lere odaklanır. AWS'nin yaklaşımı bunun tersi: önce sembolik bir graph kur, ajanı o graph üzerinde gezdir, sadece ihtiyacı olan node'ların telemetri verisini context'e çek. Bir tür retrieval augmented operations denebilir buna. Edfu ve benzeri RAG sistemleri kuran herkes bu mantığı tanır.
Topology'nin bir başka değerli yan etkisi var: multicloud ve on-premises ortamlarda bile aynı soyutlama çalışıyor. GA ile gelen Azure ve on-prem desteğinde ajan, MCP üzerinden metric, log ve kodu analiz ederek topology'yi kendi kendine inşa ediyor. Yani hibrit bir şirketin "biz hem AWS'deyiz hem on-prem'deyiz, bütün observability stack'imiz farklı yerlerde duruyor" sorununa, ajan birleşik bir bağlam katmanı olarak cevap veriyor.
Skills mimarisi: bağlam mühendisliği AWS'de de görüldü
GA ile birlikte gelen ve sessizce çok önemli olan başka bir özellik Skills. İki çeşidi var: Learned Skills ve Custom Skills.
Learned Skills, ajanın takımın investigation paternlerinden, araç kullanım alışkanlıklarından ve topology'sinden zamanla öğrenmesi. Yani belli bir tür incident'ı belli bir takım hep belli bir şekilde çözüyorsa, ajan bu yolu öğreniyor ve bir sonraki benzer olayda direkt o yolu deniyor. Bu kâğıt üstünde basit bir feedback loop, ama pratikte takımın "kurumsal hafızasının" ürün içine sızması anlamına geliyor.
Custom Skills ise daha ilginç olan kısım. Organizasyona özel prosedürleri ve best practice'leri ajana bir kez yazıp kayıt edebiliyorsunuz. Ama AWS bir adım daha ileri gitmiş: bu skill'leri spesifik agent türlerine hedefleyebiliyorsunuz. Yani aynı sistemde "On-demand", "Incident Triage", "Incident RCA", "Incident Mitigation" ve "Evaluation" diye ayrı ajan rolleri var, ve her skill'in hangi role bağlanacağını siz seçiyorsunuz. AWS bunun gerekçesini açıkça yazmış: bu yapı, bağlam tüketimini azaltıyor ve odağı artırıyor.
Burada durup not etmek lazım. AWS — yani inference sunan, modelleri üreten değil ama dağıtan tarafta dünyanın en büyük oyuncularından biri — kendi flagship agent ürününde context window'u korumayı bir mimari prensip haline getirmiş. Tek bir büyük ajan yerine, dar görevli ajanlar arası bir orkestrasyon yapmış. Bu, agent ürünleri kuran herkes için sessiz bir "best practice" ilanı gibi okunabilir. Tek model çağrısına her şeyi sığdırmaya çalışmıyorlar. Görev bazlı segmentasyon yapıyorlar. Skill'leri rollerle eşliyorlar.
Bu konuda sağlıklı bir ders var: agent mimarisi tasarlıyorsanız, "kaç token kazandık" sorusu "kaç adım kazandık" sorusundan daha az önemli değil.
MCP'nin sessiz büyük doğrulanması
GA duyurusunun en az konuşulan ama belki en önemli stratejik anlamı, AWS'nin kendi flagship agent ürününde MCP'yi (Model Context Protocol) extensibility'nin omurgası olarak benimsemesi. Built-in entegrasyonları var — Datadog, Dynatrace, New Relic, Splunk, GitHub, GitLab, ServiceNow, PagerDuty, Slack, Grafana, Azure DevOps. Ancak bu listenin dışında kalan her şey için AWS, "kendi MCP server'ınızı bağlayın" diyor. Hatta Grafana entegrasyonu bile teknik olarak built-in bir MCP server üzerinden çalışıyor.
Dahası, Private MCP desteği var: kurumun kendi araçlarına internet üzerinden geçmeyen, güvenli bir bağlantı. Bunun anlamı şu: AWS, MCP'yi sadece bir geliştirici protokolü olarak görmüyor; enterprise düzeyinde, audit'lenebilir, güvenli bir extensibility katmanı olarak tasarlıyor. Anthropic'in çıkardığı bu protokol artık AWS'nin kurumsal entegrasyon stratejisinin merkezinde duruyor.
Bu teknoloji ekosistemi açısından önemli bir an. ODBC'nin veritabanı bağlantıları için, REST'in API'ler için yaptığı şeyi, MCP'nin agent–tool bağlantıları için yapmaya başladığını gösteren birkaç sinyalden biri. Eğer kendi sisteminizde bir MCP server'ı varsa veya çıkarmayı düşünüyorsanız, AWS'nin bu pozisyonu sizi bir adım öne taşır — entegre olabileceğiniz yerlerin sayısı hızla artıyor.
Saniye bazlı fiyatlandırma: agent ekonomisinde yeni bir model
Fiyatlandırma kısmı sıradan görünüyor ama sıradan değil. AWS, DevOps Agent'ı saniye bazlı, ajanın operasyonel görevlere harcadığı zaman üzerinden faturalıyor. Token başına değil. Investigation başına değil. Ajanın "wall-clock" çalışma süresi üzerinden.
Bu seçim birkaç şey anlatıyor. Bir kere, AWS müşterinin model değiştirmeyle veya context boyutuyla ilgili endişelenmesini istemiyor — bu, AWS'ye arkada model geçişi yapma esnekliği veriyor. İki, ürünün değer önerisini "düşündüğünüz iş yükünü omuzlarımıza alıyoruz" şeklinde paketliyorlar; tıpkı bir freelancer'a saat ücreti öder gibi. Üç, AWS Support müşterileri, destek planlarına göre değişen bir oranda gross AWS Support harcamalarının yüzdesi kadar aylık DevOps Agent kredisi alıyor. Yani AWS, kendi destek operasyonunu da bu ürünle ofsetlemeye çalışıyor.
Token bazlı fiyatlandırma "model bir ürün" diyen bir dünyanın fiyatlandırması. Saniye bazlı fiyatlandırma "iş bir ürün" diyen bir dünyanın. Bu felsefi farkın önümüzdeki dönemde başka agent ürünlerinde de yayılmasını bekliyoruz.
Türkiye perspektifinden ne anlama geliyor
DevOps Agent şu an altı bölgede mevcut: us-east-1, us-west-2, Frankfurt, İrlanda, Sydney ve Tokyo. Türkiye'den bakınca en yakın bölge Frankfurt. Latency açısından makul; veri egemenliği açısından AB sınırları içinde, ki bu KVKK uyumluluğu konusunda bir kolaylık.
İkinci dikkat çeken detay yerelleştirme. Ajan, tarayıcı locale ayarına göre yanıtlarını çeviriyor. Bu küçük bir ayrıntı gibi görünüyor ama Türkiye ölçeğindeki KOBİ'ler için önemli: ekipte İngilizce'si zayıf bir junior'a "git şu investigation'a bak" diyebilmek, ürünü kullanılabilir kılmanın eşiği. Bu konuda AWS'nin lokalizasyonu ne kadar derin yaptığını henüz ölçemeyiz, ama yönelimi doğru.
Türk SaaS ve teknoloji şirketleri için asıl ilginç olan, fiyatlandırma modelinin "küçükten başla" senaryolarıyla uyumlu olması. Saniye bazlı, ön taahhütsüz, istediğin zaman aç-kapat. Bir KOBİ önce kendi production'ında en sık tekrar eden 3-5 incident tipini ajana çözdürerek hızlıca bir ROI hesabı yapabilir. Eski bir incident'ı seçip ajana yeniden çözdürmek, AWS'nin önerdiği "quick win" stratejisi — ve bu öneri pazarlama amaçlı değil, çünkü sayılar gerçekten kıyaslanabilir hale geliyor.
Şu noktada uyarı koymak da gerekiyor: bu ürün sihirli bir kutu değil. Topology'nin sağlıklı kurulabilmesi için altyapının observability açısından yeterince enstrümante edilmiş olması lazım. CloudWatch'a hiç metric göndermeyen, deployment'larını CI/CD'ye değil bir engineer'ın laptop'undan yapan bir şirket için ajan boş bir grafa bakacak. Önce evi toparlamak gerekiyor; ajan hazırlığı tamamlanmış evlerde işe yarıyor.
Sonuç olarak
DevOps Agent, agent-as-a-product kategorisinde bugün piyasada gördüğümüz en net duruşlardan biri. Ürün; topology üzerinden çalışan bir investigation motoru, rol bazlı segmentasyonla bağlam mühendisliği yapan bir agent orkestrasyonu, MCP üzerine kurulu bir extensibility katmanı ve saniye bazlı bir fiyatlandırma modelinden oluşuyor. Bu bileşenlerin her biri, "AI bir feature olarak ürüne eklenir" düşüncesinin nereye doğru evrildiğini gösteriyor: AI artık ürünün kendisi haline geliyor, ürünün bir özelliği değil.
İlginç olan, AWS'nin bu adımı atarken aslında açıkça bir mesaj vermiş olması. Eğer bir agent ürünü kuruyorsanız ve yarın AWS gibi bir oyuncuyla aynı sahaya çıkmak istiyorsanız, üç şeye dikkat etmeniz gerekiyor: bağlamı sembolik bir veri yapısı üzerinden yönetin, ajanları rollere ayırın, ve protokol seçiminizi geleceğe uygun yapın. Bu üç kararı doğru veren ekipler, frontier agent sahasında AWS'nin yanında veya yerine durmaya aday olacak. Diğerleri, AWS'nin kapsadığı yüzeyin altında kalacak.
DevOps Agent'ın asıl test edilmesi gereken yer demolar değil tabii — kendi production ortamınız. AWS'nin önerdiği "geçen ayki bir incident'ı al, ajana yeniden çözdür, sonuçları karşılaştır" yaklaşımı hala en dürüst test. Bu testi kim önce yaparsa, agent çağındaki operasyon mühendisliğinin ne anlama geldiğine dair en sağlam fikre o sahip olacak.
