AWS erişim anahtarlarını .env dosyalarınıza yapıştırmayı bırakın.
Hepimiz bu durumu yaşadık. Geç saatlerde bir Lambda izin hatasını ayıklamaya çalışıyorsunuz ve yapay zeka asistanınız sürekli hayali hesap kimliklerine sahip servis isimleri veya ARN'ler uyduruyor. Modelin halüsinasyon görmeyi bırakıp düzeltmeye başlaması için gerçek kaynaklarınızı görmesini istiyorsunuz. Çaresizlikten bir erişim anahtarı alıyor, bir ortam dosyasına bırakıyor ve ajana veriyorsunuz. Çalışıyor. Bir rahatlama geliyor. Sonra sabah oluyor ve o sırrın kabuk geçmişinizde (shell history), terminal kaydırma geçmişinizde veya daha kötüsü, paylaşılan bir depoya (repository) yeni gönderilmiş bir commit içinde durduğunu fark ediyorsunuz.
Model Context Protocol tam olarak bu karmaşayı önlemek için oluşturuldu.
MCP, yapay zeka ajanınız ile harici sistemler arasında standart bir köprü kurar. Ham kimlik bilgilerini teslim edip ajanın bunları sızdırmamasını ummak yerine; kimlik doğrulamayı yöneten, izinleri belirleyen ve anahtarlarınızı sohbet penceresinden tamamen uzak tutan kontrollü bir sunucu aracılığıyla bağlantı kurarsınız.
AWS için şu anda seçebileceğiniz iki resmi MCP sunucusu bulunuyor. Yanlış olanı seçmek, ya ajanı kör bırakır ya da çok az denetimle ona çok fazla erişim yetkisi verir.
Farkı Bilin: Bilgi vs. Uygulama
İlk seçenek AWS Knowledge MCP Server'dır. Bunu, tüm AWS dokümantasyon kütüphanesini ezberlemiş ancak hesabınız için giriş bilgilerine sahip olmayan kıdemli bir mühendis gibi düşünün. Tasarım gereği salt okunurdur; ajanın gerçek API sözdizimine, doğru servis isimlerine ve güncel en iyi uygulamalara dayandırılması için resmi AWS belgelerine atıfta bulunur.
Onu kullanmak için bir AWS hesabına ihtiyacınız yoktur. Altyapınıza bağlamazsınız. Bir mimari diyagram tasarlarken, ECS veya EventBridge gibi yeni bir servisi öğrenirken veya belirli bir API çağrısının hala iki yıl öncesinden hatırladığınız gibi davranıp davranmadığını doğrularken çalıştırırsınız. Ajanın tahmin yürütmesini engeller. Eğer bir S3 bucket politikası için Terraform yazmasını isterseniz, geçen yıl kesilen eğitim verilerinden değil, doğrudan kaynaktan çektiği için gerçek alanları ve geçerli değerleri bilir.
İkinci seçenek AWS MCP Server (Managed)'dır. Bu seçenek ajana sadece hafıza değil, uygulama yeteneği de verir. Uygun kimlik doğrulama ile CloudWatch günlüklerinizi inceleyebilir, S3 bucket'larınızı listeleyebilir, DynamoDB tablo şemalarınızı okuyabilir, bir role bağlı IAM politikalarını kontrol edebilir veya hangi güvenlik gruplarının internete açık olduğunu doğrulayabilir. Gerçek hesabınız üzerinde çalışır, bu da onu üretim (production) sorunlarını gidermek veya canlı altyapıyı yeniden yapılandırmak (refactoring) için güçlü kılar.
Managed sunucu, uzun süreli (long-lived) anahtarları reddeder. Tarayıcı üzerinden oturum açarak OAuth yoluyla veya SigV4 imzalama kullanarak AWS CLI aracılığıyla kimlik doğrular. Her araç çağrısı kısa süreli token'lar ile gerçekleşir, her eylem CloudTrail'de bir iz bırakır ve ajan, yalnızca sizin tanımladığınız IAM sınırları içinde çalışır. Organizasyonunuzdaki diğer tüm AWS kullanıcıları veya rolleri için geçerli olan politika motoruna bağlı olduğu için izinlerinin dışına çıkamaz.
Unutulmaması gereken altın kural şudur: bir sunucu ajana bilgi verir, diğeri ise uygulama yeteneği sağlar. Çalışırken veya tasarlarken Knowledge sunucusunu kullanın. İşletirken veya onarırken Managed sunucusunu kullanın.
AWS Neden Çoğu Görev İçin Managed Sunucuyu Öneriyor
AWS artık çoğu kullanıcıyı, her ikisini paralel çalıştırmak yerine tek bir Managed MCP Server'a yönlendiriyor. Managed sunucu, Knowledge sunucusunun sağladığı dokümantasyon bağlamını bünyesine kattı, bu nedenle hem referans materyallerini hem de canlı hesap işlemlerini tek bir uç nokta (endpoint) altında yönetiyor.
Her iki sunucuyu aynı anda çalıştırmak deneyimi aslında kötüleştirebilir. Ajan, çakışan araç tanımları alır ve salt okunur bir dokümantasyon sorgusu mu yoksa hesabınıza karşı canlı bir API çağrısı mı yapacağı konusunda kafası karışabilir. Bu tereddüt, daha yavaş yanıtlara ve ara sıra araç seçimi hatalarına neden olur. Managed sunucuya odaklanmak yapılandırmanızı basitleştirir ve ajanın odaklanmasını sağlar.
Managed Sunucuyu OAuth ile Kurma
Managed sunucuyu çalıştırmak yaklaşık beş dakika sürer, ancak adımlar önemlidir çünkü bu hesabınıza yapılan canlı bir bağlantıdır.
Adım 1: IAM kimliğinizi hazırlayın
Özel bir IAM rolü veya kullanıcısı oluşturun veya seçin. Root hesabınızı kullanmayın. Buna AWSMCPSignInOAuthAccessPolicy adlı yönetilen politikayı ekleyin. Bu politika, yalnızca MCP erişimi için OAuth oturum açma akışını başlatmak için gereken izinleri verir. Tek başına geniş idari haklar sağlamaz. Ajanınızın sahip olacağı gerçek yetenekler, o kimliğe eklediğiniz diğer IAM politikaları tarafından belirlenir. Eğer ajanınızın CloudWatch günlüklerini okumasını ancak IAM veya faturalandırmaya asla dokunmamasını istiyorsanız, yalnızca logs:DescribeLogGroups ve logs:FilterLogEvents izinlerini veren özel bir politika oluşturun.
Adım 2: İstemcinizi yapılandırın
Resmi AWS MCP sunucu URL'sini istemci yapılandırmanıza ekleyin. Bu; Claude Desktop, Claude Code ve Kiro ile çalışır. İstemcinin AWS ile ilgili araç çağrılarını nereye yönlendireceğini bilmesi için MCP ayar dosyanızda sunucu uç noktasını (endpoint) kaydedin.
Adım 3: Tarayıcınız aracılığıyla kimlik doğrulaması yapın
Ajan ilk kez bir AWS aracını çağırmaya çalıştığında, işletim sisteminiz bir tarayıcı penceresi açar. 1. Adımda hazırladığınız IAM kimliği ile oturum açın. OAuth akışı, MCP sunucusuna kısa süreli bir token döndürür. Bir gizli anahtar (secret key) görmeyeceksiniz. Yapılandırma dosyasına herhangi bir şey yapıştırmayacaksınız. Token otomatik olarak yenilenir ve hızlıca sona erer.
Adım 4: Güven sınırını doğrulayın
Kimlik doğrulandıktan sonra CloudTrail'i açın ve eylemlerin oluşturduğunuz kimlik altında göründüğünü onaylayın. Belirli bir IAM kullanıcısına veya rolüne bağlı ListBuckets veya DescribeInstances gibi olaylar görmelisiniz. Eğer Root hesabı etkinliği görürseniz, bir hata yapmışsınız demektir ve oturumu derhal iptal etmelisiniz.
OAuth iş akışınıza uymuyorsa, Yönetilen (Managed) sunucu mevcut AWS CLI kimlik bilgileriniz aracılığıyla SigV4 kimlik doğrulamasını da destekler. Bu yöntem tarayıcı açılır penceresini atlar, ancak yine de ham kimlik bilgilerini ajana maruz bırakmak yerine imzalama ve oturum yönetiminin MCP sunucusu tarafından yapılması avantajından yararlanırsınız.
Gerçekten Önem Taşıyan Güvenlik Alışkanlıkları
Bir MCP sunucusu, yalnızca arkasındaki IAM kimliği kadar güvenlidir.
En az ayrıcalık (least privilege) ilkesiyle başlayın. Ajanınızın, yanlış yönlendirilmiş bir API Gateway entegrasyonunu düzeltmek için AdministratorAccess yetkisine ihtiyacı yoktur. Ona yalnızca mevcut görev için gereken okuma veya yazma izinlerini verin ve iş bittiğinde bu izinleri döndürün (rotate) veya iptal edin. Bir rol kullanıyorsanız, kısa bir oturum süresi belirleyin. Bir kullanıcı kullanıyorsanız, araçlarınızın izin verdiği her yerde MFA'yı etkinleştirin.
Asla Root kullanıcısı olarak yetkilendirme yapmayın. Root, hizmet kontrol politikalarını (service control policies) atlar ve tüm hesap genelinde kısıtlanmamış erişime sahiptir. Eğer ajan bir istemi (prompt) yanlış yorumlar ve kaynakları silmeye çalışırsa, bu isteğin bir sınır politikası (boundary policy) tarafından engellenmesini istersiniz. Root'un böyle koruyucu bariyerleri yoktur.
Son olarak, ajana talimatları mükemmel bir şekilde takip eden ancak sağduyudan yoksun yeni bir stajyer gibi davranın. İstediğiniz şeyi kelimesi kelimesine ve anında yerine getirecektir. Eğer ona "kullanılmayan güvenlik gruplarını temizle" derseniz, verdiğiniz geniş kriterlere uyduğu için üretim (production) veritabanınıza bağlı olanı sonlandırabilir. Özellikle ajanın yazma erişimi olduğunda, yıkıcı olabilecek tüm komutları onaylamadan önce gözden geçirin.
Asıl Çıkarım
Kullanışlılık uğruna güvenlikten ödün vermenize gerek yok. Yönetilen AWS MCP Sunucusu, yapay zeka asistanınızın gerçek altyapınızı görmesine, kendi halüsinasyonlarını düzeltmesine ve ekibinizin geri kalanını yöneten aynı IAM çerçevesi içinde çalışmasına olanak tanır. Çevresel dosyalara (environment files) gizli bilgiler bırakmadan canlı bağlam (context) elde edersiniz. OAuth akışını kurun, izinleri kısıtlayın ve ajanın gözleri açık, elleri ise politikalarınıza bağlı bir şekilde çalışmasına izin verin.