- 01AWS alternatifi kararı hesap seviyesinde değil workload seviyesinde verilmelidir; aynı hesapta bazı sistemler AWS'de kalırken bazıları taşınabilir.
- 02AWS'ye özgü managed service bağımlılığı, global dağıtım ve elastik ölçek ihtiyacı workload'u AWS'de tutan en güçlü sinyallerdir.
- 03Sabit VM, yüksek veri çıkışı ve düşük AWS servis bağımlılığı taşıma adaylığını güçlendirir.
- 04AWS dışına çıkmadan önce Cost Optimization Hub, rightsizing ve Savings Plans fırsatları uygulanmalı; aksi halde yanlış maliyet baseline'ı oluşur.
- 05Hibrit model çoğu şirkette geçerli sonuçtur: AWS'de kalan workload'larla private veya alternatif cloud'a taşınan sistemler birlikte işletilebilir.
Kısaca
AWS alternatifi ararken doğru soru "AWS yerine ne kullanalım?" değil, "hangi iş yükü nerede daha doğru çalışır?" olmalıdır. AWS'ye özgü yönetilen servisler, global dağıtım ve hızlı ölçek ihtiyacı bazı iş yüklerini AWS'de tutabilir; sabit VM'ler, yüksek veri çıkışı veya özel kontrol gerektiren sistemler ise başka altyapılara taşınabilir. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak bu kararı workload bazında verir.
Önce hesabı değil, iş yükünü sınıflandırın
Tek bir AWS hesabında farklı teknik ve ekonomik profilde iş yükleri olabilir. Bu nedenle "AWS pahalı" veya "AWS'den çıkalım" gibi hesap seviyesindeki kararlar genellikle fazla geneldir.
Her iş yükünü şu başlıklarda değerlendirin:
- AWS'ye özgü servis bağımlılığı
- Trafik ve veri çıkışı
- Compute kullanım profili
- Veritabanı ve depolama ihtiyacı
- Çok bölgeli çalışma gereksinimi
- KVKK veya veri konumu ihtiyacı
- Operasyon ekibinin yetkinliği
- Üç yıllık toplam maliyet
- Migration ve rollback maliyeti
AWS'nin kendi migration metodolojisi de tek bir çıkış yolu önermez; workload'a göre retain, rehost, relocate, replatform veya refactor gibi farklı stratejiler kullanır.
Hızlı karar tablosu
| İş yükü | İlk karar | Neden |
|---|---|---|
| EC2 üzerinde sabit VM tabanlı uygulama | Taşıma adayı | Bağımlılık düşükse hedef TCO kolay karşılaştırılır |
| Lambda + DynamoDB + EventBridge zinciri | AWS'de kal veya refactor | Servis bağımlılığı yüksektir |
| Çok yüksek internet çıkışı olan API/medya servisi | Taşı veya hibrit değerlendir | Egress toplam maliyeti büyütebilir |
| RDS üzerinde kritik veritabanı | Kal, replatform veya hibrit | HA, backup ve failover yeniden tasarlanmalıdır |
| Global çok bölgeli uygulama | AWS'de kalabilir | Bölge çeşitliliği gerçek bir avantaj olabilir |
| Türkiye'de veri konumu gereken sistem | Özel/yerel altyapı adayı | Veri konumu ve aktarım modeli kontrol edilebilir |
| Kubernetes iş yükü | AWS'de kal veya taşınabilir | Uygulama taşınabilirliği yüksektir, operasyon modeli belirleyicidir |
| Arşiv ve yedek | Maliyet ve erişim modeline göre ayır | Erişim sıklığı ve veri çıkışı önemlidir |
Bu tablo başlangıç noktasıdır. Nihai karar tek bir teknik özelliğe göre değil, toplam operasyon modeline göre verilmelidir.
AWS'de kalması mantıklı iş yükleri
Bazı iş yükleri AWS'nin güçlü olduğu alanları gerçekten kullanır.
AWS'ye özgü managed service bağımlılığı: Lambda, DynamoDB, EventBridge, SQS veya AWS'ye özel veri servisleri yoğun kullanılıyorsa başka platforma geçiş yalnızca altyapı taşıması değildir; uygulama değişikliği de gerekir.
Global dağıtım ihtiyacı: Birden fazla bölgede düşük gecikmeyle çalışması gereken sistemlerde AWS'nin global altyapısı güçlü bir avantaj sağlayabilir.
Ani ve düzensiz ölçek: Kullanım dakikalar içinde büyük oranda değişiyorsa elastik servisler ve serverless modelleri sabit altyapıya göre daha uygun olabilir.
Mevcut AWS optimizasyonları yeterliyse: Cost Optimization Hub, rightsizing ve Savings Plans sonrası toplam maliyet hedefiniz karşılanıyorsa sırf alternatif aramak için migration yapmak gereksiz risk yaratabilir.
Taşınması mantıklı iş yükleri
AWS dışına en kolay taşınan sistemler genellikle standart ve düşük bağımlılıklı workload'lardır.
Uzun süre sabit çalışan VM'ler: Aylar boyunca benzer CPU ve RAM kullanan uygulamalar için sürekli elastiklik değeri düşük olabilir.
Yüksek veri çıkışı olan servisler: İnternete veya farklı platformlara sürekli veri çıkaran sistemlerde transfer maliyeti toplam maliyetin anlamlı parçası haline gelebilir.
Standart web uygulamaları: Nginx, IIS, Node.js, PHP, Java veya container tabanlı standart uygulamalar başka altyapılara daha kolay taşınabilir.
Özel altyapı kontrolü gereken iş yükleri: Ağ, fiziksel kaynak, veri konumu veya lisanslama üzerinde daha fazla kontrol gerekiyorsa private cloud veya alternatif cloud modeli daha uygun olabilir.
Kullanılan managed service değeri düşükse: AWS'de yalnızca EC2, EBS ve standart load balancer kullanılıyor, ama karmaşık managed service avantajlarından yararlanılmıyorsa migration eşiği daha düşüktür.
Hibrit model çoğu şirkette en gerçekçi sonuçtur
Başarılı cloud strategy her workload'u aynı platforma taşımak zorunda değildir.
Hibrit modelde örneğin:
- Lambda/DynamoDB iş yükleri AWS'de kalabilir
- Sabit Windows ve Linux VM'ler özel buluta taşınabilir
- Türkiye'de tutulması tercih edilen veri yerel ortamda kalabilir
- Global CDN veya object storage servisleri AWS'de devam edebilir
- Kubernetes cluster'larının bir kısmı farklı altyapıda çalışabilir
Bu modelde ana zorluk iki ortamı ayrı ayrı kurmak değil, birlikte işletmektir.
Ortak olarak tasarlanması gerekenler:
- Kimlik ve erişim
- DNS
- VPN veya özel ağ bağlantısı
- Gözlemlenebilirlik
- Yedekleme
- Secret yönetimi
- Olay müdahalesi
- Maliyet etiketleme
Dynamis'in hibrit bulut hizmeti, bu iki ortamı tek operasyon modeli altında yönetmek için tasarlanmıştır.
AWS içi optimizasyon yapılmadan alternatif hesabı yapmayın
AWS'den çıkış veya workload taşıma kararı vermeden önce mevcut hesabı optimize edin.
Mevcut AWS hesabının mimari, monitoring, güvenlik, backup ve maliyet katmanlarını birlikte değerlendirmek gerekiyorsa AWS yönetim hizmeti bu aşamanın commercial destination'ıdır.
AWS Cost Optimization Hub şu alanlarda öneriler sağlayabilir:
- Rightsizing
- Idle resource temizliği
- Savings Plans
- Reserved Instances
- Graviton geçişleri
- Storage optimizasyonu
Bu adım kritik çünkü kötü optimize edilmiş AWS ortamını iyi optimize edilmiş başka bir platformla karşılaştırmak yanlış baseline üretir.
En az son 60-90 günlük kullanım ve fatura verisini workload bazında gruplayın. Tek bir yüksek fatura ayına göre karar vermeyin.
AWS alternatifi hesabında yalnızca VM fiyatına bakmayın
Bir EC2 instance ile başka sağlayıcının VM fiyatını yan yana koymak gerçek toplam maliyeti göstermez.
Üç yıllık TCO modelinde şunları birlikte hesaplayın:
| Kalem | AWS | Alternatif / özel bulut |
|---|---|---|
| Compute | Instance veya Savings Plan | VM veya kapasite maliyeti |
| Storage | EBS/S3/RDS storage | Blok/object/storage altyapısı |
| Data transfer | İnternet/AZ/region transferi | Sağlayıcı veya ağ modeline göre |
| Database | RDS/Aurora | Managed DB veya self-managed |
| Backup | Snapshot / AWS Backup | Hedef platform backup modeli |
| Monitoring | CloudWatch ve diğer servisler | Gözlemlenebilirlik stack'i |
| Support | AWS Support planı | Sağlayıcı destek modeli |
| Operasyon | İç ekip zamanı | İç ekip veya yönetilen hizmet |
| Migration | Başlangıçta yok | Proje maliyeti |
| Exit riski | Vendor bağımlılığı | Yeni platform bağımlılığı |
Sabit workload'da alternatif VM fiyatı düşük olabilir ama yönetilen database veya observability avantajını kaybediyorsanız toplam maliyet yine artabilir.
Data transfer kararın önemli parçasıdır
AWS Regions'dan internete çıkan veri için aylık ilk 100 GB, uygun servisler ve bölgeler arasında toplu olarak ücretsizdir. Sonraki ücret bölge, servis ve hacme göre değişir.
Bu nedenle workload başına şu verileri çıkarın:
- İnternete çıkan GB/TB
- Availability Zone'lar arası trafik
- Region'lar arası trafik
- CDN trafiği
- Object storage erişimi
- Backup replikasyonu
Özellikle web uygulaması başka yerde, database AWS'de kalacaksa iki platform arasındaki trafik hem maliyet hem gecikme yaratabilir. Hibrit tasarımda veri akışı mimari kararın parçasıdır.
AWS'den çıkış kredisi migration maliyetini etkileyebilir
AWS, uygun müşterilerin başka bir sağlayıcıya veya on-prem ortama tamamen taşınması durumunda belirli data transfer out ücretleri için kredi programı sunuyor.
Süreç otomatik değildir:
- AWS Support üzerinden başvuru yapılır
- Exit planı paylaşılır
- Uygunluk ve kapsam onaylanır
- Onay sonrası data transfer kredisi tanımlanır
30 Eylül 2025 güncellemesine göre standart migration tamamlama penceresi 90 gündür.
Bu kredi migration maliyetini azaltabilir ancak tüm servis maliyetlerini ortadan kaldırmaz. CloudFront, Direct Connect, Snow Family veya Global Accelerator gibi bazı transfer yollarının ayrı koşulları olabilir.
İş yüklerini dört gruba ayırın
Pratikte AWS portföyünü şu dört gruba ayırmak yönetimi kolaylaştırır.
1. AWS'de kal
AWS'ye sıkı bağlı, global veya elastik iş yükleri.
2. Taşı
Standart VM, container veya düşük bağımlılıklı uygulamalar.
3. Yeniden platformla
RDS gibi managed service kullanan ancak başka bir managed veya self-managed platforma taşınabilecek sistemler.
4. Refactor et
AWS servislerine sıkı bağlı olduğu için uygulama mimarisi değişmeden taşınamayan sistemler.
Bu sınıflandırma tek bir büyük migration yerine workload bazında yatırım kararı verir.
Kubernetes iş yükleri daha taşınabilir ama otomatik taşınmaz
Container ve Kubernetes kullanan uygulamalar teorik olarak platformdan bağımsızdır; pratikte storage class, load balancer, IAM, DNS, secret yönetimi ve managed service bağlantıları sağlayıcı bağımlılığı yaratabilir.
Kubernetes workload'u taşımadan önce şunları kontrol edin:
- Cloud provider specific annotations
- LoadBalancer service davranışı
- PersistentVolume tipi
- IAM role entegrasyonları
- ExternalDNS
- Secrets/KMS
- Managed database bağlantıları
- Observability exporter'ları
Kubernetes migration planı için Kubernetes'e geçiş rehberini kullanın.
Veritabanı workload'larında karar daha dikkatli verilmelidir
RDS veya Aurora'dan çıkmak yalnızca database dump/import işi değildir.
AWS'de kullandığınız şu özellikleri hedefte karşılaştırın:
- Multi-AZ
- Automated backup
- Point-in-time recovery
- Read replica
- Encryption
- Patch management
- Monitoring
- Failover
Eğer hedef altyapıda bunları siz işletecekseniz operasyon maliyetini TCO hesabına ekleyin.
Bazı şirketlerde uygulamayı taşımak ama database'i AWS'de bırakmak kısa vadeli geçiş çözümü olabilir; ancak network gecikmesi ve data transfer maliyeti ölçülmelidir.
KVKK kararını AWS markasına bağlamayın
KVKK kişisel verinin AWS'de tutulmasını otomatik olarak yasaklamaz. Yurt dışı aktarımında Kanun'un 9. maddesindeki mekanizmalar ve teknik/idari tedbirler değerlendirilmelidir.
AWS workload'unu Türkiye'deki private cloud'a taşımak yurt dışı aktarımını azaltabilir ancak uyumu otomatik sağlamaz.
Ayrıntılı teknik çerçeve için KVKK uyumlu bulut altyapısı rehberini inceleyin.
Migration kararı verdikten sonra çıkış planına geçin
Bu comparison sayfası "hangi workload nerede kalsın?" sorusunu cevaplar. Taşınmasına karar verdiğiniz workload için asıl migration planı ayrı yürütülmelidir.
AWS'den çıkış: maliyeti düşüren bulut göçü planı şu adımları detaylandırır:
- Envanter
- Hedef mimari
- Pilot wave
- Replikasyon
- Cutover
- Rollback
- Decommission
Karar ve migration prosedürünü aynı makalede karıştırmamak, iki farklı search intent'i de korur.
Dynamis'te workload placement analizi
Dynamis, AWS hesabını kapatmak veya tüm workload'u tek platforma taşımak hedefiyle başlamaz.
İlk analizde:
- Son 60-90 günlük AWS maliyetleri
- Resource utilization
- Data transfer
- Managed service bağımlılıkları
- Workload kritikliği
- RPO/RTO
- KVKK ve veri konumu
- Ekip operasyon kapasitesi
çıkarılır.
Sonra her workload için AWS'de kal / taşı / yeniden platformla / refactor et kararı verilir.
Dynamis'in hibrit bulut hizmeti, AWS'de kalması gereken workload'larla Raff veya özel buluta taşınan sistemleri birlikte yönetmek için kullanılabilir.
Sık yapılan hatalar
AWS pahalı diye tüm hesabı taşımak: Önce Cost Optimization Hub ve rightsizing fırsatlarını uygulayın.
Yalnızca EC2 fiyatına bakmak: Managed database, backup, data transfer ve operasyon maliyetlerini ekleyin.
AWS'ye özel servisleri VM gibi görmek: Lambda/DynamoDB tabanlı sistemler çoğu zaman refactor gerektirir.
Data transferi sonradan fark etmek: Özellikle hibrit mimaride platformlar arası trafik hem maliyet hem gecikme yaratır.
KVKK'yı AWS'den çıkış gerekçesine indirgemek: Konu marka değil, veri aktarım mekanizması ve teknik kontrollerdir.
Migration maliyetini TCO dışında bırakmak: Hedef platform daha ucuz olsa bile geçiş maliyeti break-even süresini uzatabilir.
Sırada ne var
-
Cloud Migration hizmeti: bu konunun ticari/operasyonel uygulama kapsamını değerlendirin.
-
Bulut göçü sırası: bağımlılıklara göre migration wave planı: taşınacak workload'ların hangi sırayla ve hangi bağımlılık gruplarıyla ilerleyeceğini planlayın.
-
AWS'den çıkış: maliyeti düşüren bulut göçü planı: taşınacak workload için migration adımlarını planlayın.
-
Küçük ekip için Kubernetes: ne zaman fazla gelir?: AWS'den taşınacak container workload'larında Kubernetes'in gerçekten gerekli olup olmadığını değerlendirin.
-
Kubernetes'e geçiş rehberi: container workload'larının sağlayıcı bağımlılıklarını değerlendirin.
-
Özel bulut mu, genel bulut mu? KVKK açısından karar: KVKK, veri konumu ve kontrol ihtiyacına göre public/private/hybrid modelini karşılaştırın.
-
KVKK uyumlu bulut altyapısı: veri konumu ve yurt dışı aktarım modelini belirleyin.
-
Bulut sunucu mu, yönetilen altyapı mı?: workload placement kararından sonra altyapıyı içeride mi yoksa yönetilen hizmetle mi işleteceğinizi belirleyin.
-
AWS yönetim hizmeti: migration kararı vermeden önce mevcut AWS ortamını optimize edin ve operasyon risklerini çıkarın.
-
Hibrit bulut hizmeti: AWS'de kalan ve taşınan workload'ları tek operasyon modelinde yönetin.
Kaynaklar
Kaynaklar
- 1.AWS migration terms and strategiesAmazon Web Services · 2026-09-19
- 2.AWS Cost Optimization HubAmazon Web Services · 2026-09-19
- 3.Amazon EC2 On-Demand Pricing - Data TransferAmazon Web Services · 2026-09-19
- 4.Amazon EC2 FAQs - Moving data out of AWSAmazon Web Services · 2026-09-19
- 5.Free data transfer out to internet when moving out of AWSAWS News Blog · 2026-09-19
Sık sorulan sorular
Hangi iş yükleri AWS'de kalmalı?
AWS'ye özgü yönetilen servislere sıkı bağlı, global ölçek veya çok bölgeli tasarım gerektiren ve mevcut optimizasyonlarla hedef toplam maliyeti karşılayan iş yükleri AWS'de kalabilir. Karar servis bağımlılığı, performans, operasyon ve üç yıllık toplam maliyet birlikte değerlendirilerek verilmelidir.
AWS'den hangi iş yükleri taşınmalı?
Uzun süre sabit çalışan VM tabanlı uygulamalar, yüksek veri çıkışı olan ancak AWS'ye özgü servislere düşük bağımlı iş yükleri ve özel veri konumu veya altyapı kontrolü gerektiren sistemler güçlü taşıma adaylarıdır. Önce AWS içi optimizasyon yapılmalı, sonra hedef TCO karşılaştırılmalıdır.
AWS ile özel bulut birlikte kullanılabilir mi?
Evet. Hibrit modelde AWS'ye özgü veya global iş yükleri AWS'de kalırken sabit VM, veri yoğun veya özel kontrol gerektiren sistemler özel bulutta çalışabilir. Ağ, kimlik, gözlemlenebilirlik, yedekleme ve veri akışı iki ortam arasında birlikte tasarlanmalıdır.
AWS'den çıkarken data transfer ücreti ödenir mi?
AWS Regions'dan internete aylık ilk 100 GB uygun servisler arasında toplu olarak ücretsizdir. Ayrıca AWS, uygun müşterilerin başka sağlayıcıya veya on-prem ortama taşınması için Support üzerinden onaylanan bir çıkış kredisi programı sunar; standart tamamlanma penceresi 90 gündür.
AWS alternatifi seçerken sadece VM fiyatına bakmak yeterli mi?
Hayır. Compute fiyatına ek olarak veri transferi, depolama, veritabanı, yedekleme, gözlemlenebilirlik, destek, operasyon zamanı ve migration maliyeti hesaba katılmalıdır. AWS'de kullanılan yönetilen servislerin hedef ortamda nasıl karşılanacağı toplam maliyeti değiştirebilir.