- 01AWS'den çıkış kararından önce rightsizing, Savings Plans ve mevcut mimari optimizasyonlarını değerlendirin; kötü optimize edilmiş bir ortamı hedef altyapıyla karşılaştırmayın.
- 02AWS Regions'dan internete veri çıkışında aylık ilk 100 GB uygun servis ve bölgeler arasında toplu olarak ücretsizdir; sonraki maliyet servis, bölge ve hacme göre değişir.
- 03AWS'nin uygun müşteriler için sunduğu çıkış data transfer kredisinde ön onay gerekir; 30 Eylül 2025 güncellemesine göre standart tamamlanma penceresi 90 gündür.
- 04Göç sırasını sabit bir stateless-first kuralıyla değil uygulama, veritabanı, ağ ve operasyon bağımlılıklarını içeren wave planıyla belirleyin.
- 05Başarılı sonuç tam çıkış olmak zorunda değildir; bazı iş yüklerinin AWS'de kaldığı hibrit mimari teknik ve ekonomik olarak daha doğru olabilir.
Kısaca
AWS faturası büyüdüğünde ilk karar "AWS'den çıkalım" olmamalıdır. Önce kullanım ve maliyet envanterini çıkarın, AWS içindeki rightsizing ve taahhüt seçeneklerini değerlendirin, ardından her iş yükü için kalma, taşıma veya yeniden platformlama kararını ayrı verin. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak bulut göçünü fiyat listesi karşılaştırması değil; bağımlılık, veri transferi, operasyon ve geri dönüş planı üzerinden ele alır.
AWS'den çıkmadan önce faturayı normalize edin
AWS maliyetini başka bir altyapıyla karşılaştırmadan önce mevcut hesabın gerçekten optimize edildiğini doğrulayın. Aksi halde kötü boyutlandırılmış bir AWS ortamını iyi boyutlandırılmış başka bir ortamla karşılaştırmış olursunuz.
Önce AWS'de kalma seçeneğini teknik olarak iyileştirmek istiyorsanız AWS yönetim hizmeti üzerinden mevcut mimari, monitoring, backup, güvenlik ve maliyet yapısını birlikte değerlendirebilirsiniz.
İlk incelemede şu kalemleri ayrı çıkarın:
- Uzun süredir düşük kullanılan veya gereğinden büyük EC2 kaynakları
- Sahipsiz EBS diskleri, eski snapshot'lar ve artık kullanılmayan IP veya yük dengeleyici kaynakları
- Sabit çalışan iş yüklerinde on-demand kullanım
- İnternete, başka Availability Zone'lara veya başka AWS bölgelerine veri transferi
- RDS, ElastiCache, OpenSearch ve benzeri yönetilen servislerde gerçekten kullanılan özelliklerle ödenen hizmet seviyesi arasındaki fark
- Etiketsiz kaynaklar ve sahibi belli olmayan maliyetler
AWS Cost Explorer rightsizing önerileri düşük kullanılan EC2 kaynaklarını küçültme veya sonlandırma fırsatlarını gösterebilir; AWS güncel dokümantasyonunda daha geniş optimizasyon için Cost Optimization Hub kullanımını önerir. Sabit ve öngörülebilir compute tüketiminde Savings Plans veya rezervasyon modelleri de çıkış kararından önce değerlendirilmelidir.
Dynamis'te göç fizibilitesinden önce en az son 60-90 günlük maliyet ve kullanım profilini inceliyoruz; amaç tek bir yüksek faturayı değil, tekrar eden maliyet yapısını görmek.
İş yükü bazında kal, taşı veya yeniden platformla
Tek bir "AWS pahalıdır" veya "AWS'de kalmak daha iyidir" kuralı yoktur. Aynı hesap içinde bazı iş yüklerinin taşınması, bazılarının AWS'de kalması daha doğru olabilir.
| İş yükü | İlk değerlendirme | Neden |
|---|---|---|
| Uzun süre sabit çalışan VM tabanlı uygulama | Taşıma adayı | Bağımlılık düşükse hedef altyapının toplam maliyeti kolay karşılaştırılır |
| AWS'ye özgü Lambda, DynamoDB, SQS veya EventBridge zinciri | Kal veya önce ayrıştır | Sağlayıcı değişimi yalnızca altyapı değil uygulama değişikliği gerektirebilir |
| RDS üzerinde kritik veritabanı | Yeniden platformlama adayı | Yüksek erişilebilirlik, yedek, patch ve failover özellikleri hedefte yeniden tasarlanmalıdır |
| Büyük internet çıkışı olan medya veya API servisi | Transfer maliyetini ayrıca modelle | Egress, CDN ve hedef trafik modeli toplam maliyeti değiştirebilir |
| Çok bölgeli veya global gecikme hedefi olan servis | AWS'de kalabilir veya hibrit tasarlanabilir | Bölge çeşitliliği ve global ağ gerçek bir gereksinim olabilir |
| Kişisel veri içeren iş yükü | Hukuki ve teknik gereksinime göre konumlandır | KVKK veriyi otomatik olarak Türkiye'de tutmayı zorunlu kılmaz; yurt dışı aktarım mekanizması ayrıca değerlendirilir |
Bu tablo bir sonuç değil, başlangıçtır. Örneğin sabit bir EC2 iş yükü Savings Plans ile hedef maliyete iniyorsa sırf sağlayıcı değiştirmek için taşınması gerekmez. Tersine, AWS'ye özel servise bağlı olmayan ve veri transferi yüksek olan bir servis başka bir altyapıda daha öngörülebilir maliyet üretebilir.
Data transfer yalnızca internet egress değildir
AWS veri transferini tek bir kalem olarak fiyatlamaz. Güncel AWS açıklamasında üç ana kategori vardır:
- AWS servisinden internete veri çıkışı
- Aynı bölgedeki Availability Zone'lar arasında veri transferi
- AWS bölgeleri arasında veri transferi
Ayrıca CloudFront, Direct Connect ve Global Accelerator gibi servislerin kendi fiyatlandırma modelleri vardır.
AWS Regions'dan internete veri çıkışında aylık ilk 100 GB, uygun servisler ve bölgeler arasında toplu olarak ücretsizdir. Sonraki fiyat servis, bölge ve hacme göre değişir. Bu nedenle göç analizinde yalnızca "egress kaç TB" değil, trafiğin hangi kaynaktan hangi hedefe aktığını çıkarın.
Availability Zone'lar arası trafik de mimariye bağlı olarak anlamlı maliyet oluşturabilir. Uygulama ile veritabanı farklı zonlarda çok yoğun konuşuyorsa, yalnızca internet egress tablosuna bakmak toplam veri transferi maliyetini eksik gösterir.
AWS'den çıkarken ücretsiz data transfer programını önceden kontrol edin
AWS, uygun müşteriler için AWS'den veya belirli bir AWS servisinden tamamen veri taşıma senaryolarında internete veri transferi ücretleri için kredi sağlayan bir program sunuyor.
Süreç otomatik değildir. AWS Support'a göçe başlamadan önce başvurmanız, planınızı paylaşmanız ve onay almanız gerekir. Onaylanan müşterilere veri transferi için geçici kredi tanımlanır.
AWS'nin 30 Eylül 2025 güncellemesine göre onaydan sonra göçü tamamlamak için standart pencere 90 gündür. Daha uzun süre gerekiyorsa AWS Support'a bildirilmelidir.
Programla ilgili üç sınırı planınıza yazın:
- Kredi yalnızca uygun data transfer out ücretleri içindir; standart servis kullanımı devam eder.
- CloudFront, Direct Connect, Snow Family ve Global Accelerator gibi özel transfer servisleri bu programın dışında olabilir.
- Taşındığınız servis veya hesap için kalan veri ve iş yüklerinin program koşullarına uygun biçimde kapatılması gerekir.
Bu nedenle "30 TB veriyi taşırken egress kesin ücretsiz" demeyin. Önce uygunluk ve kredi onayını alın.
Göç sırası bağımlılık haritasıyla belirlenir
"Önce stateless, sonra veritabanı" iyi bir varsayım olabilir ancak evrensel kural değildir. AWS'nin kendi migration guidance dokümanları da migration wave planını uygulama, altyapı ve iş bağımlılıklarına göre oluşturmayı önerir.
Önce şu bağımlılıkları çıkarın:
- Uygulama ile veritabanı arasındaki gecikme hassasiyeti
- Kimlik doğrulama, DNS ve sertifika bağımlılıkları
- Kuyruk, obje depolama ve dosya sistemi bağlantıları
- Dış API ve allowlist gereksinimleri
- Yedekleme ve felaket kurtarma hedefleri
- Bakım pencereleri ve iş takvimi
- Ekiplerin aynı anda müdahale etmesini gerektiren operasyonel bağımlılıklar
Bir uygulama ile veritabanı arasında düşük gecikme gerektiren sıkı bağ varsa bunları farklı haftalarda taşımak kötü fikir olabilir. Buna karşılık bağımsız ve düşük riskli servisler ilk wave için daha uygundur.
Güvenli göç altı aşamada ilerler
1. Envanteri çıkarın
Compute, depolama, veritabanı, ağ, data transfer ve yönetilen servis maliyetlerini iş yükü bazında gruplayın. Her kaynağın sahibi, kritikliği ve bağımlılığı belli olsun.
2. Hedef mimariyi doğrulayın
Hedef ortamda yalnızca sunucu boyutunu değil, yedekleme, izleme, güvenlik, yük dengeleme ve felaket kurtarma modelini de fiyatlayın. AWS'de yönetilen bir özelliği hedefte elle işletmek gerekiyorsa operasyon maliyetini ekleyin.
3. Düşük riskli pilot wave seçin
AWS Prescriptive Guidance, ilk migration wave'lerinde daha düşük karmaşıklıktaki uygulamalarla başlamayı ve öğrenilenleri sonraki wave'lere taşımayı önerir. Pilot başarı kriterini önceden yazın: hata oranı, gecikme, veri tutarlılığı, geri dönüş süresi ve maliyet.
4. Yeni ortamı paralel kurun
Mümkün olan sistemlerde hedef ortamı üretimin yanında hazırlayın. Konfigürasyon, güvenlik ve gözlemlenebilirlik testleri tamamlanmadan trafik taşımayın.
5. Veriyi replikasyonla yaklaştırın
Büyük veri setlerinde ilk tam kopyayı kesim gününden önce alın. Uygulama ve veritabanı teknolojiniz destekliyorsa artımlı veya sürekli replikasyon kullanarak kesim anındaki farkı küçültün.
1 Gbit/s bağlantıda 10 TB verinin yalnızca teorik iletim süresi yaklaşık 22 saattir. Gerçek süre protokol verimi, küçük dosyalar, şifreleme, kaynak sistem performansı ve doğrulama nedeniyle daha uzun olabilir. Planı teorik bant genişliğine değil ölçülen throughput'a göre yapın.
6. Cutover ve rollback birlikte tasarlanır
Trafiği tek seferde değiştirmek zorunda değilsiniz. Uygulama mimarisi destekliyorsa canary veya kademeli trafik geçişi uygulanabilir. Ancak bazı veritabanı veya stateful sistemlerde kısa bir yazma durdurma penceresi gerekebilir.
Rollback koşulunu kesimden önce belirleyin. Örneğin hata oranı, p95 gecikme veya veri replikasyon farkı belirlenen eşiğin dışına çıkarsa eski ortama dönüleceği yazılı olmalıdır.
Eski AWS ortamını hemen kapatmayın ama açık da unutmayın
Kesimden sonra eski ortam bir süre rollback için tutulabilir. Bu sürenin uzunluğu uygulamanın riskine ve gözlem süresine göre belirlenmelidir; tüm sistemler için sabit "iki hafta" kuralı yoktur.
Rollback penceresi kapandığında ise eski kaynakların kontrollü şekilde sonlandırılması gerekir. Aksi halde göç tamamlanmış görünürken AWS faturası snapshot, disk, veritabanı, IP veya yük dengeleyici kaynakları nedeniyle devam eder.
Decommission kontrol listesinde en az şunlar olsun:
- EC2 ve Auto Scaling kaynakları
- EBS diskleri ve snapshot'lar
- RDS snapshot ve yedekleri
- S3 yaşam döngüsü ve arşivleri
- Elastic IP ve yük dengeleyiciler
- DNS kayıtları
- CloudWatch log ve metrik saklama ayarları
- IAM erişimleri ve eski servis hesapları
Hibrit sonuç çoğu zaman geçerli bir sonuçtur
Bulut göçünün başarılı olması için AWS hesabının sıfırlanması gerekmez. Bazı uygulamalar başka altyapıya taşınırken AWS'ye özgü veya global dağıtım gerektiren servisler AWS'de kalabilir.
Bu durumda ağ, kimlik, gözlemlenebilirlik ve yedekleme iki ortam arasında tasarlanmalıdır. Dynamis'in hibrit bulut hizmeti, AWS'de kalan iş yükleriyle özel veya alternatif bulut altyapısını tek operasyon modeli altında yönetmek için kullanılabilir.
Kişisel veri konumu kararınız varsa KVKK uyumlu bulut altyapısı rehberini ayrıca kullanın. Kubernetes hedefliyorsanız Kubernetes'e geçiş rehberi hedef ortamın operasyon yükünü değerlendirmek için daha doğru adımdır.
Sık yapılan hatalar
AWS'yi optimize etmeden çıkış hesabı yapmak: Rightsizing ve taahhüt seçeneklerini görmeden yapılan karşılaştırma yanlış baseline üretir.
Sadece EC2 fiyatına bakmak: Yedekleme, veri transferi, veritabanı, izleme ve operasyon maliyeti toplam maliyetin parçasıdır.
AWS'ye özgü bağımlılıkları geç fark etmek: Lambda, DynamoDB veya olay servislerine sıkı bağlı uygulama başka ortama yalnızca "taşınmaz"; çoğu zaman yeniden platformlanır veya refactor edilir.
Ücretsiz data transfer kredisini otomatik sanmak: Başvuru ve ön onay gerekir. 2025 güncellemesinden sonra standart göç penceresi 90 gündür.
Wave planını bağımlılıksız yapmak: Birbiriyle sıkı bağlı uygulama ve veritabanını farklı wave'lere koymak performans veya kesinti riski yaratabilir.
Eski kaynakları unutmak: Göç sonrası kalan disk, snapshot ve ağ kaynakları maliyet üretmeye devam edebilir.
Sırada ne var
-
Cloud Migration hizmeti: geçiş planlama, cutover ve rollback kapsamını değerlendirin.
-
Bulut göçü sırası: bağımlılıklara göre migration wave planı: AWS çıkışındaki workload'ları dependency, pilot wave, cutover ve rollback kriterlerine göre sıralayın.
-
AWS alternatifi: hangi iş yükü nerede kalmalı?: migration başlatmadan önce hangi workload'un kalması, taşınması veya hibrit çalışması gerektiğini belirleyin.
-
Broadcom sonrası VMware: lisanslama ve çıkış planı: sanallaştırma ortamından çıkışta lisans, bağımlılık, pilot wave ve rollback modelini inceleyin.
-
KVKK uyumlu bulut altyapısı: veri konumu ve yurt dışı aktarım kararını teknik mimariyle eşleştirin.
-
Kubernetes'e geçiş: 14 günde üretime hazır cluster planı: hedef ortam Kubernetes ise operasyon ve geçiş gereksinimlerini inceleyin.
-
Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: göç sonrası altyapıyı kimin işleteceğini planlayın.
-
AWS yönetim hizmeti: çıkış kararı vermeden önce mevcut AWS ortamını optimize edin ve yönetim modelini değerlendirin.
-
Hibrit bulut hizmeti: AWS'de kalan ve taşınan iş yüklerini birlikte yönetin.
-
Cloud Migration Checklist: buluta geçmeden önce 30 kontrol: AWS çıkışında cutover öncesi dependency, DNS, backup, monitoring ve rollback hazırlığını doğrulayın.
-
Cloud migration strategy: rehost, replatform ve refactor: AWS workload'ları için rehost, replatform, refactor, retain ve retire seçeneklerini workload bazında belirleyin.
Kaynaklar
- AWS EC2 On-Demand Pricing: Data Transfer
- AWS EC2 FAQ: Free data transfer when moving off AWS
- AWS News Blog: Free data transfer out to internet when moving out of AWS
- AWS Prescriptive Guidance: Evaluate exit strategy requirements
- AWS Prescriptive Guidance: Wave planning
- AWS Cost Management: Rightsizing recommendations
Kaynaklar
- 1.Amazon EC2 On-Demand Pricing - Data TransferAmazon Web Services · 2026-09-19
- 2.Amazon EC2 FAQs - Free data transfer when moving off AWSAmazon Web Services · 2026-09-19
- 3.Free data transfer out to internet when moving out of AWSAWS News Blog · 2026-09-19
- 4.Evaluate exit strategy requirementsAWS Prescriptive Guidance · 2026-09-19
- 5.Wave planningAWS Prescriptive Guidance · 2026-09-19
- 6.Optimizing your cost with rightsizing recommendationsAWS Cost Management · 2026-09-19
Sık sorulan sorular
Bulut göçü sırasında kesinti olur mu?
Kesinti zorunlu değildir ancak uygulamaya göre değişir. Paralel ortam, sürekli veya artımlı veri replikasyonu, kontrollü trafik geçişi ve geri dönüş planı kesinti penceresini azaltabilir. Veritabanı ve sıkı bağımlılıklar için kısa bakım penceresi yine gerekebilir.
AWS'den veri taşımak ne kadar sürer?
Süre veri hacmi, gerçek ağ throughput'u, şifreleme, küçük dosya sayısı ve doğrulama sürecine bağlıdır. 1 Gbit/s bağlantıda 10 TB verinin yalnızca teorik ağ süresi yaklaşık 22 saattir; gerçek göç planı ölçülen throughput ve doğrulama süresine göre yapılmalıdır.
AWS egress ücreti nedir?
Egress, AWS'den internete veya başka konumlara çıkan verinin transfer maliyetidir. AWS Regions'dan internete çıkan veride aylık ilk 100 GB tüm uygun servis ve bölgeler arasında toplu olarak ücretsizdir; sonraki ücret servis, bölge ve hacme göre değişir.
Hangi iş yükleri AWS'de kalmalı?
AWS'ye özgü yönetilen servislere sıkı bağlı, çok bölgeli tasarıma ihtiyaç duyan veya mevcut AWS optimizasyonlarıyla hedef maliyeti karşılayan iş yükleri AWS'de kalabilir. Karar; bağımlılık, operasyon, performans ve toplam maliyet birlikte değerlendirilerek verilmelidir.
Hangi durumda AWS'den çıkılmalı?
AWS içinde rightsizing ve taahhüt indirimleri değerlendirildikten sonra hedef ortam hâlâ daha düşük toplam maliyet, daha uygun veri konumu veya daha sade operasyon sağlıyorsa çıkış planlanabilir. Sağlayıcı değiştirme maliyeti ve uygulama bağımlılıkları hesaba katılmadan karar verilmemelidir.