AWS Notlarım

Kendime notlar

IaaS ile PaaS Kıyası

IaaS (Insfrasctructure as a Service)

Bu durumda katmanlı yapıda siz “Applications + Application Runtime + OS” aşamalarından sorumlusunuz ve altındaki katmanları (Virtualization + Physical Hardware + Networking) aşamalarını bulut sağlayıcıya devretmişsiniz demektir:

Applications
Application Runtime
OS
Virtualization
Physical Hardware
Networking

Sizin sorumluluğunuz işletim sisteminin seçimi, kurulumu, güncellenmesi, yamalanmasından başlayarak, kuracağınız uygulamanın (örneğin nodejs, python, java, .net, ruby vs.) çalışması için gerekli runtime kurulumu da sizdedir. Bu uygulamanın yük yedeklemesi, yüksek erişilebilirliği (aşağıda biraz daha ayrıntılı gireceğimiz farklı bölgelere dağıtımları) vs. yine sizin yönetiminizde.

PAAS (Platform as a Service)

Bulut tarafından sağlanan bir platformu kullanıyorsunuz. Bu durumda katmanlı yapıda siz “Applications” aşamasındasınız ve altındaki katmanları bulut sağlayıcıya devretmişsiniz demektir:

Applications
Application Runtime
OS
Virtualization
Physical Hardware
Networking

■ Bulut sağlayacının sorumlulukları:
• Donanım, Ağ ve Sanallaştırma
• İşletim sistemi (güncellemeleri, yamaları vs.)
• Uygulama çalışma zamanı gereksinimleri (örneğin Java/.Net runtime vs.)
• Otomatik ölçekleme, Erişilebilirği ve Yük Dengelemesi (Load Balancing) vs..

■ Sizin sorumluluklarınız:
• Uygulama/Hizmetinizin konfigürasyonu
• Uygulama kodlarınız

Örnekler:
■ Bulutta PaaS altyapıları: AWS Elastic Beanstalk, Azure App Service, Google App Engine
■ Veritabanları (RDBMS & NoSQL): Amazon RDS, Google Cloud SQL, Azure SQL Database vs.

AWS Elastic Beanstalk hizmetinin anlamını bilmek kavrayışımızı arttıracaktır. Elastic hepimizin malumu “esnek” anlamına geliyor. “Beanstalk” kelimesi, bir masaldan esinlenerek kullanılmıştır. Masalda fasulye daldan yüksek bir yere tırmanmayı simgeler. Bu bağlamda, Elastic Beanstalk, geliştiricilerin uygulamalarını bulut ortamında hızla ve kolayca “yükseltmelerine” olanak tanır. Geliştiriciler, altyapı detaylarıyla uğraşmadan uygulama kodlarına odaklanabilirler.

Konteyner ve Orkestrasyon

Bir orkestratör bize şunları sağlar:

• Otomatik ölçeklendirme (auto scaling): Gelen isteklere sunucuların cevap verecek seviyeden uzaklaşması halinde yeni sunucuların ayaklandırılması.
• Hizmetlerin keşfi (service discovery): En basit haliyle hizmetlerin DNS tabanlı keşfedilmesi.
• Yük dengeleme (load balancing): gelen yükü, uygun hizmet sağlayıcılara yönlendirerek hızlı cevap verebilmek.
• Kendini iyileştirme (self healing): Healthcheck ile düşen konteyneri yenisiyle değiştirmek.
• Sıfır kesintiyle dağıtım (zero downtime deployments): Uygulama güncellemelerinin, kullanıcıların hizmete erişimini etkilemeden gerçekleştirilmesini sağlayan bir dağıtım yöntemidir. Bu yöntem, uygulamanın güncelleme sürecinde çevrimiçi kalmasını ve kullanıcıların hizmete kesintisiz erişimini sürdürmesini amaçlar.

Bu hizmeti AWS’nin Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) verebilir.

Serverless (Sunucusuz)

