1. GİRİŞ

Bulut altyapısının kod olarak tanımlanması (Infrastructure as Code — IaC) modern yazılım mühendisliğinin temel taşlarından biri haline geldi. Terraform, sağlayıcı‑agnostik yaklaşımı ve deklaratif dil/plan‑apply döngüsü ile AWS başta olmak üzere çok sayıda bulut sağlayıcısında altyapı kurulumunu tekrarlanabilir, incelenebilir ve otomatik hale getirir. Bu rehber, Terraform ile AWS üzerinde production‑grade altyapı kurmak isteyen mühendisler için hem kavramsal hem de pratik adımlar sunar.

Bu konu neden konuşuluyor?

Şirketler daha hızlı teslimat, daha düşük insan hatası ve altyapı üzerinde daha iyi kontrol ister. IaC ile bu hedeflere ulaşmak mümkün ancak hatalı tasarım, zayıf güvenlik ve eksik test uygulamaları büyük operasyonel riskler oluşturur. Terraform, doğru kullanıldığında hem hız hem güvenlik sağlar; yanlış kullanıldığında ise felaket maliyetlerine yol açabilir. Bu yüzden sağlam rehberlik önemlidir.

Kimler için önemli?

• Altyapı, platform ve DevOps mühendisleri
• Bulut mimarları
• CI/CD sorumluları ve SRE ekipleri

Hangi problemleri çözüyor?

• Kaynakların tekrarlanabilir ve versionlanabilir şekilde oluşturulması
• İnsan kaynaklı konfigürasyon hatalarının azaltılması
• Maliyet, güvenlik ve uyumluluk kontrollerinin otomasyona dahil edilmesi

2. KAVRAMSAL TEMELLER

2.1 Terraform nedir?

Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir IaC aracıdır. Declarative HCL (HashiCorp Configuration Language) kullanarak kaynaklar tanımlanır; `terraform plan` ile değişiklikler ön izlenir, `terraform apply` ile uygulanır. Terraform state dosyası (state) mevcut altyapı durumunu saklar ve sonraki değişikliklerin hesaplanmasında referans olarak kullanılır.

2.2 Temel kavramlar ve bileşenler

• Provider: AWS gibi bulut sağlayıcılarıyla etkileşimi sağlayan eklenti.
• Resource: Oluşturulan AWS örnekleri (EC2, VPC, S3 vb.).
• Module: Yeniden kullanılabilir altyapı bileşenleri.
• State: Terraform'un mevcut altyapı durumunu tuttuğu dosya (remote backend önerilir — S3+DynamoDB locking gibi).
• Workspace: Aynı konfigürasyonun farklı ortamlar için izole edilmesi (dev, staging, prod).

2.3 AWS ile ilgili özel hususlar

AWS kaynaklarının idempotent ve güvenli oluşturulması için IAM politikaları, resource naming, tagging ve region/az seçimleri mimarinin erken aşamasında ele alınmalıdır. Ayrıca state güvenliği (S3 + encryption) ve state lock (DynamoDB) production ortamlar için zorunludur.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi ve workflow

Tipik workflow: 1) Terraform kodu GIT'te tutulur; 2) Pull Request ile değişiklikler gözden geçirilir; 3) CI pipeline `terraform fmt`, `terraform validate`, `terraform plan` ve policy taramaları (Sentinel/OPA) çalıştırır; 4) Onay sonrası `terraform apply` tetiklenir; 5) State remote backend'e yazılır ve lock mekanizması kullanılır. Bu döngü, altyapı değişikliklerinin güvenli ve izlenebilir olmasını sağlar.

3.2 Bileşenler

• VPC ve networking: Subnet, route table, NAT gateway, security groups tasarımı.
• Compute: EC2, Auto Scaling Group, Launch Templates veya EKS/Fargate çözümleri.
• Storage: S3 bucket'lar (lifecycle politikaları), EBS, EFS gibi kaynaklar.
• Identity & Access Management: IAM roller, politikalar, instance profile ve KMS anahtarları.
• Observability: CloudWatch metric/log/alarm, OpenTelemetry collector entegrasyonları.

