AWS Kesintileri: Küresel Bir Sorun mu, Yoksa Daha Fazlası mı?

Amazon Web Services (AWS) hizmetlerinde yaşanan bir kesinti haberi, genellikle tüm internetin durma noktasına geldiği endişesini doğurur. Ancak bu algı ne kadar doğru? Gerçekten AWS “küresel” bir kesinti yaşadığında, dünya genelindeki tüm uygulamalar ve web siteleri mi etkileniyor? Bu makalede, AWS kesintilerini teknik detaylarıyla inceleyecek, “küresel” kesinti kavramının ardındaki gerçekleri açıklayacak ve bulut tabanlı uygulamalarınızı bu tür durumlar karşısında nasıl daha dayanıklı hale getirebileceğinizi adım adım ele alacağız. AWS’in dağıtık yapısını, kesintilerin nedenlerini ve önleme stratejilerini derinlemesine keşfetmeye hazır olun.

Günümüz dijital dünyasında internet sitelerinin, mobil uygulamaların ve hatta birçok kurumsal yazılımın arkasında devasa bir altyapı yatar: Bulut Bilişim. Bu altyapının en büyük ve en yaygın sağlayıcısı ise Amazon Web Services (AWS) olarak karşımıza çıkar. AWS, adeta internetin görünmez omurgasını oluşturan, dünya çapında milyonlarca işletmeye ve bireysel geliştiriciye hizmet veren bir teknoloji devidir. Peki, AWS tam olarak nedir ve neden teknoloji ekosisteminin bu kadar ayrılmaz bir parçası haline gelmiştir?

AWS, Amazon tarafından sunulan ve sunucular, depolama, veritabanları, ağ, analitik, yapay zeka, makine öğrenimi, IoT ve çok daha fazlasını içeren yüzlerce bulut bilişim hizmetinden oluşan kapsamlı bir platformdur. Geleneksel yaklaşımlarda, bir web sitesi veya uygulamanın yayına alınması için fiziksel sunucular satın almak, veri merkezleri kurmak ve bu altyapıyı sürekli olarak yönetmek gerekiyordu. Bu süreç hem yüksek maliyetli hem de zaman alıcıydı. AWS ve benzeri bulut sağlayıcıları ise bu yükü tamamen ortadan kaldırarak, ihtiyacınız olan kaynakları anında ve kullandığınız kadar ödeme modeliyle sunar. Bu esneklik, küçük girişimlerden devasa küresel şirketlere kadar herkesin modern teknolojiye erişimini demokratikleştirmiştir.

AWS’in sunduğu temel hizmetlerden bazıları şunlardır:

• Amazon EC2 (Elastic Compute Cloud): Sanal sunucular sağlayarak işlem gücü sunar. Uygulamalarınızı bu sunucular üzerinde çalıştırabilirsiniz.
• Amazon S3 (Simple Storage Service): Büyük miktarda veriyi güvenli, ölçeklenebilir ve uygun maliyetli bir şekilde depolamanızı sağlar. Web sitelerinin statik dosyaları, yedeklemeler ve veri gölleri için idealdir.
• Amazon RDS (Relational Database Service): İlişkisel veritabanlarını (MySQL, PostgreSQL, Oracle vb.) kolayca kurmanızı, yönetmenizi ve ölçeklendirmenizi sağlar.
• AWS Lambda: Sunucusuz bilişim hizmetidir. Kodunuzu sunucu yönetimi derdi olmadan çalıştırır, sadece kodunuz çalıştığı zaman için ödeme yaparsınız.
• Amazon Route 53: Ölçeklenebilir ve yüksek erişilebilir bir alan adı sistemi (DNS) web hizmetidir. Alan adlarınızı yönetmenizi ve trafiği AWS kaynaklarınıza yönlendirmenizi sağlar.

Bu hizmetler, yazılım geliştiricilere ve şirketlere inanılmaz bir esneklik, maliyet etkinliği ve ölçeklenebilirlik sunar. Bir uygulama aniden milyonlarca kullanıcıya ulaştığında, AWS altyapısı sayesinde ek kaynakları saniyeler içinde devreye alabilir ve hizmet kesintisi yaşamadan büyümeyi sürdürebilirsiniz. Öte yandan, talep düştüğünde kaynakları kolayca küçülterek maliyetleri optimize etmek de mümkündür. Bu dinamik yapı, modern işletmeler için vazgeçilmez hale gelmiştir.

