Bulut Sunucu Nedir? Cloud Server Rehberi, Fiyatları ve Satın Alma 2026

Bulut sunucu (İngilizcesiyle cloud server) terimi son on yılda hosting pazarının dilini değiştirdi. Eskiden "sanal sunucu" denilen şey artık "bulut sunucu" olarak satılıyor; "adanmış sunucu" segmenti ise giderek bare-metal cloud şeklinde paketleniyor. Pazarlama dili karışsa da temel teknik fikir net: fiziksel donanımdan soyutlanmış, hipervizör veya konteyner orkestratörü üzerinde çalışan, API ile yönetilebilen ve dakikalar içinde devreye alınıp ölçeklenebilen bir sunucu. Bu rehberde bulut sunucu mimarisini, sanallaştırma katmanlarını, fiyatlandırma modellerini, performans karakteristiklerini, satın alma kriterlerini ve gerçek hayatta karşılaşacağınız tuzakları tek bir yazıda topladık.

Cloud server pazarı 2026 itibarıyla iki ekstrem arasında salınıyor: bir tarafta hyperscaler'lar (AWS EC2, Azure VM, GCP Compute Engine, OCI) — saniye bazlı faturalama, yüzlerce instance tipi, derin servis kataloğu; diğer tarafta yerel sağlayıcılar — Türkiye lokasyonu, KDV dahil sabit fiyat, Türkçe destek. Hangisinin sizin için doğru olduğu sadece fiyata değil; latency profiline, uyumluluk gereksinimlerine, ekibinizin DevOps olgunluğuna ve iş yükünüzün öngörülebilirliğine bağlı. Aşağıda her birini sırayla ele alıyoruz.

İlgili rehberler: VPS nedir, VDS ile farkı · Hosting türleri ve seçim rehberi · Linux sunucu yönetimi temelleri · VPS güvenlik sertleştirme · Terraform ile IaC · Docker ile uygulama deploy

Bulut Sunucu Nedir? Net Bir Tanım

Cloud server, fiziksel bir host node'un (genellikle Intel Xeon Scalable veya AMD EPYC tabanlı, 256-2048 GB RAM, NVMe storage taşıyan dual-socket sunucu) üzerinde çalışan bir hipervizör tarafından kiracılara sunulan sanal makinedir. Kiracı için sanal makine; kendi ağ arayüzü, kendi blok cihazı, kendi RAM ve vCPU paylaşımı bulunan bağımsız bir Linux/Windows sunucusu gibi görünür. Fakat aynı host üzerinde başka müşterilerin VM'leri de paralel çalışır — buna multi-tenancy denir.

"Bulut" sıfatını klasik VPS'ten ayıran üç özellik vardır: (1) API ile temin — bir HTTP çağrısıyla 30 saniyede yeni sunucu doğurabilirsiniz; (2) elastiklik — vCPU/RAM/disk değerlerini downtime olmadan veya kısa bir reboot ile değiştirebilirsiniz; (3) kullanım bazlı faturalama — saatlik veya saniyelik granularite ile sadece kullandığınız kadar ödersiniz. Eski tip VPS'ler genellikle aylık sabit ücretlidir ve kaynak değişikliği için manuel ticket açmak gerekir.

Türkçe pazarda cloud sunucu, bulut server, cloud server ve bulut sunucu ifadeleri pratikte aynı şeyi anlatır; bunlar VPS kavramının olgunlaşmış, API-ile-yönetilebilen ve ölçeklenebilen bir üst kategorisidir. Adanmış (dedicated) sunucudan farkı; donanımı tek başınıza değil, paylaşımlı bir kümede tüketmenizdir.

Klasik VPS, Bulut Sunucu ve Adanmış Sunucu: Spektrumun Üç Ucu

İhtiyaç matrisinizi netleştirmek için üç tipi yan yana koymak gerekir. Aşağıda gerçek çalıştığımız iş yüklerinden çıkardığımız pratik karşılaştırma var:

• Klasik VPS: Sabit aylık ücret, OpenVZ/KVM, manuel resize, çoğunlukla SSD, statik IP. Tipik fiyat 200-1500 TL/ay. Küçük site, hobi projesi, sade WordPress için ideal.
• Bulut sunucu (cloud server): KVM/Xen/Hyper-V, NVMe veya distributed block storage, API/portal üzerinden self-service, snapshot, otomatik yedek, esnek faturalama. Tipik fiyat 1 vCPU/2 GB RAM için 250-450 TL/ay (yaklaşık, sağlayıcıya göre değişir, 2026 verisi).
• Adanmış (bare-metal) sunucu: Tek bir fiziksel makine size kiralanır. Hipervizör overhead'i yok, NUMA topolojisi sizindir. CPU-bound iş yükleri, büyük veritabanları, lisans gerektiren kurumsal yazılımlar için. Aylık 2500-25000 TL aralığı (yaklaşık, 2026 verisi).

Bulut Sunucu Mimarisi: Hipervizörden Network'e

