Bir sunucu satın alıp kurmak yerine, ihtiyaç duyduğunuz hesaplama gücünü dakikalar içinde kiralayabilirsunuz. Bulut bilişim tam olarak bunu sağlıyor: sunucu, depolama, veritabanı ve ağ gibi kaynakları fiziksel donanım almadan, internet üzerinden kullanma imkânı. AWS, Azure ve GCP bu alanın üç büyük sağlayıcısı ve her biri aynı temel işi kendi yöntemiyle çözüyor. Bu rehberde üçünü pratik açıdan karşılaştırıp, hangi durumda hangisinin daha mantıklı olduğuna bakıyoruz.
Bulut Bilişim Aslında Ne İşe Yarar
Bulut bilişim, bir sağlayıcının veri merkezindeki sunucu, depolama ve ağ kaynaklarını kiralamanız anlamına geliyor. Kendi sunucu odanızı kurmak yerine, AWS'nin İrlanda'daki veya Azure'un Frankfurt'taki veri merkezinde bir sanal makine açıyorsunuz. İhtiyaç arttığında kaynak ekliyor, azaldığında kapatıyorsunuz; fatura da kullanıma göre şekilleniyor.
Bu modelin klasik altyapıya göre en büyük farkı, ön yatırım gerektirmemesi. Bir e-ticaret sitesi Kasım ayındaki kampanya trafiği için 20 sunucuya ihtiyaç duyabilir, Ocak'ta bunun beşte biri yeterli olur. Fiziksel donanımla bu esnekliği sağlamak zordur, bulutta ise birkaç komutla yapılır.
Kaynakları komut satırından veya API üzerinden yönetmek, bulutun günlük kullanımının büyük kısmını oluşturuyor. Örneğin AWS'de çalışan sanal makineleri listelemek şu kadar basit:
aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,State.Name]" --output table
Bu komut, hesabınızdaki tüm sunucuları ve durumlarını tek ekranda listeliyor. Aynı bilgiyi web arayüzünde bulmak birkaç tıklama gerektirirken, komut satırına alışmış biri için bu yol çok daha hızlı. Otomasyon script'leri de zaten bu tür komutların üzerine kuruluyor.
IaaS, PaaS, SaaS Farkı Nedir
Bulut hizmetleri üç ana katmanda toplanıyor ve bu ayrım, ne kadar kontrol istediğinizle doğrudan ilgili. IaaS (Infrastructure as a Service) size çıplak sanal makine, disk ve ağ verir; işletim sistemini siz kurar, siz güncellersiniz. AWS EC2, Azure Virtual Machines ve GCP Compute Engine bu katmanın örnekleri.

PaaS (Platform as a Service) bir adım daha yukarıda durur. Kodunuzu yüklersiniz, sunucu yönetimi, ölçekleme ve işletim sistemi yamaları sağlayıcının işidir. AWS Elastic Beanstalk, Azure App Service ve Google App Engine bu gruba giriyor.
SaaS ise en üst katman: uygulamayı doğrudan tarayıcıdan kullanırsınız, altyapıyla hiç ilginiz olmaz. Gmail, Microsoft 365 ve Salesforce klasik SaaS örnekleri. Bir geliştirme ekibi genelde IaaS ile PaaS arasında gidip gelir, SaaS ise son kullanıcı tarafını kapsar.
Bu üç katmanı bir tabloda toplamak, aradaki farkı daha net gösteriyor:
| Katman | Ne yönetirsiniz | Ne sağlayıcı yönetir | Örnek |
|---|---|---|---|
| IaaS | İşletim sistemi, uygulama, veri | Fiziksel donanım, sanallaştırma | EC2, Azure VM, Compute Engine |
| PaaS | Uygulama kodu, veri | İşletim sistemi, çalışma zamanı, ölçekleme | Elastic Beanstalk, App Service, App Engine |
| SaaS | Sadece kullanım ve veri girişi | Her şey | Gmail, Microsoft 365, Salesforce |
Hangi katmanı seçeceğiniz, ekibinizin ne kadar kontrol istediğine bağlı. Altyapı ekibi güçlüyse ve özelleştirme önemliyse IaaS mantıklı; küçük bir geliştirme ekibi hızlı ürün çıkarmak istiyorsa PaaS zaman kazandırır. Çoğu proje aslında bu iki katmanı bir arada kullanıyor: veritabanı PaaS üzerinden yönetilirken, özel bir servis IaaS'te çalışabilir.
AWS, Azure ve GCP Arasındaki Temel Farklar
AWS, pazara en erken giren ve hâlâ en geniş hizmet kataloğuna sahip sağlayıcı. Yüzlerce servisi, en yüksek bölge sayısı ve büyük bir ortak ekosistemi var; bunun bedeli bazen kafa karıştırıcı bir arayüz ve karmaşık bir fiyatlandırma. Startup'lardan bankalara kadar geniş bir kullanıcı kitlesi AWS'yi tercih ediyor.

