Sanallaştırma & Bulut

    IaaS, PaaS ve SaaS Farkı

    Üç bulut hizmet modelinin sorumluluk sınırları ve doğru seçim kriterleri.

    9 dk okuma Güncellendi: 25 Ağustos 2026

    Bir bulut sağlayıcısının fiyat sayfasına baktığında karşına üç harfli kısaltmalar çıkar: IaaS, PaaS ve SaaS. Bunlar pazarlama etiketi değil, gerçekten farklı sorumluluk ve maliyet modelleridir. Hangi katmanı satın aldığın, sunucu güncellemelerini kimin yapacağını, bir güvenlik açığı çıktığında kimin yamayacağını, veri kaybında kimin sorumlu olduğunu ve maliyetin nasıl büyüyeceğini doğrudan belirler.

    Bu rehberde üç modeli teknik olarak ayıracağım: hangi katmanı sen yönetiyorsun, hangisini sağlayıcı yönetiyor, sorumluluk sınırı tam olarak nerede çizilir. Ardından gerçek örneklerle her modelin ne zaman doğru seçim olduğunu, maliyet eğrilerinin nasıl farklılaştığını, modeller arası geçişin ne kadar zor olduğunu ve karar verirken en sık yapılan hataları anlatacağım.

    Üç Model Neyi Ayırır#

    En basit tanımıyla üç model, bir uygulamayı ayakta tutmak için gereken katman yığınının nerede bölündüğünü tarif eder. Yığın aşağıdan yukarıya şöyledir: veri merkezi, donanım, sanallaştırma, işletim sistemi, çalışma zamanı (runtime), uygulama, veri.

    IaaS (Infrastructure as a Service) sana sanal makineyi verir. İşletim sisteminden yukarısı senindir: kernel güncellemesi, güvenlik duvarı, web sunucusu kurulumu, veritabanı ayarları, yedekleme — hepsi sende. Klasik bir sanal sunucu ya da bulut sunucu bu kategoridedir.

    PaaS (Platform as a Service) sana çalışan bir platform verir. Kodunu yüklersin, gerisiyle ilgilenmezsin: işletim sistemi güncellemeleri, çalışma zamanı sürümü, ölçekleme ve çoğu zaman veritabanı yönetimi sağlayıcıdadır. Karşılığında platformun kurallarına uymak zorundasın.

    SaaS (Software as a Service) sana bitmiş bir uygulama verir. Ne kod yazarsın ne sunucu yönetirsin; sadece kullanır ve yapılandırırsın. E-posta hizmeti, muhasebe yazılımı ya da müşteri ilişkileri yönetimi araçları bu kategoridedir.

    KatmanIaaSPaaSSaaS
    Veri merkezi, donanımSağlayıcıSağlayıcıSağlayıcı
    SanallaştırmaSağlayıcıSağlayıcıSağlayıcı
    İşletim sistemiSenSağlayıcıSağlayıcı
    Çalışma zamanı / kütüphanelerSenSağlayıcıSağlayıcı
    Uygulama koduSenSenSağlayıcı
    Veri ve erişim yetkileriSenSenSen

    Tablonun son satırı en kritik olanıdır ve sık atlanır: veri her üç modelde de senin sorumluluğundadır. SaaS kullanıyor olman, kimin hangi veriye eriştiğinden ve verinin yedeğinin alınıp alınmadığından seni muaf tutmaz.

    IaaS: Kontrol Sende, Sorumluluk da Sende#

    IaaS, geleneksel sistem yönetimine en yakın modeldir. Bir sanal sunucu alırsın, işletim sistemini seçersin, root erişimine sahip olursun. İstediğin kernel parametresini değiştirebilir, istediğin paketi kurabilir, mimarini istediğin gibi kurgulayabilirsin.

    Bu esnekliğin bedeli, tüm bakım yükünün sende olmasıdır. Tipik bir IaaS sunucusunda düzenli olarak yapman gerekenler şunlardır:

    # Güvenlik güncellemelerini uygula
    apt update && apt upgrade -y
    
    # Açık portları denetle
    ss -tulpn | grep LISTEN
    
    # Güvenlik duvarı kurallarını kontrol et
    ufw status verbose
    
    # Disk kullanımı ve doluluk riski
    df -h --output=source,pcent,target | sort -k2 -r | head
    

    Bu listeye yedeklemenin doğrulanması, log rotasyonunun çalıştığından emin olunması ve sertifika yenilemelerinin izlenmesi de eklenir. Bir sunucuyu kurmak birkaç saat sürer; doğru işletmek sürekli bir iştir. IaaS'ı seçerken asıl soru "kurabilir miyim" değil, "aylarca bakımını yapacak zamanım ve disiplinim var mı" olmalıdır.

    IaaS'ın güçlü olduğu durumlar nettir: özel yazılım gereksinimleri, uyumluluk nedeniyle tam kontrol zorunluluğu, maliyet optimizasyonu için kaynak üzerinde ince ayar yapma ihtiyacı ve platformun desteklemediği teknolojiler. Sanal sunucu ve VDS paketlerimiz bu modelin tipik örnekleridir; kaynak tahsisi açısından aralarındaki farkı VPS, VDS ve VM terimleri yazısında ayrıntılandırdım.

    PaaS: Hızlı Yayın, Kısıtlı Özgürlük#

    PaaS'ta hikâye şudur: kodunu bir depoya gönderirsin, platform onu derler, çalıştırır, ölçekler ve gerektiğinde yeniden başlatır. İşletim sistemi güncellemeleriyle, web sunucusu yapılandırmasıyla, sertifika yenilemeleriyle uğraşmazsın. Küçük bir ekip için bu, aylarca sistem yönetimi işinden kurtulmak anlamına gelir.

    Bedeli üç başlıkta toplanır. Birincisi esneklik kaybı: platformun desteklemediği bir çalışma zamanı sürümünü ya da sistem kütüphanesini kullanamazsın. İkincisi maliyet eğrisi: PaaS başlangıçta ucuzdur ama trafiğin arttıkça birim maliyet, eşdeğer IaaS kurulumunun belirgin biçimde üstüne çıkar. Üçüncüsü taşınabilirlik: uygulamanı platformun kendine özgü servislerine bağladıkça başka yere taşımak zorlaşır.

    Uygulamanı taşınabilir tutmak için basit bir kural: platforma özgü olan her şeyi yapılandırmayla dışarıdan ver, koda gömme.

    # İyi: ortam değişkeniyle yapılandırma (her platformda çalışır)
    DATABASE_URL=postgres://kullanici:[email protected]:5432/uygulama
    CACHE_URL=redis://cache.firmaniz.com:6379/0
    STORAGE_ENDPOINT=https://depolama.firmaniz.com
    
    # Kötü: sağlayıcıya özgü SDK çağrısını iş mantığının içine gömmek
    

    Bu ayrım, ileride geçiş yapman gerektiğinde haftalar kazandırır. Bağımlılığın nasıl birikip nasıl maliyete dönüştüğünü vendor lock-in yazısında ayrıntılı ele aldım.

    SaaS: Sadece Kullan#

    SaaS'ta yönetilecek hiçbir altyapı yoktur. Kayıt olursun, yapılandırırsın, kullanırsın. Muhasebe programından e-posta hizmetine, proje yönetim aracından e-ticaret platformuna kadar geniş bir yelpaze bu modele girer.

    Doğru soru "SaaS mı IaaS mı" değil, "bu iş bizim ayırt edici yeteneğimiz mi" sorusudur. Şirketin işi e-posta sunucusu işletmek değilse, kendi mail sunucunu kurup IP itibarı yönetmek yerine hazır bir hizmet almak neredeyse her zaman doğrudur. Ama işin özü olan, rakiplerinden ayrıştığın yazılımı SaaS'a devredemezsin — zaten öyle bir ürün de yoktur.

    SaaS'ta ihmal edilen üç sorumluluk vardır ve üçü de senindir:

    1. Erişim yönetimi. Kimin hangi veriye erişebildiği, ayrılan çalışanın hesabının kapatılması, iki faktörlü doğrulamanın zorunlu kılınması.
    2. Veri ihracı. Hizmeti bırakmak istediğinde verini hangi formatta, ne kadar sürede alabileceğini önceden test etmek.
    3. Yedekleme. Sağlayıcının yedeği felaket kurtarma içindir; senin yanlışlıkla sildiğin veriyi geri getirme garantisi çoğu sözleşmede yoktur.

    Kurumsal e-posta gibi klasik SaaS ihtiyaçlarında hazır bir çözüm kullanmak istersen e-posta hizmetimiz bu işi üstlenir; kendi mail sunucunu kurmayı tercih edersen SMTP sunucu tarafı IaaS yaklaşımının karşılığıdır.

    Maliyet Eğrileri Nasıl Farklılaşır#

    Üç modelin maliyeti aynı hızda büyümez ve karar genellikle bu eğrilerin kesişme noktasında verilir. Kaba bir çerçeve:

    ÖlçekIaaSPaaSSaaS
    Çok küçük (tek geliştirici)Orta (emek maliyeti yüksek)DüşükDüşük
    Küçük – orta (birkaç sunucu)DüşükOrtaKullanıcı başına artar
    Büyük (onlarca sunucu)En düşük birim maliyetYüksekÇok yüksek
    Değişken / ani tepe yüküOrta (ölçekleme emeği)Düşükİlgisiz

    Bu tabloda görünmeyen ama en büyük kalem emek maliyetidir. IaaS'ın sunucu bedeli düşüktür ama bakımı bir insanın zamanını tüketir. Ayda 30 saatlik sistem yönetimi işini kendi zamanınla ölçtüğünde, PaaS'ın fiyat farkı çoğu küçük ekip için makul hale gelir. Tersine, ekibinde zaten sistem yöneticisi varsa IaaS'ın birim maliyeti karşılaştırılamayacak kadar düşüktür.

    Faturayı gerçekten neyin şişirdiğini görmek ve modeller arası karşılaştırmayı sağlıklı yapmak için bulut maliyeti hesaplama yazısındaki kalem listesini kullanabilirsin; özellikle çıkış trafiği ve depolama kalemlerini karşılaştırmaya dahil etmeyi unutma.

    Modelleri Birlikte Kullanmak ve Geçişler#

    Gerçek hayatta çoğu şirket üç modeli aynı anda kullanır ve bu doğru bir yaklaşımdır. Tipik bir dağılım şöyle görünür: e-posta ve muhasebe SaaS, ana uygulama IaaS üzerinde kendi sunucularında, yardımcı servisler (bildirim, arama, izleme) PaaS ya da yönetilen servis.

    Geçişlerin zorluğu yöne göre değişir. Aşağı doğru geçiş (SaaS'tan PaaS'a, PaaS'tan IaaS'a) genellikle zordur çünkü üst katmanın sağladığı işleri artık senin yapman gerekir. Yukarı doğru geçiş (IaaS'tan PaaS'a) daha kolaydır ama uygulamanın platformun beklediği yapıya uyması gerekir; durum tutan (stateful) bileşenler ve yerel dosya sistemine yazan kodlar en çok sorun çıkaran kısımlardır.

    Geçişi kolaylaştıran mimari alışkanlıklar şunlardır:

    1. Durumu dışarı taşı. Oturum bilgisi, yüklenen dosyalar ve önbellek uygulamanın diskinde durmasın.
    2. Yapılandırmayı ortam değişkeniyle ver. Sabit yollar ve gömülü kimlik bilgileri geçişin önündeki en büyük engeldir.
    3. Bağımlılıkları açıkça listele. Konteyner imajı ya da paket manifestosu, "hangi sürüm nerede çalışıyordu" sorusunu ortadan kaldırır.
    4. Veri ihracını periyodik test et. Yıllık bir tatbikat, gerçek geçiş gününde saatler kazandırır.

    Konteynerleştirme bu dört maddenin çoğunu kendiliğinden çözdüğü için, model bağımsız kalmanın en pratik yolu genellikle uygulamayı konteyner olarak paketlemektir.

    Sık Yapılan Hatalar ve Tuzaklar#

    En yaygın hata, modeli maliyetten önce sorumlulukla değerlendirmemek. IaaS'ı ucuz diye seçip aylarca güvenlik güncellemesi geçmeyen bir sunucu bırakmak, hem ucuz değildir hem de risklidir. Sunucunun bakımını üstlenecek biri yoksa ya yönetilen bir hizmet al ya da IaaS'ı sunucu yönetimi desteğiyle birlikte al.

    İkinci hata, PaaS maliyetini ilk aya bakarak değerlendirmek. Başlangıç fiyatları düşüktür; asıl fatura trafik büyüdüğünde ortaya çıkar. Karar vermeden önce, hedeflediğin trafiğin iki katı için fiyat hesabı yap ve aynı yükü IaaS üzerinde kaç sunucuyla karşılayacağını da hesapla.

    Üçüncü tuzak, SaaS'ta yedeklemeyi sağlayıcıya devredildi sanmak. Yanlışlıkla silinen bir kayıt ya da bir hesabın ele geçirilmesi sonucu bozulan veri, sağlayıcının felaket kurtarma yedeğiyle geri gelmez. Kritik SaaS verilerini düzenli olarak dışarı aktarıp kendi arşivinde tut.

    Dördüncü hata, karma yapıda kimlik ve erişimi dağınık bırakmak. Üç modelde de çalışan hesapları, API anahtarları ve yetkiler ayrı ayrı yönetiliyorsa, ayrılan bir çalışanın erişimini tamamen kapatmak imkânsız hale gelir. Merkezî bir erişim envanteri tutmak, en az teknik önlemler kadar önemlidir. Anahtar ve parolaların üretimi için şifre üretici gibi araçlar işini kolaylaştırır ama envanteri tutmak yine senin işindir.

    Sıkça Sorulan Sorular#

    IaaS ile PaaS arasındaki sınır tam olarak nerede#

    Sınır, işletim sistemi ve çalışma zamanının kimin sorumluluğunda olduğu noktasındadır. Sunucuya SSH ile bağlanıp paket kurabiliyor, kernel parametresi değiştirebiliyorsan IaaS'tasın. Yalnızca kodunu ve yapılandırmanı gönderiyor, altındaki işletim sistemine hiç dokunmuyorsan PaaS'tasın. Bazı ürünler ikisinin arasında konumlanır; belirleyici soru "işletim sistemi güncellemesini kim yapıyor" sorusudur.

    Küçük bir işletme için hangisi daha mantıklı#

    Ekipte sistem yönetimi yapabilecek biri yoksa, ana işiniz olmayan her şey için SaaS ve PaaS genellikle daha doğrudur. E-posta, muhasebe ve dosya paylaşımı gibi standart ihtiyaçları hazır hizmetlerle çözüp, yalnızca kendi ürününüzü barındıran katmanda IaaS kullanmak yaygın ve sağlıklı bir dengedir. Sunucu yönetimi desteği alarak IaaS'ın esnekliğini bakım yükü olmadan kullanmak da mümkündür.

    SaaS kullanırken verilerim gerçekten kimin#

    Sözleşmede aksi yazmıyorsa veriler sana aittir, ancak fiziksel olarak sağlayıcının sistemlerinde durur. Önemli olan üç madde vardır: verinin hangi ülkede saklandığı, hizmeti bıraktığında hangi formatta ve ne sürede dışa aktarabileceğin, sağlayıcı personelinin erişim politikası. Bu maddeleri sözleşmede yazılı görmeden hassas veri taşımamalısın; ihracı yılda bir kez test etmek de iyi bir alışkanlıktır.

    PaaS'tan IaaS'a geçiş ne kadar zordur#

    Uygulamanın platforma ne kadar bağlandığına göre değişir. Ortam değişkenleriyle yapılandırılan, durumu dışarıda tutan ve standart bir çalışma zamanı kullanan bir uygulamanın taşınması birkaç gün sürer. Platformun kendine özgü veritabanı, kuyruk ve kimlik doğrulama servislerini kullanan bir uygulamada ise her servis için bir karşılık bulmak ve veri taşımak gerekir; bu haftalara yayılabilir. Konteynerleştirilmiş uygulamalar en kolay taşınanlardır.

    Yönetilen hizmet ile PaaS aynı şey mi#

    Tam olarak değil ama akrabadırlar. Yönetilen hizmet, belirli bir bileşenin (örneğin veritabanı ya da önbellek) işletiminin sağlayıcıya devredilmesidir; sen yine kendi sunucularını yönetiyor olabilirsin. PaaS ise uygulamanın tamamının çalıştığı bir platform sunar. Pratikte birçok ekip IaaS üzerinde çalışıp yalnızca veritabanı gibi kritik bileşenler için yönetilen hizmet alır ve bu melez yaklaşım iyi sonuç verir.

    Bulut hizmet modeli seçimi güvenliği nasıl etkiler#

    Modelin kendisi güvenli ya da güvensiz değildir; sorumluluk dağılımını değiştirir. IaaS'ta işletim sistemi yamaları, güvenlik duvarı ve servis sertleştirmesi tamamen sende olduğu için ihmal riski yüksektir. PaaS ve SaaS'ta bu katmanlar sağlayıcıdadır ama erişim yetkileri, parola politikası ve veri paylaşım ayarları hâlâ senin sorumluluğundadır. İstatistiksel olarak en sık görülen ihlal nedeni her üç modelde de yanlış yapılandırmadır.

    Kapanış#

    IaaS, PaaS ve SaaS arasındaki fark teknoloji değil sorumluluk sınırıdır: ne kadar yukarı çıkarsan o kadar az yönetir, o kadar az özgürlük ve genellikle o kadar yüksek birim maliyetle çalışırsın. Karar verirken aklında tutman gereken dört alışkanlık şunlar — modeli emek maliyetiyle birlikte hesapla, veri sorumluluğunun her üç modelde de sende olduğunu unutma, uygulamayı taşınabilir tutacak mimari kuralları baştan uygula ve veri ihracını düzenli olarak test et.

    Tam kontrol isteyip altyapıyı kendin kurmak istiyorsan sanal sunucu ve VDS paketlerimiz IaaS tarafındaki doğru başlangıçtır; esnek ölçeklenme arıyorsan bulut sunucu seçeneğine bakabilirsin. Sunucu bakımını üstlenmek istemiyorsan sunucu yönetimi hizmetimiz IaaS'ı yönetilen bir modele dönüştürür, e-posta gibi standart ihtiyaçları hazır çözmek istersen e-posta hizmetimiz işini görür.

    BulutIaaSSaaS

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.