Cloud Nedir? IaaS, PaaS, SaaS, Serverless, Shared Responsibility, Region ve Availability Zone

Sürüm notu: Bu yazıdaki örnekler .NET 10 (SDK 10.0.404) ile denenmiştir. Azure'da kaynak oluşturulmadı; servis, region ve erişilebilirlik taahhüdü bilgileri Microsoft Learn'den, liste fiyatları Azure Retail Prices API'sinden 14 Kasım 2026'da alındı.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'u (bir online kitapçı) buluta taşıdın: Bookstore.Api App Service'te, BookstoreDb Azure SQL Database'de duruyor. Microsoft'un yayımladığı rakamlara göre App Service için taahhüt %99,95, Azure SQL Database için %99,99. Kullanıcının bir kitabı sepete ekleyebilmesi için ikisinin de ayakta olması gerekiyor. Bookstore'un bütünü için ayda kaç dakika kesintiyi "normal" saymalısın: 4 dakika mı, 22 dakika mı, yoksa başka bir şey mi? İkinci soru: aynı API'yi kendi kiraladığın bir VPS'e (Virtual Private Server; bir fiziksel sunucunun sana ayrılmış sanal parçası) koysaydın bu hesabı kim yapardı? Cevaplar yazının ortasında.

Cloud Ne Satıyor: Kiralanan Kapasite, API ile Yönetim, Kullandıkça Öde

Cloud'a "başkasının bilgisayarı" demek yanlış değil ama eksik. Bir sunucu kiralamak 2000'lerden beri mümkündü. Cloud'u farklı kılan üç şey var. Birincisi, kapasite dakikalar içinde ve bir API çağrısıyla geliyor: portalda bir düğmeye bastığında ya da az komutunu çalıştırdığında arkada çağrılan şey, Azure Resource Manager'ın REST (HTTP üzerinden kaynak odaklı çağrı yapılan API tarzı) API'si. Bu, altyapıyı kodla tarif edebilmenin ön koşulu; Infrastructure as Code: Terraform serisinin bütünü bu API'nin üstünde duruyor. İkincisi, elastikiyet: kampanya haftasında Bookstore.Api'yi iki instance'tan sekize çıkarıp hafta bitince geri indirebilirsin. Üçüncüsü, kullandıkça öde: kullandığın saat, gigabayt, istek sayısı kadar ödersin; donanımı peşin almazsın.