Elbette sunucu olmadan bir hizmeti ayaklandırmaktan bahsetmiyor “serverless” kavramından. Sadece sunucuyla muhatap olmuyor, hizmetinize odaklanıyorsunuz demek. Ölçekleme, yüksek erişilebilirlik de sizin mevzunuz olmuyor, ne kadar kullanırsanız o kadar ödüyorsunuz. Fiyatı “ne kadar istek olduğu (request)”, “bu isteklerin ne kadar süre işlendiği (duration)”, “ne kadar bellek tükettiği (memory consumption)” etkileyecek.

Sizin için tek temas noktanız “funcitons” tepe noktası yani işleviniz/kodunuz olup altındaki tüm katmanlar bulut sağlayıcının sorumluluğundadır.

Functions
Applications
Application Runtime
OS
Virtualization
Physical Hardware
Networking

AWS Lambda, Azure Functions, Google Cloud Functions bu hizmeti sağlıyor ancak ücretsiz kurabileceğiniz Openstack içinde de Qinling (Faas) hizmetini bulabilirsiniz. Apache’nin OpenWhisk sunucusuz hizmetini de kendi platformunuz gibi kullanarak kurumunuz içinde ayaklandırabilirsiniz.

Daha kısa süreli çalışacak işlevleriniz (function) için sunucusuz hizmetini, daha uzun çalışacak uygulamalarınızı barındıracak konteynerler için de sağlıyor bulut şirketleri. Serverless container hizmetleri, geliştiricilerin altyapı yönetimi ile uğraşmadan konteyner tabanlı uygulamalar geliştirmelerine olanak tanır. Yine “kullandıkça öde” modeli ile çalışır ve otomatik ölçeklendirme gibi özellikler sunar. Google Cloud Run, Azure Container Apps, AWS Fargate, sunucu yönetimini ortadan kaldırarak konteynerlerin çalıştırılmasını sağlar.

Yine sunucusuz veritabanı hizmetlerini de bulut sağlayıcılarından alabilirsiniz:

1. Amazon Aurora Serverless:

• AWS tarafından sunulan bu hizmet, otomatik olarak ölçeklenebilir ve yalnızca kullanılan kaynaklar için ödeme yapılmasını sağlar. Aurora, hem MySQL hem de PostgreSQL ile uyumlu bir veritabanıdır

2. AWS DynamoDB

3. Google Cloud Firestore:

• Firestore, dinamik ve ölçeklenebilir bir NoSQL veritabanıdır. Geliştiricilere gerçek zamanlı veri senkronizasyonu ve güçlü sorgulama yetenekleri sunar

4. BigQuery (Google)

5. Azure SQL Database Serverless:

• Microsoft’un Azure platformunda yer alan bu hizmet, otomatik olarak ölçeklenebilir ve yalnızca ihtiyaç duyulduğunda çalışır. Geliştiricilerin uygulamalarını hızla dağıtmasına olanak tanır

6. FaunaDB:

• FaunaDB, sunucusuz bir veritabanı olarak global dağıtım ve ACID özellikleri sunar. Geliştiricilere esnek bir veri modeli ve güçlü sorgulama yetenekleri sağlar

7. Couchbase Serverless:

• Couchbase, sunucusuz mimaride çalışan bir NoSQL veritabanıdır. Dinamik ölçeklendirme ve düşük gecikme süreleri ile yüksek performans sunar

Aynı şekilde kuyruk mekanizmaları gibi çok fazla hizmete sunucusuz erişebilirsiniz.

1. Amazon Simple Queue Service (SQS):

• AWS tarafından sunulan SQS, tam olarak yönetilen bir ileti kuyruğu hizmetidir. Mikro hizmetleri ve dağıtılmış sistemleri ayırarak ölçeklendirme imkanı sunar.

2. Oracle Cloud Infrastructure (OCI) Queue:

• OCI Queue, sunucusuz bir şekilde zaman uyumsuz iletişim sağlayan bir hizmettir. Yüksek hacimli işlem verilerini kayıp veya çoğaltma olmaksızın ele alır ve açık standartlar kullanarak iletişim sağlar. Mesajların kalıcı olmasını garanti eder ve dalgalanan hizmet taleplerini yönetebilir

3. Azure Queue Storage:

• Microsoft Azure’un sunduğu bu hizmet, esnek uygulamalar oluşturmak ve büyük iş yüklerinde dayanıklılığı artırmak için kullanılabilir. Kuyruk depolama, işlevlerin ayrılmasına olanak tanır ve uygulamaların daha iyi performans göstermesine yardımcı olur

AWS Global Infrastructure: Availability Zones

AWS’in temel yapı taşlarından biri olan Availability Zones (AZ), fiziksel veri merkezleridir. Bu veri merkezlerinde, sanal özel bulutlarımızda (VPC) kullandığımız hesaplama, depolama, ağ ve veritabanı kaynakları bulunur.

Bir yaygın yanlış anlaşılma, tek bir Availability Zone’un tek bir veri merkezine eşit olduğudur. Aslında, birden fazla veri merkezi bir Availability Zone’u oluşturabilir. Bu veri merkezleri, yüksek güvenilirlik ve düşük gecikmeli fiber optik bağlantılarla birbirine bağlıdır. Ancak, her AZ, diğerlerinden bağımsız güç ve ağ bağlantılarına sahip olduğundan, bir AZ’de sorun yaşansa bile diğerleri etkilenmez.

Bu düşük gecikmeli bağlantılar, birçok AWS hizmetinde yüksek kullanılabilirlik ve dayanıklılık için veri çoğaltımında kullanılır. Örneğin, RDS (Relational Database Service) için “Multi-AZ” dağıtımı yapılandığında, AWS, birincil ve ikincil veritabanı arasında eşzamanlı çoğaltma ve oluşturulan tüm okuma replikaları için eşzamansız çoğaltma kullanır.

Bir bölgedeki birden fazla AZ, yüksek oranda kullanılabilir ve dayanıklı uygulamalar ve hizmetler oluşturmanıza olanak tanır. Çözümlerinizi birden fazla AZ’deki kaynakları kullanacak şekilde tasarlayarak, bir AZ’de sorun yaşansa bile altyapınızın minimum düzeyde etkilenmesini veya hiç etkilenmemesini sağlayabilirsiniz.

AWS Global Infrastructure’ın diğer önemli bileşenleri:

• Regions: Birden fazla AZ’nin coğrafi olarak gruplandırılmasıdır.
• Edge Locations: İçerik dağıtımı ağının uç noktalarıdır.
• Regional Edge Caches: İçerik dağıtımını hızlandırmak için kullanılır.
• Local Zones: Metropollerdeki düşük gecikmeli yüksek performanslı hizmetleri sağlar.
• Wavelength Zones: Mobil ağ sağlayıcılarının hücre kulelerine yakın yerleştirilmiş veri merkezleridir.
• Outposts: Müşteri veri merkezlerine yerleştirilen AWS altyapısıdır.

AWS üzerinde hizmet dağıtımı yaparken, bu bileşenlerin nasıl çalıştığını ve çözümlerinizde nasıl kullanabileceğinizi anlamak önemlidir.

AWS Global Infrastructure: Regions

Bir Region (Bölge), coğrafi olarak yakın konumda bulunan birden fazla Availability Zone (AZ) koleksiyonudur. Genellikle aynı şehirdeki AZ’ler bir Region’u oluşturur. AWS, dünya çapındaki müşterilerinin düşük gecikmeli bağlantılardan yararlanabilmesi için bu bölgeleri küresel olarak dağıtmıştır.

Her Region diğerlerinden bağımsızdır ve en az iki Availability Zone içerir. Örneğin, Londra merkezli bir şirket Avrupa genelindeki müşterilere hizmet veriyorsa, yalnızca gecikme süreleri nedeniyle Sydney Region’da hizmet dağıtmanın mantıklı bir yanı yoktur. Bunun yerine, şirket, müşteri tabanına en uygun olan Londra, Frankfurt veya İrlanda Region’unu seçer.

Küresel bölgeler, veri depolama (saklama ve aktarım sırasında) ile ilgili düzenlemeler, yasalar ve yönetişimle uyumluluğa da olanak sağlar. Örneğin, tüm verileri belirli bir konumda, örneğin Avrupa’da tutmanız gerekebilir. Bu konumda birden fazla Region olması, bir organizasyonun bu gereksinimi karşılamasını sağlar.