Azure, kurumsal dünyada özellikle güçlü; çünkü Windows Server, Active Directory ve Microsoft 365 ile entegrasyonu sorunsuz çalışıyor. .NET ekosisteminde çalışan veya hibrit altyapı (yerinde sunucu + bulut) kuran şirketler için doğal bir seçim oluyor. Azure Arc gibi araçlar, şirket içi sunucuları da bulut yönetim paneline dahil edebilir.
GCP, veri analitiği, makine öğrenmesi ve Kubernetes konusunda öne çıkıyor; Kubernetes'i baştan Google geliştirdi. BigQuery gibi araçlar büyük veri sorgularında hız avantajı sağlıyor. Fiyatlandırma tarafında GCP genelde saniyelik faturalama ve otomatik indirimlerle daha sade bir yapı sunuyor.
Üçünün de temel hizmetleri (sanal makine, nesne depolama, yönetilen veritabanı, konteyner orkestrasyon) birbirine çok yakın. Fark, ekosistemde, fiyatlandırma detaylarında ve mevcut altyapınızla ne kadar uyumlu olduklarında ortaya çıkıyor. Bir şirketin hangi sağlayıcıyı seçtiğine bakmak yerine, kendi ekibinizin hangi ekosistemde daha rahat çalışacağına bakmak daha isabetli.
Küresel altyapı büyüklüğü de karşılaştırmada önemli bir konu. AWS'nin dünya genelinde en fazla bölgesi (region) var; bu da kullanıcıya coğrafi olarak yakın bir veri merkezi seçme imkânı sağlıyor. Azure ve GCP de bölge sayısını hızla artırıyor, özellikle Avrupa ve Orta Doğu'da yeni veri merkezleri açılıyor. Hedef kitleye yakın bir bölge seçmek, gecikmeyi doğrudan etkiliyor.
Bulut Maliyetleri Nasıl Kontrol Altında Tutulur
Kullandıkça öde modeli kulağa cazip geliyor ama dikkatli izlenmezse fatura hızla büyüyebilir. En sık karşılaşılan sorun, test için açılan bir sanal makinenin kapatılmasının unutulması ya da gereğinden büyük bir örnek türünün seçilmesi. Bu yüzden her üç sağlayıcı da harcama izleme ve uyarı araçları sunuyor.
Maliyeti yönetmenin pratik yolları şunlar:
- Kullanılmayan kaynakları (boşta duran diskler, eski snapshot'lar, atıl IP adresleri) düzenli olarak temizlemek
- İş yüküne uygun örnek türünü seçmek, gereğinden büyük başlayıp sonra küçültme alışkanlığından kaçınmak
- Öngörülebilir iş yükleri için rezerve örnek veya taahhütlü indirim planlarına geçmek
- Bütçe uyarıları kurup belirli bir eşiği aşınca bildirim almak
- Otomatik kapatma kuralları tanımlayıp geliştirme ortamlarını mesai dışında durdurmak
Güncel fiyatlar sağlayıcıdan sağlayıcıya ve bölgeden bölgeye değişiyor; bu yüzden kesin bir rakam vermek yerine her zaman ilgili sağlayıcının güncel fiyat sayfasına bakmak gerekiyor. Azure CLI ile bir kaynak grubundaki sanal makineleri hızlıca listelemek şöyle görünüyor:
az vm list --resource-group my-resource-group --output table
Bu komutun çıktısı, hangi sanal makinelerin çalışır durumda olduğunu ve hangi kaynak grubuna ait olduğunu gösteriyor. Kaynak gruplarını düzenli tutmak, hangi projenin ne kadar harcadığını takip etmeyi kolaylaştırıyor. Etiketleme (tagging) alışkanlığı da aynı işi görüyor: her kaynağa proje adı ve sorumlu ekip etiketi eklemek, fatura döküldüğünde kimin ne kadar harcadığını hemen gösteriyor.
Hangi Sağlayıcı Size Göre Seçim Kriterleri
Doğru sağlayıcıyı seçmek, teknik özelliklerden çok mevcut ekibin bilgisine ve iş ihtiyacına bağlı. Ekip zaten .NET ve Windows ile çalışıyorsa Azure'a geçiş sürtünmesi düşük olur. Veri bilimi ve makine öğrenmesi ağırlıklı bir proje için GCP'nin BigQuery ve Vertex AI kombinasyonu zaman kazandırabilir.

Seçim yaparken kontrol edilmesi gereken noktaları kısa bir liste hâlinde toplamak faydalı:
- Ekibin hâlihazırda hangi platformda deneyimi var
- Kullanılacak servisler (veritabanı, AI, IoT) hangi sağlayıcıda daha olgun
- Şirketin hedef pazarına yakın bir veri merkezi bölgesi var mı
- Uyumluluk gereksinimleri (KVKK, sektörel regülasyon) hangi bölgeleri zorunlu kılıyor
- Mevcut lisanslar (örneğin Microsoft anlaşmaları) hangi platformda avantaj sağlıyor
Küçük bir proje veya kişisel deneme için üç sağlayıcının da ücretsiz katmanı var; gerçek kararı vermeden önce bunları denemek makul bir başlangıç. GCP tarafında kaynakları listelemek için gcloud komutu şöyle çalışıyor:
gcloud compute instances list --format="table(name,zone,status)"
Ücretsiz katmanların sınırları her sağlayıcıda farklı; kimi ay bazlı belirli saatlik kullanım sunar, kimi belirli hizmetleri süresiz ücretsiz tutar. Denemeye başlamadan önce ücretsiz katmanın hangi hizmetleri ve hangi limitleri kapsadığını sağlayıcının güncel sayfasından kontrol etmek gerekiyor; aksi hâlde deneme sırasında beklenmedik bir ücretle karşılaşmak mümkün.
Buluta Geçiş ve Çoklu Bulut Stratejisi
Mevcut sistemleri buluta taşımak tek seferde değil, aşamalı yapılmalı. Önce kritik olmayan bir iş yükü (örneğin bir test ortamı veya statik bir web sitesi) taşınır, süreç ve maliyet gözlemlenir. Ardından kademeli olarak daha kritik sistemler buluta alınır.
Altyapıyı kod olarak tanımlamak, geçiş sürecini tekrarlanabilir hâle getiriyor. Terraform gibi araçlarla hem AWS hem Azure hem GCP kaynaklarını aynı mantıkla tanımlamak mümkün:
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
tags = {
Name = "web-sunucu"
}
}
Bazı şirketler tek sağlayıcıya bağlı kalmak yerine çoklu bulut stratejisi izliyor: örneğin ana iş yükü AWS'de dururken, veri analitiği GCP'de çalışıyor. Bu yaklaşım tek noktadan bağımlılığı azaltıyor ama yönetim karmaşıklığını da artırıyor. Her platform için ayrı uzmanlık, ayrı izleme aracı ve ayrı fatura takibi gerekiyor.
Küçük ve orta ölçekli ekipler için çoğu zaman tek sağlayıcıda derinleşmek, kaynakları birden fazla platforma dağıtmaktan daha verimli sonuç veriyor. Çoklu bulut, genelde belirli bir hizmetin bir platformda gerçekten daha iyi olduğu veya düzenleyici bir zorunluluğun birden fazla sağlayıcı gerektirdiği durumlarda anlam kazanıyor; her iş için varsayılan strateji olarak seçilmemeli.
Buluta geçerken atılacak en pratik ilk adım, mevcut iş yüklerinden birini seçip küçük bir pilot proje olarak taşımak. Bu pilotta gerçek maliyet ve performans verisi gözlemlenir, ekip alışkanlık kazanır. Teorik karşılaştırmalar ne kadar detaylı olursa olsun, kendi iş yükünüzün bir sağlayıcıda nasıl davrandığını görmenin yerini tutmuyor.
AWS, Azure ve GCP dokümantasyonları bu konuda ayrıntılı geçiş rehberleri sunuyor; karar öncesi göz atmaya değer: AWS ürünleri, Azure ürünleri ve Google Cloud dokümantasyonu. Hangi platformu seçerseniz seçin, gerçek fatura ve gerçek gecikme rakamları, herhangi bir karşılaştırma yazısından daha güvenilir bir kılavuzdur.
Henüz yorum yok.
Sohbete katıl. Yorumlar yayınlanmadan önce moderasyondan geçer.