Bulut Bilişimin Temelleri: Neden Bu Kadar Önemli?

Bulut bilişimin bu denli önem kazanmasının temelinde, geleneksel IT altyapılarının karşılaştığı zorluklara getirdiği radikal çözümler yatar. Şirketler artık milyonlarca dolarlık ön yatırım yaparak sunucu odaları kurmak ve bunları yönetmek zorunda kalmıyor. Bunun yerine, AWS gibi bir bulut sağlayıcısından ihtiyacı olan kaynakları tıpkı elektrik veya su gibi bir hizmet olarak alabiliyor. Bu model, özellikle yeni kurulan girişimler için başlangıç maliyetlerini düşürerek inovasyonun önünü açmıştır. Mevcut işletmeler içinse operasyonel verimliliği artırmış, pazara çıkış sürelerini kısaltmış ve küresel pazarlara erişimi kolaylaştırmıştır.

AWS’in küresel altyapısı, bu esnekliğin temelini oluşturur. AWS, hizmetlerini “Bölgeler” (Regions) ve bu bölgelerin içinde yer alan “Erişilebilirlik Alanları” (Availability Zones – AZ’ler) şeklinde yapılandırır. Her bölge, coğrafi olarak ayrı ve bağımsız bir alana denk gelir (örneğin, Kuzey Virginia, Frankfurt, Tokyo). Her bir bölge içinde ise en az iki, genellikle üç veya daha fazla sayıda Erişilebilirlik Alanı bulunur. Bu AZ’ler, birbirinden fiziksel olarak ayrı binalarda konumlandırılmış, kendi güç, ağ ve soğutma sistemlerine sahip bağımsız veri merkezleridir. Ancak aynı bölge içindeki AZ’ler, düşük gecikmeli, yüksek bant genişliğine sahip bağlantılarla birbirine bağlıdır.

Bu dağıtık mimari, AWS’in yüksek erişilebilirlik ve hata toleransı iddialarının temelini oluşturur. Bir bölgedeki tek bir AZ’de yaşanacak bir elektrik kesintisi veya doğal afet, diğer AZ’lerdeki hizmetleri etkilemez. Bu sayede, geliştiriciler uygulamalarını birden fazla AZ’ye yayarak, tek bir hata noktasından kaynaklanan kesintilere karşı koruma sağlayabilirler. Örneğin, bir web uygulamasının sunucularını farklı AZ’lere dağıtırsanız, bir AZ tamamen devre dışı kalsa bile uygulamanız diğer AZ’lerden çalışmaya devam edecektir. Bu yapı, “küresel” kesinti kavramını anlamamızda kilit bir rol oynar, zira genellikle bir kesinti tüm AWS bölgelerini aynı anda etkilemez. Aksine, büyük kesintiler genellikle tek bir bölgeyi, hatta bazen sadece bir AZ’yi etkiler. Bu nedenle, bir sonraki bölümde ele alacağımız “küresel” kesinti iddialarının genellikle bir yanlış anlama olduğunu göreceğiz.

AWS Kesintileri Gerçekten “Küresel” mi Oluyor?

AWS’in bir kesinti yaşadığına dair haberler çıktığında, çoğu zaman “AWS küresel bir kesinti yaşadı” veya “İnternetin yarısı çöktü” gibi ifadelerle karşılaşırız. Ancak bu tür başlıklar, genellikle olayın gerçek boyutunu abartılı bir şekilde yansıtmaktadır. AWS’in devasa ve dağıtık altyapısı göz önüne alındığında, tüm dünyayı aynı anda ve tamamen etkileyen bir kesinti senaryosu oldukça nadirdir, hatta imkansıza yakındır. Peki, o zaman neden bu tür algılar oluşuyor ve AWS kesintileri aslında ne tür sorunları ifade ediyor?

