AWS, mimari incelemelerini otomatikleştirmek için Well-Architected Agent önizlemesini başlattı

Ne başlatıldı

1 Ekim 2026'da AWS, Matias Martinez'in dev.to üzerindeki yazısına göre Well-Architected Agent'ı herkese açık önizlemeye açtı. Servis, AWS hesaplarını sürekli olarak tarıyor ve müşterilerin kendilerinin tanımladığı hedeflere göre sıralanmış maliyet, güvenlik, dayanıklılık ve performans önerileri üretiyor — örneğin gereksiz harcamaları kesmek veya iş yüklerinin aksiliklerden zarif bir şekilde kurtulmasını sağlamak. AWS, bunu AWS Support üzerinden sunulan ve Trusted Advisor ile Well-Architected Tool'un ötesinde bir adım olarak konumlandırıyor.

Agent'ın uç noktaları us-east-1, us-east-2 ve us-west-2 bölgelerinde çalışıyor; ancak herhangi bir ticari Region'daki kaynakları analiz edebiliyor. Kurulum bir profile etrafında dönüyor: en fazla 100 hedef hesap, taranacak Region'lar, odaklanılacak sütunlar ve sütun başına bir yazılı hedef. İlk önerilerin 24 saat içinde geldiği belirtiliyor.

Nasıl çalışıyor

Agent, salt-okunur IAM rollerini kullanarak 65'ten fazla serviste yapılandırmayı, kullanım metriklerini ve uygulama topolojisini tarıyor. Erişim, role chaining üzerine kurulu: profile hesabındaki bir execution role — wellarchitected.amazonaws.com tarafından güvenilen — her hedef hesabındaki bir access role'ü üstleniyor. Bu access rolleri, WellArchitectedAgentResourceScanning yönetilen politikasını taşıyor ve profile ARN'si, confused-deputy saldırılarını engellemek için external ID olarak kullanılıyor. Onboarding hesap başına opt-in ve console'da silmeye karşı koruma varsayılan olarak açık.

İsteğe bağlı bir uygulama bağlamı adımı, kullanıcıların hangi uygulamaların mevcut olduğunu, nerede çalıştığını ve hangi etiketlerin onları tanımladığını kaydetmesine olanak tanıyor. Martinez'e göre bu, izlenmeyen bir kuyruk kümesi gibi ham bulguları, üç Region'unun tamamında hata gözlemlenebilirliği olmayan bir event pipeline gibi anlamlı bir ifadeye dönüştüren şey.

Öneriler ve düzeltme

Bulgular üç düzeyde geliyor: kaynak düzeyi (tek bir kaynak veya küçük bir grup), uygulama düzeyi (şu an beta, tek bir uygulamayı kapsıyor) ve mimari düzeyi (desenler ve IaC değişiklikleri). Her biri öncelik, efor, etki, bir ROI tahmini, etkilenen kaynaklar, sütunlar arası faydalar ve açık ödünleşmeler taşıyor — Martinez'in belirttiğine göre bu sonuncusu, iyi bir mimarın genellikle sözlü olarak sunduğu türden bir yargının burada açık hale getirilmiş hali.

AWS'nin gösterdiği örnekler arasında yalnızca yedi service namespace'e ihtiyaç duyulurken Action: "" ve Resource: "" izni veren bir CloudFormation rolü; alarmı olmayan ve medyan tespit süresi 48 dakika olan üç Region'a yayılmış 15 dead-letter kuyruğu; ve 30 günlük p95 CPU ile bellek verilerine göre gerektiğinin yaklaşık iki katı büyüklükte çalışan ECS Fargate task'leri yer alıyor.

Düzeltme; console adım adım rehberler, güncellenmiş IaC şablonları veya CLI çağrıları biçimini alabiliyor; API ayrıca SDK, SSM runbook'ları, MCP ve bir AUTO_REMEDIATION türünü listeliyor. Şimdiye kadar AWS'nin gösterdiği her şeyde agent kaynakları kendisi değiştirmiyor. IaC yolu, bir stack'e yapıştırmaya hazır, aşamalara bölünmüş bir CDK helper'ı geri verebiliyor.

Dağıtım öncesi IaC incelemesi

Kullanıcılar, zip'lenmiş bir Terraform, CloudFormation veya CDK projesini S3'e yükleyip herhangi bir şey dağıtılmadan önce Well-Architected Framework merceğiyle bulgular alabiliyor; ikili ve medya dosyaları hariç tutuluyor. dev.to makalesine göre danışmanlık firması Classmethod bunu lansman gününde test etti: inceleme yaklaşık 30 dakika sürdü ve bunların yanı sıra alarmı veya ayarlama otomasyonu olmayan, MemorySize: 256 olarak sabit kodlanmış bir Lambda fonksiyonunu işaretledi.

Sınırlar ve uyarılar

API operasyonel mükemmelliği geçerli bir değer olarak listelemiş olsa da, önizleme console'u dört sütunu — maliyet, güvenlik, dayanıklılık, performans — gösteriyor. Etkin bir AWS Support planı gerekiyor ve önizleme fiyatlandırması henüz yayınlanmadı. AWS, agent'ın manuel incelemeler için Well-Architected Tool'unun yerini almadığını, bir uyumluluk denetçisi olmadığını ve her öneriye, yapay zekâ tarafından üretildiği ve yanlış ya da eksik olabileceği yönünde bir feragatname damgası vurduğunu söylüyor.

Martinez ayrıca operasyonel bir tuzağa dikkat çekiyor: GitOps kurulumunda CLI düzeltmelerini doğrudan uygulamak, çünkü Terraform veya Argo CD ortaya çıkan drift'i kolayca geri alacaktır.

Neden önemli

Bir Well-Architected incelemesi geleneksel olarak bir iki gün anket yanıtlama ve birden fazla console'da kanıt toplama anlamına geliyordu ve hızla eskiyen bir rapor üretiyordu. Bu döngüyü sürekli çalışan, hedeflere göre sıralama yapan, onlarca servisi okuyan ve yapıştırmaya hazır düzeltmeler döndüren bir agent'a taşımak, mimari incelemeyi planlanmış bir etkinlikten arka plan sürecine dönüştürüyor. Tuzaklar gerçek: servis, yayımlanmamış fiyatlandırmaya sahip bir AWS Support planının arkasında duruyor, çıktısı yapay zekâ tarafından üretiliyor ve otonom değil, ayrıca önizleme Region'a sınırlı. Terraform veya CDK üzerinde çok hesaplı platformlar çalıştıran ekipler, dağıtım öncesi IaC inceleme yolundan en kısa vadede en çok kazanç sağlayacaklar.