Aklınızı Kaybetmeden Güvenli ve Güvenilir Bir AWS Bulut Mimarisi Nasıl Oluşturulur?

Giriş

AWS'de bulut mimarisini sıfırdan tasarlamayı denediyseniz, muhtemelen zaten biliyorsunuzdur: özgürlük ve kaos eşit parçalardır. Bir şey inşa etmenin binlerce yolu olduğu gibi, onu berbat etmenin de bir o kadar yolu vardır.

AWS belgelerine kısa bir bakış sizi "Harika, sadece birinci sınıf uygulamaları gözlemleyeceğiz" diye düşündürebilir. Ancak gerçek uluslararası ortamlarda, birinci sınıf uygulamalar genellikle gerçek ticari işletme ihtiyaçları, fiyat aralığı sınırları veya insan hatası ile ilk temasta bulunmaz. Bu nedenle perfsys gibi profesyonellerle çalışmak, daha sonra koruma açıkları ve ölçeklendirme komplikasyonları ile köstebek kumarı oynamayı önleyebilir.

Amaç sadece çalışan bir şey elde etmek değildir. Trafik arttığında veya bir bölge devre dışı kaldığında devrilmeyen ve ön kapıyı internete açık bırakmayan bir sistem inşa etmektir.

Bariz Olanla Başlayalım: AWS Bir Canavar

AWS ile neredeyse her şeyi kurabilirsiniz. İki kişilik girişimlerden geniş kurumsal platformlara kadar, yapı taşlarının hepsi orada - EC2, Lambda, RDS, S3, IAM, VPC'ler, liste uzayıp gidiyor. İşin püf noktası? Ne kadar çok seçeneğiniz olursa, karmakarışık bir karmaşa yaratmak da o kadar kolay olur.

Bu AWS'nin kötü tasarlanmış olmasından kaynaklanmıyor. Sadece düzgün bir şekilde tasarlamanız gerekiyor. Aksi takdirde, bazı ekiplerin "bulut spagettisi" dediği şeyle karşılaşırsınız: birbirine bağlı hizmetler, kodlanmış sırlar, etiketleme yok, günlük kaydı yok ve neyin ne kadara mal olduğu hakkında kesinlikle hiçbir fikriniz yok.

Güvenilirlik ve Güvenlik Olmazsa Olmazlar Değildir

Güvenlik ve güvenilirliği geleceğin sorunu olarak görmek caziptir. "Canlıya geçtikten sonra güvenliğini sağlarız." "Bir sonraki sprintte izleme ekleyeceğiz." Ancak bir veri ihlali ya da saatlerce süren bir kesintiyle karşılaşan herkese sorun; bu adımları atladığınızda bütün gece çalışmanız gerekebilir.

Güvenilirlik Gerçekten Ne Anlama Geliyor?

Bu, bir slayt destesindeki çalışma süresi garantileriyle ilgili değildir. Bu, başarısızlık için mühendislikle ilgili. Hizmetler çöker. Diskler arızalanır. API'ler zaman aşımına uğrar. Önemli olan, bir şeyler bozulduğunda sisteminizin çalışmaya devam edip etmediğidir.

Kullanılabilirlik Bölgeleri arasında yedeklemeniz var mı? Sisteminiz veri kaybetmeden veya hata vermeden arızalı bir veritabanı düğümünü tolere edebiliyor mu? Kritik iş yüklerini tek bir bölgede mi çalıştırıyorsunuz çünkü "dağıtımı en kolay olan buydu"? Bunlar, çalışan sistemleri esnek olanlardan ayıran sorulardır.

Peki ya Güvenlik? Bu Sadece IAM Değil

Evet, Kimlik ve Erişim Yönetimi (IAM) ilk duvardır. Ancak güvenlik bunun çok ötesine uzanıyor. Herkese açık S3 kovaları. Aşırı izin verilen roller. Lambda işlevlerine kodlanmış sırlar. "Maliyetten tasarruf etmek için" kapatılan günlükler. Bunların hepsi birer saatli bombadır.