Bu yanılgının temelinde, AWS’in küresel erişimi ve birçok popüler internet hizmetinin AWS üzerinde çalışıyor olması yatar. Örneğin, bir dönem yaşanan ve AWS’in US-EAST-1 bölgesini etkileyen bir kesinti, Slack, Amazon.com’un bazı bölümleri, Netflix gibi yüzlerce popüler hizmeti de etkilemişti. Bu hizmetler dünya genelinde milyonlarca kullanıcıya sahip olduğu için, US-EAST-1 bölgesindeki bir kesinti bile, ABD’nin doğu kıyısında veya Avrupa’daki kullanıcılarda “küresel” bir etki hissi yaratabiliyor. Çünkü o bölgedeki hizmetlere erişilememesi, dünyanın dört bir yanındaki insanların o hizmetleri kullanamaması anlamına geliyor. Ancak bu, diğer AWS bölgelerindeki hizmetlerin de durduğu anlamına gelmez. Frankfurt’taki veya Tokyo’daki AWS sunucuları genellikle etkilenmez ve o bölgelerde barındırılan uygulamalar çalışmaya devam eder.

Kesinti Türleri ve AWS’in Dağıtık Yapısı Nasıl Çalışır?

AWS kesintilerini daha iyi anlamak için, farklı kesinti türlerini ve bunların AWS’in bölgeler (Regions) ve erişilebilirlik alanları (Availability Zones – AZ’ler) kavramlarıyla nasıl ilişkili olduğunu bilmek önemlidir:

1. Tek Erişilebilirlik Alanı (AZ) Kesintileri: Bu, en yaygın ve genellikle en az etkili kesinti türüdür. Tek bir veri merkezinde (yani bir AZ’de) elektrik kesintisi, ağ sorunu veya donanım arızası gibi bir sorun yaşanabilir. Uygulamanız yalnızca bu AZ’de barındırılıyorsa etkilenirsiniz. Ancak uygulamanız Multi-AZ (çoklu erişilebilirlik alanı) mimarisiyle tasarlanmışsa, diğer AZ’lerdeki yedek kaynaklar devreye girer ve hizmet kesintisiz devam eder.
2. Bölgesel Kesintiler: Bu, tek bir AWS bölgesindeki tüm Erişilebilirlik Alanlarını veya bölgedeki kritik bir hizmeti etkileyen daha geniş çaplı bir sorundur. Örneğin, bir bölgedeki temel bir ağ hizmetinin veya kontrol panelinin çökmesi, o bölgedeki tüm hizmetleri etkileyebilir. Bu tür kesintiler “küresel” olarak algılanabilir, çünkü yukarıda bahsedildiği gibi, bu bölge birçok küresel şirketin ana operasyon merkezidir (özellikle US-EAST-1). Ancak diğer AWS bölgeleri (örneğin Avrupa, Asya, Güney Amerika) genellikle bu durumdan etkilenmez.
3. Küresel Hizmet Kesintileri: Çok nadiren de olsa, AWS’in DNS hizmeti olan Route 53 gibi gerçekten küresel olarak çalışan veya AWS konsolu gibi tüm bölgeleri etkileyebilecek merkezi bir hizmette sorun yaşanabilir. Bu tür sorunlar, tüm AWS kullanıcılarını veya genel olarak interneti daha geniş çapta etkileme potansiyeline sahiptir. Ancak bu, bir bölgenin tamamen kapanmasından farklıdır ve genellikle daha hızlı bir şekilde çözülür.

AWS kesintilerinin tipik nedenleri oldukça çeşitlidir:

• Ağ Sorunları: Yönlendiricilerdeki hatalar, trafik yoğunluğu veya konfigürasyon yanlışlıkları.
• Donanım Arızaları: Sunucuların, depolama birimlerinin veya ağ ekipmanlarının fiziksel arızaları.
• Yazılım Hataları: AWS altyapısını yöneten yazılımlardaki bug’lar veya güncelleme hataları.
• Yapılandırma Yanlışlıkları: AWS mühendisleri tarafından yapılan yanlış yapılandırmalar (örneğin, bir hizmetin yanlışlıkla kapatılması veya yanlış yönlendirme kuralları).
• DDoS Saldırıları: Dağıtık Hizmet Reddi (DDoS) saldırıları, altyapıyı aşırı yükleyerek kesintilere neden olabilir.

Vaka Analizi: 2021 AWS US-EAST-1 Kesintisi