Bir Region içinde birden fazla AZ kullanmanın yüksek kullanılabilirlik sağladığı gibi, birden fazla Region kullanmak da aynı şekilde yüksek kullanılabilirlik sağlar. İhtiyacınız olan iş sürekliliği düzeyine bağlı olarak, bir Region tamamen kullanılamaz hale geldiğinde (örneğin doğal afet nedeniyle), uygulamalarınızı ve hizmetlerinizi desteklemek için AWS ortamınızı birden fazla Region’da tasarlayabilirsiniz.

Farklı ülkelerde bulunan müşterilere hizmet veren küresel bir organizasyon iseniz, veri kullanımına ilişkin belirli yasaları ve yönetişimi olan farklı bölgelerde birden fazla Region kullanmak isteyebilirsiniz. Bu durumda, farklı bölgelerdeki farklı VPC’leri birbirine bağlayabilirsiniz.

AWS, bulut bilişim hizmetlerine olan talebi karşılamak için her yıl daha fazla Region eklemektedir. Bu yazının yayınlandığı tarih itibariyle (Ağustos 2023), 32 Region ve 102 Availability Zone bulunmakta olup, 4 ek Region ve 12 ek AZ planlanmaktadır.

İlginç bir şekilde, tüm AWS hizmetleri her Region’da mevcut değildir. Altyapınızı tasarlarken bu dikkate alınmalıdır. AWS Identity & Access Management (IAM) veya Amazon CloudFront gibi bazı hizmetler küresel hizmetler olarak sınıflandırılır, yani bu hizmetler belirli bir Region’a bağlı değildir. Ancak, çoğu hizmet Region’a özgüdür ve hangi hizmetlerin hangi Region’da mevcut olduğunu anlamanız gerekir.

AWS, yönetimi kolaylaştırmak için Region’larını daha büyük coğrafi bölgelere gruplandırır. Örneğin, N. Virginia ve Ohio Region’ları, ABD Doğu coğrafi konumu altındadır.

Bölgeler bu şekilde gruplandırılmış olsa da, her Region diğerlerinden bağımsızdır.

AWS GovCloud, yalnızca ABD devlet kurumları ve devlet düzenlemelerine tabi endüstrilerdeki organizasyonların kullanabileceği, katı gereksinimleri karşılaması gereken ABD’deki izole bir Region’dur.

Region ve Availability Zone Adlandırma Konvansiyonları

AWS, hem Regionlar hem de Availability Zone’lar için belirli bir adlandırma kuralına sahiptir.

Region adını görüntülediğiniz ve kullandığınız yere bağlı olarak, aynı Region için iki farklı isimle temsil edilebilir.

Regionlar, hem Yönetim Konsolu’nda görüntülenebilen bir konumu gösteren “dostu” bir isme, hem de AWS CLI gibi programatik olarak referans verildiğinde kullanılan bir Kod Adına sahiptir.

Availability Zone’lar her zaman Kod Adı ile referanslanır. Bu kod adı, AZ’nin ait olduğu Region’un Kod Adı ile takip eden bir harften oluşur. Örneğin, eu-west-1 bölgesindeki (AB İrlanda) AZ’ler şunlardır:

eu-west-1a eu-west-1b eu-west-1c

Burada dikkat edilmesi gereken ilginç bir nokta, AWS’in bu AZ harf tanımlayıcılarını farklı AWS hesapları için farklı fiziksel AZ’lere eşleştirmesidir. Bu, bir Region içindeki tüm AZ’ler arasında daha eşit bir kaynak dağılımı sağlar.

Birden fazla AWS hesabınız varsa ve aynı AZ Kod Adı’nı seçerek aynı AZ içindeki kaynakları koordine etmeye çalışırsanız, bu, yukarıdaki resimde görebileceğiniz gibi, bu kaynakların fiziksel olarak aynı AZ’de konumlandığı anlamına gelmeyebilir.

AWS Global Infrastructure: Edge Locations

