- 01Azure maliyet analizi toplam faturadan değil service, resource, tag ve ownership seviyesinden yapılmalıdır.
- 02En sık waste alanları idle/oversized compute, unattached disk-snapshot, network, logging, commitment ve ownership eksikliğidir.
- 03Actual cost ile amortized cost reservation/savings plan kullanılan ortamlarda farklı anlam taşır; commitment analizi için ikisi birlikte okunmalıdır.
- 04Azure Advisor önerileri otomatik uygulanmamalı; workload owner ve production peak davranışıyla doğrulanmalıdır.
- 05Sağlıklı sıra idle cleanup ve rightsizing ile başlar, commitment kararı en son stabil baseline üzerinde verilir.
Kısaca
Azure faturası büyüdüğünde ilk soru "hangi servis pahalandı?" değil, hangi kullanım iş değeri üretmeden maliyet oluşturuyor? olmalıdır. Azure Cost Management, Advisor ve resource-level kullanım verileri birlikte incelendiğinde fatura içindeki waste kaynakları daha görünür hale gelir.
Dynamis Teknoloji'de Azure maliyet incelemesini fiyat listesi karşılaştırması olarak değil; idle kaynak, oversizing, storage kalıntıları, network trafiği, log hacmi, commitment kullanımı ve ownership eksikliği üzerinden yapıyoruz.
Bu rehberde gerçek faturada en sık karşılaşılan 7 israf kalemini ve bunların nasıl bulunacağını ele alıyoruz.
Azure faturası nereden okunmalı?
Başlangıç noktası Azure Cost Management içindeki Cost Analysis ekranıdır.
İlk filtreler:
- subscription
- resource group
- resource
- service name
- meter category
- location
- tag
olmalıdır.
Ardından maliyeti iki farklı açıdan inceleyin:
- Actual cost: ilgili dönemde gerçekten faturaya yansıyan maliyet
- Amortized cost: reservation veya savings plan gibi ön ödemeli/taahhütlü maliyetlerin zamana yayılmış görünümü
Taahhüt kullanımını değerlendirirken yalnız actual cost'a bakmak yanlış yorum üretebilir.
1. Kullanılmayan veya düşük kullanılan sanal makineler
Azure faturasında ilk bakılması gereken alan çoğu zaman Virtual Machines'tir.
İsraf sinyalleri:
- uzun süre düşük CPU
- sürekli düşük network kullanımı
- non-production VM'in 7/24 açık olması
- unutulmuş test VM'i
- deallocated sanılan ama aslında running durumda kalan kaynak
Tek başına CPU düşük diye VM kapatılmamalıdır. Memory, disk I/O, connection ve business schedule da değerlendirilmelidir.
Ne yapılabilir?
- rightsizing
- schedule ile kapatma
- autoscale
- dev/test ortamlarını mesai dışı durdurma
- workload consolidation
Azure Advisor bu alanda cost recommendation üretebilir; ancak öneri production davranışıyla doğrulanmalıdır.
2. Gereğinden büyük VM SKU'ları
Idle ile oversize aynı şey değildir.
Bir VM aktif olarak kullanılıyor olabilir fakat seçilen SKU ihtiyacın çok üzerinde olabilir.
Örnek:
- 8 vCPU VM
- gerçek peak 2 vCPU
- RAM kullanımının yarısı boş
Bu durumda workload çalışıyor ama gereksiz kapasite faturalanıyor olabilir.
Kontrol edin
- p95 CPU
- memory working set
- disk throughput
- disk IOPS
- network
- peak saatler
- burst ihtiyacı
Rightsizing haftalık ortalamaya göre değil, gerçek peak ve SLO ihtiyacına göre yapılmalıdır.
3. Unattached disk, snapshot ve eski storage
VM silindiğinde managed disk her zaman otomatik olarak silinmez.
Bu nedenle:
- unattached managed disk
- eski snapshot
- gereksiz image
- kullanılmayan storage account
- uzun retention
maliyet üretmeye devam edebilir.
Özellikle kontrol edin
- disk state
- last attached resource
- snapshot yaşı
- recovery requirement
- retention owner
Disk'i silmeden önce gerçekten kullanılmadığını ve backup/rollback ihtiyacının olmadığını doğrulayın.
4. Public IP, NAT ve network egress
Network faturası compute kadar görünür değildir.
Maliyet kaynakları:
- internet egress
- inter-region transfer
- cross-zone trafik
- NAT Gateway
- public IP
- load balancer
- VPN/ExpressRoute
Özellikle mimari büyüdükçe network path yanlışlığı küçük küçük kalemlerle toplam faturayı artırabilir.
Egress maliyeti nasıl düşürülür? rehberi bu alanı cloud genelinde ayrıntılı ele alır.
Ne yapılabilir?
- same-region/same-zone data locality
- gereksiz inter-region replication azaltma
- CDN/cache
- private endpoint/NAT path optimizasyonu
- kullanılmayan public IP temizliği
5. Log Analytics ve telemetry hacmi
Observability görünürlüğü artırır; ancak kontrolsüz telemetry maliyeti hızla büyüyebilir.
İsraf sinyalleri:
- debug log'ların production'da sürekli açık olması
- yüksek hacimli low-value log
- aynı verinin birden fazla workspace'e yazılması
- gereğinden uzun retention
- gereksiz diagnostic category
Kontrol edin
- GB/day ingestion
- table bazlı hacim
- retention
- archive kullanımı
- DCR/filter
- noisy resource
Amaç log toplamayı azaltmak değil, aksiyon üretmeyen veriyi azaltmaktır.
6. Reservation / Savings Plan coverage ve utilization hataları
Taahhüt ürünleri doğru kullanıldığında compute maliyetini azaltabilir; yanlış kullanıldığında ise yeni waste oluşturabilir.
İki temel metrik:
- coverage
- utilization
Coverage düşükse çok fazla kullanım On-Demand kalıyor olabilir.
Utilization düşükse satın alınan commitment tam kullanılmıyor olabilir.
Taahhüt almadan önce rightsizing yapılmalıdır.
Savings Plan mı, Reserved Instance mı? rehberi AWS tarafındaki commitment mantığını detaylandırır; Azure tarafında da aynı FinOps prensibi geçerlidir: önce baseline, sonra commitment.
Azure reservation ve savings plan kararında:
- workload ömrü
- region
- VM family
- çalışma süresi
- büyüme planı
birlikte değerlendirilmelidir.
7. Ownership ve tagging eksikliği
En pahalı waste bazen teknik değil yönetişim problemidir.
Owner'ı olmayan kaynaklar kolayca unutulur.
Minimum tag set örneği:
- owner
- workload
- environment
- cost-center
- criticality
Tagging yoksa şu sorular zorlaşır:
- Bu kaynak kimin?
- Hangi ürüne ait?
- Prod mu test mi?
- Kapatılabilir mi?
- Maliyeti hangi ekibe yazılmalı?
Bu nedenle tagging doğrudan FinOps kontrolüdür. Azure'a özel optimizasyonu genel cloud maliyet yönetimiyle birlikte yürütmek istiyorsanız FinOps hizmeti görünürlük, rightsizing, bütçe ve sürekli maliyet kontrolünü tek süreçte ele alır.
Azure faturasını 30 dakikada hızlı tarama
İlk hızlı audit için şu sırayı kullanabilirsiniz:
- Cost Analysis → top services
- Top resources
- Son 30 gün vs önceki 30 gün
- VM ve compute trendi
- Disk/snapshot kaynakları
- Network/NAT/egress
- Log Analytics ingestion
- Reservation/Savings Plan utilization
- Untagged resources
Bu tarama root cause'u tek başına çözmez ama hangi alanda derinleşmeniz gerektiğini gösterir.
Actual cost ile amortized cost neden farklı olabilir?
Reservation veya savings plan gibi taahhüt modellerinde ödeme ile kullanım aynı zaman aralığında görünmeyebilir.
Bu nedenle:
- actual cost
- amortized cost
ayrı okunmalıdır.
Özellikle ekip veya workload bazlı maliyet dağıtımında amortized cost daha anlamlı olabilir.
Azure Advisor önerileri doğrudan uygulanmalı mı?
Hayır.
Advisor güçlü bir başlangıç noktasıdır ancak:
- uygulama peak'lerini
- business calendar'ı
- failover gereksinimini
- özel latency hedefini
her zaman tam bilmeyebilir.
Bu nedenle recommendation → owner review → impact test → apply akışı kullanılmalıdır.
Azure Cost Management budget ne işe yarar?
Budget maliyeti otomatik durdurmaz; görünürlük ve alarm sağlar.
Örnek threshold'lar:
- %50
- %80
- %100
yanında forecast bazlı alarm da kullanılabilir.
Budget subscription, resource group veya uygun scope'ta uygulanabilir.
Anomaly detection neden önemlidir?
İsraf yalnız uzun vadeli olmayabilir.
Örneğin:
- yanlış deploy
- infinite loop
- log explosion
- network spike
- autoscale hatası
birkaç saat içinde maliyeti artırabilir.
Bu nedenle aylık faturayı beklemek yerine anomaly bazlı takip daha sağlıklıdır.
Maliyet optimizasyonunda yanlış sıralama
Yaygın hata:
- reservation satın al
- sonra rightsizing yap
Doğru sıra çoğu zaman:
- ownership
- idle cleanup
- rightsizing
- architecture/network cleanup
- storage/log cleanup
- baseline ölçümü
- commitment
olmalıdır.
Azure Landing Zone ile maliyet kontrolü nasıl bağlanır?
Azure Landing Zone tasarımında cost ownership ilk günden kurulmalıdır.
Özellikle:
- budget
- mandatory tags
- subscription ayrımı
- policy
- owner
sonradan eklenirse geçmiş maliyetin kime ait olduğunu bulmak zorlaşır.
7 israf kaleminin özet tablosu
| İsraf alanı | İlk kontrol | Tipik aksiyon |
|---|---|---|
| Idle VM | CPU/network/schedule | kapat/schedule |
| Oversized VM | p95 CPU/RAM/IO | resize |
| Disk/snapshot | attachment/age | cleanup/retention |
| Network | egress/NAT/region | topology/cache |
| Logs | ingestion/retention | filter/retention |
| Commitment | coverage/utilization | rebalance |
| Ownership | tags/owner | tagging/policy |
Dynamis'te Azure maliyet incelemesi
Dynamis'in Azure yönetimi hizmetinde cost review şu sırayla ilerler:
- Cost Analysis
- resource ownership
- idle ve oversize kaynaklar
- disk/snapshot kalıntıları
- network transfer
- logging
- reservation/savings plan kullanımı
- budget ve tagging
Ardından aksiyon listesi risk ve tasarruf potansiyeline göre sıralanır.
Amaç tek seferlik faturayı düşürmek değil, tekrar eden waste'i azaltacak operasyon modelini kurmaktır.
Sık yapılan hatalar
Sadece toplam faturaya bakmak: Service/resource seviyesine inin.
Düşük CPU = kapatılabilir demek: Memory, I/O ve business schedule'ı kontrol edin.
VM silinince disk de silindi sanmak: Unattached disk'leri ayrı kontrol edin.
Log maliyetini görmezden gelmek: Ingestion ve retention ayrı incelenmeli.
Commitment'ı ilk çözüm yapmak: Önce idle ve rightsizing.
Tagging'i operasyon dışı görmek: Ownership yoksa waste tekrar oluşur.
Sırada ne var
Kaynaklar
Kaynaklar
- 1.Microsoft Cost Management overviewMicrosoft Learn · 2026-09-25
- 2.Analyze costs with Cost AnalysisMicrosoft Learn · 2026-09-25
- 3.Azure Advisor cost recommendationsMicrosoft Learn · 2026-09-25
- 4.Azure Monitor cost and usageMicrosoft Learn · 2026-09-25
- 5.Azure reservationsMicrosoft Learn · 2026-09-25
- 6.Azure savings plan for computeMicrosoft Learn · 2026-09-25
- 7.Azure Cost Management budgetsMicrosoft Learn · 2026-09-25
Sık sorulan sorular
Azure faturasında ilk hangi ekrana bakılmalı?
Azure Cost Management içindeki Cost analysis ekranı iyi başlangıçtır. Önce toplam maliyeti Service name, Resource group, Resource, Subscription ve gerekirse Meter bazında kırın. Reservation veya Savings Plan kullanıyorsanız actual cost ile amortized cost görünümünü ayırın; amortized cost taahhüt maliyetini kullanım alan kaynaklara yaydığı için gerçek workload maliyetini anlamada daha faydalı olabilir.
Azure Advisor maliyet optimizasyonu için yeterli mi?
Azure Advisor önemli bir sinyal kaynağıdır; idle/underutilized kaynaklar, rightsizing, reservation ve savings plan fırsatlarını gösterebilir. Ancak tek başına yeterli değildir. Business criticality, planned migration, seasonal workload, licensing, network architecture ve service-specific kullanım şekilleri Advisor tarafından tam olarak bilinemez. Öneriler Cost Management verisi ve workload owner bilgisiyle doğrulanmalıdır.
Azure reservation veya savings plan almadan önce ne yapılmalı?
Microsoft'un kendi öneri sırası önce idle kaynakları kapatmak ve rightsizing yapmak, ardından reservations ve en son savings plan senaryolarını değerlendirmektir. Çünkü rightsizing mevcut on-demand kullanım profilini değiştirir; önce taahhüt satın almak eski ve şişkin baseline'a göre fazla commitment yaratabilir.
Azure'da unattached disk gerçekten ücret yazmaya devam eder mi?
Evet. VM'den ayrılmış managed disk silinmediği sürece disk kaynağı olarak kalır ve seçilen disk SKU/kapasitesine göre ücret üretmeye devam edebilir. Azure Advisor da unattached diskleri maliyet optimizasyon fırsatı olarak gösterebilir. Silmeden önce verinin artık gerekli olmadığını doğrulayın ve gerekiyorsa snapshot alın.
Azure Monitor ve Log Analytics faturası neden büyüyebilir?
Azure Monitor Logs maliyetinde temel belirleyiciler veri ingestion hacmi, table plan ve retention'dır. Gereksiz verbose log, fazla diagnostic category, duplicate collection ve uzun interactive retention maliyeti büyütebilir. Microsoft, gereksiz veri toplamayı sınırlamayı, table plan'ları ve retention'ı ihtiyaca göre ayarlamayı ve yüksek ingestion için alarm kurmayı önerir.