AWS Istanbul Local Zone ile KVKK Uyumlu Cloud Mimarisi - Bölüm 4: Production'a Taşımak

Bu blog, AWS Istanbul Local Zone ile KVKK Uyumlu Cloud Mimarisi - Bölüm 3: Node'lar ve Servisler'in devamıdır.

Bu yazıda kurulum boyunca karşılaştığımız tüm hataları ve çözümlerini, maliyet analizini ve production için best practices listesini paylaşıyorum.

11. Karşılaşılan Sorunlar ve Çözümleri

Bu kurulum boyunca karşılaştığımız tüm hatalar ve çözümleri:

1. EKS Control Plane Subnet Hatası

Error: at least 2 subnets in different availability zones required

Neden: Yalnızca eu-central-1-ist-1a subnet'i verilmişti. Control plane Local Zone subnet'i kabul etmez ve minimum 2 standart AZ gerektirir.

Çözüm:

# Sadece eu-central-1a ve eu-central-1b (index 0 ve 1)
subnet_ids = slice(dependency.vpc.outputs.private_subnets, 0, 2)

2. VPC Module region Unsupported Argument

Error: An argument named "region" is not expected here.

Neden: VPC module 6.x, AWS Provider v6'ya özgü argüman ekledi. EKS module 20.x, Provider v5 gerektiriyor.

Çözüm: VPC module'ü 5.19.0'a downgrade et.

3. SSO Backend Uyumsuzluğu

Error: error configuring S3 Backend: no valid credential sources found

Neden: Terraform S3 backend sso_session formatını desteklemiyor.

Çözüm:

eval "$(aws configure export-credentials --profile hepapi-sso --format env)"

4. Helm Provider v3 Breaking Change

Error: Unsupported block type - "kubernetes"

Neden: Helm provider v3, kubernetes {} blok syntax'ını kaldırdı.

Çözüm — tüm provider.tf dosyalarında:

# ÖNCE (v2)
provider "helm" {
  kubernetes {
    host = var.kube_host
    exec {
      command = "aws"
    }
  }
}

# SONRA (v3)
provider "helm" {
  kubernetes = {
    host = var.kube_host
    exec = {
      command = "aws"
    }
  }
}

set {} blokları da değişti:

# ÖNCE (v2)
dynamic "set" {
  for_each = var.sets
  content {
    name  = set.value.name
    value = set.value.value
  }
}

# SONRA (v3)
set = var.sets

5. IAM Module "Unreadable Directory" Hatası

Error: Unreadable module directory — no Terraform files found in
.terraform/modules/lb_role/modules/iam-role-for-service-accounts-eks

Neden: IAM module v6, iç dizin yapısını değiştirdi. Versiyon pinlenmemişti ve v6 indirildi.

Çözüm:

source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
version = "~> 5.52.0"  # v6'ya geçmesin

6. Karpenter Replicas=0

kubectl get pods -n kube-system -l app.kubernetes.io/name=karpenter
# No resources found

Neden: Helm values'ta replicas: 0 olarak set edilmişti.

Çözüm: env.hcl'de replicas = "1" yap.

7. EKS Access Entry Invalid Principal

Error: InvalidParameterException: principalArn is not valid

Neden: Mevcut olmayan bir IAM user ARN (arn:aws:iam::ACCOUNT:user/username) verilmişti.

Çözüm: SSO role ARN kullan (user ARN değil):

aws iam list-roles --profile hepapi-sso \
  --query 'Roles[?contains(RoleName, `AWSReservedSSO`)].Arn'

12. Maliyet Analizi

Local Zone kullanımı standart bölgelere göre bazı maliyet farklılıkları içerir.

EC2 Instance Maliyeti

Local Zone instance'ları standart AZ fiyatının yaklaşık %10-20 üzerinde fiyatlanır:

Güncel fiyatlar için AWS Pricing sayfasını kontrol edin, Local Zone fiyatları düzenli güncellenir.

Spot Instance Yok

Standart AZ'larda Spot ile %60-70 tasarruf mümkünken, Local Zone'da bu seçenek yoktur. Karpenter ve node group konfigürasyonunda ON_DEMAND zorunludur. Bu maliyet planlamasında kritik bir faktör.

Cross-Zone Data Transfer

İki ek cross-zone ücret kategorisi var:

Yüksek egress trafiğiniz varsa (video streaming, büyük dosya indirme) bu rakamlar önemli olabilir.

Genel Değerlendirme

Local Zone maliyeti standart bölgeye göre %20-30 daha yüksek çıkabilir. Ancak elde edilen gecikme avantajı (~5-8ms vs ~35-40ms) latency-sensitive uygulamalar için bu maliyeti fazlasıyla karşılar. KVKK uyumu açısından bakıldığında ise on-premise maliyetiyle kıyaslandığında Local Zone çok daha rekabetçi.

13. Best Practices Özeti

Mimari

• Control plane için asla Local Zone subnet kullanma — 2 standart AZ şart
• Subnet'leri isim değil index ile ayır — VPC module sıra garantisi verir
• Istanbul node'larını label ile işaretle (topology: local-zone, zone: istanbul)
• ALB için Ingress'e alb.ingress.kubernetes.io/subnets: eu-central-1-ist-1a annotation'ı ekle

Karpenter

• topology.kubernetes.io/zone: eu-central-1-ist-1a olmadan NodePool tüm zone'lara node açar
• instance-generation Gt 6 ile sadece c7i/m7i/r7i hedefle — 6. nesil Istanbul'da yok
• capacity-type: on-demand zorunlu, Spot kullanılamaz

Storage

• EBS StorageClass'ta volumeBindingMode: WaitForFirstConsumer kullan
• Hardcoded zone topology pod migration'da volume kaybına yol açar

Versiyon Yönetimi

• Tüm module ve helm versiyonlarını env.hcl'de merkezi tut
• Provider versiyonlarını ~> ile minor seviyede sabitle
• Module yükseltmeden önce provider uyumluluğunu mutlaka test et

Maliyet

• Yüksek egress trafiği varsa cross-zone transfer ücretlerini hesapla
• Spot kullanamayacağını baştan maliyet modeline yansıt
• Local Zone fiyat farkını (~%15-20) rezervasyon veya savings plan ile azaltabilirsin

Sonuç

Istanbul Local Zone, KVKK uyumu arayan Türkiye'deki şirketler için gerçek bir çıkış noktası. Veri Türkiye'de kalıyor, modern cloud-native altyapı kullanılabiliyor ve Frankfurt'a kıyasla gecikme ~5-6x oranında düşüyor.

Kurulum standart EKS'ten daha karmaşık: control plane Local Zone'da çalışmıyor, Spot yok, NAT Gateway yok. ALB ise alb.ingress.kubernetes.io/subnets: eu-central-1-ist-1a annotation'ı ile doğrudan Istanbul'da oluşturulabiliyor. Bu kısıtlamaları anlayarak tasarladığınız subnet stratejisi ve Karpenter konfigürasyonu ile production-grade bir cluster kurabilirsiniz.

Kurulum sırası:

VPC → EKS → Node Group → Karpenter → EBS CSI → ALB Controller

Kodların tamamına GitHub üzerinden ulaşabilirsiniz.

Profesyonel desteğe ihtiyacınız olursa, bize info@hepapi.com adresinden ulaşabilirsiniz.