En son ve en akılda kalıcı bölgesel kesintilerden biri, Aralık 2021’de AWS’in US-EAST-1 bölgesinde yaşanan geniş çaplı sorundu. Bu kesinti, bölgedeki bir ağ cihazında yaşanan sorun nedeniyle başladı ve ardından AWS’in iç ağ ve erişilebilirlik kontrollerini de etkiledi. Sonuç olarak, US-EAST-1 bölgesindeki birçok AWS hizmeti (EC2, Lambda, S3, RDS dahil) ya tamamen erişilemez hale geldi ya da ciddi performans düşüşleri yaşadı. Bu kesinti, Amazon’un kendi teslimat operasyonlarını bile etkiledi.

Bu olay, “küresel” bir kesinti gibi hissedilse de, aslında bölgeseldi. Diğer AWS bölgeleri (örneğin US-WEST-2 veya EU-CENTRAL-1) bu kesintiden doğrudan etkilenmedi. Ancak US-EAST-1, AWS’in en eski ve en yoğun bölgelerinden biri olduğu için, burada barındırılan birçok kritik uygulamanın dünya genelinde etkisi oldu. Örneğin, bazı kullanıcılar Disney+, Netflix gibi hizmetlere erişemedi, ancak bu hizmetlerin diğer bölgelerde yedekli olarak çalışıp çalışmadığı veya bu kesintiye karşı ne kadar dayanıklı oldukları, kullanıcı deneyimini doğrudan etkileyen faktörlerdi. Bu vaka, uygulamaların bölgesel kesintilere karşı ne kadar dayanıklı tasarlandığının ne kadar önemli olduğunu bir kez daha gösterdi. Dolayısıyla, bir dahaki sefere bir “AWS küresel kesintisi” haberi duyduğunuzda, büyük olasılıkla belirli bir bölgedeki kapsamlı bir kesintiden bahsedildiğini, ancak AWS’in dünya genelindeki diğer bölgelerinin genellikle çalışmaya devam ettiğini aklınızda bulundurmalısınız. Asıl sorumluluk, uygulamaları bu bölgesel kesintilere karşı koruyacak şekilde mimari tasarlamaktadır.

Bir AWS Kesintisi Uygulamalarımızı Nasıl Etkiler ve Nasıl Öğreniriz?

AWS’in sunduğu bulut altyapısı ne kadar sağlam olursa olsun, hiçbir sistem %100 kesintisiz değildir. Dolayısıyla, bir AWS kesintisinin uygulamalarınızı nasıl etkileyebileceğini anlamak ve böyle bir durumda nasıl bilgi alacağınızı bilmek, iş sürekliliğiniz için hayati önem taşır. Bir kesinti, basit bir yavaşlamadan tam bir hizmet kesintisine kadar çeşitli şekillerde kendini gösterebilir ve kullanıcı deneyiminizi doğrudan etkiler.

Bir AWS kesintisi sırasında uygulamalarınızda gözlemleyebileceğiniz başlıca etkiler şunlardır:

• Erişilemezlik: En belirgin etki, uygulamanızın veya web sitenizin tamamen erişilemez hale gelmesidir. Kullanıcılar hata mesajlarıyla karşılaşır veya siteye/uygulamaya hiç bağlanamaz.
• Yavaşlama: Hizmetler tamamen kesilmese bile, performans düşüşleri yaşanabilir. Sayfalar daha yavaş yüklenir, veritabanı sorguları gecikir veya API yanıt süreleri uzar. Bu durum, özellikle yoğun trafik alan uygulamalar için kötü bir kullanıcı deneyimine yol açar.
• Veri Kaybı (Nadir): Çok nadir durumlarda, bir depolama veya veritabanı hizmetindeki kritik bir arıza, veri kaybına neden olabilir. Ancak AWS’in yedeklilik mekanizmaları sayesinde bu oldukça istisnai bir durumdur. Genellikle veriler korunur ancak geçici olarak erişilemez hale gelir.
• İşlevsellik Kaybı: Uygulamanızın bazı özellikleri, bağımlı oldukları AWS hizmetleri kesintiye uğradığında çalışmayabilir. Örneğin, S3 kesintisi, resimlerin yüklenememesine veya gösterilememesine neden olabilirken, Lambda kesintisi arka uç işlemlerinin durmasına yol açabilir.

