Bulut Bilişim Temelleri ve AWS Çözüm Mimarlığına Giriş
AWS erişim sorunlarında ilk üç kontrol hesabı, bölgeyi ve IAM yetkilerini kapsar. Ardından DNS, ağ kuralları, uygulama günlükleri ve kapasite ölçümlerini sırayla inceleyerek sorunun kaynağını daraltabilirsiniz.

Bu yazıda neler var?
- Hizmet Modelini ve Sorumlulukları Belirleyin
- Hesap, Bölge ve IAM Hatalarını Giderin
- DNS ve Ağ Bağlantısını Katman Katman Sınayın
- Uygulama Durumunu ve Kapasiteyi Ölçün
- AWS Çözüm Mimarlığında Seçenekleri Karşılaştırın
- RTO ve RPO Hedeflerini Test Edin
- Ne Zaman Uzman Desteği Alınmalı?
- Sık Yapılan Hatalar ve Çözümleri
AWS uygulamasına erişemiyorsanız ilk 3 kontrolü hesabınıza, seçili bölgeye ve IAM yetkilerine ayırın. Hata mesajını kaydedin, ardından DNS çözümünü ve ağ bağlantısını sınayın. Bu sıra, yanlış ayar değiştirmeden sorunun kimlik, ağ veya uygulama katmanında olduğunu gösterir.
Bulut bilişim temelleri, işlem gücü, depolama ve ağ gibi kaynakların hizmet olarak kullanılmasını açıklar. AWS çözüm mimarlığı ise bu kaynakları güvenlik, performans, süreklilik ve işletme gereksinimleriyle birlikte tasarlar.
Hizmet Modelini ve Sorumlulukları Belirleyin
Sorun giderme başlamadan önce kullandığınız hizmet modelini belirleyin. Yönetim görevi IaaS, PaaS ve SaaS arasında aynı şekilde paylaşılmaz. Bir bileşenin sağlayıcı tarafından işletilmesi, uygulama kodu veya veriler üzerindeki sorumluluğun da sağlayıcıya geçtiği anlamına gelmez.
| Model | Sağlayıcının yönettiği alan | Sizin yönettiğiniz alan |
|---|---|---|
| IaaS | Fiziksel altyapı ve sanallaştırma | İşletim sistemi, uygulama, ağ ayarları ve veri |
| PaaS | Altyapı ve çalışma ortamı | Uygulama kodu, yapılandırma ve veri |
| SaaS | Hazır uygulama ve hizmet altyapısı | Kullanıcılar, erişim ve kullanım ayarları |
İşletim sistemi üzerinde yönetim istiyorsanız IaaS yaklaşımını seçin. Amazon EC2, sanal sunucu sağlayan bir IaaS örneğidir. Kod çalıştırmak ve sunucu işletimini azaltmak istiyorsanız PaaS türü bir hizmete bakın. Hazır işlevler için SaaS kullanın.
AWS çözüm mimarı, her bileşenin amacını ve sorumluluk sahibini açıkça yazar. Mimari şemada kullanıcı, uygulama, veri deposu, ağ sınırı ve dış hizmetleri ayrı gösterin. Bu şema, hata sırasında kontrol edilecek katmanı hızlıca seçmenizi sağlar.
Hesap, Bölge ve IAM Hatalarını Giderin
Kaynak listede görünmüyorsa veya Access Denied hatası alıyorsanız önce hesap ve bölgeyi kontrol edin. AWS kaynakları çoğu zaman belirli bir bölgede oluşturulur. Yanlış bölge seçildiğinde kaynak silinmiş gibi görünebilir; yanlış hesapta oturum açıldığında ise aynı belirti oluşur.
- AWS konsolunda oturum açtığınız hesap veya rolü kontrol edin.
- Kaynağın oluşturulduğu bölgeyi seçin ve listeyi yenileyin.
- Hata mesajını, işlem adını ve kaynak kimliğini kaydedin.
- IAM kullanıcı veya rolünün ilgili işlem için yetkisini inceleyin.
- İzin gerekiyorsa erişimi yalnızca gerekli işlem ve kaynağa sınırlayın.
- İşlemi yeniden deneyin ve yeni sonucu önceki kayıtla karşılaştırın.
IAM politikasında izin bulunması, işlemin kesin olarak serbest olduğu anlamına gelmez. Kaynak politikası, açık bir ret, kuruluş kuralı veya oturum politikası da erişimi engelleyebilir. Yetki düzeltirken geniş yönetici izni vermek yerine belirli işlem ve kaynakları tanımlayın.
İpucu: Yönetim hesabında çok faktörlü doğrulamayı etkinleştirin. Gizli anahtarları günlük dosyalarına, destek kayıtlarına veya ekran görüntülerine eklemeyin.
DNS ve Ağ Bağlantısını Katman Katman Sınayın
IAM kontrolü geçildiği hâlde uygulama yanıt vermiyorsa ağ yolunu ayrı inceleyin. İstemci, DNS, yönlendirme, güvenlik kuralları ve hedef uygulama aynı erişim zincirinin parçalarıdır. Her katmanı tek tek sınamak, aynı anda birçok ayarı değiştirip yeni bir hata oluşturmanızı önler.
- Alan adının beklenen hedefe çözümlendiğini kontrol edin.
- Aynı adrese farklı bir ağdan erişip sonuçları karşılaştırın.
- İstemcinin hedefe ulaşabildiğini ve doğru bağlantı noktasını kullandığını sınayın.
- Güvenlik gruplarını ve ağ erişim listelerini ilgili kaynakla karşılaştırın.
- Alt ağ, yönlendirme tablosu ve ağ geçidi ilişkisini inceleyin.
- Uygulamanın hedef sunucuda çalıştığını ve bağlantı noktasını dinlediğini doğrulayın.
Bir uygulama sunucusu veritabanına bağlanıyorsa dış erişimden ayrı bir bağlantı testi yapın. İstemciden uygulamaya erişim başarılı olsa bile uygulamadan veritabanına giden yol kapalı olabilir. Ağ kuralını düzeltirken kaynak, hedef ve bağlantı noktasını açıkça belirleyin.
DNS sonucu doğru, ağ yolu açık ve uygulama yanıt vermiyorsa günlükleri inceleyin. İsteğin zamanını, kaynak adresini ve hata kodunu birlikte kaydedin. Bu bilgiler, ağ reddi ile uygulama içi hatayı birbirinden ayırır.
Uygulama Durumunu ve Kapasiteyi Ölçün
Uygulama açılıyor fakat yavaş çalışıyorsa gözleminizi ölçüme çevirin. Eş zamanlı kullanıcı sayısını, isteklerin yanıt süresini, hata oranını ve veri hacmini kaydedin. Yanıt süresini milisaniye, veri hacmini MB veya GB, işlemci ve belleği yüzde olarak izleyin.