Edge Locations, dünya genelindeki büyük şehirlerde ve yoğun nüfuslu bölgelerde dağıtılmış AWS siteleridir. Sayıları, mevcut Availability Zone sayısından çok daha fazladır.

Edge Locations, EC2 instance, EBS depolama, VPC veya RDS kaynakları gibi ana altyapınızı dağıtmak için kullanılmaz. Bunun yerine, AWS CloudFront ve AWS Lambda@Edge (şu anda Önizleme aşamasında) gibi AWS hizmetleri tarafından, Edge Locations’ı küresel bir İçerik Dağıtım Ağı (CDN) olarak kullanarak uç kullanıcı erişimi için veri önbelleklemek ve gecikmeyi azaltmak için kullanılır.

Sonuç olarak, Edge Locations öncelikle hizmetlerinize erişen ve kullanan uç kullanıcılar tarafından kullanılır.

Örneğin, web sitenizi Ohio bölgesindeki EC2 instance’lar ve S3 (kaynak) üzerinde barındırıyor ve yapılandırılmış bir CloudFront dağıtımıyla ilişkili olabilir. Bir kullanıcı web sitenize Avrupa’dan erişirse, en yakın Edge Location’a (Avrupa’da) yönlendirilir ve önbelleğe alınmış veriler web sitenizde okunabilir, böylece gecikme önemli ölçüde azalır.

AWS Global Infrastructure: Regional Edge Cache

Kasım 2016'da AWS, Regional Edge Cache adı verilen yeni bir Edge Location türünü duyurdu. Bunlar, CloudFront Kaynak sunucularınız ve Edge Locations arasında yer alır. Bir Regional Edge Cache, her bir Edge Location’dan daha geniş bir önbellek genişliğine sahiptir ve veriler Edge Locations’daki önbellekten süresi dolduğunda, veriler Regional Edge Caches’te saklanır.

Bu nedenle, artık kullanılabilir olmayan bir Edge Location’da veri talep edildiğinde, Edge Location, daha yüksek gecikmeye sahip olan Kaynak sunucuları yerine Regional Edge Cache’den önbelleğe alınmış verileri alabilir.

AWS Global Infrastructure: Local Zones

2022'de Amazon, yeni bir altyapı dağıtımı türü olan ilk 16 Local Zone’u (Yerel Bölge) başlattığını duyurdu. Bu, yakınında bir AWS Region bulunmayan büyük şehirler gibi yoğun nüfuslu alanlara temel AWS Hesaplama, Depolama, Ağ ve Veritabanı hizmetlerini yerleştirmek için tasarlanmıştır. Örneğin, Amerika Birleşik Devletleri’nin doğusunda, kuzey Virginia’da us-east-1 ve Ohio’da us-east-2 olmak üzere iki Region vardır. Ancak, Boston, New York City, Philadelphia, Atlanta ve Miami gibi çok büyük metropolitan alanlar da vardır ve bunların tümü, bu Region’un en yakın Availability Zone’larındaki veri merkezlerinden 100 mil veya daha fazla uzaklıktadır. AWS Local Zones, bu bölgelerdeki müşterilerin, en yakın Region’lara olan coğrafi mesafeden dolayı aksi takdirde ulaşılamayacak tek haneli milisaniye gecikme gerektiren kaynakları ve uygulamaları dağıtmalarına olanak tanır.

Ayrıca, veri ikametgahı gereklilikleri, verilerin belirli coğrafi sınırlar içinde saklanmasını gerektirebilir.

Tüm AWS Local Zones, güvenli, özel ve yüksek hızlı bir bağlantı aracılığıyla diğer tüm AWS hizmetlerine sorunsuz bir şekilde bağlanmanıza olanak tanıyan bir ana Region’a bağlıdır. AWS Local Zones, şu anda toplam 33 metropol bölgesinde mevcuttur ve gelecekte 19 ek bölge planlanmaktadır. Local Zone’ları kullanmak için öncelikle AWS hesabınızda etkinleştirmeniz gerekir. Bundan sonra, tüm Local Zone’lar, o Region içindeki Availability Zone’lar ile birlikte listelenecek ve VPC alt ağlarından EC2 instance’larına ve EBS volume’larına, ECS ve EKS kümelerine kadar her şeyi dağıtırken seçilebilecektir.