Uygulamalarınızın AWS hizmetlerine olan bağımlılıkları, kesintinin etkisini belirlemede kritik rol oynar. Modern bulut uygulamaları genellikle “mikro hizmet” mimarileriyle tasarlanır ve birçok farklı AWS hizmetini kullanır. Bir hizmetteki kesinti (örneğin S3), bu hizmeti kullanan diğer tüm hizmetleri (örneğin statik dosyaları S3’ten çeken bir EC2 tabanlı web sitesi veya Lambda fonksiyonu) zincirleme bir reaksiyonla etkileyebilir. Bu nedenle, bağımlılık haritalarını ve kritik yol analizi yapmak, olası kesinti etkilerini önceden görmek açısından önemlidir.

Kesinti Anında Neler Olur ve Durumu Nasıl Takip Ederiz?

Bir AWS kesintisi yaşadığınızı düşündüğünüzde veya genel bir kesinti haberi duyduğunuzda, durumu hızlı ve doğru bir şekilde takip etmek, doğru kararları almanızı sağlar. AWS, bu tür durumlar için çeşitli resmi kanallar sunar:

1. AWS Service Health Dashboard (SHD): Bu, AWS’in genel durumunu gösteren herkese açık bir web sayfasıdır. status.aws.amazon.com adresinden erişebilirsiniz. Burada tüm AWS bölgelerindeki hizmetlerin anlık sağlık durumunu görebilirsiniz. Bir hizmetin yanında kırmızı bir işaret varsa, o bölgede bir sorun olduğu anlamına gelir. SHD, genel durumu hızlıca anlamak için harika bir başlangıç noktasıdır.
2. AWS Personal Health Dashboard (PHD): Bu, AWS hesabınıza özel bir gösterge panosudur. Size özel olarak etki eden olayları ve ilgili hizmet kesintilerini gösterir. PHD, kullandığınız AWS hizmetlerini ve kaynaklarını doğrudan etkileyen olaylar hakkında kişiselleştirilmiş bildirimler sunar. Örneğin, bir EC2 örneğinizin bulunduğu bir AZ’de kesinti varsa, bu bilgiyi PHD’niz üzerinden alırsınız. Bu, sorunun genel mi yoksa sadece sizin kaynaklarınızı mı etkilediğini anlamanıza yardımcı olur. AWS konsolu üzerinden erişilebilir.
3. AWS Destek ve Sosyal Medya: Ciddi kesintilerde, AWS’in resmi Twitter hesabı (@awscloud veya @aws_support) genellikle hızlı güncellemeler sağlar. Ayrıca, AWS Destek ekibiyle iletişime geçmek de detaylı bilgi almanıza yardımcı olabilir, ancak destek ekibi yoğun zamanlarda yavaş yanıt verebilir.
4. Monitoring (İzleme) Araçları: Kendi uygulamalarınız için kullandığınız izleme araçları (örn. Amazon CloudWatch, Prometheus, Grafana, Datadog) kesintiyi ilk fark edenler olabilir. Bu araçlar, uygulamanızın performans metriklerini (CPU kullanımı, ağ trafiği, hata oranları, yanıt süreleri) izleyerek anormal durumları tespit eder ve size uyarı gönderir.

Bir kesinti anında yapılması gerekenler:

• Sakin Kalın: Panik yapmak yerine, önce durumu resmi kanallardan doğrulamaya çalışın.
• Durumu Takip Edin: AWS SHD ve PHD’yi düzenli olarak kontrol edin. Twitter gibi sosyal medya kanallarını da takip edebilirsiniz.
• İç İletişimi Sağlayın: Ekibinizi ve ilgili paydaşları durum hakkında bilgilendirin.
• Acil Durum Planını Uygulayın: Eğer bir felaket kurtarma veya yüksek erişilebilirlik planınız varsa, bunu devreye sokma zamanı gelmiş olabilir.

Aşağıda, bir EC2 örneğinin durumunu kontrol etmek için kullanabileceğiniz basit bir Python kodu örneği yer almaktadır. Bu tür komut dosyaları, kesinti anında manuel kontrol sağlamanıza yardımcı olabilir.

import boto3

# AWS SDK'yı kullanarak EC2 istemcisi oluşturun
# Kendi bölgenizi buraya yazabilirsiniz, örneğin 'eu-central-1' (Frankfurt)
ec2 = boto3.client('ec2', region_name='us-east-1')

