.jpeg?width=50&name=1612817579623%20(1).jpeg)
·
3 minute read
Türkiye'de faaliyet gösteren şirketlerin büyük bir kısmı KVKK nedeniyle public cloud kullanamıyor. Veri yurt dışına çıkamaz, ama Frankfurt'taki bir EKS cluster'ı tam olarak bunu yapıyor. AWS Istanbul Local Zone bu kısıtlamayı kırdı, artık veriler Türkiye'de kalırken tam anlamıyla cloud-native çalışmak mümkün.
Bu serinin bölümleri:
- Bölüm 1: Mimari ve Karar - KVKK, Local Zone nedir, kısıtlamalar, mimari tasarım
- Bölüm 2: Temel Altyapı - Gereksinimler, Terragrunt yapısı, VPC kurulumu
- Bölüm 3: Node'lar ve Servisler - EKS, Karpenter, EBS CSI, ALB Controller
- Bölüm 4: Production'a Taşımak - Sorunlar, maliyet analizi, best practices
Neden Bu Yazıyı Yazdım?
Türkiye'de yazılım geliştiren ekiplerin önünde yıllardır görünmez bir duvar vardı: KVKK.
6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verinin yurt dışına aktarılmasını ciddi koşullara bağlıyor. Fintech, sağlık, e-ticaret, sigorta - kullanıcı verisi işleyen her sektörden şirket aynı soruyla boğuşuyordu: "Modern cloud altyapısı kurmak istiyoruz, ama verimiz Türkiye'de kalmak zorunda."
Çözüm seçenekleri hep aynıydı ve hep sancılıydı:
- On-premise datacenter: yüksek sermaye maliyeti, yavaş ölçeklenme, ops yükü
- Colocation: biraz daha esnek ama aynı sorunların çoğu hâlâ var
- Frankfurt'ta AWS: KVKK riskini göze almak demek; hukuki belirsizlik, denetim kaygısı
- Türkiye'deki yerel cloud sağlayıcılar: managed Kubernetes yok, ekosistem kısıtlı
Sonra AWS, Istanbul Local Zone'u duyurdu.
eu-central-1-ist-1a - compute ve storage Türkiye topraklarında, Frankfurt'un yönetim düzlemiyle bağlı, tam AWS ekosistemi. KVKK uyumu artık cloud-native mimariyle çelişmiyor.
Biz de bu Local Zone'u production EKS cluster'ı kurmak için test ettik. Teoride basitti: aynı altyapı, sadece worker node'lar Istanbul'da. Pratikte ise Local Zone'a özgü kısıtlamalar, provider versiyon çakışmaları ve Karpenter v1'in değişen API'si bizi uzun süre uğraştırdı.
Bu seri, o süreçte öğrendiklerimizin tamamını belgeleyen bir rehber. KVKK uyumu arayan ekipler için sıfırdan production'a her adımı gerçek kod örnekleriyle anlattım.
Istanbul Local Zone Nedir?
AWS Local Zone'lar, AWS altyapısının büyük şehirlere taşınmış küçük uzantılarıdır. Frankfurt ana bölgesine (eu-central-1) bağlı olan Istanbul Local Zone, eu-central-1-ist-1a identifier'ıyla hizmet veriyor.
Ne işe yarar?
Standart cloud mimarisinde kullanıcı trafiği Frankfurt'taki data center'a gidip geliyor. Local Zone ile bu mesafe dramatik şekilde kısalıyor:
|
Senaryo |
Yaklaşık Latency |
|
Türkiye → Frankfurt EKS |
~35-40ms |
|
Türkiye → Istanbul Local Zone EKS |
~2-8ms |
|
Fark |
~5-6x daha hızlı |
Bu fark şu use case'lerde kritik önem taşıyor:
- Gaming backend'leri - ping hassasiyeti olan oyunlar
- Fintech uygulamaları - gerçek zamanlı fiyatlama, işlem onayı
- Video streaming - adaptive bitrate, düşük buffer
- Veri egemenliği - Türkiye'de işlenmesi gereken veriler
- IoT platformları - düşük latency gerektiren cihaz komutları
1. Istanbul Local Zone'u Anlamak
Desteklenen Instance Tipleri
Istanbul Local Zone yalnızca 7. nesil Intel instance'larını destekler:
|
Tip |
Kullanım Alanı |
vCPU Aralığı |
Örnek Kullanım |
|
c7i |
Compute-optimized |
2-192 |
Web server, batch işleme, CI/CD |
|
m7i |
General purpose |
2-192 |
Uygulama sunucuları, microservice |
|
r7i |
Memory-optimized |
2-192 |
In-memory cache, analitik DB |
Önemli: 6. nesil ve altı (c6i, m6i vb.) Istanbul'da desteklenmez. Graviton/ARM (c7g, m7g vb.) instance'ları da şu an desteklenmemektedir. Karpenter konfigürasyonunda bu kritik bir detay.
Kritik Kısıtlamalar
Local Zone standart bir AWS bölgesi değildir, bazı servisleri ve özellikleri desteklemez:
|
Kısıtlama |
Açıklama |
Çözüm |
|
Spot instance yok |
Tüm node'lar ON_DEMAND olmak zorunda |
Maliyet planlaması yapın |
|
NAT Gateway yok |
Internet çıkışı için Frankfurt NAT kullanılır, cross-zone transfer maliyeti oluşur |
|
|
EKS Control Plane yok |
Sadece worker node'lar Local Zone'da olabilir |
Control plane Frankfurt'ta kalır |
|
EFS yok |
Elastic File System Local Zone'da desteklenmez |
EBS (gp3) veya self-hosted NFS |
|
RDS / Aurora yok |
Managed DB desteklenmez, KVKK nedeniyle Frankfurt'a da gönderilmez |
EC2 üzerinde Percona Server / Percona XtraDB Cluster |
|
ElastiCache yok |
Managed cache yok |
Self-hosted Redis (EC2 veya pod olarak) |
|
Graviton / ARM yok |
c7g, m7g gibi ARM instance'lar desteklenmez |
Yalnızca Intel (c7i, m7i, r7i) kullanın |
|
ALB - subnet annotation gerekir |
ALB Local Zone'da oluşturulabilir; Ingress'e alb.ingress.kubernetes.io/subnets: eu-central-1-ist-1a annotation'ı eklenince ALB doğrudan Istanbul subnet'inde kurulur |
Ingress annotation'ına Local Zone subnet adını verin |
|
S3 Express One Zone - yerel |
S3 Express One Zone artık Istanbul Local Zone'da GA. Veri Türkiye'de kalır, KVKK uyumlu |
Bucket adı --euc1-ist1-az1--x-s3 suffix'i ile oluşturulur, Location.Type: LocalZone, DataRedundancy: SingleLocalZone |
Veritabanı: Neden Frankfurt seçenek değil?
RDS / Aurora Istanbul'da desteklenmez. Ama Frankfurt'ta managed DB açmak da KVKK açısından sorunlu - kişisel veri Türkiye dışına çıkmış olur.
Önerilen yaklaşım: EC2 üzerinde self-hosted veritabanı, Istanbul Local Zone subnet'inde.
|
Seçenek |
Açıklama |
Kullanım |
|
MySQL uyumlu, enterprise özellikler |
Genel OLTP |
|
|
Multi-master MySQL cluster |
Yüksek erişilebilirlik |
|
|
PostgreSQL + HA araçları |
PostgreSQL workload'ları |
Bu yaklaşım hem verinin Türkiye'de kalmasını sağlar hem de yönetilen servis kısıtlamasını aşar.
Not: S3 Express One Zone artık Istanbul Local Zone'da GA. Bucket'ı zone-aware olarak oluşturmak için:
Bucket adının sonundaki --euc1-ist1-az1--x-s3
Mimari Genel Bakış
Trafik akışı:
- Gelen trafik: Internet → ALB (Istanbul Local Zone - alb.ingress.kubernetes.io/subnets: eu-central-1-ist-1a annotation'ı ile) → Pod (Istanbul)
- Çıkan trafik: Pod (Istanbul) → NAT instance / fck-nat (EC2) → Internet (NAT Gateway Istanbul'da yok; Frankfurt NAT kullanmak cross-zone transfer maliyeti doğurur)
- Control plane iletişimi: Worker node (Istanbul) ↔ API Server (Frankfurt) ~5ms ek gecikme
- DB/Cache erişimi: Pod (Istanbul) → Percona / Redis (EC2, Istanbul Local Zone'da) - Frankfurt'a veri çıkmaz, KVKK uyumlu
Not: Istanbul Local Zone, AWS mimarisinde standart bir Availability Zone gibi davranır - subnet, route table, security group mantığı aynıdır. Fark yalnızca desteklenen servis setindedir. Cross-zone transfer maliyetleri standart AZ'lara kıyasla küçük farklılıklar gösterebilir.
NAT Gateway Alternatifi: Açık Kaynak ile Maliyet Düşürme
Istanbul Local Zone'da NAT Gateway yok. Varsayılan yöntem Frankfurt'taki NAT Gateway'i kullanmak - ama bu hem cross-zone veri transferi maliyeti doğurur hem de tüm çıkan trafik Frankfurt'tan geçer.
Daha ucuz ve Türkiye'de kalan alternatifler:
|
Çözüm |
Açıklama |
Maliyet |
|
EC2 tabanlı NAT, Terraform modülü mevcut |
~$4-8/ay (t4g.nano) |
fck-nat
Terraform ile kurulum:
Istanbul Local Zone subnet'indeki route table'ı Frankfurt NAT yerine bu instance'a yönlendirdiğinizde trafik Türkiye'de kalır ve cross-zone maliyeti ortadan kalkar.
Serinin devamı için takipte kalın → Bölüm 2: Temel Altyapı - Gereksinimler, Terragrunt Yapısı ve VPC Kurulumu