Ağustos 2023'te AWS, belirli bir müşteri veya topluluğun özel kullanımı için oluşturulmuş özel, tamamen yönetilen bir altyapı sunan Dedicated Local Zone’ları duyurdu. Dedicated Local Zone’lar, mevcut bir şirket içi veri merkezinde veya kritik görev ve diğer hassas iş yükleri için güvenlik veya diğer veri egemenliği düzenlemelerine uymak için bir müşteri veya topluluğun gereksinimleri tarafından belirlenebilecek diğer konumlarda dağıtılabilir. Bunlar, özellikle kamu sektöründe ve sıkı yönetişim kontrollerinin yerel yasa ve düzenlemelerine uymak için gerekli olduğu diğer endüstrilerde kullanışlıdır.

AWS Global Infrastructure: Wavelength Zones

AWS Local Zone’lara çok benzer şekilde, AWS Wavelength Zone’lar da temel AWS hizmetlerini büyük uç kullanıcı tabanlarına daha yakın yerleştirir ve güvenli, özel, yüksek hızlı bir bağlantı ile bir ana Region’a bağlanır. Ancak, AWS Wavelength Zone’lar, 5G mobil genişbant ağlarına gömülüdür ve büyük telekomünikasyon sağlayıcılarının veri merkezlerine dağıtılır. VPC alt ağları, EC2 instance’ları ve EBS volume’ları gibi AWS kaynaklarını bir AWS Wavelength Zone’a dağıtmak, uç kullanıcıların bu kaynaklara mobil sağlayıcının ağından hiç çıkmadan bağlanmasına olanak tanır. Ağ atlamalarının sayısını azaltarak ve trafiğin kamu internetinden geçme ihtiyacını ortadan kaldırarak, geliştiriciler canlı video akışı ve interaktif oyun gibi 5G uygulamaları için ultra düşük gecikme ve artan güvenilirlik sunabilir. AWS Wavelength Zone’lar şu anda ABD’de Verizon, Japonya’da KDDI, Güney Kore’de SK Telecom, İngiltere ve Almanya’da Vodafone ve Kanada’da Bell aracılığıyla kullanılabilir.

AWS Global Infrastructure: Outposts

AWS Outposts, AWS bulutunun yeteneklerini şirket içi veri merkezinize getirir. Bu, AWS’in veri merkezlerinde kullandığı aynı donanımı içerir, böylece altyapınızı AWS içinde çalıştırırken kullanacağınız aynı araçları ve API’leri kullanarak yerel AWS hizmetlerini kullanmanıza olanak tanır. Outposts, 1U veya 2U raf monte edilebilir sunucular veya 96 raka kadar dağıtıma ölçeklenebilen 42U raf olarak mevcuttur. Outposts, bir Direct Connect veya VPN bağlantısı kullanılarak AWS’ye bağlanabilir. Outposts, EC2, ECS, EKS, S3, RDS ve EMR gibi AWS hizmetlerini şirket içinde çalıştırmanıza olanak tanır. Müşteriler ayrıca, DynamoDB gibi diğer hizmetlere ve kaynaklara güvenli ve özel bir şekilde bağlanmak için PrivateLink geçidi uç noktalarını kullanabilirler. AWS Outposts’ta çok çeşitli EC2 instance türleri mevcuttur. Bunlar arasında M5, C5 ve R5 instance’lar ile EBS volume’ları, yerel diskler ve yerel instance depolama için depolama seçenekleri bulunur.

AWS Outposts tamamen yönetildiğinden, altyapınız genelinde bir yama yönetimi düzeyi tutmanız veya herhangi bir yazılımı yükleme veya güncelleme konusunda endişelenmenize gerek yoktur. AWS, Outposts’larınızın gerektiği gibi yamalanmasını ve güncellenmesini sağlayacaktır.