try:
    # Belirtilen bölgedeki tüm EC2 örneklerinin durumunu sorgula
    response = ec2.describe_instance_status(IncludeAllInstances=True)

    print(f"Bölge '{ec2.meta.region_name}' içindeki EC2 örneklerinin durumu:")
    if not response['InstanceStatuses']:
        print("Bu bölgede çalışan hiçbir EC2 örneği bulunamadı.")
    else:
        for instance_status in response['InstanceStatuses']:
            instance_id = instance_status['InstanceId']
            instance_state = instance_status['InstanceState']['Name']
            system_status = instance_status['SystemStatus']['Status']
            instance_status_check = instance_status['InstanceStatus']['Status']

            print(f"  Instance ID: {instance_id}")
            print(f"    Durum: {instance_state}")
            print(f"    Sistem Durumu Kontrolü: {system_status}")
            print(f"    Örnek Durumu Kontrolü: {instance_status_check}")
            print("-" * 30)

except Exception as e:
    print(f"Bir hata oluştu: {e}")

Bu kodu çalıştırmak için Boto3 kütüphanesini kurmanız ve AWS kimlik bilgilerinizi yapılandırmanız gerekir. Bu tür izleme ve hızlı kontrol mekanizmaları, olası kesintilere karşı proaktif olmanızı ve sorunları daha hızlı teşhis etmenizi sağlar. Ancak en önemlisi, kesintilere karşı mimarinizi dayanıklı tasarlamaktır.

Uygulamalarımızı AWS Kesintilerine Karşı Nasıl Koruyabiliriz?

AWS gibi bulut sağlayıcılarının kesintiye uğraması kaçınılmaz bir gerçekliktir, ancak bu durum uygulamalarınızın da durması gerektiği anlamına gelmez. Anahtar nokta, uygulamalarınızı bu tür olaylara karşı "dayanıklı" (resilient) ve "yüksek erişilebilir" (highly available) bir şekilde tasarlamaktır. Bu yaklaşım, tek bir hata noktasının (Single Point of Failure - SPOF) tüm sistemi çökertmesini engellemeyi amaçlar. Peki, bu dayanıklılığı ve yüksek erişilebilirliği AWS üzerinde nasıl sağlarız?

Yüksek Erişilebilirlik ve Felaket Kurtarma Stratejileri

Uygulamalarınızı kesintilere karşı korumanın temelinde, AWS'in sunduğu dağıtık altyapı özelliklerini akıllıca kullanmak yatar. İşte en etkili stratejiler:

1. Çoklu Erişilebilirlik Alanı (Multi-AZ) Mimarisi: Bu, AWS üzerinde yüksek erişilebilirlik sağlamanın ilk ve en temel adımıdır. Uygulamanızın bileşenlerini (EC2 örnekleri, RDS veritabanları, Kafka kümeleri vb.) tek bir Erişilebilirlik Alanına (AZ) yerleştirmek yerine, aynı bölgedeki birden fazla AZ'ye dağıtmalısınız. Bir AZ'de sorun yaşandığında, diğer AZ'deki kaynaklar hizmet vermeye devam eder.
   
   Örneğin, bir web sunucusu grubunuz varsa, bu sunucuların yarısını AZ-1'e, diğer yarısını AZ-2'ye yerleştirin. Önlerine bir Yük Dengeleyici (Load Balancer, örneğin Application Load Balancer - ALB) koyarak, trafiği yalnızca sağlıklı AZ'lerdeki sunuculara yönlendirmesini sağlayın. Veritabanları için RDS Multi-AZ dağıtımları, otomatik olarak birincil veritabanınızın bir AZ'de, senkron replikasının başka bir AZ'de olmasını sağlar ve birincil AZ çökerse otomatik failover (devir teslim) yapar.
2. Çoklu Bölge (Multi-Region) Mimarisi: En üst düzey dayanıklılık için, uygulamanızı farklı AWS bölgelerine (örneğin, us-east-1 ve eu-central-1) dağıtmayı düşünebilirsiniz. Bu strateji, tüm bir AWS bölgesini etkileyen (bkz: 2021 US-EAST-1 kesintisi) büyük ölçekli kesintilere karşı koruma sağlar. Multi-Region mimarileri daha karmaşık ve maliyetli olsa da, kritik iş yükleri için vazgeçilmezdir.
   
   Multi-Region stratejileri genellikle şu modellerden birini takip eder:
   • Aktif-Pasif (Pilot Light/Warm Standby): Bir bölge aktif çalışırken, diğer bölgedeki kaynaklar daha az kapasiteyle veya sadece temel hizmetlerle beklemede tutulur. Bir kesinti durumunda, pasif bölge aktive edilir.
   • Aktif-Aktif: Her iki (veya daha fazla) bölge de aynı anda trafik alır ve hizmet verir. Bu, en yüksek erişilebilirliği ve en düşük kurtarma süresini (RTO) sağlar ancak veri senkronizasyonu ve global yük dengeleme gibi konularda daha karmaşık çözümler gerektirir (örn. Route 53 Weighted/Latency Routing).