- Yavaş işlemi ve beklenen yanıt süresini tanımlayın.
- Aynı senaryoyu kontrollü bir test ortamında çalıştırın.
- İşlemci, bellek, depolama, ağ ve uygulama hatalarını aynı zaman aralığında izleyin.
- Yavaşlama anını uygulama ve sistem günlükleriyle eşleştirin.
- Darboğazı belirleyin ve yalnızca ilgili kapasiteyi veya ayarı değiştirin.
- Aynı testi tekrarlayıp iki ölçüm grubunu karşılaştırın.
İşlemci kullanımı yüksekse hesaplama kapasitesini ve uygulama iş parçacıklarını inceleyin. Bellek baskısı varsa önbellek, işlem kuyruğu ve bellek tüketen sorguları kontrol edin. Depolama gecikmesi yüksekse disk işlemlerini ve veri erişim desenini ölçün.
Pilot çalışmada tek bir başarı ölçütü kullanmayın. Yanıt süresi, hata oranı ve kaynak tüketimini birlikte değerlendirin. Ölçüm sonucu olmadan kapasite artırmak, gerçek darboğazı çözmeden işletme yükünü büyütebilir.
AWS Çözüm Mimarlığında Seçenekleri Karşılaştırın
Bir mimariyi seçerken yalnızca hizmet adını listelemeyin. Her bileşenin neden kullanıldığını, hangi veriyi taşıdığını ve arıza durumunda ne olacağını yazın. Bu yaklaşım, bulut bilişim temellerini doğrudan işletme kararlarına bağlar.
| İhtiyaç | Başlangıç yaklaşımı | Kontrol edilecek ölçüt |
|---|---|---|
| Hızlı prototip | Yönetilen çalışma ortamı | Dağıtım süresi ve yapılandırma sınırları |
| İşletim sistemi kontrolü | Sanal sunucu | Yama, izleme ve ölçekleme sorumluluğu |
| Hazır iş uygulaması | SaaS | Kullanıcı erişimi ve veri dışa aktarımı |
| Kesinti sonrası geri dönüş | Yedekleme ve geri yükleme düzeni | Geri yükleme süresi ve veri kaybı sınırı |
Şu durumlarda yönetilen hizmeti seçin: küçük bir ekip işletim yükünü azaltmak istiyorsa, standart bir çalışma ortamı yeterliyse veya hızlı bir pilot gerekiyorsa. İşletim sistemi ayarı, özel ağ davranışı ya da özel yazılım bağımlılığı gerekiyorsa sanal sunucu yaklaşımını değerlendirin.
Mimari karar kaydına varsayımlarınızı, alternatifleri ve ölçüm sonuçlarını ekleyin. Örneğin veri tabanının aynı ağ sınırında bulunması, uygulama trafiğinin tek bir bağlantı noktasından geçmesi ve yedeklerin geri yüklenmesi gibi varsayımları ayrı yazın.
RTO ve RPO Hedeflerini Test Edin
Hizmet sürekliliği için iki temel hedef belirleyin. RTO, hizmetin geri getirilmesi için kabul edilen süreyi ifade eder. RPO, geri yükleme sırasında kabul edilen veri kaybını zaman aralığıyla tanımlar.
- Hangi işlevlerin kesinti sırasında öncelikli olduğunu listeleyin.
- Her işlev için kabul edilen geri dönüş süresini yazın.
- Kaybedilebilecek veri aralığını iş birimiyle belirleyin.
- Yedekleme ve çoğaltma düzeninin bu hedefleri karşılayıp karşılamadığını kontrol edin.
- Geri yükleme testi yapın ve gerçek süreyi kaydedin.
- Hedef ile test sonucu arasındaki fark için düzeltme planı oluşturun.
Yedek alınması, geri yüklemenin çalıştığını kanıtlamaz. Test sırasında uygulamanın açıldığını, verinin okunabildiğini ve bağımlı hizmetlerin erişilebilir olduğunu kontrol edin. Test kayıtlarında başlangıç saatini, bitiş saatini, geri getirilen veriyi ve görülen hataları saklayın.
Ne Zaman Uzman Desteği Alınmalı?
Hesap, bölge, IAM, DNS ve ağ kontrollerinden sonra hata sürüyorsa olay kaydını genişletin. Birden fazla kullanıcı aynı anda erişemiyorsa ve uygulama günlüklerinde istek görünmüyorsa altyapı veya ağ katmanına odaklanın. İstek günlükte görünüyor, fakat uygulama hata üretiyorsa uygulama ekibini dahil edin.
Yetkili bulut yöneticisine veya AWS Support kanalına başvururken hesap tanımını, bölgeyi, hizmet adını, hata kodunu ve olay zamanını paylaşın. Denediğiniz adımları ve sonuçlarını sıralayın. Parola, gizli anahtar, erişim belirteci veya kişisel veriyi destek kaydına koymayın.
Kişisel veri işleyen mimarilerde veri işleme, saklama ve erişim yükümlülüklerini Kişisel Verileri Koruma Kurumunun resmî kaynaklarından kontrol edin. Mevzuata ilişkin güncel uygulama için kurumun yayımladığı açıklamaları ve kuruluşunuzun yetkili danışmanını esas alın.
Sık Yapılan Hatalar ve Çözümleri
- Yanlış bölgeyi kontrol etmek: Kaynağın oluşturulduğu bölgeyi seçin ve kimlik bilgilerini doğrulayın.
- Geniş yönetici izni vermek: Gerekli işlem ve kaynakla sınırlı bir politika kullanın.
- Aynı anda birçok ayarı değiştirmek: Tek değişiklik yapın, testi tekrarlayın ve sonucu kaydedin.
- Günlük saatlerini karşılaştırmamak: İstemci, uygulama ve altyapı kayıtlarında aynı zaman aralığını kullanın.
- Yedeği hiç geri yüklememek: İzole bir ortamda geri yükleme testi yapın.
- Performansı yalnızca işlemciyle ölçmek: Bellek, depolama, ağ, hata oranı ve yanıt süresini birlikte izleyin.
Her olay için kısa bir kayıt şablonu hazırlayın. Şablonda hesap, bölge, hizmet, hata mesajı, başlangıç zamanı, yapılan değişiklik ve test sonucu bulunsun. Bu alanlar, aynı arızanın tekrarlanması hâlinde tanı süresini kısaltır.
AWS hizmetlerinin teknik ayrıntıları ve hizmete özgü sınırlar için AWS belgelerine başvurun. Kişisel veri işleme yükümlülükleri için Kişisel Verileri Koruma Kurumunun resmî kaynaklarını kullanın.