Sunucu seçerken sorulması gereken ilk soru "hangi katman yeterli?" değil, "iş yükümün şekli ne?"dir. CPU steal time'a duyarlı (gerçek-zamanlı analiz, oyun sunucusu) veya disk IOPS'una duyarlı (transactional veritabanı) iş yükleri için bulut sunucu yeterliyken, ML eğitimi veya 100+ vCPU gerektiren analitikler için bare-metal'a kayar. Bulut sunucunun arkasındaki yığını dört katmanda incelemek mantıklıdır: donanım, hipervizör, sanal cihazlar ve orkestrasyon kontrol düzlemi. Her katmanın kendi performans imzası, kendi tipik arızası vardır. Daha derin VPS özelinde tartışmayı VPS rehberinde bulabilirsiniz.

Hipervizör Tipleri: Type 1 ve Type 2

Type 1 hipervizörler doğrudan donanım üzerinde çalışır — KVM (Linux çekirdeğine entegre), Xen, VMware ESXi, Microsoft Hyper-V Server bu kategoridedir. Bare-metal'a yakın performans, düşük overhead. Type 2 hipervizörler bir host işletim sistemi üzerinde çalışır (VirtualBox, VMware Workstation) — geliştirici masaüstü için uygun, üretim bulut sunucusu için neredeyse hiç kullanılmaz.

Türkiye'deki hosting pazarında baskın hipervizör KVM'dir. Açık kaynak olması, virtio paravirtual sürücülerinin olgun olması ve QEMU üzerinden geniş bir araç ekosistemi sunması nedeniyle pazarın %70+'ı KVM üzerinden hizmet verir. Hyperscaler'larda ise özelleşmiş türevler kullanılır: AWS Nitro (KVM tabanlı + Nitro hardware offload), Azure Hyper-V, GCP gVisor + KVM. Sunucunuzun hangi hipervizörde çalıştığını saniyeler içinde tespit edebilirsiniz:

Sanal CPU (vCPU): Çekirdek mi, Thread mi?

vCPU terimi yanıltıcıdır. Çoğu sağlayıcıda 1 vCPU = 1 hyper-thread'tir, fiziksel çekirdek değil. Yani "4 vCPU" sattığınızda altta 2 fiziksel çekirdek var olabilir. Intel Xeon ve AMD EPYC'nin SMT (simultaneous multi-threading) açıkken bir core iki hyper-thread görevi paralel çalıştırabilir; ama bunların performansı toplamda 1 core'un yaklaşık %1.3-1.7 katıdır, 2 katı değil.

Bazı premium sağlayıcılar (AWS dedicated tenancy, GCP sole-tenant, Hetzner CCX serisi) dedicated vCPU garantisi verir. Bu durumda vCPU sizin VM'inize tahsis edilmiştir; başka kiracıdan steal time kapmazsınız. Shared vCPU modellerinde host yüklendikçe sizin %iowait ve %steal değerleriniz artabilir.

Sanal Disk: virtio-blk, virtio-scsi, NVMe Passthrough

Steal time sürekli %5'i aşıyorsa host node aşırı abone edilmiş demektir; sağlayıcıyla ticket açın veya farklı bir paket/lokasyona migrate edin. Performansın bir diğer gizli düşmanı diskdir. Modern bulut sunucularda üç tip disk arayüzü görürsünüz: virtio-blk (klasik blok cihaz, basit ve hızlı), virtio-scsi (SCSI komutlarının tamamı, multipath ve discard desteği) ve NVMe (gerçek veya emulated; en düşük gecikme, en yüksek queue depth). Storage backend'i de en az arayüz kadar önemlidir: Local NVMe (host'a fiziksel takılı) en hızlısıdır, IOPS milyonlara çıkar; ama host arızasında veriniz risk altındadır. Distributed block storage (Ceph RBD, Linstor, AWS EBS, GCP PD) replikalı ve dayanıklıdır; gecikme tipik 0.5-3 ms aralığındadır. SAN tabanlı kurumsal storage (NetApp, Dell EMC) yüksek SLA sunar ama maliyetli.

Sanal Network: virtio-net, SR-IOV, DPDK

Tipik aralıklar: orta-segment bir bulut sunucu için 4K random read 30.000-100.000 IOPS, latency 0.2-0.5 ms beklenir. Altındaysanız ya host disk darboğazında ya da QoS ile boğuluyorsunuz. Network arayüzü de hipervizörden geçtiği için pakettleme overhead'i yaratır. virtio-net standart paravirtual NIC'tir; modern host'larda 5-10 Gbit pratik throughput verir. Yüksek paket-rate gereken durumlar için SR-IOV (fiziksel NIC'in sanal fonksiyonunu doğrudan VM'e bağlar) veya DPDK (kullanıcı-uzayında pakettleme, kernel bypass) kullanılır. Çoğu sağlayıcı kiracı başına egress trafiği faturalar (özellikle hyperscaler'lar); Türkiye'deki yerel sağlayıcılar genellikle "sınırsız trafik" sunar fakat fair-use politikası ile aylık 5-50 TB üzeri kullanımı kısıtlayabilir.

Bulut Sunucu Hizmet Modelleri: IaaS, PaaS, FaaS

Bulut sunucu satın alırken ne kadar yönetimi siz, ne kadarını sağlayıcı üstleniyor diye sınıflandırılır. NIST SP 800-145 standardı üç temel servis modelini tanımlar.