Umarım bu gönderi, Availability Zone’lar, Region’lar, Edge Locations, Regional Edge Caches, Local Zone’lar, Wavelength Zone’lar ve Outposts’tan oluşan AWS küresel altyapısı hakkında bazı açıklıklar sağlamıştır.

Bu bileşenlerin her birinin size ne yapmanıza izin vereceğini anlamak, sizin ve müşterileriniz için esnek, yüksek oranda kullanılabilir, güvenli ve düşük gecikmeli bir çözüm tasarlayabilmenize yardımcı olacaktır.

AWS Shared Responsibility Model

“AWS Shared Responsibility Model” ifadesinden de anlaşılacağı üzere, AWS Cloud’da güvenlik uygulaması tek bir tarafın sorumluluğu değildir, AWS ve müşteri arasında paylaşılır.

AWS Shared Responsibility Model, hangi güvenlik kontrollerinin AWS’in sorumluluğunda olduğunu ve hangilerinin sizin sorumluluğunuzda olduğunu belirler. Kısacası, kaynaklarınızın bulut içinde nasıl konumlandırılacağına (başka bir deyişle, kaynaklarınıza ne kadar erişim vermeye veya almaya karar verdiğinize) siz karar verirsiniz, AWS ise bulutun küresel güvenliğini (yani, kaynaklarınızı barındırmak ve bağlamak için sağladıkları altta yatan ağ ve donanım) garanti eder.

Deneyimlerime göre, AWS Shared Responsibility Model’in sağlam bir şekilde anlaşılması, yüksek güvenlikli ve güvenilir bir ortam oluşturmayı ve sürdürmeyi kolaylaştırır. Veri güvenliği konusunda nerede devreye girmem ve kontrolü ele almam gerektiğini bilmeden, ortamımın ne kadar güvenli olduğunu doğru bir şekilde tanımlayamadım.

Güvenlik, her açıdan AWS için bir numaralı önceliktir. AWS’in büyük miktarda sermaye ve kaynak ayırdığı ve sürekli dikkat gerektiren bir alandır.

Bunun bir nedeni var. Çeşitli endüstrilerdeki işletmeler, bulut benimseme konusunda isteksizliğin ana nedenlerinden biri olarak güvenliği görmeye devam ediyor. Bu tereddüdün üstesinden gelmek için AWS’in güvenlik hizmetleri, hizmetleri ve yönetişiminin en üst düzeyde olması gerekiyor.

AWS, dünyanın en güvenlik duyarlı müşterilerinin düzenleyici gerekliliklerini karşılamak için en sıkı güvenlik standartlarını karşılar. Çok sayıda düzenlemeyle karşı karşıya olan AWS, PCI DSS, ISO ve SOC dahil olmak üzere çok geniş bir güvenlik standardı yelpazesinde sertifikalı ve uyumludur.

AWS Hizmetleri, tüm küresel altyapısı boyunca tam olarak aynı şekilde dağıtılır ve dağıtılır. Bu, basit bir S3 kovasına erişen tek bir kullanıcının, en büyük ve en talepkar şirketlerle aynı sıkı güvenlik standartları tarafından kapsandığı anlamına gelir.

AWS Shared Responsibility Modelleri

Sorumluluk sınırlarını net bir şekilde tanımlamak için AWS, AWS ve müşteri sorumluluklarının nerede başladığını ve bittiğini tanımlayan 3 ana model tasarlamıştır:

• Altyapı Hizmetleri için Paylaşılan Sorumluluk Modeli
• Kapsayıcı Hizmetler için Paylaşılan Sorumluluk Modeli
• Soyut Hizmetler için Paylaşılan Sorumluluk Modeli

Bu modellerin her birine bakarak, farklılıkları net bir şekilde görebileceğiz. Öncelikle, EC2 gibi hizmetleri içeren bir altyapıya dayalı ilk modele bakalım. Ardından, kapsayıcı hizmetlerine ve soyut hizmetlere geçerken sorumluluk düzeyinin nasıl değiştiğine bakacağız.

AWS Paylaşımlı Sorumluluk Modeli: Daha Derine İnmek

