AWS'ye geçiş: Türkiye işletmeleri için adım adım rehber
Mevcut sistemi AWS'ye taşımak, çoğu işletme için teknik bir karar değil, stratejik bir dönüşümdür. Bu yazıda AWS bulutuna geçiş sürecini adım adım ele alıyoruz: hazırlık, mimari kararlar, migrasyon stratejileri, maliyet yönetimi ve KVKK uyumu.
Özet
AWS'ye geçiş; doğru planlamayla 2-8 hafta içinde, kesintiyi minimize ederek ve maliyeti öngörülebilir biçimde tamamlanabilecek bir süreçtir. Üç ana migrasyon stratejisi (rehost, replatform, refactor) arasından ihtiyacınıza göre seçim yapılır. Türkiye'deki işletmeler için eu-central-1 (Frankfurt) bölgesi hem gecikme hem KVKK açısından tipik tercihtir.
AWS'ye neden geçilmeli?
AWS (Amazon Web Services), dünyanın en olgun ve en geniş hizmet yelpazesine sahip bulut platformudur. 200'den fazla hizmet, 30+ coğrafi bölge ve güçlü bir ekosistem sunar. On-premise (kendi sunucularınız) veya daha küçük sağlayıcılardan AWS'ye geçişin temel faydaları:
- Ölçeklenebilirlik: Trafik artışını otomatik absorbe eder; zirve yükler için kapasite peşin satın almazsınız.
- Maliyet esnekliği: Yalnızca kullandığınız kaynak için ödeme yaparsınız. Reserved Instance ve Savings Plans ile %30-72 tasarruf mümkün.
- Güvenilirlik: Çoklu bölge ve kullanılabilirlik alanları (AZ) ile yüksek erişilebilirlik yerleşik.
- Güvenlik: Paylaşımlı sorumluluk modeliyle, AWS fiziksel ve altyapısal güvenliği siz üstlenir; siz uygulamayı ve veriyi korursunuz.
- İnovasyon hızı: Yeni servisleri (örn. Lambda, Bedrock) saatler içinde deneyip production'a alabilirsiniz.
Adım 1: Mevcut sistem analizi
Geçişin ilk adımı mevcut sistemin detaylı analizidir. Şunları belgeleyin:
- Trafik desenleri: Günlük/zirve istek sayısı, bant genişliği, coğrafi dağılım
- Kaynak kullanımı: CPU, RAM, disk I/O, ağ — ortalama ve zirve değerler
- Veritabanı karakteristiği: Veri büyüklüğü, büyüme hızı, okuma/yazma oranı, sorgu desenleri
- Bağımlılıklar: Harici API'ler, üçüncü taraf servisler, entegrasyonlar
- Uyumluluk gereksinimleri: KVKK, varsa ISO 27001, PCI-DSS
- Bütçe kısıtları: Aylık bulut bütçesi, opex/capex tercihleri
Bu analiz, hangi migrasyon stratejisinin uygun olduğunu belirler.
Adım 2: Migrasyon stratejisi seçimi
Üç ana yaklaşım var:
Rehost (lift-and-shift)
Mevcut uygulamayı minimum değişikliklerle AWS'ye taşırsınız. EC2 instance'larına kurar, veritabanını RDS'e taşır, dosyaları S3'e koyarsınız. Avantajı: hızlı, düşük risk, düşük maliyet. Dezavantajı: bulut-native avantajlardan (auto-scaling, serverless) yararlanmazsınız. Basit uygulamalar için doğru başlangıç.
Replatform (lift-tinker-and-shift)
Mevcut mimari korunur ama küçük iyileştirmeler yapılır: container'a taşınma (ECS/EKS), managed database kullanma (RDS), auto-scaling grubuna ekleme. Avantajı: orta hız, orta risk, ölçeklenebilirlik avantajı kısmen kullanılır. Çoğu B2B uygulaması için ideal denge.
Refactor (re-architecture)
Uygulamayı bulut-native prensiplerle yeniden tasarlarsınız: mikro hizmetlere bölme, serverless (Lambda) kullanma, event-driven mimari, tam managed servislerden yararlanma. Avantajı: en yüksek fayda, gerçek bulut esnekliği. Dezavantajı: en uzun süre, en yüksek maliyet, en yüksek risk. Sadece ölçek veya farklılaşma gerektiren stratejik ürünler için mantıklı.
Pratik yaklaşım: Genelde karışık bir strateji uygulanır. Kritik ve sık kullanılan parçalar refactor edilir; diğerleri rehost veya replatform edilir. Önceliklendirme, iş değerine ve riske göre yapılır.
Adım 3: Hedef mimari tasarımı
AWS'de mimari kararları birbiriyle ilişkilidir:
- Bölge (region) seçimi: Türkiye'deki kullanıcılar için eu-central-1 (Frankfurt) veya eu-west-1 (Ireland) tipik tercih. Türkiye'den gecikme ~40-60ms, KVKK açısından sorun yok.
- Networking: VPC (Virtual Private Cloud) içinde public/private subnet ayrımı, NAT gateway, security group'lar. Veritabanı private subnet'te olmalı.
- Compute: EC2 (VM), ECS/EKS (container), Lambda (serverless). Uygulama tipine göre.
- Database: RDS (managed PostgreSQL, MySQL, SQL Server), DynamoDB (NoSQL), Aurora (optimize edilmiş RDS).
- Storage: S3 (object storage), EBS (block storage), EFS (file storage).
- CDN: CloudFront ile statik varlıkların global olarak dağıtımı.
- Security: IAM (kimlik), KMS (şifreleme), GuardDuty (tehdit tespiti), WAF (web uygulama güvenlik duvarı).
- Monitoring: CloudWatch (metrik), CloudTrail (audit), X-Ray (tracing).
Mimariyi AWS Well-Architected Framework'ün 6 sütununa göre değerlendirin: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability.
Adım 4: Infra-as-code
Mimariyi elle console'dan kurmak yerine Terraform (veya AWS CDK, CloudFormation) kullanın. Neden?
- Tekrarlanabilirlik: Aynı kodla dev, staging, prod ortamları oluşturulur.
- Versiyonlama: Her değişiklik Git'te, code review'la.
- Geri dönüş: Bir hata yapıldığında
terraform destroy && terraform apply. - Dokümantasyon: Kod kendiliğinden dokümantasyondur.
Tipik bir Terraform yapısı:
infrastructure/
modules/
vpc/
database/
compute/
monitoring/
environments/
staging/
main.tf
variables.tf
production/
main.tf
variables.tf
Adım 5: Aşamalı migrasyon
Kesintisiz (zero-downtime) migrasyon için aşamalı yaklaşım:
- AWS'de hedef altyapıyı kur (VPC, database, compute). Veri henüz taşınmadı.
- Veritabanını çoğalt (DMS - Database Migration Service ile mevcut DB'den AWS RDS'e sürekli replikasyon).
- Uygulamayı AWS'de ayağa kaldır (henüz trafik almıyor, smoke test).
- Trafiği kademeli taşı: DNS seviyesinde ağırlıklı yönlendirme (weighted routing) ile %5 trafik AWS'ye, %95 mevcut sisteme. İzle.
- Oranı artır: %25 → %50 → %100. Her aşamada metrikleri izle.
- Eski sistemi kapat: Birkaç gün yedekte tut, sonra deprovision.
Bu yaklaşım kesintiyi sıfıra yakın tutar ve geri dönüşü kolaylaştırır.
Adım 6: Maliyet optimizasyonu
AWS faturalarının %30-40'ı genellikle optimize edilebilir:
- Reserved Instances / Savings Plans: 1 veya 3 yıllık taahhüt karşılığında %30-72 indirim. Stabil iş yükleri için ideal.
- Spot Instances: Boşta kalan kapasite, %90'a varan indirim. Batch iş yükleri, stateless worker'lar için.
- Auto-scaling: Trafiğe göre otomatik ölçeklenme. Boşta kapasiteyi kapatır.
- Lifecycle policies: S3'te eski objeleri Glacier'a taşıma (10x daha ucuz).
- Sağ boyutlandırma: Aşırı büyük EC2 instance'larını küçültme.
- Elastic IP temizliği: Kullanılmayan Elastic IP'ler saatlik ücret.
- FinOps kültürü: AWS Budgets + Cost Anomaly Detection ile harcamayı izleme.
AWS Cost Explorer'ı her hafta kontrol etmek, biriken atıl kaynakları yakalar.
KVKK ve veri出境
KVKK (Kişisel Verilerin Korunması Kanunu), kişisel verilerin işlenmesi ve korunması için kurallar koyar. AWS'ye geçişte dikkat edilmesi gerekenler:
- Veri bölgesi: Verilerin Türkiye dışında tutulması KVKK'ya aykırı değildir ama kişisel verilerin出境ünde açık rıza veya yasal istisna gerekir. eu-central-1 (Frankfurt) tipik tercih — hem KVKK hem GDPR uyumlu.
- Şifreleme: Verilerin transit (TLS) ve dururken (KMS ile) şifrelenmesi KVKK'nın " uygun güvenlik önlemleri" gerekliliğine uyar.
- Erişim kontrolü: IAM politikaları en az ayrıcalık (least-privilege) prensibiyle. IAM Role ve IAM User ayrımı.
- Loglama: CloudTrail ile tüm API çağrıları, CloudWatch ile uygulama logları. KVKK denetim izlenebilirliği gerektirir.
- Veri saklama ve imha: Lifecycle policy ve otomatik silme kuralları.
- Olay müdahale planı: Veri ihlali durumunda bildirim süreci (KVKK'ya göre 72 saat içinde KVKK'ya bildirim).
Teknik uyumluluk için Clouify'un sunduğu destek: şifreleme, IAM, loglama, audit. Yasal uyumluluk için avukatla çalışmanız gerekir (aydınlatma metni, açık rıza, VERBİS kaydı).
Sık yapılan hatalar
- Aşırı boyutlandırma: "Belki trafik artar" diye en büyük instance'ı seçmek. Auto-scaling bunu gereksiz kılar.
- Manuel kurulum: Console'dan elle resource yaratmak. İleride tekrarlanamaz, audit edilemez.
- Public subnet'te veritabanı: Güvenlik açığı. Veritabanı her zaman private subnet'te.
- Hardcoded secret: Kodda AWS access key. IAM Role kullanın.
- Yedekleme yok: RDS otomatik yedeği açık ama retention süresi kısa. Cross-region backup düşünün.
- Monitoring eksik: "Çalışıyor" varsayımı. CloudWatch alarm'ları kurun.
Ne kadar sürer?
- Basit tek sunuculu uygulama: 1-2 hafta
- Orta ölçek web/mobil app + RDS: 3-4 hafta
- Mikro hizmet mimarisi, multi-AZ: 6-12 hafta
- Tam refactor + bulut-native: 3-6 ay
Bu süreler mimari kararlılıktan ekibin tecrübesine kadar birçok faktöre bağlı. Ücretsiz değerlendirme toplantısında net tahmin veririz.
Sonuç
AWS'ye geçiş; doğru strateji, sağlam infra-as-code ve aşamalı yaklaşım with kesintiyi minimize eden, maliyeti öngörülebilir bir süreçtir. Türkiye'deki işletmeler için Frankfurt bölgesi hem teknik hem KVKK açısından makul bir tercih. AWS partner olmaya gerek yok — bağımsız bir danışmanlık (Clouify gibi) vendor-neutral tavsiye verir ve satış baskısı olmadan doğru kararı almanıza yardımcı olur.
Bu yazı, Clouify ekibinin saha deneyimlerinden derlenmiştir. AWS'ye geçiş planlıyorsanız ücretsiz ilk değerlendirme için talep oluşturun; doğru stratejiyi birlikte belirleyelim.