- 01Azure VM sizing yalnız vCPU ve RAM seçimi değildir; disk IOPS/throughput, network ve availability limitleri birlikte değerlendirilmelidir.
- 02VM family workload tipine göre seçilmeli ve karar gerçek p95/p99 metric'leriyle doğrulanmalıdır.
- 03Production availability için tek VM yeterli olmayabilir; çoklu Availability Zone veya uygun scale-out tasarımı değerlendirilmelidir.
- 04Managed disk seçimi workload'un IOPS, throughput, latency ve bütçe ihtiyacına göre yapılmalıdır.
- 05Rightsizing ve idle cleanup tamamlanmadan uzun süreli commitment satın almak gereksiz maliyeti kilitleyebilir.
Kısaca
Azure VM seçerken yalnız vCPU ve RAM'e bakmak production ortamı için yeterli değildir. Doğru sanal makine; CPU, memory, disk IOPS/throughput, network kapasitesi, availability, backup, monitoring ve maliyet birlikte değerlendirilerek seçilmelidir.
Dynamis Teknoloji'de Azure VM sizing sürecini önce workload davranışını ölçerek, sonra uygun VM family ve disk/network sınırlarını kontrol ederek yapıyoruz. Amaç en büyük VM'i seçmek değil, SLO'yu karşılayan en verimli production konfigürasyonunu bulmaktır.
Azure VM nedir?
Azure Virtual Machines, Windows veya Linux işletim sistemi çalıştırabileceğiniz IaaS sanal sunucu hizmetidir.
Azure VM üzerinde:
- web application
- API
- Windows business software
- database
- build server
- self-hosted application
- batch workload
çalıştırılabilir.
Ancak VM'in production'a hazır olması yalnız instance oluşturmakla tamamlanmaz.
Production tasarımında:
- size
- disk
- network
- availability
- security
- backup
- monitoring
birlikte planlanmalıdır.
Azure VM size neyi belirler?
VM size temel olarak şu limitleri etkiler:
- vCPU
- memory
- temporary storage
- max data disk
- disk IOPS/throughput limiti
- network bandwidth
- NIC sayısı
- bazı özelliklerin desteği
Bu nedenle aynı 4 vCPU / 16 GB RAM görünen iki farklı family aynı production davranışını vermeyebilir.
VM family nasıl seçilir?
Azure VM family'leri workload tipine göre ayrılır.
General purpose
CPU ve memory arasında dengeli kullanım için uygundur.
Örnek workload:
- web server
- API
- küçük/orta uygulama sunucusu
- domain controller
Compute optimized
CPU yoğun workload için uygundur.
Örnek:
- high-throughput API
- build/compile
- batch processing
- compute worker
Memory optimized
RAM yoğun workload için değerlendirilir.
Örnek:
- in-memory cache
- büyük database
- analytics
- memory-heavy application
Storage optimized
Yüksek disk throughput veya IOPS isteyen workload'lar için uygundur.
GPU
AI/ML, rendering veya GPU compute gerektiren workload'larda kullanılır.
İlk karar: workload profili
VM seçmeden önce şu soruları cevaplayın:
- CPU peak nedir?
- memory peak nedir?
- disk read/write IOPS nedir?
- throughput nedir?
- network throughput nedir?
- latency hassasiyeti var mı?
- burst mü sürekli yük mü?
- workload 7/24 mü çalışıyor?
Bu değerler olmadan sizing çoğu zaman tahmine dönüşür.
Ortalama yerine p95/p99 neden önemlidir?
Ortalama CPU %20 olabilir.
Ama her gün 10:00-12:00 arasında %95'e çıkıyorsa yalnız average üzerinden küçültme production problemi yaratabilir.
Bu nedenle:
- p50
- p95
- p99
- peak window
birlikte değerlendirilmelidir.
CPU-bound workload nasıl anlaşılır?
İşaretler:
- CPU sürekli yüksek
- request latency CPU ile birlikte artıyor
- disk/network normal
- queue backlog oluşuyor
Bu durumda:
- daha fazla vCPU
- compute optimized family
- scale-out
değerlendirilebilir.
Memory-bound workload nasıl anlaşılır?
İşaretler:
- available memory sürekli düşük
- swap/pagefile kullanımı
- frequent GC
- cache eviction
- OOM
Bu durumda memory optimized family veya application memory tuning değerlendirilebilir.
Disk performansı neden kritik?
Bir VM güçlü CPU/RAM'e sahip olabilir ancak disk limiti workload'u bottleneck edebilir.
Kontrol edin:
- IOPS
- throughput
- latency
- queue depth
- read/write ratio
Özellikle database ve log-heavy workload'larda disk seçimi VM size kadar kritiktir.
Azure Managed Disk seçenekleri
Yaygın disk tipleri:
- Standard HDD
- Standard SSD
- Premium SSD
- Premium SSD v2
- Ultra Disk
Her disk tipi:
- performans
- latency
- kapasite
- maliyet
trade-off'u sunar.
Production database için yalnız capacity GB'ına göre disk seçmek doğru değildir.
Premium SSD ne zaman gerekir?
Low-latency ve daha yüksek IOPS/throughput ihtiyacı olan production workload'larda değerlendirilir.
Örnek:
- SQL Server
- PostgreSQL
- transactional application
- busy application server
Ancak VM size'ın desteklediği disk limitleri ayrıca kontrol edilmelidir.
Premium SSD v2 ne zaman anlamlıdır?
IOPS, throughput ve capacity'nin daha bağımsız ayarlanabildiği workload'larda değerlendirilebilir.
Bu, disk performansını gereksiz capacity büyütmeden ayarlamayı kolaylaştırabilir.
Ultra Disk ne zaman kullanılır?
Çok yüksek IOPS/throughput ve düşük latency gerektiren belirli workload'lar için tasarlanmıştır.
Her workload için gerekli değildir.
Ultra Disk seçmeden önce:
- Region/zone desteği
- VM family desteği
- gerçek IOPS ihtiyacı
- bütçe
doğrulanmalıdır.
OS disk ile data disk ayrılmalı mı?
Production database veya yoğun I/O uygulamalarında data ve log workload'unu OS disk'ten ayırmak daha sağlıklı olabilir.
Avantaj:
- performans izolasyonu
- backup/restore kolaylığı
- disk tuning
- lifecycle ayrımı
sağlar.
Availability Zone nedir?
Availability Zone, aynı Azure Region içindeki fiziksel olarak ayrılmış zone'lardır.
Tek VM tek zone'da ise zone-level outage sırasında erişilemez olabilir.
Yüksek availability gereken workload'larda:
- birden fazla VM
- farklı Availability Zone
- load balancer
- database HA
birlikte tasarlanmalıdır.
Tek VM production için yeterli mi?
Bu iş gereksinimine bağlıdır.
Tek VM kabul edilebilir olabilir:
- non-critical application
- kısa downtime toleransı
- hızlı restore imkanı
varsa.
Ama kritik sistemlerde single VM:
- host failure
- zone failure
- maintenance
riskini artırır.
VM Scale Sets ne zaman kullanılmalı?
Horizontal scale gereken stateless veya benzeri workload'larda değerlendirilebilir.
Scale set ile:
- instance sayısı artırılabilir
- autoscale uygulanabilir
- zone dağılımı yapılabilir
Ancak stateful workload'larda application architecture ayrıca değerlendirilmelidir.
Azure Load Balancer veya Application Gateway?
Layer 4 trafik için Azure Load Balancer değerlendirilebilir.
HTTP/HTTPS application-level routing için Application Gateway veya Front Door gibi servisler değerlendirilebilir.
Karar:
- protocol
- TLS termination
- WAF
- global routing
- latency
ihtiyacına göre verilmelidir.
Accelerated Networking neden önemli olabilir?
Uygun VM size ve işletim sistemlerinde Accelerated Networking network latency ve jitter'ı azaltabilir ve throughput'u iyileştirebilir.
High-throughput veya latency-sensitive workload'larda destek durumu kontrol edilmelidir.
Network bandwidth sınırını unutmayın
Azure VM size'ların network throughput limitleri farklıdır.
Özellikle:
- file server
- media workload
- proxy
- VPN gateway benzeri self-hosted network application
senaryolarında CPU boş olsa bile network sınırına takılabilirsiniz.
Public IP gerekli mi?
Her VM'e public IP vermek iyi production pratiği değildir.
Alternatifler:
- Bastion
- VPN
- private endpoint
- jump host
- load balancer
olabilir.
Direct RDP/SSH public exposure mümkün olduğunca azaltılmalıdır.
NSG tasarımı
Network Security Group kuralları:
- least privilege
- source restriction
- required port only
mantığıyla uygulanmalıdır.
0.0.0.0/0 üzerinden yönetim portu açmak ciddi risk yaratır.
Windows VM için nelere dikkat edilmeli?
Windows workload'da ayrıca:
- licensing
- RDP access
- patching
- Defender
- domain join
- backup
planlanmalıdır.
SQL Server on Azure VM varsa licensing modeli ve SQL backup/HA ayrıca değerlendirilmelidir.
Linux VM için nelere dikkat edilmeli?
Linux workload'da:
- SSH key
- root login policy
- firewall
- patching
- package repo
- monitoring agent
standartlaştırılmalıdır.
Monitoring: yalnız CPU yeterli değil
Production VM için en az:
- CPU
- memory
- disk latency
- disk IOPS
- disk throughput
- network
- filesystem usage
- process/service health
izlenmelidir.
Azure Monitor ve VM insights host ve guest telemetry için kullanılabilir.
Alert nasıl tasarlanmalı?
Alert yalnız metric threshold değildir.
Örnek:
- CPU > %90 15 dakika
- free disk < %15
- memory pressure
- service stopped
- heartbeat missing
Alarmın:
- owner'ı
- severity'si
- aksiyonu
olmalıdır.
Backup production tasarımının parçasıdır
Snapshot backup değildir.
VM backup planında:
- frequency
- retention
- restore test
- application consistency
- RTO/RPO
tanımlanmalıdır.
Resize nasıl yapılmalı?
Azure VM resize teknik olarak mümkün olsa da:
- SKU Region'da var mı?
- aynı hardware cluster'da mı?
- restart/deallocation gerekir mi?
- disk/network limitleri değişiyor mu?
kontrol edilmelidir.
Production resize maintenance window ile planlanmalıdır.
Rightsizing yaklaşımı
İyi rightsizing süreci:
- 30-60 günlük metric topla
- peak window belirle
- p95 CPU/memory değerlendir
- disk/network limitlerini kontrol et
- candidate SKU oluştur
- staging/test
- production resize
- tekrar ölç
tek adımlı değildir.
Cost optimization
VM maliyeti:
- size
- çalışma saati
- disk
- public IP/network
- backup
- monitoring/logging
- reservation/savings plan
ile oluşur.
Azure faturasındaki 7 israf kalemi idle ve oversized VM riskini ayrıca ele alır.
Dev/Test VM'ler 7/24 açık olmalı mı?
Genellikle hayır.
Non-production ortamlar için:
- auto-shutdown
- schedule
- on-demand start
maliyet azaltabilir.
Ancak CI/CD veya integration test ihtiyacı hesaba katılmalıdır.
Spot VM ne zaman kullanılmalı?
Interruptible workload'larda değerlendirilebilir.
Örnek:
- batch
- rendering
- stateless worker
- CI runner
Critical stateful production workload'larda eviction riski nedeniyle dikkatli kullanılmalıdır.
Reservation veya savings plan ne zaman düşünülmeli?
Önce:
- idle cleanup
- rightsizing
- schedule optimization
yapılmalıdır.
Sonra stabil 7/24 baseline üzerinde commitment değerlendirilir.
VM seçimi için örnek karar tablosu
| Workload | Öncelik | Aile yaklaşımı |
|---|---|---|
| Web/API | Dengeli CPU/RAM | General purpose |
| Build worker | CPU | Compute optimized |
| SQL Server | RAM + disk | Memory optimized + premium disk |
| Cache | RAM | Memory optimized |
| Batch | CPU + spot uygunluğu | Compute optimized |
| AI/ML | GPU | GPU family |
Bu yalnız başlangıç yaklaşımıdır; gerçek sizing metric ile yapılmalıdır.
Production öncesi kontrol listesi
- doğru VM family
- doğru size
- disk IOPS/throughput yeterli
- network limit yeterli
- public exposure minimum
- NSG doğru
- backup açık
- restore test edildi
- monitoring açık
- alert owner belli
- patching planı var
- availability ihtiyacı karşılanıyor
Well-Architected Framework ile bağlantı
Azure Well-Architected Framework VM tasarımını şu pillar'lar üzerinden değerlendirmeye yardımcı olur:
- Reliability → zone/HA
- Security → identity/network
- Cost → rightsizing/commitment
- Operations → monitoring/patching
- Performance → VM/disk/network sizing
Landing Zone ile bağlantı
Azure Landing Zone VM'in çalışacağı platform guardrail'lerini belirler.
Örneğin:
- allowed Region
- public IP policy
- tagging
- logging
- RBAC
merkezi uygulanabilir.
Dynamis'te Azure VM yaklaşımı
Dynamis'in Azure yönetimi hizmetinde Azure VM seçimini yalnız SKU tavsiyesi olarak görmüyoruz.
Assessment'ta:
- workload profile
- peak metric
- disk I/O
- network
- availability
- backup
- monitoring
- cost
birlikte incelenir.
Sonra VM family, disk ve network tasarımı oluşturulur.
Amacımız en büyük VM'i vermek değil, production ihtiyacını gereksiz kapasite olmadan karşılamak.
Sık yapılan hatalar
Sadece vCPU/RAM'e bakmak: Disk ve network limitleri bottleneck olabilir.
Tek VM'i HA sanmak: Zone/host failure riski devam eder.
CPU ortalamasına göre küçültmek: Peak ve p95/p99 değerlerini kullanın.
OS disk'e her şeyi koymak: Yoğun I/O workload'da ayrım gerekebilir.
Public RDP/SSH açmak: Private management yaklaşımı kullanın.
Backup var ama restore test yok: Backup'ın değeri restore ile ölçülür.
Sırada ne var
- Azure Well-Architected Framework
- Azure Landing Zone Nedir?
- Azure faturasındaki 7 israf kalemi
- Azure yönetimi hizmeti
Kaynaklar
Kaynaklar
- 1.Azure Virtual Machines documentationMicrosoft Learn · 2026-09-25
- 2.Azure VM sizes overviewMicrosoft Learn · 2026-09-25
- 3.Availability options for Azure VMsMicrosoft Learn · 2026-09-25
- 4.Azure managed disk typesMicrosoft Learn · 2026-09-25
- 5.Accelerated Networking overviewMicrosoft Learn · 2026-09-25
- 6.Monitor Azure virtual machinesMicrosoft Learn · 2026-09-25
- 7.VM insights overviewMicrosoft Learn · 2026-09-25
- 8.Resize a virtual machineMicrosoft Learn · 2026-09-25
Sık sorulan sorular
Azure VM nedir?
Azure Virtual Machines, Windows veya Linux işletim sistemi çalıştırabileceğiniz IaaS sanal sunucu hizmetidir. VM size; vCPU, memory, disk ve network limitlerini belirler. Production kullanımında doğru size seçimi kadar availability, managed disk, network, backup ve monitoring tasarımı da önemlidir.
Azure VM size nasıl seçilir?
Önce workload'un CPU, memory, disk IOPS/throughput, network ve GPU ihtiyacı ölçülmelidir. General purpose, compute optimized, memory optimized, storage optimized veya GPU ailelerinden workload'a uygun kategori seçilir. Son karar yalnız vCPU/RAM'e değil, disk ve network limitlerine, Region/zone availability'ye ve gerçek p95/p99 kullanımına göre verilmelidir.
Production Azure VM tek Availability Zone'da çalıştırılmalı mı?
Tek zonal VM zone outage'a karşı dayanıklı değildir. Microsoft, yüksek erişilebilirlik gereken workload'larda birden fazla VM'i birden fazla Availability Zone'a yaymayı veya uygun Virtual Machine Scale Sets kullanmayı önerir. Tek VM kullanımında işletim sistemi ve application seviyesinde kesinti riski ayrıca kabul edilmeli ve backup/restore planı doğrulanmalıdır.
Azure VM için hangi disk tipi seçilmeli?
Disk seçimi IOPS, throughput, latency, kapasite, redundancy ve bütçeye göre yapılmalıdır. Standard SSD/HDD düşük maliyetli workload'larda, Premium SSD ve Premium SSD v2 daha yüksek performans ihtiyacında, Ultra Disk ise çok yüksek IOPS/throughput isteyen belirli workload'larda değerlendirilebilir. VM size'ın disk limitleri de ayrıca kontrol edilmelidir.
Azure VM monitoring için yalnız CPU metriği yeterli mi?
Hayır. Production VM için CPU yanında available memory, disk latency/IOPS/throughput, network, guest OS metrikleri, application health ve alert'ler izlenmelidir. Azure Monitor ve VM insights host ve guest telemetry'sini toplamak, trendleri görmek ve alert üretmek için kullanılabilir.