- 01Provider karşılaştırmasından önce mevcut ortam rightsizing, waste ve commitment açısından normalize edilmelidir.
- 02Provider değişimi aylık liste fiyatıyla değil compute, storage, network, lisans, developer time ve migration effort dahil toplam TCO ile değerlendirilmelidir.
- 03Migration kararları hesap seviyesinde değil workload bazında kal, optimize et, taşı veya yeniden platformla şeklinde verilmelidir.
- 04Break-even süresi migration toplam maliyeti ile aylık net tasarruf arasındaki ilişki üzerinden hesaplanmalıdır.
- 05FinOps ve migration birbirinin alternatifi değildir; FinOps analizi provider değişimini bazı workload'lar için mantıklı bir sonuç haline getirebilir.
Kısaca
Cloud provider değiştirmek, yüksek faturaya verilen ilk tepki olmamalıdır. Önce mevcut ortamın rightsizing, idle kaynak, storage, network, database ve commitment açısından gerçekten optimize edilip edilmediği ölçülmelidir. Provider değişimi ancak optimize edilmiş mevcut ortam ile hedef platformun gerçek toplam maliyeti karşılaştırıldığında teknik ve ticari avantaj sağlıyorsa anlamlıdır.
Dynamis Teknoloji'de bu kararı hesap seviyesinde değil, workload bazında veriyoruz: kal, optimize et, taşı veya yeniden platformla.
Cloud provider değiştirmek mi, mevcut altyapıyı optimize etmek mi?
Doğru cevap çoğu zaman tüm hesap için tek bir seçim değildir.
Aynı cloud hesabında:
- bir workload mevcut provider'da kalabilir
- başka bir workload optimize edilebilir
- başka biri taşınabilir
- bir diğeri managed service'e yeniden platformlanabilir
Bu nedenle "AWS pahalı", "Azure pahalı" veya "başka provider daha ucuz" gibi genel sonuçlar sağlıklı karar üretmez.
Önce mevcut ortamı normalize edin
Provider karşılaştırmasından önce mevcut ortamda şu alanları kontrol edin:
- oversized VM / instance
- idle resource
- unattached disk
- snapshot ve backup retention
- database tier
- egress ve NAT
- dev/staging kaynakları
- logging
- Savings Plan / RI / reservation coverage
- utilization
- tagging ve ownership
Optimize edilmemiş bir ortamı iyi optimize edilmiş hedef altyapıyla karşılaştırmak yanlış baseline üretir.
Cloud Faturası Neden Beklenenden Yüksek Gelir? rehberi bu ilk audit'i ayrıntılı açıklar.
Provider değişimi ne zaman mantıklı olabilir?
1. Workload standart ve taşınabilir ise
Örneğin:
- standart Linux VM
- IIS / Windows application server
- containerized web app
- PostgreSQL / MySQL
- object storage kullanan standart uygulamalar
başka platformlara nispeten daha kolay taşınabilir.
2. Kullanım uzun süre sabitse
Çok elastik kapasite ihtiyacı olmayan 7/24 çalışan workload'larda daha basit compute modeli ekonomik olabilir.
3. Egress toplam maliyetin büyük bölümüyse
Yüksek internet veya provider-to-provider trafik, liste compute fiyatından daha önemli olabilir.
4. Lisanslama farklı platformda avantajlıysa
Özellikle Windows ve SQL Server workload'larında altyapı ve lisanslama modeli birlikte değerlendirilmelidir.
5. Operasyon karmaşıklığı business value üretmiyorsa
Küçük bir ekip yüzlerce servis ve karmaşık cloud-native yapı yönetiyorsa daha basit platform toplam maliyeti azaltabilir.
Ne zaman mevcut provider'da kalmak daha mantıklı olabilir?
Provider-specific managed service bağımlılığı varsa
Örneğin yoğun kullanılan:
- serverless event mimarisi
- proprietary database
- managed streaming
- identity entegrasyonları
- provider-specific data platform
taşıma yalnız altyapı migration'ı değil application değişikliği gerektirebilir.
Global veya multi-region ihtiyaç varsa
Mevcut provider'ın global servisleri business gereksinimini karşılıyorsa daha basit bir platforma geçiş operasyonel gerileme yaratabilir.
Mevcut ortam optimizasyon sonrası hedef maliyete iniyorsa
Rightsizing ve commitment sonrası fark küçülüyorsa migration riski ekonomik avantajı silebilir.
Liste fiyatı neden yeterli değildir?
Bir VM'in aylık fiyatını karşılaştırmak toplam maliyeti göstermez.
Gerçek TCO şunları içermelidir:
- compute
- storage
- database
- network
- egress
- backup
- monitoring
- lisans
- support
- developer time
- incident operasyonu
- migration effort
Örneğin hedef provider'ın VM'i %30 daha ucuz olabilir ama uygulama migration'ı iki mühendisin birkaç haftasını alıyorsa ilk yıl toplam avantaj daha düşük olabilir.
Migration maliyetini ayrı hesaplayın
Provider değişimi tek seferlik maliyet üretir:
- discovery
- architecture
- target setup
- data transfer
- parallel environment
- testing
- cutover
- rollback hazırlığı
- ekip öğrenme süresi
- decommission
Bu maliyet amortize edilmeden yalnız aylık fatura farkına bakmak yanlış karar verebilir.
Cloud Migration hizmeti, migration kararını yalnız taşıma işlemi değil; dependency, test, cutover ve rollback planıyla birlikte ele alır.
Break-even süresi hesaplanmalı
Basit model:
Break-even süresi = Migration toplam maliyeti / Aylık net tasarruf
Örneğin:
- migration toplam maliyeti: 18.000 USD
- aylık net tasarruf: 1.000 USD
teorik break-even 18 aydır.
Ancak bu hesapta risk, büyüme, yeni lisans ve operasyon maliyeti de dikkate alınmalıdır.
Workload bazında karar tablosu
| Workload | İlk karar | Neden |
|---|---|---|
| Standart 7/24 VM | Optimize et / taşı | Portability yüksek olabilir |
| AWS'ye özgü serverless zinciri | Kal / refactor | Migration application değişikliği yaratabilir |
| Yüksek egress üreten servis | Optimize et / taşı | Network TCO önemli olabilir |
| Kritik managed database | Kal / replatform | HA, backup ve failover yeniden tasarlanmalı |
| Dev/staging | Önce optimize et | Schedule ve küçültme en düşük riskli tasarruftur |
| Kubernetes workload | Operasyon TCO'yu ölç | Node fiyatı tek başına yeterli değildir |
Bu tablo nihai sonuç değil, discovery başlangıcıdır.
AWS'de kalmak mı, çıkmak mı?
AWS ortamlarında önce:
- EC2 rightsizing
- EBS / snapshot
- RDS
- Cost Optimization Hub
- Savings Plans
- Reserved Instances
- egress
- NAT
değerlendirilmelidir.
Mevcut AWS ortamını optimize etmek için AWS yönetim hizmeti kullanılabilir.
AWS alternatifi: hangi iş yükü nerede kalmalı? workload placement kararını daha detaylı ele alır.
Azure'da kalmak mı, çıkmak mı?
Azure'da önce:
- VM sizing
- managed disk
- Azure SQL tier
- backup
- Azure Monitor
- reservation / savings plan
- network
- idle resource
incelenmelidir.
Mevcut Azure ortamını optimize etmek için Azure yönetimi hizmeti ana commercial destination'dır.
Provider değiştirmeden önce 10 soru
- Mevcut ortam rightsized mı?
- Idle kaynaklar temizlendi mi?
- Dev/staging optimize mi?
- Egress ve network akışları biliniyor mu?
- Database gerçekten doğru tier'da mı?
- Commitment utilization sağlıklı mı?
- Provider-specific dependency listesi var mı?
- Migration engineering effort hesaplandı mı?
- Hedef platformdaki operasyon modeli net mi?
- Break-even süresi business açısından kabul edilebilir mi?
Bu sorulardan birkaçına cevap yoksa provider değişimi için henüz yeterli veri yoktur.
Vendor lock-in nasıl değerlendirilir?
Lock-in yalnız bir provider kullanmak değildir.
Gerçek bağımlılık şuralarda oluşabilir:
- proprietary API
- managed database feature
- serverless runtime
- event bus
- identity
- observability
- deployment tooling
- data format
- operational knowledge
Portable VM workload ile provider-specific application architecture aynı risk seviyesinde değildir.
Hybrid sonuç da doğru olabilir
Tüm workload'ların aynı yerde çalışması zorunlu değildir.
Örneğin:
- global API mevcut provider'da kalır
- sabit VM workload başka platforma taşınır
- backup ayrı lokasyonda tutulur
- identity merkezi kalır
Bu durumda hybrid operasyon modeli gerekir.
FinOps ve migration birbirinin alternatifi değildir
FinOps'un amacı mevcut maliyet yapısını görünür ve optimize hale getirmektir.
Migration bu analizden sonra çıkabilecek sonuçlardan yalnız biridir.
Sağlıklı sıra:
- Visibility
- Waste temizliği
- Rightsizing
- Commitment
- Workload placement
- Gerekirse migration
Dynamis'in FinOps hizmeti ilk beş adımı yönetilebilir hale getirir; Cloud Migration hizmeti ise taşıma kararı verilen workload'larda migration sürecini yürütür.
Yazılım şirketleri için neden özellikle önemli?
Küçük ekiplerde yanlış migration kararı developer kapasitesini haftalarca infrastructure işine bağlayabilir.
Yazılım Şirketleri Cloud Maliyetlerini Nasıl Düşürebilir? rehberi infrastructure spend ile developer time'ı birlikte ele alır.
Sık yapılan hatalar
Liste fiyatına bakıp karar vermek: TCO hesaplayın.
Mevcut ortamı optimize etmeden kıyaslamak: Yanlış baseline üretir.
Her workload'u birlikte taşımak: Workload bazında karar verin.
Migration engineering time'ını ücretsiz saymak: Toplam maliyete ekleyin.
Provider-specific dependency'yi geç keşfetmek: Discovery aşamasında çıkarın.
Break-even hesaplamamak: Tasarrufun migration maliyetini ne zaman geri ödediğini ölçün.
Sonuç
Cloud provider değiştirmek maliyet düşürmenin araçlarından biridir; hedef değildir.
En sağlıklı yaklaşım mevcut ortamı optimize etmek, gerçek TCO'yu ölçmek ve workload bazında karar vermektir.
Bazı workload'lar kalabilir, bazıları taşınabilir. İyi karar tek bir provider seçmek değil, her workload için doğru ekonomik ve teknik ortamı bulmaktır.
Sırada ne var
- Cloud Faturası Neden Beklenenden Yüksek Gelir?
- Yazılım Şirketleri Cloud Maliyetlerini Nasıl Düşürebilir?
- AWS alternatifi: hangi iş yükü nerede kalmalı?
- Cloud Migration Checklist
- FinOps hizmeti
- Cloud Migration hizmeti
- AWS yönetim hizmeti
- Azure yönetimi hizmeti
Kaynaklar
Kaynaklar
- 1.FinOps FrameworkFinOps Foundation · 2026-09-29
- 2.AWS Cost Optimization HubAmazon Web Services · 2026-09-29
- 3.Azure Advisor cost recommendationsMicrosoft · 2026-09-29
Sık sorulan sorular
Cloud provider değiştirmek ne zaman mantıklıdır?
Mevcut ortam rightsizing, waste temizliği ve commitment optimizasyonundan sonra hâlâ pahalıysa; workload başka platforma düşük bağımlılıkla taşınabiliyorsa; egress, lisans, operasyon veya kapasite modeli yeni platformda anlamlı toplam maliyet avantajı sağlıyorsa provider değişimi değerlendirilebilir.
Cloud provider değiştirmeden maliyet ne kadar düşürülebilir?
Sabit bir oran vermek doğru değildir. Tasarruf potansiyeli overprovisioning, idle kaynaklar, storage, network, database, commitment ve mimariye göre değişir. İlk adım mevcut ortamın gerçek optimizasyon potansiyelini ölçmektir.
Cloud migration maliyet hesabında hangi kalemler olmalı?
Hedef platform faturası yanında engineering effort, data transfer, paralel çalışma süresi, yeniden test, downtime riski, lisans, backup, monitoring, yeni operasyon araçları ve ekip öğrenme süresi de hesaba katılmalıdır.
AWS veya Azure'da kalmak vendor lock-in anlamına mı gelir?
Her kullanım vendor lock-in değildir. Lock-in derecesi workload'un sağlayıcıya özgü managed servis, API, data formatı, identity, event sistemi ve operasyon süreçlerine bağımlılığına göre değişir. Karar provider adından çok workload portability üzerinden verilmelidir.
Provider değişimi ile FinOps birbirinin alternatifi mi?
Hayır. FinOps önce mevcut maliyet yapısını görünür ve optimize edilebilir hale getirir. Provider değişimi ise bu analizden sonra bazı workload'lar için çıkabilecek stratejik bir sonuç olabilir. İyi bir migration kararı, optimize edilmiş mevcut ortamı gerçek hedef TCO ile karşılaştırır.