Aws'in iyi mimarileştirilmiş çerçevesini kullanmak, bu sorunları patlamadan önce tespit etmeye yardımcı olabilir. Mimariyi güvenlik, güvenilirlik, operasyonel mükemmellik, performans verimliliği ve maliyet optimizasyonu olmak üzere beş temel alana ayırır ve ekipleri her birini dürüstçe değerlendirmeye zorlar. Sihirli bir değnek değildir, ancak sizi zor sorular sormaya iter.

Gerçekten Önemli Olan Yapı Taşları

Pekala, şimdi işin özüne geçelim. AWS'de güvenli ve güvenilir bir mimari oluştururken nelerin önemli olduğunu ve ekiplerin en sık nerede yanlış yaptığını burada bulabilirsiniz.

IAM Rollerini Doğru Şekilde Kullanın (Evet, Gerçekten)

IAM rolleri güçlüdür. Bazen çok güçlüdür. Bir şey çalışmıyor diye "AdministratorAccess" rolünü yüklemek, daha sonra düzelteceğine söz vermek ve sonra asla düzeltmemek çok kolaydır.

Bunu erkenden kilitlemeniz gerekir. En az ayrıcalık ilkesi sadece en iyi uygulama değil, aynı zamanda tek aklı başında çalışma yöntemidir. Bu şu anlama gelir:

• Hizmet başına kapsamlandırılmış roller

• İzinlerde joker karakterlerden kaçınma

• Kısa ömürlü kimlik bilgileri

• İnsan kullanıcılar için zorunlu MFA

Kulağa acı gibi mi geliyor? Evet, öyle. Ancak patronunuza birisinin neden yanlış yapılandırılmış bir Lambda'dan müşteri verilerini sızdırdığını açıklamak da öyle.

Ağınızı Ciddi Olduğunuz Gibi Ayırın

Bu, kestirme yolların geri teptiği bir başka alandır. Süper karmaşık bir ağ kurulumuna ihtiyacınız yoktur, ancak bazı temel bilgiler uzun bir yol kat etmenizi sağlar:

• Genel alt ağlar yalnızca internete bakması gereken şeyler içindir (örn. ALB'ler)

• Diğer her şey için özel alt ağlar

• Kontrollü giden erişim için NAT ağ geçitleri

• Genel internete girmeden AWS hizmet trafiği için VPC uç noktaları

Her şeyin aynı alt ağda olduğu düz bir VPC kolay gelebilir. Ta ki bir şeyler kırılıp her şeyi beraberinde götürene kadar.

Kayıt ve İzleme: Göremediğinizi Düzeltemezsiniz

Bu artık tartışma konusu bile olmamalı. Günlük kaydı isteğe bağlı değildir. CloudTrail, CloudWatch metrikleri ve VPC akış günlüklerini yakalamıyorsanız, kör uçuyorsunuz demektir.

Ancak işin püf noktası şu: Günlük kaydı tek başına yeterli değil. Günlüklere gerçekten bakmanız gerekir. Önemli olan şeyler için uyarılar oluşturun. Gürültüyü filtreleyin. Ve günlüklerin hesaplar ve bölgeler arasında merkezileştirildiğinden emin olun. Parçalanmış görünürlük, görünürlük değildir.

Her Şeyi Şifreleyin (İstisnasız)

Bekleyen veriler için KMS kullanın. Aktarım halindeki veriler için TLS kullanın. Anahtarları döndürün. Erişimi izleyin. Bu, şimdi tembel olmanın daha sonra çok pahalıya mal olacağı alanlardan biridir.

Ayrıca RDS şifrelemesi, EBS birim ayarları ve API Gateway TLS zorlaması gibi şeyleri de unutmayın. Bu küçük ayrıntılar üst üste yığılıyor.

Kod Olarak Altyapı ya da Büst

Hala AWS konsoluna tıklayarak mı dağıtım yapıyorsunuz? Bu geliştirme için iyi, prod için tehlikeli.

Terraform, CloudFormation veya CDK kullanın. Ekibiniz hangisini tercih ederse etsin, sadece birini seçin ve ona sadık kalın. Şablonlarınızı sürüm kontrolünden geçirin. Dağıtmak için CI/CD kullanın. Geri dönüşleri otomatikleştirin. Manuel dağıtımlar hatalar için açık bir davettir.

Ayrıca: her şeyi etiketleyin. Etiketsiz kaynaklar, etiketsiz kablolar gibidir - kimse ne işe yaradıklarını bilmez ve herkes onlara dokunmaya korkar.

Batmadan Ölçeklendirme

Açık olalım: AWS aşırı kaynak sağlamanıza bayılır. Siz "performans" elde edersiniz, onlar da paranızı alır. Verimli ölçeklendirme, kalıplarınızı bilmek ve bunlar için planlama yapmakla ilgilidir.

Otomatik ölçeklendirme gruplarını, spot örnekleri (dikkatlice) ve önbelleğe alma katmanlarını kullanın. Ancak daha da önemlisi: yük altında test edin. En son isteyeceğiniz şey, RDS örneğinizin başlatıldıktan iki gün sonra gerçek trafik altında eridiğini keşfetmektir.

Ayrıca, mantıklı olduğunda kapasite ayırın. Para tasarrufu sağlar ve sürpriz provizyon hatalarını önler.

Felaket Kurtarma Planları İsteğe Bağlı Değildir

Bir bölge çökerse ne olur? Ya birincil veritabanınız bozulursa? Eğer cevabınız "başımız belaya girer" ise, DR stratejinizi yeniden gözden geçirmenin zamanı gelmiş demektir.

Bu, başka bir bölgede altyapınızın birebir kopyasını oluşturmak anlamına gelmez. Bilmek anlamına gelir:

• Geri yükleyeceğiniz şey

• Ne kadar sürer

• Hangi veriler kaybolacak (varsa)

• Yük devretme sırasında kim neyden sorumludur?

Ve evet - kurtarma planınızı test etmelisiniz. Aksi takdirde, sadece kurgu olur.

Kaçınılması Gereken Yaygın Anti-Paternler

Çok sık karşımıza çıkan bazı hayır-hayırları hızlıca gözden geçirelim:

• Her şey için tek bir büyük hesap: AWS Organizasyonlarını kullanın. Prod, dev, staging vb. hesapları ayırın.

• Varsayılan VPC'leri ve güvenlik gruplarını dokunulmadan bırakmak: onları kilitleyin.

• "Test için" t2.micro örneklerine aşırı güvenmek - eninde sonunda prod'ye gidecekler.

• CloudWatch maliyetleri için bütçe ayırmamak: evet, loglama maliyetlidir. Günlüğe kaydetmemek daha pahalıya mal olur.

• "Sadece hızlı bir şekilde düzeltmek" için erişim vermek: bunun yerine sürecinizi düzeltin.

Son Sözler? Esnek Kalın, Aklınızı Başınızda Tutun

Bulut mimarisi mükemmel kurulumu bulmakla ilgili değildir. Bu, esnek, sağlam ve sadece onu yazan kişiden daha fazlası tarafından anlaşılabilir bir şey inşa etmekle ilgilidir.

Asla gerçekten "bitmiş" sayılmazsınız - ve bu sorun değil. Önemli olan kasıtlı olmaktır. Zor soruları erkenden sormak. Sık sık denetlemek. Gerektiği yerde otomatikleştirmek. Ve ne zaman yardım çağıracağınızı bilmek.

Çünkü dürüst olalım - AWS güçlüdür, ancak içinde kaybolmak da kolaydır. Bulut mimarisini yaşayan ve soluyan deneyimli mühendislerle çalışmak, "çoğunlukla çalışıyor" ile "geceleri uyuyoruz" arasındaki farkı yaratabilir.

Ve bunun için inşa etmeye değer.