• IaaS (Infrastructure as a Service): Sağlayıcı sadece sanal donanımı sunar — VM, blok storage, sanal network, load balancer. İşletim sistemi, paket güncellemesi, uygulama, güvenlik tamamen size aittir. AWS EC2, Azure VM, GCP CE, Hetzner Cloud, Linode, DigitalOcean Droplet bu kategoride.
• PaaS (Platform as a Service): Sağlayıcı işletim sistemi ve runtime'ı yönetir; siz sadece kod ve config sağlarsınız. Heroku, Vercel, Render, AWS Elastic Beanstalk, Google App Engine örnekleri.
• FaaS (Function as a Service / Serverless): Bireysel fonksiyonlar, olay tetikleyicili çalışır; sunucu yönetimi tamamen soyutlanmıştır. AWS Lambda, Cloudflare Workers, Azure Functions, GCP Cloud Functions.
• BaaS (Backend as a Service): Database + auth + storage + functions paketi. Firebase, Supabase, Appwrite gibi platformlar bu kategoride.

Public, Private, Hybrid ve Multi-Cloud

"Bulut sunucu" terimi kesinlikle IaaS'a karşılık gelir. PaaS/FaaS'ta sunucu kavramı saklanmıştır — siz container, fonksiyon veya app yüklersiniz. IaaS, kontrol/sorumluluk dengesinin en aşağıda olduğu seçenektir; ne kadar Linux yönetebildiğinizle doğru orantılı uygundur (Linux sunucu yönetimi temelleri iyi bir başlangıç). Sunum modelinin yanında dağıtım (deployment) modelleri de farklılaşır; çoğunlukla şirketinizin uyumluluk gereksinimi (KVKK, ISO 27001, PCI-DSS) ayrımı zorunlu kılar.

• Public cloud: Sağlayıcının paylaşımlı altyapısında, multi-tenant. En düşük maliyet, en yüksek elastiklik. Çoğu uygulama için varsayılan tercih.
• Private cloud: Tek müşteriye adanmış altyapı (genellikle on-premise veya colocation). Yüksek uyumluluk gereksinimleri, hassas veriler için. OpenStack, VMware vSphere, Proxmox VE ile inşa edilir.
• Hybrid cloud: Public + Private karması. Stable yükler private'da, yük artışı (burst) public'a. VPN veya Direct Connect ile bağlanır.
• Multi-cloud: Birden fazla public cloud sağlayıcısının (örn. AWS + GCP) paralel kullanımı. Vendor lock-in riskini azaltır, bölgesel SLA çeşitliliği sağlar — ama operasyonel karmaşıklık 2-3x artar.

KOBİ ve orta-büyüklükte uygulamalar için public cloud yeterlidir. Private/hybrid'i sadece yasal zorunluluk veya 100+ kişilik ekipte gerekçeli karar olarak değerlendirin. Terraform ile birden fazla bulut sağlayıcısını ortak şekilde yönetebilirsiniz.

Bulut Sunucu Fiyatları: Ne Ödüyorsunuz?

Bulut sunucu fiyatları dört bileşenden oluşur ve her biri ayrı pazarda hareket eder: hesaplama (vCPU+RAM), blok storage, ağ trafiği ve ek hizmetler (load balancer, snapshot, yedek). Fiyat karşılaştırması yaparken bu dört kalemi ayrı ayrı sorgulamak gerekir.

2026 Türkiye Pazar Aralıkları

Aşağıdaki rakamlar yaklaşık değerlerdir, sağlayıcıya, sözleşme süresine ve kampanyalara göre değişir; 2026 ilk yarısı orta-segment Türk pazar verisidir.

• 1 vCPU / 2 GB RAM / 40 GB NVMe: 250-450 TL/ay (yaklaşık)
• 2 vCPU / 4 GB RAM / 80 GB NVMe: 450-850 TL/ay (yaklaşık)
• 4 vCPU / 8 GB RAM / 160 GB NVMe: 850-1.700 TL/ay (yaklaşık)
• 8 vCPU / 16 GB RAM / 320 GB NVMe: 1.700-3.400 TL/ay (yaklaşık)
• 16 vCPU / 64 GB RAM / 1 TB NVMe: 5.000-12.000 TL/ay (yaklaşık)
• Ek IPv4: 30-90 TL/ay (yaklaşık)
• Snapshot/backup: Genellikle disk boyutunun %20-30'u oranında ek ücret
• Windows lisansı: 150-450 TL/ay/sunucu (Standard ed.)

Faturalama Modelleri

Hyperscaler'lar (AWS, Azure, GCP) için fiyatlar genellikle dolarlıdır ve saatlik faturalanır. Eşdeğer bir t3.medium (2 vCPU/4 GB) on-demand instance ay sonunda yaklaşık 30-35 USD'ye gelir; reserved instance veya savings plan ile %30-72 indirim mümkündür ama 1-3 yıllık taahhüt gerektirir.