3. Yük Dengeleyiciler (Load Balancers): AWS Application Load Balancer (ALB) ve Network Load Balancer (NLB) gibi hizmetler, gelen trafiği birden fazla hedefe (örneğin farklı AZ'lerdeki EC2 örnekleri) dağıtarak tek bir sunucunun aşırı yüklenmesini veya başarısız olmasını engeller. Yük dengeleyiciler aynı zamanda "sağlık kontrolleri" (health checks) yaparak sağlıklı olmayan hedeflere trafik göndermeyi durdurur.
4. Otomatik Ölçeklendirme (Auto Scaling): Otomatik ölçeklendirme grupları (Auto Scaling Groups - ASG), uygulamanızın talebe göre otomatik olarak ölçeklenmesini sağlar. Bir sunucu çökerse veya yetersiz kalırsa, ASG otomatik olarak yeni bir sunucu başlatır. Bu, hem yüksek erişilebilirlik hem de maliyet optimizasyonu sağlar.
5. Veri Yedekleme ve Felaket Kurtarma (Backup & Restore / Disaster Recovery): Verilerinizin düzenli olarak yedeklenmesi ve bu yedeklerin farklı bir konumda (tercihen farklı bir bölgede veya S3'te) saklanması kritik öneme sahiptir. AWS Backup, S3 sürümleme (versioning) ve RDS anlık görüntüleri (snapshots) gibi hizmetler, veri kaybını önlemek ve hızlı bir şekilde geri dönmek için kullanılabilir. Felaket kurtarma (DR) planları, bir kesinti durumunda verilerinizi ve uygulamalarınızı ne kadar sürede geri yükleyebileceğinizi (RTO - Recovery Time Objective) ve ne kadar veri kaybına dayanabileceğinizi (RPO - Recovery Point Objective) tanımlar.
6. Sunucusuz Mimariler (Serverless Architectures): AWS Lambda, S3, DynamoDB gibi sunucusuz hizmetler, AWS tarafından tamamen yönetildiği için inherent olarak yüksek erişilebilirliğe sahiptirler. Bu hizmetler genellikle Multi-AZ olarak tasarlanmıştır ve altyapı yönetimi yükünü sizden alır. Uygulamanızın mümkün olduğunca sunucusuz bileşenler kullanması, operasyonel yükü ve kesinti riskini azaltabilir.

İşte bir Multi-AZ EC2 dağıtımını temsil eden basit bir CloudFormation şablonu (veya Terraform mantığına benzer bir yapı):

// Bu, bir AWS CloudFormation veya Terraform tanımına benzer bir kurgusal örnektir.
// Gerçek kod, kullandığınız IaC (Infrastructure as Code) aracına göre değişecektir.

// AWS::EC2::Instance kaynağını iki farklı Erişilebilirlik Alanına dağıtma örneği
Resources:
  WebServerInstance1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0abcdef1234567890 # Kendi AMI ID'nizi buraya yazın
      InstanceType: t2.micro
      KeyName: MyKeyPair
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      SubnetId: !Select [0, !GetAtt VPC.PrivateSubnets] # VPC'deki ilk özel alt ağa dağıt
      AvailabilityZone: !Select [0, !GetAZs ] # İlk Erişilebilirlik Alanına dağıt

  WebServerInstance2:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0abcdef1234567890 # Kendi AMI ID'nizi buraya yazın
      InstanceType: t2.micro
      KeyName: MyKeyPair
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      SubnetId: !Select [1, !GetAtt VPC.PrivateSubnets] # VPC'deki ikinci özel alt ağa dağıt
      AvailabilityZone: !Select [1, !GetAZs ] # İkinci Erişilebilirlik Alanına dağıt

  # Yük Dengeleyici (ALB) tanımı (Örnek)
  LoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Scheme: internet-facing
      Subnets:
        - !Select [0, !GetAtt VPC.PublicSubnets] # İlk genel alt ağ
        - !Select [1, !GetAtt VPC.PublicSubnets] # İkinci genel alt ağ
      SecurityGroups:
        - !Ref LoadBalancerSecurityGroup

  # Yük Dengeleyici Hedef Grubu (Örnek)
  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Port: 80
      Protocol: HTTP
      VpcId: !Ref VPC
      Targets:
        - Id: !Ref WebServerInstance1
          Port: 80
        - Id: !Ref WebServerInstance2
          Port: 80
      HealthCheckIntervalSeconds: 30
      HealthCheckPath: /health
      HealthCheckPort: '80'
      HealthCheckProtocol: HTTP
      HealthCheckTimeoutSeconds: 5
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2

  # Listener (Dinleyici) tanımı (Örnek)
  Listener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
        - TargetGroupArn: !Ref TargetGroup
          Type: forward
      LoadBalancerArn: !Ref LoadBalancer
      Port: 80
      Protocol: HTTP

// Not: Bu örnek, sadece Multi-AZ dağıtım mantığını göstermektedir.
// VPC, Security Group'lar ve diğer bağımlılıklar da tanımlanmalıdır.

Bu stratejileri uygulayarak, AWS'in bölgesel kesintilerinin uygulamanız üzerindeki etkisini minimize edebilir, hatta çoğu durumda tamamen görünmez hale getirebilirsiniz. Unutmayın, bulut sağlayıcısının sorumluluğu altyapının "buluta kadar" (up to the cloud) güvenliğini sağlamaktır. Sizin sorumluluğunuz ise, "bulutta" (in the cloud) çalışan uygulamalarınızın dayanıklılığını ve erişilebilirliğini tasarlamak ve yönetmektir. Bu ortak sorumluluk modelini (Shared Responsibility Model) anlamak, başarılı bir bulut stratejisinin temelidir.

Sonuç

Bu makale boyunca, AWS kesintilerinin doğasını, "küresel" kesinti yanılgısını ve uygulamalarımızı bu tür olaylara karşı nasıl dayanıklı hale getirebileceğimizi derinlemesine inceledik. Gördüğümüz gibi, AWS gibi devasa bir bulut altyapısı sağlayıcısında zaman zaman kesintiler yaşanması kaçınılmazdır. Ancak bu kesintiler genellikle bölgeseldir ve tüm dünyanın aynı anda felç olduğu senaryolar oldukça nadirdir. "Küresel" algısı, US-EAST-1 gibi kritik bölgelerdeki kesintilerin, dünya çapında popüler birçok hizmeti etkilemesinden kaynaklanmaktadır.

AWS, yüksek erişilebilirlik ve hata toleransı sağlamak için Bölgeler (Regions) ve Erişilebilirlik Alanları (Availability Zones) gibi gelişmiş bir mimariye sahiptir. Bu dağıtık yapı, tek bir hata noktasının geniş çaplı bir kesintiye yol açmasını engellemeyi amaçlar. Ancak AWS'in sorumluluğu, altyapıyı "buluta kadar" güvenli ve erişilebilir kılmaktır. Sizin sorumluluğunuz ise, uygulamalarınızı "bulutta" bu kesintilere karşı koruyacak şekilde tasarlamak, dağıtmak ve yönetmektir. Multi-AZ dağıtımlar, Multi-Region stratejileri, yük dengeleyiciler, otomatik ölçeklendirme, düzenli yedeklemeler ve sağlam bir felaket kurtarma planı, bu dayanıklılığı sağlamanın anahtarlarıdır.

Sonuç olarak, AWS'e duyulan güvenin sarsılması yerine, kesintileri bir öğrenme ve gelişme fırsatı olarak görmek önemlidir. Modern bulut bilişim, işletmelere daha önce hayal bile edilemeyecek bir esneklik ve güç sunarken, aynı zamanda kendi sistemlerimizin dayanıklılığına yönelik proaktif bir yaklaşım benimsememizi de gerektirir. Doğru mimari stratejilerle, AWS kesintilerini minimize edebilir ve iş sürekliliğinizi koruyabilirsiniz.

Sıkça Sorulan Sorular (SSS)