Bu üçünün bedeli de var. Kapasite kolay geldiği için kolay unutulur; elastikiyet ancak uygulama stateless (durumunu instance'ta değil dışarıda tutan) yazılmışsa işe yarar; kullandıkça öde modeli, faturanın da her ay değişmesi demektir. Serinin son iki yazısı tam olarak bu bedellerle ilgili.

IaaS, PaaS, SaaS ve Serverless

Service modelleri, yığının hangi katmanının sana kaldığına göre ayrılır. IaaS'te (Infrastructure as a Service; sanal makineyi kiraladığın, işletim sistemini senin yönettiğin model) sana bir VM, disk ve sanal ağ verilir; işletim sistemi güncellemesi, .NET runtime kurulumu, reverse proxy ayarı senin işin. Azure Virtual Machines bunun örneği. PaaS'te (Platform as a Service; kodu ya da container'ı verip altındaki makineyi görmediğin model) Bookstore.Api'yi bir zip ya da image olarak teslim edersin; işletim sistemi, runtime yamaları ve load balancer platformun işi. App Service, Azure SQL Database ve Azure Functions bu gruba girer. SaaS'te (Software as a Service; hazır bir uygulamayı kullandığın model) yazılımı da sen yazmazsın: Bookstore ekibinin kullandığı e-posta ve ofis paketi, ya da Jira bu sınıfta.

Serverless ayrı bir katman değil, PaaS'in bir faturalama ve ölçekleme biçimi. "Sunucu yok" demek değil; sunucuyu düşünmediğin, iş yokken sıfıra inen ve kullanım kadar ödenen model demek. Azure Functions'ın Flex Consumption planı ve Container Apps'in Consumption planı bu yüzden serverless sayılır; ikisi de istek gelmediğinde instance sayısını sıfıra indirebilir. Bedeli, ilk isteğin uyanan bir instance'a düşmesidir; buna cold start denir ve 4. yazıda Bookstore.Api üzerinde ölçüyoruz.

Shared Responsibility: Kim Neyi Yönetir?

Model seçtiğinde aslında bir sorumluluk dağılımı seçmiş olursun. Microsoft'un shared responsibility (paylaşılan sorumluluk) sayfası bunu bir tabloyla anlatıyor; aşağıdaki görsel o tablonun özeti.

Tablonun en önemli satırları en üsttekiler. Veri, hesaplar, kimin neye erişebildiği ve yapılandırma her modelde senin. SaaS kullansan bile bir çalışanın hesabı ele geçirilirse ya da bir storage container'ını herkese açık bırakırsan bu senin sorunun. Örneğin Azure SQL'i seçtiğinde SQL Server'ın yamalarını Microsoft yapar ama veritabanına 0.0.0.0-255.255.255.255 firewall kuralı ekleyip parolayı repoya koymak senin hatandır. Ortadaki "paylaşılan" hücreler de pratikte en çok karışıklık çıkan yer: PaaS'te ağın temel korumasını platform sağlar, uygulamaya kimin hangi IP'den gelebileceğini ise sen ayarlarsın.

Reliability için de aynı mantık geçerli. Microsoft region'ın ve zone'ların ayakta kalmasından sorumlu; Bookstore.Api'nin geçici bir bağlantı hatasında isteği tekrar denemesi, iki instance'la çalışması ve yedeğin gerçekten geri yüklenebildiğinin test edilmesi senin sorumluluğun.

Region, Availability Zone ve Region Pair

Region, aynı metropol alanındaki bir veya birkaç datacenter'dan oluşan ve kendi içinde düşük gecikmeli ağla bağlı bir bölge. Microsoft Learn'e göre Azure'da 70'ten fazla region var ve her region tek bir geography'ye (veri yerleşimi sınırı, örneğin Avrupa) ait. Region'ı programda kısa adıyla kullanırsın: Infrastructure as Code: Terraform serisinde Bookstore'un kaynakları westeurope'ta (Hollanda) duruyordu, bu seride de aynı region'ı kullanıyoruz.

Availability zone, bir region içindeki fiziksel olarak ayrı datacenter grubu: kendi elektriği, soğutması ve ağı var. Zone destekleyen region'larda en az üç zone bulunuyor. Uygulamanı zone-redundant kurduğunda (örneğin App Service Premium v3 planında en az iki instance ve zone redundancy açık) bir datacenter'ın çökmesi uygulamanı durdurmaz. Region pair ise Microsoft'un bazı region'ları ikişer eşlemesi: West Europe'un eşi North Europe (İrlanda). Bazı servisler geo-redundant kopyalarını eş region'a yazar ve Microsoft güncellemeleri iki eşe aynı anda yaymamaya çalışır. Daha yeni region'ların çoğunun eşi yok (Italy North, Poland Central, Spain Central gibi); bunlar dayanıklılık için önce zone'lara güveniyor. Region seçerken üç soruyu sırayla sor: kullanıcıya yakın mı (latency), ihtiyacın olan servisler ve zone desteği orada var mı, veri yerleşimi gereksinimini karşılıyor mu?

Son soru Türkiye'deki ekipler için ayrıca önemli. Azure'un Kasım 2026 tarihli region listesinde Türkiye'de bir region yok; Google Cloud, Turkcell ortaklığıyla bir Türkiye region'ı duyurdu ama bu yazı yazılırken açılmış değil. Yani Bookstore'un müşteri verisi Azure'da büyük olasılıkla yurt dışında durur. Bu bir hukuki tavsiye değil; ama mimari karar vermeden önce hukuk ya da uyum ekibine şu soruları götürmen gerekir: Hangi kişisel veriyi işliyoruz (ad, adres, sipariş geçmişi, kurumsal müşterinin çalışanları)? KVKK'nın (Kişisel Verilerin Korunması Kanunu) 1 Haziran 2024'te yürürlüğe giren 9. madde değişikliğinden sonra yurt dışı aktarımın dayanağı ne olacak: yeterlilik kararı mı, Kurul'un yayımladığı standart sözleşme mi? Standart sözleşme imzalanırsa, imzadan sonraki beş iş günü içinde Kurum'a bildirilmesi gerekiyor. Log'lar, yedekler ve sağlayıcının destek ekibinin erişimi de aynı veriyi taşıyor mu? Bu soruların cevabı region seçimini, hangi verinin hangi servise gideceğini ve bazen bulut kararının kendisini değiştirir.

SLA Okumak: Composite SLA'yı Hesaplamak

SLA (Service Level Agreement; sağlayıcının taahhüt ettiği erişilebilirlik oranı ve tutmadığında vereceği kredi) bir hedef değil, bir sözleşme. Microsoft'un Learn'deki örneğine göre App Service web app'leri için %99,95, Azure SQL Database için %99,99 taahhüt ediliyor; güncel ve bağlayıcı rakamlar "SLA for Online Services" belgesinde, her servis için ayrı koşullarla yazılı. Bookstore'un isteği iki servisten de geçtiği için ikisinin olasılıkları çarpılır. Hesabı elle yapmak yerine depoya küçük bir file-based app koyduk:

// Bookstore isteğinin geçtiği zincir için composite SLA ve kesinti bütçesi.
// Çalıştır: dotnet run tools/cloud/sla.cs

const double MinutesPerMonth = 30 * 24 * 60; // 43.200 dakika: SLA tablolarının kullandığı 30 günlük ay

(string Name, double Sla)[] chain =
[
    ("App Service (Bookstore.Api)", 99.95),
    ("Azure SQL Database (BookstoreDb)", 99.99),
];

double composite = chain.Aggregate(1.0, (product, part) => product * part.Sla / 100) * 100;

Console.WriteLine("Serial dependencies (all must be up):");
foreach ((string name, double sla) in chain)
{
    Console.WriteLine($"  {name,-34} {sla,7:0.###}%  {Downtime(sla),6:0.0} min/month");
}
Console.WriteLine($"  {"Composite",-34} {composite,7:0.###}%  {Downtime(composite),6:0.0} min/month");

Console.WriteLine();
Console.WriteLine("Downtime budget per 30-day month:");
foreach (double target in new[] { 99.0, 99.9, 99.95, 99.99, 99.999 })
{
    Console.WriteLine($"  {target,7:0.###}%  {Downtime(target),7:0.0} min");
}

// Failover yapan bir router arkasında iki region: iki region birden düşerse uygulama düşer.
double twoRegions = (1 - Math.Pow(1 - composite / 100, 2)) * 100;
Console.WriteLine();
Console.WriteLine($"Same stack in two regions (ignoring the router): {twoRegions:0.#####}%  {Downtime(twoRegions):0.00} min/month");

static double Downtime(double slaPercent) => (1 - slaPercent / 100) * MinutesPerMonth;

.NET 10'daki file-based app desteği sayesinde proje dosyası gerekmiyor; dotnet run tools/cloud/sla.cs yeterli:

Serial dependencies (all must be up):
  App Service (Bookstore.Api)          99.95%    21.6 min/month
  Azure SQL Database (BookstoreDb)     99.99%     4.3 min/month
  Composite                            99.94%    25.9 min/month

Downtime budget per 30-day month:
       99%    432.0 min
     99.9%     43.2 min
    99.95%     21.6 min
    99.99%      4.3 min
   99.999%      0.4 min

Same stack in two regions (ignoring the router): 99.99996%  0.02 min/month

Tahmin sorusunun cevabı bu: Bookstore'un bütünü için taahhüt edilebilecek üst sınır %99,94, yani 30 günlük bir ayda yaklaşık 26 dakika. Zincire bir servis daha eklersen (örneğin kapak resimleri için Storage, kimlik için ayrı bir servis) sayı daha da düşer. Rakamların üç sınırı var. Birincisi, SLA yalnız taahhüdün kapsadığı durumu ölçer: Well-Architected Framework'ün (Microsoft'un mimari değerlendirme rehberi) hatırlattığı gibi App Service'in SLA'sı uygulamanın 200 dönmesini kapsar, slot swap gibi özellikleri kapsamaz. İkincisi, senin kodundaki hata, yanlış konfigürasyon ve deploy sırasındaki kesinti bu hesaba hiç girmez. Üçüncüsü, taahhüt tutmadığında aldığın şey faturanın bir kısmının kredi olarak dönmesidir; kaybedilen siparişin karşılığı değildir. Bu yüzden SLA'yı "platformdan bekleyebileceğim en iyi durum" olarak oku, kendi hedefini, yani SLO'yu (Service Level Objective; ekibin kendine koyduğu erişilebilirlik hedefi) bunun altında koy. Son satırdaki iki region hesabı da gerçekçi değil: iki region'a dağıtmanın router, veri replikasyonu ve failover maliyeti 11. yazının konusu.

VPS sorusunun cevabı da burada: tek bir VPS'te bu hesabı kimse yapmaz, çünkü taahhüt edilen bir oran ya da zone yoktur. Sunucu, disk ve ağ tek parça; biri giderse hepsi gider.

Bulut Ne Zaman Gereksiz ya da Pahalı

Cloud her iş için doğru cevap değil. Üç durumda iki kez düşünmek gerekir. Birincisi, yükü sabit ve küçük olan uygulamalar: trafiği yıl boyunca aynı kalan bir iç uygulama için elastikiyet işe yaramaz, ödediğin şey yalnızca yönetim kolaylığıdır. Kıyas için 14 Kasım 2026'daki West Europe liste fiyatları: Linux App Service B1 (Basic katmanın en küçük boyutu) saatte 0,018 dolar (ayda yaklaşık 13 dolar), Premium v3 P0v3 saatte 0,089 dolar (ayda yaklaşık 65 dolar), iki vCPU'lu bir B2s (kısa süreli CPU patlamalarına izin veren küçük VM serisinden bir boyut) Linux VM saatte 0,048 dolar. Bunlar indirimsiz liste fiyatları ve sık değişir; ama küçük bir siteyi aylık sabit ücretli bir VPS'te çalıştırmanın daha ucuz olabileceğini göstermeye yeter. İkincisi, egress (veri çıkışı) yoğun işler: Azure'dan internete giden trafiğin ilk 100 GB'ı ayda ücretsiz, sonrası Avrupa ve Kuzey Amerika çıkışlı trafik için Microsoft ağı üzerinden GB başına 0,087 dolar. Bookstore ayda 2 TB kapak resmi servis etseydi yalnız bu kalem ayda yaklaşık 170 dolar tutardı; CDN (içeriği kullanıcıya yakın sunuculardan dağıtan ağ) ve cache (önbellek) bu yüzden bir maliyet konusudur. Üçüncüsü, ekibin bulutu işletecek bilgisi yoksa: identity, ağ ve maliyet ayarları yanlış kurulan bir subscription, iyi yönetilen bir VPS'ten daha güvensiz ve daha pahalı olabilir.

Bunun tersi de doğru. Kampanya dönemlerinde yükü on katına çıkan, birden çok environment'ı olan, yönetilen veritabanı, yedek ve kimlik servislerinden yararlanacak bir ekip için cloud, aynı işi kendi başına kurmaktan genellikle daha ucuzdur; çünkü pahalı olan donanım değil, işletim için harcanan insan zamanıdır.

AWS, Azure ve GCP Terim Eşlemesi

Seri boyunca Azure üzerinde çalışıyoruz ama kavramlar sağlayıcıdan bağımsız. Sonraki yazılarda her konunun AWS (Amazon Web Services; Amazon'un sunduğu bulut platformu) karşılığını ayrıca veriyoruz; GCP'yi (Google Cloud Platform, Google'ın bulut platformu) yalnız bu tabloda topluyoruz. Tablodaki kısaltmalar: OU (Organizational Unit; AWS hesaplarını gruplayan birim), IAM (Identity and Access Management; kimlik ve erişim yönetimi), RBAC (Role-Based Access Control; rol tabanlı yetkilendirme), EC2 (Elastic Compute Cloud; AWS'de sanal makine çalıştıran servis), ECS (Elastic Container Service; AWS'nin container çalıştırma servisi), EKS (AWS), AKS (Azure) ve GKE (Google Cloud) yönetilen Kubernetes servisleri, S3 (Simple Storage Service; AWS'nin object storage servisi), RDS (Relational Database Service; AWS'nin yönetilen veritabanı servisi), VPC (Virtual Private Cloud; sağlayıcı içindeki özel sanal ağ), NSG (Network Security Group; ağ trafiğine izin veren ya da engelleyen kural kümesi).

Eşleme birebir değil. Azure'daki resource group'un AWS'de doğrudan karşılığı yok (en yakını tag'ler ve CloudFormation stack'leri); AWS'de bir account hem faturalama hem güvenlik sınırıyken Azure'da bu iki rol subscription ile tenant arasında bölünüyor. 2. yazıda bu farkın günlük işe etkisine bakıyoruz.

Üretimde Dikkat

Region'ı bir kez seç ve yaz. Bookstore'un bütün kaynakları westeurope'ta; veritabanı bir region'da, API başka bir region'da olursa her sorgu region'lar arası gecikme ve trafik ücretiyle gelir. Yeni bir servis eklemeden önce o servisin region'da ve zone redundancy ile kullanılabildiğini "Products available by region" sayfasından kontrol et.

SLA hesabını belgeye koy. Bookstore'un mimari dokümanında hangi servisin hangi SLA'yı verdiği, composite sonucun ne olduğu ve ekibin kendi hedefinin bunun neresinde durduğu yazmalı; bir servis eklendiğinde hesap güncellenir. SLA tutmadığında kredi otomatik gelmez, destek talebiyle istenir; olay kayıtlarını bunun için de sakla.

İlk günden maliyet görünürlüğü kur. Budget alarmı, tag'ler ve hangi ortamın ne harcadığını gösteren bir görünüm 2. ve 10. yazıların konusu, ama alışkanlık burada başlar: bir kaynağı oluşturan kişi onun aylık fiyatını da bilmeli.

Sık Düşülen Tuzaklar

"Bulutta olduğu için yüksek erişilebilir" sanmak. Tek instance'lı bir App Service planı, zone redundancy kapalı bir veritabanı ve tek region, bir VPS'ten daha dayanıklı olabilir ama kendiliğinden yüksek erişilebilir değildir. Instance sayısı, zone ayarı ve yedek senin seçimin.

SLA'ları toplamak ya da en düşüğünü almak. Seri bağlı servislerin oranları çarpılır; %99,95 ile %99,99'un birleşimi %99,94'tür, %99,95 değil.

Lift-and-shift'i (uygulamayı değiştirmeden VM'e taşımak) son adım sanmak. VM'e taşınan uygulama, işletim sistemi yamasından yedeğe kadar bütün işleri de beraberinde getirir. Bookstore için hedef, 5. yazıda göreceğimiz gibi PaaS.

Veri yerleşimini deploy'dan sonra düşünmek. Region değiştirmek çoğu servis için taşıma projesidir; bu kararı en başta, hukuk ekibiyle birlikte ver.

Küçük Bir Deneme

★☆☆ tools/cloud/sla.cs'teki zincire Blob Storage'ı ekle (Learn'deki güncel SLA değerini kendin bul) ve composite sonucun aylık dakikasını yeniden hesapla.

★★☆ Bookstore için bir "neden bu region" notu yaz: westeurope ile Türkiye'ye coğrafi olarak daha yakın, eşi olmayan bir region'ı (örneğin Italy North ya da Poland Central) latency, zone desteği, eş region ve servis bulunurluğu açısından karşılaştır.

★★★ Bookstore'un müşteri, sipariş ve kurumsal kullanıcı verisini listele; her veri türü için KVKK açısından hukuk ekibine götüreceğin soruları ve hangi Azure servisinde duracağını bir tabloya yaz.

Bir sonraki yazıda bir Azure hesabının içine giriyoruz: tenant, management group, subscription ve resource group hiyerarşisi, Bookstore'un isimlendirme ve tag standardı, ilk resource group ve ilk gün kurulması gereken budget alarmı.