• On-demand / saatlik: Yarattığınız andan kapattığınız ana kadar saatlik (veya saniyelik) fatura. Test, geliştirme, kısa süreli batch işler için.
• Aylık sabit ücret: Türk pazarındaki yaygın model. Yıllık ödemede ek %10-25 indirim sıktır.
• Reserved instance / sözleşmeli: 1-3 yıllık taahhüt karşılığı %30-72 indirim. Stabil yükler için.
• Spot / preemptible: Sağlayıcının fazla kapasitesi indirimli kullanılır; her an sonlandırılabilir. Stateless batch, ML eğitimi için.
• Bring-your-own-license (BYOL): Windows, MS SQL, Oracle gibi lisansları kendi sözleşmenizden getirebilirsiniz.

Bulut Sunucu Satın Alma: Adım Adım Kontrol Listesi

Hosting bütçenizi sağlam tutmak için ay sonu Surprise Bill (sürpriz fatura) tuzağına dikkat edin: hyperscaler'larda bandwidth egress, NAT gateway saatleri, snapshot retention ve CloudWatch/Stackdriver log yutulması ay sonu hesabınızı 2-3 katına çıkarabilir; aylık budget alert ve cost anomaly detection kurmayı ihmal etmeyin. Bulut sunucu satın alırken "en ucuzunu seç" yaklaşımı 3 ay içinde fatura olarak geri gelir: yetersiz IOPS, yetersiz network, sürekli reboot, yetersiz destek. Aşağıdaki kontrol listesi yıllardır onboarding'lerde damıtılmıştır.

• İş yükü profili: CPU-bound mu, disk-bound mu, network-bound mu, RAM-bound mu? Profil bilinmeden vCPU/RAM/IOPS oranı seçilmez.
• Lokasyon: Kullanıcılarınız nerede? Türkiye trafiği için Türkiye lokasyonu (İstanbul, Ankara, İzmir) ~10 ms RTT'de kalır; Almanya/Hollanda'dan ~40-60 ms, ABD'den ~150 ms'tir.
• Sanallaştırma: KVM tercih edilir. OpenVZ konteyner tabanlı olduğu için kernel paylaşır — bazı modüller (XFS quota, custom kernel) çalışmaz.
• Disk tipi: NVMe veya en kötü ihtimalle enterprise SSD. Spinning disk 2026'da kabul edilemez.
• RAM oranı: Genel kural: 1 vCPU başına 2-4 GB RAM. Veritabanı için 1:8'e çıkabilir.
• Network throughput: 1 Gbit minimum; ciddi yükler için 5+ Gbit. Burst limiti olup olmadığını sorun.
• SLA: %99.9 yıllık ~8.7 saat kesinti, %99.95 ~4.4 saat, %99.99 ~52 dakika kesinti demektir. Critical iş yükleri için en az %99.95.
• Yedekleme politikası: Otomatik mi? Hangi sıklıkta? Off-host saklanıyor mu? Kaç gün retention? Restore prosedürünü test ettiniz mi?
• DDoS koruması: Volumetric DDoS karşı L3/L4 koruma fiyata dahil mi? Kapasite (Gbps) nedir?
• API/CLI desteği: Self-service var mı? Terraform provider mevcut mu? Snapshot otomasyonu var mı?
• Destek: Türkçe destek, telefon mu sadece ticket mı? Yanıt SLA'i ne (15 dk, 1 saat, 24 saat)?
• Çıkış stratejisi: Vendor lock-in riski ne? Image export, IP taşıma, DNS migration ne kadar sürer?

Bulut Sunucu Kiralama Süreci ve Sözleşme

Bulut sunucu kiralama sözleşmesi imzalamadan önce dikkat edilmesi gereken üç madde: SLA tanımı, çıkış prosedürü ve veri sahipliği. SLA'da "%99.9 uptime" yazıyorsa kesintinin nasıl ölçüldüğünü, hangi durumların hariç tutulduğunu ve kredilendirmenin nasıl yapıldığını kontrat metninde bulun. Kiralama tipik akışı: (1) sağlayıcının portalında hesap aç + KVKK onayı, (2) ödeme yöntemi ekle, (3) paket-lokasyon-OS image seç, (4) SSH key veya başlangıç parolası belirle, (5) deploy butonu — 30-90 saniye içinde sunucu hazır, IP ve SSH credentials e-posta ile gelir, (6) ilk girişte güvenlik sertleştirmesi (firewall, fail2ban, key-based auth).

Bu temel sertleştirmeyi her yeni sunucuda mutlaka yapın. Daha kapsamlı bir kontrol listesi VPS güvenlik sertleştirme rehberinde ve SSH özelinde Fail2ban kurulum yazısında mevcut.

Otomasyon: Terraform ile Bulut Sunucu Yönetimi