Açıklandığı gibi, AWS, bulutun “güvenliği” olarak bilinen şeyden sorumludur. Bu, Bölgeler, Kullanılabilirlik Bölgeleri ve Edge Konumları dahil olmak üzere küresel altyapı öğelerini ve Hesaplama, Depolama, Veritabanı ve Ağ hizmetlerinin temellerini kapsar.

AWS, müşteri verilerinizin bulunduğu veri merkezlerine erişimi sahip olur ve kontrol eder. Bu, tüm donanım ve ağ bileşenlerine ve jeneratörler, kesintisiz güç kaynağı (UPS) sistemleri, güç dağıtım üniteleri (PDU’lar), bilgisayar odası klima (CRAC) üniteleri ve yangın söndürme sistemleri dahil olmak üzere ek veri merkezi tesislerine fiziksel erişimi kapsar. Daha önce belirtilen bazı güvenlik uyumluluk kontrolleri, bu fiziksel erişim girişine ve kontrolüne dayanmaktadır. Esasen, AWS bulutu oluşturan bileşenlerden sorumludur, buluta “konulan” herhangi bir veri sizin sorumluluğunuzdadır.

Temel Bulut altyapısı AWS tarafından güvence altına alındığında, buluta nelerin ekleneceğinin sorumluluğu size aittir. Bu, hem istemci hem de sunucu tarafı şifrelemeyi ve ağ trafiği korumasını, işletim sistemi, ağ ve güvenlik duvarı yapılandırmasının güvenliğini ve ardından uygulama güvenliği ile kimlik ve erişim yönetimini kapsar.

Uygulamak istediğiniz bu ek güvenliğin ne kadarı tamamen sizin kararınızdır. Seçtiğiniz şey, işinizin doğasına veya zaten sahip olabileceğiniz mevcut kontrollerine bağlı olabilir. Ortamınızı tehdit altına sokabilecek dış tehditlere maruz kalmayı en aza indirmek için güvenliği mümkün olduğunca sıkılaştırmanızı öneririm. Unutulmaması gereken önemli nokta, AWS’in birçok güçlü güvenlik kontrolü sağlarken, bunların nasıl ve ne zaman uygulanacağının AWS’in sorumluluğu olmadığıdır.

Paylaşımlı Sorumluluk Modeli: Kapsayıcı Hizmetler

AWS kapsayıcı hizmetlerine örnekler şunları içerir:

• Amazon Relational Database Service (RDS)
• Amazon Elastic MapReduce (EMR)
• AWS Elastic Beanstalk

Hemen, hem Platform hem de Uygulama yönetiminin yanı sıra herhangi bir işletim sistemi veya sistem ve ağ yapılandırmasının AWS’in sorumluluğuna geçtiğini ve artık müşteri olarak yönetmemize kalmadığını görebiliriz. Bu, altyapı tabanlı hizmetlere göre büyük bir farktır. Ancak, tüm sorumluluk devredilmemiştir. Güvenlik duvarı yapılandırmasının platform ve uygulama yönetimi düzeyinde entegre olan son kullanıcının sorumluluğunda olduğunu unutmamalısınız. Örneğin, RDS, yapılandırmasından ve uygulanmasından sorumlu olacağınız güvenlik grupları kullanır.

Paylaşımlı Sorumluluk Modeli: Soyut Hizmetler

Soyut hizmetlere örnekler şunları içerir:

Amazon Simple Storage Service (S3) Amazon DynamoDB Amazon Glacier Amazon Simple Queue Service (SQS)

Daha fazla sorumluluğun AWS’ye devredildiğini, özellikle de AWS’in tüm geçiş halindeki verileri AWS’in kendi ağı kullanarak koruyacağı ağ trafiği korumasını göreceksiniz. Ayrıca, hem platform (S3 Kova politikaları gibi) hem de IAM kullanıcı/grup düzeyinde doğru izinleri uygulamak için IAM araçlarını kullanmaktan sorumlusunuz.

Bu modellerin her birinde ilerledikçe, kontrol ve sorumluluk düzeyinin müşteriye göre daha fazla AWS’ye kaydığı açıkça görülmektedir.