3.3 Veri akışı ve state yönetimi

Terraform state dosyası kritik bir bileşendir. Remote state S3 (şifrelenmiş) + DynamoDB lock ile birlikte kullanıldığında paralel apply'lerin yol açacağı sorunlar engellenir. State'e hassas veri yazılmamalı; sensitive çıktılar için secure storage (Secrets Manager) tercih edilmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix / büyük ölçekli altyapılar

Büyük şirketler Terraform benzeri IaC araçlarını modüler hale getirip organizasyon çapında kullanır. Modüller, şirket içi standartları zorunlu kılar ve güvenlik/uyumluluk gereksinimlerini merkezi olarak uygular.

4.2 Startuplar — hızlı iterasyon

Startuplar hızlı prototipleme için Terraform modüllerini kullanır; ancak production'a geçerken state yönetimi ve politika otomasyonu kritik hale gelir. Hızlı ama kontrolsüz değişim risklidir.

4.3 Kurumsal kullanım: Bankacılık ve fintech

Uyumluluk gereksinimleri (PCI, SOC2) nedeniyle altyapı otomasyonu sıkı denetimlerle desteklenir: immutable infrastrucure, policy as code ve audit logging ön plandadır.

4.4 AI/ML altyapıları

GPU kümeleri ve model serving altyapıları Terraform ile kurulur; maliyet optimizasyonu, autoscaling ve GPU allocation politikaları iyi tasarlanmalıdır.

4.5 Örnek pratik akış

Basit bir uygulama için: VPC + public/private subnetler, RDS (multi‑AZ), EKS cluster ve S3 artifact storage oluşturulur. Her kaynak için tagging, IAM rolleri ve lifecycle politikaları tanımlanır. Bu bileşenler modüller halinde paketlenir ve farklı ortamlar için parametrize edilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Tekrarlanabilirlik: Aynı konfigürasyonla farklı ortamlar oluşturulabilir.
• İzlenebilirlik: Değişiklikler PR ile izlenir, plan diff'leri incelenir.
• Otomasyon: CI/CD ile altyapı yaşam döngüsü otomatikleşir.

Dezavantajlar

• State management karmaşıklığı: State'in bozulması veya yanlış el ile müdahale ciddi sorunlara yol açar.
• Provider sürüm uyumsuzlukları: Terraform provider ve AWS API değişiklikleri uyumluluk sorunları yaratabilir.
• Güvenlik riskleri: Hassas verinin state içinde saklanması tehlikeli olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo Terraform ve bazı alternatifleri karşılaştırır.

7. EN İYİ PRATİKLER

Production kullanımı

• Remote state S3 + DynamoDB locking kullanın ve state'i encryption ile koruyun.
• Modüler yapı: küçük, test edilebilir modüller yazın; public/private module ayrımına dikkat edin.
• CI pipeline: `fmt`, `validate`, `tflint`/`checkov`, `plan` ve otomatik policy taramaları ekleyin.

Performans optimizasyonu

• Kaynak sayısını optimize edin: gereksiz replication ve over‑provisioning'den kaçının.
• State'in büyümesini kontrol edin: büyük state parçalarını ayırın (ör. ayrı state'ler: network, compute, data).

Güvenlik

• Hassas verileri state içinde saklamayın; secrets manager ve KMS kullanın.
• Least privilege prensibini uygulayan IAM rolleri oluşturun ve rol bazlı erişim kontrolleri sağlayın.
• Policy as Code ile güvenlik kurallarını CI'de zorunlu hale getirin.

İzleme ve operasyon

• Change management: plan çıktıları arşivlenmeli ve audit log tutulmalı.
• Disaster recovery: state yedekleme ve restore prosedürleri dokümante edilmeli.
• Rollback stratejileri: immutable patterns ve canary yaklaşımı ile güvenli rollback planları kurun.

