AWS rehberi, üretim yapay zeka agent'larını ECS'den Bedrock AgentCore'a taşıma sürecini adım adım anlatıyor

Rehberin kapsadığı konular

AWS, üretimde kullanılan bir agent'ı self-managed container'lardan managed Bedrock AgentCore runtime'ına taşımayı gösteren bir migration rehberi yayımladı. Rehberin dev.to üzerindeki özetine göre, ele alınan örnek üç foundation model'i koordine eden bir sağlık agent'ı — biri triyajda semptomları sınıflandırıyor, biri ayırıcı tanılar üretiyor, biri de bakım planı önerileri hazırlıyor — ve bunların üzerine tıbbi bilgi tabanı üzerinde vektör arama ekleniyor.

Orijinal deployment Amazon ECS ve Fargate üzerinde çalışıyordu. Operatörler task definition'ları, container yaşam döngülerini, scaling politikalarını ve CloudWatch logging'i yönetiyordu. Her model çağrısı elle yazılmış state yönetimi, retry mantığı ve instrumentation gerektiriyordu; retrieval ise OpenSearch veya Pinecone gibi bir vektör veritabanına doğrudan API çağrıları anlamına geliyordu.

AgentCore'un devraldığı şeyler

AgentCore altında agent, JSON veya YAML manifest'ında deklaratif olarak tanımlanıyor: isimlendirilmiş model endpoint'leri, rolleri ve top-k ile minimum relevans skoru gibi retrieval ayarlarıyla birlikte bilgi tabanı kaynağı. AWS daha sonra provisioning, execution, konuşma ve ara çıktıların kalıcılığı, model routing ve logging'i üstleniyor — böylece bir değişikliği göndermek, container build ve registry push yerine bir konfigürasyon güncellemesi oluyor.

Üçlü model deseni bu geçişte korunuyor. Geliştiriciler bağımlılıkları tanımlıyor: triyaj önce çalışıyor, tanı onun çıktısını bekliyor, tedavi ise her iki sonucu kullanıyor. AgentCore çağrıları sıralıyor, ara çıktıları serileştiriyor ve bunları aşağı akışta bağlam olarak enjekte ediyor. ECS'de aynı akış, sonuçları DynamoDB veya S3'e yazmayı, tamamlanmayı algılamak için polling yapmayı veya EventBridge kullanmayı ve sonraki her çağrıdan önce bağlamı çekmeyi gerektiriyordu.

Vazgeçtikleriniz

Yazı bunu bir özellik tanıtımı değil, bir altyapı kararı olarak çerçeveliyor ve tavizler somut:

• Execution görünürlüğü. CPU, bellek, ağ I/O ve görev süresi gibi container düzeyindeki metrikler, agent düzeyindeki metriklerle değiştiriliyor — çağrı sayıları, latency, hata oranları ve token kullanımı — artı yapılandırılmış CloudWatch logları. Runtime iç yapısı erişilemez kalıyor, dolayısıyla model çağrıları arasındaki dağıtık tracing loglardan çıkarımla yapmak zorunda.
• State kontrolü. Kalıcılık managed ve opak. Özel retention politikaları ve cross-region replication yapılandırılamıyor.
• Retrieval esnekliği. Yerleşik bilgi tabanı bağlayıcısı embedding'leri ve aramayı yönetiyor, ancak algoritmanın kendisi sabit. Hibrit vektör-artı-anahtar kelime arama, özel reranking veya dinamik embedding güncellemeleri AgentCore dışında çalışmalı ve sonuçlar girdi olarak geçirilmeli.
• Hata yönetimi. Retry'lar otomatik ama özelleştirilemez — kendi tanımladığınız circuit breaker veya retry politikaları yok.
• Güvenlik çevresi. ECS'de ekipler VPC'yi, subnet'leri, IAM rollerini ve secret'ları kontrol ediyor. AgentCore ise AWS tarafından yönetilen altyapıda çalışıyor: model ve bilgi tabanı erişimi için IAM politikalarını siz belirliyorsunuz, ancak altta yatan ağı değil. Müşteri tarafından yönetilen KMS anahtarları, bekleme ve aktarım sırasında şifreleme için destekleniyor; rehber bunu telafi edici kontrol olarak konumlandırıyor.

Yazıda ayrıca bir karşılaştırma tablosu da var: ECS daha fazla operasyonel çaba talep ediyor ama tam görünürlük ve yapılandırılabilir hata izolasyonu sunuyor; AgentCore bu takası tersine çeviriyor ve görev başına fiyatlandırma yerine çağrı başına fiyatlandırmaya geçiyor.

Migration ne zaman mantıklı

Rehberin taşıma için kendi kriterleri: altyapı işi agent mantığı işinin önüne geçmeye başlamışsa, orchestration deklaratif sınırlar içinde kalıyorsa, yerleşik observability debugging için yeterliyse ve container rebuild'leri olmadan daha hızlı iterasyon önemliyse. Yerinde kalma nedenleri arasında ise özel runtime'lar veya sistem bağımlılıkları, karmaşık dallanma, döngüler veya harici servis çağrıları içeren orchestration, belirli altyapı konfigürasyonları için uyumluluk zorunlulukları ya da runtime dışında ara state'i inceleme ve değiştirme ihtiyacı sayılıyor.

Neden önemli

Bugün üretimdeki agent'ların çoğu genel amaçlı container altyapısı üzerinde elle kuruluyor; ekipler aynı state, retry ve retrieval tesisatını yeniden inşa ediyor. AWS şimdi yönetilen bir alternatif sunuyor ve gerçekçi bir çok modelli iş yükünün buna nasıl taşındığını tam olarak belgelendiriyor. Bulut yapay zeka benimseyenleri için rehber aynı zamanda bir due-diligence kontrol listesi olarak da işlev görüyor: operasyonel tasarruf açık, ancak execution görünürlüğü, state kontrolü, retrieval özelleştirmesi ve ağ düzeyinde güvenlik hep AWS'ye geçiyor. Sağlık örneği gibi regüle alanlarda, migration'ın uygulanabilir olup olmadına bu tavizler — konfor değil — karar verecek.