Manuel portal tıklamaları üç sunucuda eğlencelidir, otuz sunucuda işkencedir. Bulut sunucu yönetimini olgun bir noktaya taşımak için Infrastructure as Code (IaC) uygulamak gerekir. Pazar lideri Terraform; Pulumi, OpenTofu (Terraform fork'u) ve Ansible alternatifleridir.

terraform plan ve terraform apply ile bu manifest dakikalar içinde 3 web sunucu + bir load balancer kurar. Aynı kod tekrar çalıştırıldığında değişiklik yapmaz (idempotent); değişiklikler diff olarak gösterilir. Bütünüyle Terraform IaC rehberinde ele alıyoruz. Cloud-init dosyası ile sunucu açılır açılmaz paket kurulumu, kullanıcı oluşturma, SSH key dağıtımı ve firewall ayarları otomatik uygulanır:

Ölçeklenme: Vertical, Horizontal ve Auto-Scaling

Bulut sunucunun esas vaadi elastikliktir. Üç ölçeklenme stratejisini ihtiyacınıza göre kombinleyebilirsiniz.

• Vertical scaling (scale up): Aynı sunucuya daha fazla vCPU/RAM/disk ekleme. Genelde kısa bir reboot gerektirir. Stateful (DB, Redis) yükler için pratiktir. Sınır donanım sınırıdır.
• Horizontal scaling (scale out): Daha fazla sunucu eklemek. Stateless web/api yükleri için ideal. Load balancer ve session externalization gerektirir.
• Auto-scaling: CPU/RAM/queue depth metriklerine göre instance sayısını otomatik artırma/azaltma. AWS Auto Scaling Group, GCP MIG, Azure VMSS, Hetzner ile manuel cron, hosting'de yaygın değil ama hyperscaler'larda standarttır.

Container ve Bulut Sunucu: Docker ile Birlikte

Pratik tavsiye: yeni bir uygulamayı 2 küçük sunucu + load balancer ile başlatın. 1 sunucu down olursa diğeri trafiği üstlenir; aynı zamanda blue/green deploy yapabilirsiniz (Node.js cluster ve PM2 tek-makinada paralel çalıştırmanın iyi bir başlangıcıdır). Modern üretim deploy'larında bulut sunucu artık "OS yükleyip uygulama kuruyorum" yerine "OS yükleyip Docker engine'ini koşturuyorum" şekline kayar. Konteynerleştirme (Docker, Podman, containerd) reproducible build, hızlı rollout ve resource isolation sağlar (Docker ile uygulama deploy derinlemesine kaynak).

Tek bulut sunucuda Docker Compose ile 5-10 servis koşturmak mümkündür. Daha büyük ölçekte Kubernetes veya managed alternatifleri (EKS, GKE, AKS) devreye girer. Docker Compose rehberi üretim setup'ı için derinlemesine kaynak.

İşletim Sistemi Seçimi: Linux Dağıtımları ve Windows

Çoğu bulut sunucu sağlayıcısı standart image olarak şu OS'leri sunar: Ubuntu LTS (22.04 / 24.04), Debian (12 Bookworm / 13 Trixie), AlmaLinux 9 ve Rocky Linux 9 (CentOS halefleri), RHEL, Fedora Server, openSUSE, Windows Server 2019/2022. Hangisini seçmelisiniz?

• Ubuntu LTS: En geniş topluluk, snap/apt ile bol paket. Yeni başlayanlar ve docker-heavy yükler için varsayılan.
• Debian: Stabil, az şişirilmiş, paket havuzu temiz. Uzun ömürlü production için ideal.
• AlmaLinux / Rocky: RHEL bineriyle uyumlu. SELinux varsayılan açık, kurumsal yazılımlar (Oracle, SAP) RHEL ailesinde daha rahat çalışır.
• Windows Server:.NET Framework, MSSQL, AD, IIS bağımlılığı varsa zorunlu. Ek lisans maliyeti aylık 150-450 TL.

Performans İzleme ve Sürekli Görünürlük

Hangi dağıtımı seçerseniz seçin, image versiyonunun aktif destek periyodunda olduğundan emin olun. Ubuntu 18.04, CentOS 7, Debian 10 gibi EOL sürümlerle 2026'da yeni sunucu kurmayın — güvenlik patch'i alamazsınız. Bulut sunucu kurulduktan sonra "çalıştı, geçtim" tutumu üretimde maliyetlidir; üç katmanda izleme şarttır: sistem metrikleri (CPU/RAM/disk/net), uygulama metrikleri (request rate, latency, error rate, queue depth) ve log toplama (structured logs).

Kalıcı izleme için Prometheus + Grafana stack'i kurmak hayatı kolaylaştırır: node_exporter ile sistem metrikleri, blackbox_exporter ile uptime probe, application instrumentation ile uygulama metrikleri tek panelde toplanır. Log tarafı için ELK Stack veya daha hafif Grafana Loki tavsiye edilir.

Yedekleme ve Felaket Kurtarma

Yedeği olmayan veri sahibi değil, mülki kaybetmek üzere olan kişidir. Bulut sağlayıcılarının çoğu otomatik snapshot sunar; ama snapshot tek başına yeterli değildir.

• 3-2-1 kuralı: 3 kopya, 2 farklı medyada, 1'i off-site. Bulut snapshot'ı genelde aynı bölgede kalır — ek olarak farklı bölge/sağlayıcıya off-site yedek alın.
• RPO (Recovery Point Objective): Kaç dakika veri kaybını tolere edebilirsiniz? E-ticaret için tipik 5-15 dk, statik blog için 24 saat.
• RTO (Recovery Time Objective): Kesintiden ne kadar sürede ayağa kalkmanız gerekiyor? Critical SaaS için <1 saat, internal tool için 24 saat.
• Disaster recovery testi: Restore prosedürünü en az çeyrekte bir test edin. Test edilmemiş yedek = yedek değil.
• Off-host yedek: S3, Backblaze B2, Wasabi gibi object storage'a şifreli yedek alın (örn. restic, borg, duplicity).
• Versiyonlama: Sadece son yedek değil; 7 gün, 4 hafta, 12 ay retention.

Veritabanı yedekleme stratejisi konusunda 3-2-1 kuralı, full/incremental ve PITR rehberini mutlaka okuyun — bulut sunucu üzerinde DB tutuyorsanız vazgeçilmezdir.

Güvenlik: Bulut Sunucuda Tehdit Modeli

Bulut sunucu kurulduğu anda halka açık IP üzerinden internete bağlıdır. İlk 24 saatte SSH brute-force, web exploit scan, port scan, mail relay denemesi gibi binlerce isteği görürsünüz. Tehdit modeli üç katmanlıdır: ağ, OS, uygulama.

• Ağ: Cloud security group / firewall ile sadece gerekli port'ları açın. SSH için 22 yerine yüksek bir port + sadece bilinen IP'lere izin idealdir. DDoS koruma için Cloudflare proxy + sağlayıcı L3/L4 koruması katmanlı kullanılmalı.
• OS: Otomatik güvenlik güncellemesi (unattended-upgrades, dnf-automatic), SELinux/AppArmor enforcing modda, fail2ban SSH/web için. Auditd ile değişiklik denetimi.
• Uygulama: Reverse proxy arkasında çalıştır (nginx/caddy), TLS 1.3 zorunlu (HTTPS ve TLS 1.3 rehberi), rate limit (API rate limiting stratejileri), OWASP Top 10 kontrol listesi.
• Secret management:.env dosyası repo'ya commit'lenmemeli; HashiCorp Vault, AWS Secrets Manager, Doppler, sops + age kullanın.
• SSH key rotation: Çalışan ayrılığı veya şüpheli aktivite sonrası key'leri değiştirin.

Bulut Sunucu Lokasyonu ve Latency

Düzenli olarak lynis audit system çalıştırın — ücretsiz, hızlı, eyleme dönüştürülebilir öneriler verir. Ayrıca rkhunter veya chkrootkit ile rootkit taraması haftalık cron olarak ayarlanmalı. Türkiye'deki bir kullanıcının bulut sunucunuza gönderdiği TCP segment'i fiziksel olarak optik fiber üzerinden hareket eder; mesafe ne kadar uzaksa RTT (round-trip time) o kadar yüksektir. Tipik TCP RTT değerleri:

• İstanbul ↔ İstanbul: 1-5 ms
• İstanbul ↔ Ankara/İzmir: 8-15 ms
• İstanbul ↔ Frankfurt/Amsterdam: 35-55 ms
• İstanbul ↔ Helsinki/Stockholm: 50-70 ms
• İstanbul ↔ Virginia (ABD doğu): 130-160 ms
• İstanbul ↔ Singapur: 180-220 ms

HTTP/HTTPS bir sayfa yüklemesi tipik 5-15 round trip'tir (DNS, TCP handshake, TLS handshake, HTTP request, asset'ler); 100 ms'lik RTT sayfa yükleme süresine 500-1500 ms ekler. Türkiye trafiği ağırlıklı e-ticaret için Türkiye lokasyonu dönüşüm oranını doğrudan artırır. Latency'i kendiniz ölçmek için:

Network Topolojisi: VPC, Subnet, NAT, Load Balancer

Üretim ortamında tek bir public IP'li sunucu yeterli değildir. Sağlam bir bulut topolojisi şöyle görünür:

• VPC (Virtual Private Cloud): Sunucularınızın izole edildiği özel ağ. Hyperscaler'larda standart; yerel sağlayıcılar private network olarak sunar.
• Public subnet: Load balancer, NAT gateway, bastion host buradadır. Doğrudan internete bağlı.
• Private subnet: Web/app/db sunucuları buradadır. İnternete sadece NAT üzerinden çıkar; gelen trafiği yalnızca load balancer üzerinden alır.
• Bastion host (jump server): Private subnet'e SSH erişimi yalnızca bu adanmış host üzerinden. Loglanır, audit edilir.
• Load balancer: L4 (TCP, daha hızlı) veya L7 (HTTP, daha akıllı) — sağlık kontrolü, sticky session, TLS termination yapar.
• NAT gateway: Private subnet'in dışarı çıkışı. Hyperscaler'larda saatlik ücretli, yerel sağlayıcılarda fiyata dahil.

Bulut Sunucu Türkiye'de: Yerel Sağlayıcı mı, Hyperscaler mı?

Bu mimari ilk kurulumda fazla görünebilir; ama 5+ sunucuya çıktığınızda doğru yapı ile yanlış yapı arasındaki maliyet ve hata farkı 10x'tir (Nginx yapılandırma rehberi reverse proxy'yi self-managed kurmak isteyenler için yol gösterici). Türkiye'de bulut sunucu pazarı hızla büyüyor. Yerel datacenter işleten sağlayıcılar (İstanbul, Ankara, İzmir lokasyonları) ile global hyperscaler'lar (AWS Türkiye Local Zone yok ancak edge lokasyonu var; Azure ve GCP'nin Türkiye region'ı yok) arasında seçim yaparken şu kriterler belirleyici olmalıdır:

• KVKK ve veri lokalizasyonu: Kişisel verileri yurt dışında işliyorsanız aydınlatma yükümlülüğünüz farklılaşır. Bazı sektörler (sağlık, finans) yerel saklama zorunluluğu içerir.
• Türk Lirası faturalama: Yerel sağlayıcılar TL/KDV dahil sabit fiyat verir; hyperscaler'lar dolarlıdır, kur dalgalanması direkt size yansır.
• Latency: Türkiye'deki kullanıcılar için Türkiye lokasyonu kazanır.
• Servis genişliği: Hyperscaler'larda 200+ managed service (SQS, DynamoDB, Lambda, SageMaker...). Yerel sağlayıcılarda IaaS + temel managed DB/object storage tipiktir.
• Destek: Türkçe telefon desteği, KOBİ'ler için yerel sağlayıcının temel avantajı.
• Compliance: ISO 27001, ISO 27017, ISO 27018 sertifikaları kontrol edin. Hyperscaler'larda standart, yerel sağlayıcılarda farklılık gösterir.

Migration: Eski VPS'ten Bulut Sunucuya Taşınma

Pratik tavsiye: stable production yükleri için yerel sağlayıcı + Cloudflare CDN kombinasyonu çoğu KOBİ için yeterli ve maliyet-etkindir; hyperscaler'a geçiş çok bölgeli aktif-aktif mimari, derin managed servis bağımlılığı veya 100k+ MAU üzerinde anlamlı olur. Mevcut bir VPS'ten bulut sunucuya geçiş tipik şu adımları içerir: yeni sunucu provision, OS hazırlığı, uygulama deploy, veri sync, DNS cutover, eski sunucu çekimi. En kritik adım veri sync — büyük veritabanları için canlı replikasyon, küçük veriler için snapshot+rsync yeterli.

Maliyet Optimizasyonu: Bulut Sunucu Faturanızı Yarıya İndirin

Cutover öncesi mutlaka staging ortamında geçişi prova edin; mail server, cron job, SSL sertifikası, log rotation gibi kolay unutulanları kontrol listesine alın (Let's Encrypt SSL kurulumu yeni sunucuda HTTPS'i hızlı ayağa kaldırmak için pratik kaynak). Bulut harcaması büyüdükçe optimizasyonun ROI'si kartopu gibi büyür; aşağıdaki 12 madde sıkça gözden kaçan tasarruf alanlarıdır:

• Right-sizing: CloudWatch/Grafana'dan CPU/RAM ortalama kullanımını çıkarın. %30'un altında kullanılan instance bir tık küçültülmeli.
• Reserved instance / savings plan: Stable yükler için 1-3 yıllık taahhüt %30-72 indirim getirir.
• Spot instance: Stateless batch için %70-90 indirimli kapasite.
• Idle resource'leri kapatın: Geliştirme/test ortamlarını gece + hafta sonu kapatın, %60+ tasarruf.
• Snapshot retention politikası: Yıllık biriken snapshot'lar fatura yarısını yiyebilir. 30 gün üzeri otomatik silinmeli.
• Old AMI / image temizliği: Custom image'lar ücretlidir; aktif olmayanları silin.
• NAT Gateway maliyeti: AWS'da saatlik + GB başına ücret. Yüksek egress varsa NAT instance veya VPC endpoint düşünün.
• Egress traffic: CDN katmanı kullanın (Cloudflare, Bunny). Origin'in egress'i 1/10'a düşer.
• Object storage tier: Eski log'ları S3 Glacier'a, S3 Intelligent-Tiering'e taşıyın.
• Karmaşık paket optimizasyonu: ARM (Graviton, Ampere) instance'ları %20-40 daha ucuz; uyumlu yüklerde geçin.
• Container density: 8 vCPU bir instance'a 8 ufak app sığdırmak, 8 küçük instance'tan daha ucuzdur (paylaşılan OS overhead).
• FinOps panosu: Monthly cost report + anomaly alert + tag-bazlı cost allocation.

Sık Yapılan Hatalar

Hyperscaler'larda Compute Optimizer (AWS) veya Recommender (GCP) right-sizing önerilerini otomatik çıkarır. Yerel sağlayıcılarda manuel raporlama yapın; ay sonu üst-5 fatura kalemini incelemek bile büyük tasarruf çıkarır. Aşağıda ekiplerin sık tekrarladığı tuzaklar:

• Tek sunucuya bağımlılık: Tek instance'ta blog/api koşturup yedek almamak — donanım/host arızasında saatlerce kesinti.
• Public IP'de DB: PostgreSQL/MySQL port'unu (5432/3306) public'e açmak. Mutlaka VPC içinde, sadece app sunucudan erişilmeli.
• Default SSH portu + parola: 22 portu + parola login + zayıf parola = ilk 48 saatte compromise.
• Snapshot = yedek sanmak: Snapshot aynı bölgede tutulur. Region/zone arızasında kayıp.
• Auto-scaling'siz launch: Tek instance'ta deploy, trafik patladı, sunucu yatdı, müşteri kaybetti.
• NAT Gateway maliyetini görmezden gelmek: Ay sonu sürpriz $300 fatura — egress trafiği takip edilmemiş.
• Logsuz deploy: Application log'u yok, hata gerçekleşince hiçbir şey debuglanamıyor.
• HTTPS ihmal: Let's Encrypt ücretsizken HTTP'de bırakmak — SEO ve güvenlik kaybı.
• Tek bölgede DR: Yedek + DR'ı aynı sağlayıcıda aynı bölgede tutmak — provider-level outage olduğunda hiçbir şey çalışmaz.
• Ölçmeden optimize: CPU/RAM/IOPS metriği bilmeden "daha büyük instance al" demek — para harcamak, problemi çözmemek.

Karar Çerçevesi: Hangi Bulut Sunucu Sizin İçin Doğru?

Beş soruya cevap verin; bulut sunucu seçiminiz büyük ölçüde belirlenir.

• 1. Kullanıcılar nerede? Türkiye → yerel TR datacenter; Avrupa → Frankfurt/Amsterdam; ABD → Virginia/Oregon.
• 2. İş yükü stable mi, dalgalı mı? Stable → reserved/yıllık; dalgalı → on-demand + auto-scaling.
• 3. Compliance gereksinimleri var mı? KVKK + sektörel → ISO 27001 sertifikalı yerel sağlayıcı.
• 4. Ekibinizin DevOps olgunluğu ne? Düşük → managed PaaS; orta → IaaS + Terraform; yüksek → hyperscaler + Kubernetes.
• 5. Aylık tahmini bütçe? <2.000 TL → tek-sağlayıcı yerel paket; 2.000-50.000 TL → multi-region yerel + CDN; >50.000 TL → hyperscaler ile reserved kapasite.

Test ve Yük Provası

Bu beş soruya verilen cevaplar bir başlangıç noktasıdır; nihai karar üretim verisi (yük testi sonuçları, latency profili, fatura analizi) ile rafine edilmelidir. Üretime almadan önce sunucunun gerçek yüke nasıl davrandığını ölçmek gerekir. ab, wrk, k6, vegeta, locust popüler yük testi araçlarıdır; k6 JavaScript senaryosu yazabildiği için en esnek olanıdır.

İleri Konular: GPU, Edge ve Bare-Metal Cloud

Yük testini canlı production'a değil, üretim klonu staging'e uygulayın. Sonuçlardan p50/p95/p99 latency ve hata oranını çıkarın; üretime alınma kararını bu numaralara dayandırın (Playwright e2e testing işlevsel doğruluk için yük testini tamamlar). Standart bulut sunucunun ötesinde üç gelişen kategori öne çıkıyor:

• GPU instance'lar: NVIDIA A10/A100/H100 GPU'lu sunucular ML training/inference, video transcoding, scientific computing için. Saatlik 1-12 USD aralığında. Türkiye'de yerel GPU bulutu sınırlı, çoğunlukla AWS p4d/p5, GCP A3, Azure NCv4 üzerinden.
• Edge compute: Cloudflare Workers, Fastly Compute@Edge, AWS Lambda@Edge — kullanıcının coğrafi olarak yakınında çalışan kod. Statik personalization, A/B test, auth redirect için ideal.
• Bare-metal cloud: Adanmış sunucu + bulut API'si. AWS i4i.metal, Equinix Metal, Hetzner Bare-Metal. Hipervizör overhead'i yok ama API ile sağlanır. Yüksek-IOPS DB, lisans-bazlı yazılım için.
• Confidential computing: AMD SEV-SNP, Intel TDX, AWS Nitro Enclaves. Çalışan VM'in belleği bile host operatörüne kapalı; finans/sağlık sektörü için.

Kaynaklar

• NIST SP 800-145 — Cloud computing'in resmi tanımı
• linux-kvm.org — KVM resmi sayfası
• QEMU docs — Emülasyon ve sanallaştırma
• OpenStack docs — Açık kaynak özel bulut
• cloud-init.io — Cross-distro init standardı
• developer.hashicorp.com/terraform — Terraform docs
• restic.net — Backup aracı
• k6 docs — Yük testi
• CIS Benchmarks — OS sertleştirme rehberi
• OWASP — Web uygulama güvenliği
• prometheus.io — Monitoring
• grafana.com/docs — Görselleştirme

İlgili Yazılar

• VPS Nedir? VPS-VDS Farkı ve Kiralama Rehberi
• Hosting Nedir? Web Hosting Türleri ve Fiyatları
• Linux Sunucu Yönetimi Temelleri
• VPS Güvenlik Sertleştirme
• Terraform ile Infrastructure as Code
• Docker ile Uygulama Deploy
• Kubernetes Temelleri
• Prometheus ve Grafana ile Sunucu İzleme
• Veritabanı Yedekleme Stratejileri
• DDoS Koruma Rehberi