8. SIK YAPILAN HATALAR

• State'i local tutmak — production'da remote backend kullanılmalı.
• Modülleri aşırı özelleştirip yeniden kullanılabilirliği düşürmek.
• IAM policy'lerini geniş yetkilerle oluşturmak (wildcard izinler).
• Plan çıktılarını göz ardı ederek doğrudan apply yapmak.

9. GELECEK TRENDLER

9.1 Policy as Code ve otomatik uyumluluk

Güvenlik otomasyonu, IaC pipelines içinde derinleşecek; OPA, Sentinels ve benzeri araçlar uyumluluğu CI seviyesinde sağlayacak.

9.2 Yapay zekâ destekli öneriler

AI, terraform plan analizleri yapıp maliyet/güvenlik önerileri sunacak; potansiyel hataları önceden tespit eden modeller yaygınlaşacak.

9.3 Multi‑cloud ve federated state yönetimi

Organizasyonlar multi‑cloud stratejilerini IaC ile daha güvenli yönetmek isteyecek; federated state ve cross‑account erişim modelleri gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Terraform state nedir ve neden önemli?

   State, Terraform'un mevcut altyapı durumunu tuttuğu dosyadır; doğru yönetilmediğinde çakışmalar ve veri kayıpları oluşabilir.

2. State'i nasıl güvenli tutarım?

   Remote backend (S3) + encryption + DynamoDB locking kullanın ve IAM erişimini kısıtlayın.

3. Modül yazarken nelere dikkat etmeliyim?

   Parametrizasyon, input/output sınırlandırması ve dokümantasyon önemli; side‑effect içeren kaynaklardan kaçının.

4. Terraform plan'ı kim onaylamalı?

   Critical değişiklikler için insan onayı önerilir; CI süreçlerinde otomatik policy taramaları çalıştırılmalı.

5. Hassas değerleri nasıl yönetirim?

   Secrets Manager veya SSM Parameter Store kullanın; state içinde plaintext saklamayın.

6. Terraform sürüm yönetimi neden önemli?

   Provider ve Terraform sürümleri arasında uyumsuzluklar oluşabilir; sürüm pinleme ve upgrade stratejisi oluşturun.

7. Terraform ile Kubernetes kaynaklarını nasıl yönetmeliyim?

   Kubernetes provider veya Helm provider kullanabilirsiniz; ancak cluster içi konfigurasyonlar için GitOps çözümleri (ArgoCD) tercih edilebilir.

8. State bozulduğunda ne yapmalıyım?

   State restore planı ve son bilinen iyi state yedeğini kullanarak adım adım restore uygulayın; manual state edit'leri son çare olmalıdır.

Anahtar Kavramlar

IaC

Altyapının kod aracılığıyla tanımlanması ve yönetilmesi.

State

Terraform'un altyapı durum bilgisini tuttuğu dosya.

Module

Yeniden kullanılabilir Terraform yapı bloğu.

Provider

AWS gibi kaynak sağlayıcıyla etkileşim sunan eklenti.

Policy as Code

Uyumluluk ve güvenlik kurallarını kodla ifade etme yaklaşımı.

Öğrenme Yol Haritası

1. 0–1 ay: AWS temelleri, VPC, EC2, S3 ve IAM kavramlarını öğrenin.
2. 1–3 ay: Terraform temel yapı taşları, HCL, provider konfigürasyonu, basit modüller yazın.
3. 3–6 ay: Remote state, locking, modüler yapı, CI entegrasyonu ve temel policy as code uygulamaları.
4. 6–12 ay: Production‑grade pattern'ler, multi‑region stratejileri, DR planları ve güvenlik entegrasyonları.
5. 12+ ay: Advanced state management, federation, multi‑cloud stratejileri ve AIOps destekli altyapı yönetimi.