Bölgesel kesintiler iş sürekliliğinizi tehdit mi ediyor? AWS ve Terraform kullanarak çok bölgeli bir felaket kurtarma (DR) mimarisi kurmayı adım adım öğrenin, sistemlerinizi kesintisiz çalıştırın ve veri kayıplarını en aza indirin. Günümüzün dijital dünyasında, işletmeler için kesintisiz hizmet sunumu, sadece bir tercih değil, aynı zamanda zorunluluk haline gelmiştir. Peki, bir veri merkezinde yaşanan bölgesel bir elektrik kesintisi, doğal afet veya geniş çaplı bir siber saldırı durumunda şirketinizin operasyonları ne kadar dayanıklı? Bu tür senaryolar, sadece ciddi finansal kayıplara yol açmakla kalmaz, aynı zamanda müşteri güvenini sarsar ve marka itibarını zedeler. İşte tam da bu noktada, çok bölgeli bir felaket kurtarma (Disaster Recovery – DR) stratejisi devreye girer ve iş sürekliliğinin sigortası niteliğini taşır.
Geleneksel felaket kurtarma yaklaşımları genellikle tek bir yedek site veya bölgeye odaklanırken, bulut bilişimin sunduğu imkanlar sayesinde, artık birden fazla coğrafi bölgeye yayılan, daha esnek ve daha dayanıklı sistemler inşa edebiliriz. Amazon Web Services (AWS) gibi bulut sağlayıcıları, dünya genelinde birbirinden bağımsız birçok coğrafi bölge (Region) sunarak bu imkanı bize sağlıyor. Ancak bu karmaşık altyapıyı manuel olarak yönetmek hem zaman alıcı hem de hataya açık olabilir. İşte tam bu aşamada, altyapıyı kod olarak (Infrastructure as Code – IaC) tanımlamanın gücünü kullanan Terraform gibi araçlar, bize büyük bir kolaylık sunar. Terraform, karmaşık AWS kaynaklarını tutarlı, tekrarlanabilir ve sürüm kontrolüne tabi bir şekilde dağıtarak felaket kurtarma kurulumlarını otomatize etmemizi sağlar. Bu makalede, çok bölgeli bir felaket kurtarma kurulumunun temel prensiplerinden başlayarak, AWS’nin sunduğu hizmetleri ve Terraform’un gücünü birleştirerek nasıl sağlam bir DR mimarisi oluşturabileceğinizi adım adım ele alacağız. Hedefimiz, okuyucunun konuyu sıfırdan anlayarak kendi DR stratejilerini geliştirebilmesini sağlamaktır. Bu yolculukta gerçek dünya senaryolarına ve pratik kod örneklerine de yer vereceğiz.
Temel Kavramlar: Felaket Kurtarma Modelleri ve Metrikleri Nelerdir?
Herhangi bir felaket kurtarma stratejisi geliştirmeden önce, işinizin gereksinimlerini anlamak ve doğru hedefleri belirlemek kritik öneme sahiptir. Bu hedefler, genellikle iki ana metrikle ifade edilir: RTO ve RPO. Ayrıca, farklı felaket kurtarma senaryolarına uygun çeşitli modeller bulunmaktadır. Bu bölümde, bu temel kavramları detaylı bir şekilde inceleyerek, hangi stratejinin sizin için en uygun olabileceğine dair net bir anlayış kazanmanızı sağlayacağız. Unutmayın ki doğru strateji seçimi, hem maliyetleri optimize etmenize hem de felaket anında hızlı ve etkili bir kurtarma gerçekleştirmenize yardımcı olacaktır.
RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) Nedir ve Neden Önemlidir?
RTO (Recovery Time Objective – Kurtarma Süresi Hedefi), bir felaket sonrası hizmetlerin ne kadar süre içinde yeniden çalışır hale gelmesi gerektiğini ifade eder. Yani, sistemleriniz tamamen kesintiye uğradıktan sonra, maksimum ne kadar süre içinde normal operasyonlara dönebileceğinizi gösteren bir hedeftir. Örneğin, bir web sitesinin RTO’su 4 saat ise, felaketten sonra en geç 4 saat içinde web sitesinin erişilebilir olması gerekir. Bu süre; işinizin kritikliği, müşteri beklentileri ve finansal kayıplar gibi faktörlere bağlı olarak belirlenir. RTO’yu ne kadar kısaltırsanız, genellikle o kadar çok maliyetle karşılaşırsınız, çünkü daha kısa RTO’lar daha fazla kaynak ve otomasyon gerektirir.
RPO (Recovery Point Objective – Kurtarma Noktası Hedefi) ise, bir felaket durumunda kaybedilebilecek maksimum veri miktarıdır. Bir diğer deyişle, felaketin meydana geldiği an ile en son geçerli yedekleme veya replikasyon noktası arasındaki zaman dilimini ifade eder. Eğer bir veritabanının RPO’su 15 dakika ise, felaket anında en fazla 15 dakikalık veri kaybını kabul ediyorsunuz demektir. RPO ne kadar düşük olursa, veri kaybı riski o kadar azalır. Sıfıra yakın RPO’lar için genellikle sürekli veri replikasyonu veya senkronizasyonu gibi daha karmaşık ve maliyetli çözümler gereklidir. İş birimleriyle yakın çalışarak bu hedefleri gerçekçi bir şekilde belirlemek, başarılı bir DR stratejisinin temelini oluşturur.
Felaket Kurtarma Stratejileri: Soğuk, Ilık ve Sıcak Bekleme Modelleri
AWS gibi bulut ortamlarında uygulanabilecek çeşitli felaket kurtarma stratejileri bulunmaktadır. Bu stratejiler genellikle RTO ve RPO hedeflerinize, bütçenize ve karmaşıklık toleransınıza göre seçilir:
- Yedekleme ve Geri Yükleme (Backup and Restore – Soğuk Bekleme): Bu en temel ve en uygun maliyetli yaklaşımdır. Verileriniz düzenli olarak farklı bir bölgeye yedeklenir. Bir felaket durumunda, bu yedeklerden yeni bir altyapı oluşturulur ve veriler geri yüklenir. RTO ve RPO hedefleri genellikle saatler veya günler mertebesindedir. Örneğin, S3’e yedeklenen EBS snapshot’ları veya RDS anlık görüntüleri bu kategoriye girer. Bu model, kritik olmayan uygulamalar veya maliyeti ön planda tutan senaryolar için uygundur.
- Pilot Light (Ilık Bekleme): Bu model, temel altyapının (veri tabanları, ağ yapılandırması gibi) yedek bölgede sürekli çalışır durumda tutulduğu bir yaklaşımdır. Uygulama sunucuları gibi daha maliyetli kaynaklar ise felaket anına kadar kapalı veya minimum kapasitede bekletilir. Bir felaket durumunda, bu kapalı kaynaklar devreye alınır ve kapasite artırılarak tam operasyonel hale getirilir. RTO ve RPO genellikle dakikalar veya saatler mertebesindedir. RDS Read Replica’lar veya replike edilmiş S3 bucket’ları bu stratejinin temelini oluşturabilir. Daha düşük RTO’lar elde etmek isteyen ancak maliyetleri de düşündüren işletmeler için ideal bir çözümdür.
- Warm Standby (Sıcak Bekleme – gelişmiş Ilık Bekleme): Pilot Light’a benzer ancak yedek bölgedeki altyapı, birincil bölgenin tam kapasitesinin küçük bir kısmıyla sürekli çalışır durumdadır. Bu, felaket anında daha hızlı bir geçiş sağlar, çünkü sistemler zaten minimum yükle çalışmaktadır. Ölçeklendirme işlemi daha hızlı gerçekleşir. RTO ve RPO genellikle dakikalar mertebesindedir. Genellikle Auto Scaling Grupları ve Load Balancer’lar ile birlikte kullanılır.
- Multi-Site Active-Active (Sıcak Bekleme – Tamamen Etkin): Bu, en karmaşık ve en maliyetli ancak en yüksek kullanılabilirliği ve en düşük RTO/RPO’yu sunan yaklaşımdır. Uygulama aynı anda birden fazla bölgede tam kapasiteyle çalışır ve gelen trafik bu bölgeler arasında dağıtılır. Veri replikasyonu genellikle senkron veya near-real-time (neredeyse gerçek zamanlı) olarak yapılır. Bu sayede, bir bölgedeki felaket durumunda diğer bölge anında trafiği devralabilir ve neredeyse hiç kesinti yaşanmaz. RTO ve RPO genellikle saniyeler mertebesindedir.
AWS Region’ları coğrafi olarak ayrılmış, bağımsız veri merkezleri kümeleridir ve her Region, kendi içinde izole edilmiş birden fazla Availability Zone (AZ) içerir. AZ’ler, bir Region içindeki ayrı veri merkezleridir ve birbirlerinden bağımsız güç, ağ ve soğutma sistemlerine sahiptir. Çok bölgeli bir DR kurulumunda, farklı Region’ları kullanarak bölgesel felaketlere karşı korunurken, her bir Region içindeki AZ’ler arası dağıtım ile de AZ bazlı kesintilere karşı dayanıklılık sağlanır. Bu iki katmanlı yaklaşım, maksimum dayanıklılık için kritik öneme sahiptir.
Terraform ile Altyapıyı Kod Olarak Tanımlamak: Neden IaC Tercih Ediyoruz?
Felaket kurtarma mimarileri genellikle birden fazla bölgeye yayılan karmaşık altyapılar gerektirir. Bu altyapıyı manuel olarak kurmak ve yönetmek, hem zaman alıcı hem de insan hatasına açık bir süreçtir. İşte bu noktada, Altyapıyı Kod Olarak (Infrastructure as Code – IaC) yaklaşımı devreye girer. IaC, sunucular, ağlar, depolama ve veritabanları gibi altyapı kaynaklarının yapılandırmasını ve yönetimini kod aracılığıyla otomatize etme pratiğidir. Terraform ise bu IaC araçlarının en popüler ve güçlü örneklerinden biridir. Neden mi IaC ve Terraform’u felaket kurtarma için tercih etmeliyiz? Çünkü otomasyon, tutarlılık ve hız, DR senaryolarında hayati öneme sahiptir.
Terraform’un Felaket Kurtarmadaki Rolü Nedir?
Terraform, felaket kurtarma stratejilerini uygulamada bir dizi avantaj sunar:
- Otomasyon ve Hız: Bir felaket anında her saniye değerlidir. Terraform ile yedek bölgedeki tüm altyapıyı saniyeler içinde ayağa kaldırabilirsiniz. Manuel kurulumun aksine, uzun süren yapılandırma işlemleriyle uğraşmak zorunda kalmazsınız. Bu otomasyon, RTO hedeflerinize ulaşmanızı kolaylaştırır.
- Tutarlılık ve Tekrarlanabilirlik: İnsan hatası, manuel süreçlerin kaçınılmaz bir parçasıdır. Terraform, altyapınızı kod olarak tanımladığınız için, her dağıtımın aynı sonucu vermesini sağlar. Bu, ana ve yedek bölgeler arasındaki tutarlılığı garantiler ve kurtarma süreçlerindeki hataları minimuma indirir. Altyapınızın bir kopyasını farklı bir bölgede, hatta farklı bir AWS hesabında bile tamamen aynı şekilde oluşturabilirsiniz.
- Sürüm Kontrolü ve Geri Alma: Terraform yapılandırma dosyaları (
.tfuzantılı dosyalar), Git gibi sürüm kontrol sistemlerinde saklanabilir. Bu sayede, altyapı değişikliklerini takip edebilir, kimin ne zaman hangi değişikliği yaptığını görebilir ve gerektiğinde önceki bir versiyona geri dönebilirsiniz. Bu özellik, özellikle karmaşık DR mimarilerinde hata ayıklama ve denetim için paha biçilmezdir. - Maliyet Optimizasyonu: Pilot Light gibi DR stratejilerinde, yedek bölgede sadece minimum kaynakları çalışır durumda tutmak istenir. Terraform ile bu minimum altyapıyı kolayca tanımlayabilir ve felaket durumunda ek kaynakları anında devreye alabilirsiniz. Bu, gereksiz kaynakların çalıştırılmasını önleyerek maliyetleri düşürmeye yardımcı olur.
Terraform’un temel çalışma prensibi oldukça basittir: İstenen durumu (desired state) tanımlarsınız ve Terraform, mevcut durumu (current state) bu istenen duruma getirmek için gerekli AWS API çağrılarını yapar. Temel Terraform komutları şunlardır:
terraform init: Terraform yapılandırma dizinini başlatır, gerekli sağlayıcı eklentilerini (AWS provider gibi) indirir.terraform plan: Yapılandırma dosyalarında tanımlanan kaynakları mevcut durumla karşılaştırır ve yapılacak değişiklikleri gösterir. Bu komut, bir “kuru çalıştırma” gibidir ve gerçek bir değişiklik yapmaz.terraform apply:plançıktısında gösterilen değişiklikleri AWS hesabınızda uygular ve kaynakları oluşturur veya günceller.terraform destroy: Terraform tarafından oluşturulan tüm kaynakları temizler. Bu, test ortamlarını hızlıca kaldırmak veya maliyetleri düşürmek için faydalıdır.
Terraform projeleri genellikle main.tf (ana kaynak tanımları), variables.tf (değişken tanımları) ve outputs.tf (çıktı tanımları) gibi dosyalardan oluşur. Örneğin, farklı bir bölgede bir EC2 örneği oluşturmak için aşağıdaki gibi bir yapılandırma dosyası kullanabiliriz:
# main.tf
# AWS sağlayıcısını us-east-1 bölgesinde yapılandır
provider "aws" {
region = "us-east-1"
alias = "primary" # Birincil bölge için takma ad
}
# AWS sağlayıcısını us-west-2 bölgesinde yapılandır (yedek bölge)
provider "aws" {
region = "us-west-2"
alias = "secondary" # İkincil bölge için takma ad
}
# Birincil bölgede EC2 örneği
resource "aws_instance" "primary_web_server" {
provider = aws.primary
ami = "ami-0abcdef1234567890" # Lütfen güncel bir AMI ID kullanın
instance_type = "t2.micro"
tags = {
Name = "PrimaryWebServer"
}
}
# İkincil bölgede (yedek) EC2 örneği
resource "aws_instance" "secondary_web_server" {
provider = aws.secondary
ami = "ami-0fedcba9876543210" # Lütfen güncel bir AMI ID kullanın
instance_type = "t2.micro"
tags = {
Name = "SecondaryWebServer"
}
# Bu örneği felaket anına kadar kapalı tutmak için yorum satırı olarak bırakıyoruz:
# user_data = file("bootstrap.sh") # Uygulama kurulumu için
# Bu kaynağın otomatik olarak oluşturulmasını engellemek için lifecycle bloğu kullanılabilir:
# lifecycle {
# prevent_destroy = true
# }
}
output "primary_instance_ip" {
description = "Birincil web sunucusunun genel IP adresi."
value = aws_instance.primary_web_server.public_ip
}
output "secondary_instance_ip" {
description = "İkincil web sunucusunun genel IP adresi (şu an kapalı)."
value = aws_instance.secondary_web_server.public_ip
}
Yukarıdaki örnekte, aynı anda iki farklı AWS bölgesinde kaynak tanımlayabiliyoruz. Bu esneklik, çok bölgeli DR kurulumları için Terraform'u vazgeçilmez kılar. Bu sayede, felaket anında yedek bölgedeki sunucuları anında başlatarak ve uygulama yapılandırmalarını devreye alarak hızlı bir geçiş sağlayabiliriz.
Çok Bölgeli Bir Felaket Kurtarma Senaryosu Oluşturma: Adım Adım Rehber
Artık temel kavramlara ve Terraform'un gücüne aşina olduğunuza göre, gerçek bir çok bölgeli felaket kurtarma (DR) senaryosu oluşturmanın adımlarına geçebiliriz. Bu bölümde, popüler bir DR stratejisi olan "Pilot Light" mimarisini temel alarak, birincil ve ikincil bölgelerde gerekli AWS kaynaklarını Terraform ile nasıl dağıtacağımızı adım adım inceleyeceğiz. Bu senaryo, küçük ve orta ölçekli bir e-ticaret sitesi gibi bir uygulamayı ele alacak ve veri tutarlılığını sağlamanın yanı sıra, felaket anında hızlı bir geçiş yapabilme yeteneğini gösterecektir.
Senaryo Seçimi: Pilot Light Mimarisi Nasıl Uygulanır?
Senaryomuz için birincil bölgemiz eu-central-1 (Frankfurt) ve ikincil bölgemiz eu-west-1 (Dublin) olacaktır. Uygulamamız, bir web sunucusu (EC2), bir ilişkisel veritabanı (RDS) ve statik varlıklar için bir S3 bucket'ından oluşmaktadır. Pilot Light stratejisinde, ikincil bölgede veritabanının bir kopyası (örneğin bir RDS Read Replica) ve S3 verilerinin replikasyonu sürekli olarak senkronize edilirken, EC2 web sunucusu gibi daha maliyetli işlem kaynakları felaket anına kadar minimalde tutulur veya kapatılır.
Bu yaklaşım, aktif-aktif bir setup kadar maliyetli değildir ancak yine de dakikalar içinde bir kurtarma sağlayarak Backup & Restore modelinden çok daha düşük RTO/RPO hedeflerine ulaşmamızı sağlar. Veri replikasyonu, bu stratejinin kalbidir. RDS için Multi-AZ dağıtımı veya Read Replica'lar kullanılırken, S3 için Cross-Region Replication (CRR) özelliği devreye girecektir. Felaket anında, ikincil bölgedeki Read Replica ana veritabanına terfi ettirilir, web sunucuları başlatılır ve DNS kayıtları ikincil bölgeye yönlendirilir.
Terraform ile Temel Altyapı Kurulumu
Şimdi, bu mimariyi Terraform ile nasıl oluşturacağımıza bakalım. İlk adım, AWS sağlayıcılarını her iki bölge için de yapılandırmaktır.
# providers.tf
provider "aws" {
region = "eu-central-1" # Birincil bölge
alias = "primary"
}
provider "aws" {
region = "eu-west-1" # İkincil bölge (felaket kurtarma)
alias = "secondary"
}
Ardından, her iki bölgede de temel ağ altyapısını (VPC, subnetler, güvenlik grupları) oluşturalım. Basitlik adına, her bölgede tek bir VPC ve iki alt ağ (bir genel, bir özel) tanımlayacağız. Gerçek bir senaryoda, üretim ortamında birden fazla AZ ve daha karmaşık ağ yapıları kullanmak gerekebilir.
# network.tf
# Birincil bölge (eu-central-1) VPC ve Subnetler
resource "aws_vpc" "primary_vpc" {
provider = aws.primary
cidr_block = "10.0.0.0/16"
tags = {
Name = "Primary-DR-VPC"
}
}
resource "aws_subnet" "primary_public_subnet" {
provider = aws.primary
vpc_id = aws_vpc.primary_vpc.id
cidr_block = "10.0.1.0/24"
availability_zone = "eu-central-1a" # Lütfen bölgenizdeki geçerli bir AZ kullanın
map_public_ip_on_launch = true
tags = {
Name = "Primary-Public-Subnet"
}
}
resource "aws_subnet" "primary_private_subnet" {
provider = aws.primary
vpc_id = aws_vpc.primary_vpc.id
cidr_block = "10.0.2.0/24"
availability_zone = "eu-central-1a" # Lütfen bölgenizdeki geçerli bir AZ kullanın
tags = {
Name = "Primary-Private-Subnet"
}
}
# İkincil bölge (eu-west-1) VPC ve Subnetler (Pilot Light için minimumda)
resource "aws_vpc" "secondary_vpc" {
provider = aws.secondary
cidr_block = "10.1.0.0/16"
tags = {
Name = "Secondary-DR-VPC"
}
}
resource "aws_subnet" "secondary_public_subnet" {
provider = aws.secondary
vpc_id = aws_vpc.secondary_vpc.id
cidr_block = "10.1.1.0/24"
availability_zone = "eu-west-1a" # Lütfen bölgenizdeki geçerli bir AZ kullanın
map_public_ip_on_launch = true
tags = {
Name = "Secondary-Public-Subnet"
}
}
resource "aws_subnet" "secondary_private_subnet" {
provider = aws.secondary
vpc_id = aws_vpc.secondary_vpc.id
cidr_block = "10.1.2.0/24"
availability_zone = "eu-west-1a" # Lütfen bölgenizdeki geçerli bir AZ kullanın
tags = {
Name = "Secondary-Private-Subnet"
}
}
# Güvenlik Grupları (Basit örnekler)
resource "aws_security_group" "primary_web_sg" {
provider = aws.primary
name = "primary-web-sg"
description = "Allow HTTP and SSH"
vpc_id = aws_vpc.primary_vpc.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_security_group" "secondary_web_sg" {
provider = aws.secondary
name = "secondary-web-sg"
description = "Allow HTTP and SSH"
vpc_id = aws_vpc.secondary_vpc.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
Veritabanı Replikasyonu (RDS Read Replica): Pilot Light modelinde, birincil bölgedeki RDS veritabanımızın bir Read Replica'sını ikincil bölgede tutarız. Bu, veri kaybını en aza indirmek için sürekli replikasyon sağlar. Felaket anında bu Read Replica ana veritabanına terfi ettirilebilir.
# database.tf
# Birincil bölgede RDS instance
resource "aws_db_instance" "primary_db" {
provider = aws.primary
allocated_storage = 20
engine = "mysql"
engine_version = "8.0.28"
instance_class = "db.t3.micro"
name = "ecommerce_db"
username = "admin"
password = "SecurePassword123" # Gerçek ortamda Secrets Manager kullanın
vpc_security_group_ids = [aws_security_group.primary_web_sg.id]
db_subnet_group_name = "primary-db-subnet-group" # Terraform ile oluşturulmalı
skip_final_snapshot = true # Üretim ortamında 'false' olmalı
multi_az = true # Yüksek erişilebilirlik için
tags = {
Name = "Primary-ECommerce-DB"
}
}
# İkincil bölgede Read Replica (Pilot Light için)
resource "aws_db_instance" "secondary_db_replica" {
provider = aws.secondary
engine = "mysql"
instance_class = "db.t3.micro"
identifier = "ecommerce-replica-db"
replicate_source_db = aws_db_instance.primary_db.identifier
vpc_security_group_ids = [aws_security_group.secondary_web_sg.id]
db_subnet_group_name = "secondary-db-subnet-group" # Terraform ile oluşturulmalı
skip_final_snapshot = true
multi_az = false # DR için yeterli, ana DB Multi-AZ ise
tags = {
Name = "Secondary-ECommerce-DB-Replica"
}
}
S3 Cross-Region Replication (CRR): Statik varlıklar ve yedeklemeler için kullanılan S3 bucket'larının otomatik olarak yedek bölgeye kopyalanması için CRR kullanırız.
# s3.tf
# Birincil bölge S3 Bucket
resource "aws_s3_bucket" "primary_assets_bucket" {
provider = aws.primary
bucket = "my-ecommerce-assets-primary-region"
acl = "private"
versioning {
enabled = true
}
tags = {
Name = "Primary-ECommerce-Assets"
}
}
# İkincil bölge S3 Bucket
resource "aws_s3_bucket" "secondary_assets_bucket" {
provider = aws.secondary
bucket = "my-ecommerce-assets-secondary-region"
acl = "private"
versioning {
enabled = true
}
tags = {
Name = "Secondary-ECommerce-Assets"
}
}
# Cross-Region Replication için gerekli IAM Role
resource "aws_iam_role" "s3_replication_role" {
name = "s3-replication-role"
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = "sts:AssumeRole",
Effect = "Allow",
Principal = {
Service = "s3.amazonaws.com"
}
},
],
})
}
resource "aws_iam_policy" "s3_replication_policy" {
name = "s3-replication-policy"
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = [
"s3:GetReplicationConfiguration",
"s3:ListBucket",
],
Effect = "Allow",
Resource = [
aws_s3_bucket.primary_assets_bucket.arn,
]
},
{
Action = [
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:GetObjectVersionTagging",
],
Effect = "Allow",
Resource = [
"${aws_s3_bucket.primary_assets_bucket.arn}/*",
]
},
{
Action = [
"s3:ReplicateObject",
"s3:ReplicateDelete",
"s3:ReplicateTags",
],
Effect = "Allow",
Resource = [
"${aws_s3_bucket.secondary_assets_bucket.arn}/*",
]
},
],
})
}
resource "aws_iam_role_policy_attachment" "s3_replication_attach" {
role = aws_iam_role.s3_replication_role.name
policy_arn = aws_iam_policy.s3_replication_policy.arn
}
# Cross-Region Replication yapılandırması
resource "aws_s3_bucket_replication_configuration" "primary_to_secondary" {
provider = aws.primary
role = aws_iam_role.s3_replication_role.arn
bucket = aws_s3_bucket.primary_assets_bucket.id
rule {
id = "replicate-all-objects"
status = "Enabled"
destination {
bucket = aws_s3_bucket.secondary_assets_bucket.arn
storage_class = "STANDARD"
replication_time {
status = "Enabled"
minutes = 15 # RPO hedefi
}
}
}
}
Web Sunucuları (EC2 ve Auto Scaling Group): Birincil bölgede aktif web sunucularımız olacak. İkincil bölgede ise Pilot Light stratejisine uygun olarak, felaket anına kadar bu sunucuları ya kapalı tutarız ya da minimum kapasitede (0 instance) bir Auto Scaling Group tanımlarız. Felaket durumunda bu grup ölçeklendirilir.
# webserver.tf
# Birincil bölge Web Sunucusu (Örnek)
resource "aws_instance" "primary_web_instance" {
provider = aws.primary
ami = "ami-0abcdef1234567890" # eu-central-1 için uygun bir AMI
instance_type = "t2.micro"
subnet_id = aws_subnet.primary_public_subnet.id
vpc_security_group_ids = [aws_security_group.primary_web_sg.id]
tags = {
Name = "Primary-ECommerce-WebServer"
}
}
# İkincil bölge Web Sunucusu için Launch Configuration ve Auto Scaling Group
# Pilot Light için ASG'yi min_size = 0, desired_capacity = 0 olarak ayarlıyoruz.
resource "aws_launch_configuration" "secondary_web_lc" {
provider = aws.secondary
name_prefix = "secondary-web-lc-"
image_id = "ami-0fedcba9876543210" # eu-west-1 için uygun bir AMI
instance_type = "t2.micro"
security_groups = [aws_security_group.secondary_web_sg.id]
# user_data = file("bootstrap.sh") # Uygulama kurulum betiği
lifecycle {
create_before_destroy = true
}
}
resource "aws_autoscaling_group" "secondary_web_asg" {
provider = aws.secondary
name = "secondary-web-asg"
launch_configuration = aws_launch_configuration.secondary_web_lc.name
vpc_zone_identifier = [aws_subnet.secondary_public_subnet.id]
min_size = 0 # Pilot Light: Normalde 0, felakette ölçeklenir
max_size = 2
desired_capacity = 0 # Pilot Light: Normalde 0, felakette ölçeklenir
health_check_type = "EC2"
termination_policies = ["OldestInstance"]
wait_for_capacity_timeout = "5m"
tags = [
{
key = "Name"
value = "Secondary-ECommerce-WebServer"
propagate_at_launch = true
}
]
}
Uygulama Dağıtımı ve DNS Yönlendirmesi
Uygulamanın kendisinin (kod tabanı) dağıtımı için genellikle CI/CD boru hatları kullanılır. Felaket anında, ikincil bölgedeki Auto Scaling Group tetiklenir, yeni EC2 örnekleri başlatılır ve bu örneklere uygulama kodu dağıtılır. En son adım ise DNS yönlendirmesidir. AWS Route 53 kullanarak, birincil bölgenin sağlık durumunu izleyebilir ve bir sorun algılandığında trafiği otomatik olarak ikincil bölgeye yönlendirebiliriz.
# dns.tf
resource "aws_route53_zone" "main" {
name = "example.com" # Alan adınızı buraya yazın
}
# Birincil bölge için DNS kaydı (örnek)
resource "aws_route53_record" "primary_app" {
zone_id = aws_route53_zone.main.zone_id
name = "app.example.com"
type = "A"
ttl = 60 # Düşük TTL, failover süresini kısaltır
records = [aws_instance.primary_web_instance.public_ip]
# Sağlık kontrolü ve failover için yorum satırı bırakılan kısım:
# set_identifier = "primary-region"
# failover_routing_policy {
# type = "PRIMARY"
# }
# health_check_id = aws_route53_health_check.primary_health_check.id
}
# İkincil bölge için DNS kaydı (örnek)
resource "aws_route53_record" "secondary_app" {
zone_id = aws_route53_zone.main.zone_id
name = "app.example.com"
type = "A"
ttl = 60
records = ["${aws_autoscaling_group.secondary_web_asg.name}.elb.amazonaws.com"] # ASG'nin arkasındaki Load Balancer DNS'i
# Sağlık kontrolü ve failover için yorum satırı bırakılan kısım:
# set_identifier = "secondary-region"
# failover_routing_policy {
# type = "SECONDARY"
# }
# health_check_id = aws_route53_health_check.secondary_health_check.id
# depends_on = [aws_autoscaling_group.secondary_web_asg]
}
# Health Check örnekleri (gerçek bir Load Balancer veya EC2 IP'si ile ilişkilendirilmelidir)
# resource "aws_route53_health_check" "primary_health_check" {
# fqdn = "primary-app.example.com" # Birincil uygulamanın Load Balancer DNS'i
# port = 80
# type = "HTTP"
# resource_path = "/health"
# failure_threshold = 3
# request_interval = 30
# }
# resource "aws_route53_health_check" "secondary_health_check" {
# fqdn = "secondary-app.example.com" # İkincil uygulamanın Load Balancer DNS'i
# port = 80
# type = "HTTP"
# resource_path = "/health"
# failure_threshold = 3
# request_interval = 30
# }
Yukarıdaki örnekler, birincil ve ikincil bölgelerde temel altyapının nasıl yapılandırılabileceğini gösteriyor. Gerçek bir senaryoda, Load Balancer'lar, NAT Gateway'ler, Internet Gateway'ler gibi ek ağ bileşenleri de eklenmelidir. Ayrıca, DNS failover mekanizmasını tam olarak kurmak için Route 53 sağlık kontrolleri ve politika tabanlı yönlendirme (failover routing policy) aktif olarak kullanılmalıdır. Birincil bölgedeki kaynaklar sağlık kontrolünü geçemediğinde, Route 53 otomatik olarak trafiği ikincil bölgedeki kaynaklara yönlendirecektir. Bu, felaket kurtarma sürecinin önemli bir otomasyon ayağıdır.
Vaka Analizi: Küçük Bir E-ticaret Sitesinin DR Kurulumu
Diyelim ki "Sepetim.com" adında küçük bir e-ticaret sitesi işletiyorsunuz. Ana müşteri kitleniz Avrupa'da, bu yüzden birincil AWS bölgeniz olarak Frankfurt'u (eu-central-1) seçtiniz. Ancak, bir bölgesel kesintinin işinizi tamamen durdurmasını istemiyorsunuz. RTO hedefiniz 1 saat, RPO hedefiniz ise 15 dakikadır.
Bu durumda, yukarıda gösterdiğimiz Pilot Light mimarisi Sepetim.com için idealdir. Terraform kullanarak:
- Frankfurt'ta tam işlevli bir uygulama altyapısı (Web sunucuları, RDS Multi-AZ veritabanı, S3 statik varlıklar) kurarsınız.
- Dublin'de (eu-west-1) ise bir RDS Read Replica'sını Frankfurt'taki ana veritabanından veri çekmek üzere yapılandırırsınız. S3 bucket'larınız için Cross-Region Replication'ı etkinleştirirsiniz.
- Dublin'de, web sunucularını barındıracak bir Auto Scaling Group'u
min_size = 0vedesired_capacity = 0olarak ayarlarsınız. Yani, felaket anına kadar bu sunucular aktif olmaz, maliyet yaratmaz. - Route 53 üzerinde, Sepetim.com domaini için birincil olarak Frankfurt'u gösteren bir A kaydı ve sağlık kontrolleri ile birlikte, ikincil olarak Dublin'deki Auto Scaling Group'un arkasındaki yük dengeleyiciyi gösteren bir failover kaydı oluşturursunuz.
Bir felaket anında (örneğin Frankfurt bölgesi tamamen devre dışı kaldığında):
- Route 53 sağlık kontrolleri Frankfurt'taki uygulamanın erişilemez olduğunu tespit eder.
- DNS kayıtları otomatik olarak Dublin'deki yedek siteye yönlendirilir.
- Dublin'deki RDS Read Replica, birincil veritabanına terfi ettirilir.
- Dublin'deki Auto Scaling Group'un
desired_capacitydeğeri manuel veya otomatik olarak artırılarak web sunucuları başlatılır. - Uygulama kodları ve statik varlıklar Dublin'deki yeni sunuculara ve replike edilmiş S3 bucket'ına yönlendirilir.
Bu sayede Sepetim.com, 15 dakikalık veri kaybı toleransı ve 1 saat içinde hizmete geri dönüş hedefiyle operasyonlarına devam edebilir. Bu, iş sürekliliği için oldukça pratik ve maliyet-etkin bir yaklaşımdır.
İleri Düzey Teknikler ve En İyi Uygulamalar: Daha Dayanıklı Sistemler İçin Neler Yapmalıyız?
Çok bölgeli felaket kurtarma kurulumu, temel kaynakları dağıtmakla bitmez. Gerçekten dayanıklı, maliyet etkin ve güvenli bir DR mimarisi oluşturmak için bazı ileri düzey teknikleri ve en iyi uygulamaları benimsemek şarttır. Bu bölüm, mevcut kurulumunuzu daha da güçlendirmek için atabileceğiniz ek adımları ve dikkat etmeniz gereken kritik noktaları ele alacaktır.
Maliyet Optimizasyonu Nasıl Sağlanır?
Felaket kurtarma, ek kaynaklar gerektirdiği için doğal olarak maliyetli olabilir. Ancak akıllı stratejiler ve otomasyon ile bu maliyetleri önemli ölçüde optimize edebilirsiniz:
- Pilot Light ve Warm Standby Modelini Doğru Kullanın: Tamamen aktif-aktif bir setup yerine, uygulamalarınızın kritiklik seviyesine göre Pilot Light veya Warm Standby modellerini tercih edin. Bu modellerde, yedek bölgede yalnızca minimum gerekli kaynakları (veri replikasyonu, temel ağ) çalışır durumda tutarak işlem maliyetlerini düşürebilirsiniz. Felaket anında devreye girecek EC2'leri ve diğer işlem kaynaklarını kapalı tutmak, en büyük maliyet tasarrufunu sağlar.
- On-Demand vs. Spot Instance Kullanımı: Kritik olmayan iş yükleri veya geçici test ortamları için ikincil bölgede Spot Instance'ları kullanarak önemli ölçüde maliyet tasarrufu sağlayabilirsiniz. Ancak, üretim ortamı için genellikle On-Demand veya Reserved Instance'lar daha güvenli bir seçenektir.
- Otomatik Kapatma ve Başlatma: Felaket kurtarma testleri sonrası veya gelişim/test ortamlarında kullanılmayan kaynakları otomatik olarak kapatmak için AWS Lambda ve CloudWatch gibi hizmetleri kullanarak otomasyon kuralları tanımlayın. Terraform ile bu otomasyonu da kod olarak yönetebilirsiniz.
- Depolama Sınıflarını Optimize Edin: S3'te replike ettiğiniz veriler için doğru depolama sınıfını seçmek önemlidir. Sık erişilmeyen veriler için S3 Infrequent Access (IA) veya S3 Glacier gibi daha uygun maliyetli depolama sınıflarını kullanmayı düşünebilirsiniz.
- Veri Transfer Maliyetleri: Bölgeler arası veri transferi maliyetli olabilir. Veri replikasyonunu optimize etmek, gereksiz transferleri azaltmak ve ağ mimarinizi dikkatlice tasarlamak önemlidir. Örneğin, sadece değişen verileri replike eden çözümleri tercih edin.
Güvenlik ve Kimlik Yönetimi (IAM) Önemleri
DR kurulumunda güvenlik, asla göz ardı edilmemesi gereken bir konudur. İki bölgeye yayılan bir mimaride güvenlik riskleri de iki katına çıkabilir:
- Minimum Yetki Prensibi (Least Privilege): Terraform tarafından kullanılan IAM rolleri ve kullanıcıları için yalnızca görevlerini yerine getirmek için kesinlikle gerekli olan minimum izinleri atayın. Örneğin, S3 replikasyonu için oluşturduğunuz IAM rolüne sadece ilgili S3 bucket'larına erişim yetkisi verin.
- Bölgeler Arası Erişim Kontrolleri: Farklı bölgelerdeki kaynaklar arasında güvenli iletişimi sağlamak için VPC peering veya Transit Gateway gibi mekanizmalar kullanırken, güvenlik gruplarını ve ağ ACL'lerini dikkatlice yapılandırın. Her iki bölge için de ağ segmentasyonunu ve trafik filtrelemeyi uygulayın.
- Şifreleme: Hem beklemedeki (at rest) hem de hareket halindeki (in transit) tüm verileri şifreleyin. RDS, S3 ve EBS gibi hizmetler için AWS Key Management Service (KMS) kullanarak şifrelemeyi etkinleştirin. Bu, veri ihlali riskini önemli ölçüde azaltır.
- Gizli Bilgilerin Yönetimi: Veritabanı şifreleri, API anahtarları gibi hassas bilgileri Terraform dosyalarına doğrudan yazmak yerine, AWS Secrets Manager veya AWS Systems Manager Parameter Store gibi güvenli hizmetleri kullanın. Terraform, bu hizmetlerden gizli bilgileri güvenli bir şekilde çekebilir.
Otomasyon ve Test Süreçleri
Bir felaket kurtarma planı, ancak düzenli olarak test edildiğinde güvenilirdir. Otomasyon, bu testleri daha kolay ve tekrarlanabilir hale getirir:
- DR Testlerini Otomatize Edin (Game Day): DR planınızın işe yaradığından emin olmak için düzenli olarak "Game Day" tatbikatları yapın. Terraform, bu tatbikatlar sırasında yedek bölgedeki kaynakları hızla başlatmanıza ve test senaryolarını uygulamanıza olanak tanır. Kurtarma adımlarını otomatize etmek için AWS Lambda fonksiyonları veya Step Functions kullanabilirsiniz.
- Kurtarma Süreçlerini Belgeleyin ve Otomatize Edin: Kurtarma süreçlerini adım adım belgeleyin ve mümkün olduğunca otomatize edin. Herhangi bir felaket durumunda panik yerine, önceden tanımlanmış ve test edilmiş bir "runbook" ile hareket etmek kritik öneme sahiptir. Terraform kodunuz, bu runbook'un temelini oluşturur.
- CI/CD Entegrasyonu: Terraform yapılandırma dosyalarınızı bir CI/CD boru hattına entegre edin. Bu, altyapı değişikliklerinin otomatik olarak planlanmasını, doğrulanmasını ve uygulanmasını sağlar. Ayrıca, DR altyapınızdaki olası sapmaları (drift) tespit etmek için düzenli
terraform plançalıştırmaları planlayın. - İzleme ve Uyarılar: Hem birincil hem de ikincil bölgelerdeki tüm kritik kaynaklar için kapsamlı izleme ve uyarı sistemleri kurun. AWS CloudWatch, Prometheus veya Datadog gibi araçlar kullanarak uygulamanızın ve altyapınızın sağlık durumunu sürekli takip edin. Bu, olası sorunları erken tespit etmenize ve proaktif adımlar atmanıza yardımcı olur. Özellikle Route 53 Health Check'lerinin doğru çalıştığından ve uyarıları zamanında tetiklediğinden emin olun.
Bu ileri düzey teknikler ve en iyi uygulamalar, sadece DR kurulumunuzu daha sağlam hale getirmekle kalmaz, aynı zamanda operasyonel verimliliği artırır, maliyetleri düşürür ve genel güvenlik duruşunuzu güçlendirir. Unutmayın ki felaket kurtarma, tek seferlik bir proje değil, sürekli bir iyileştirme ve test sürecidir.
Sonuç: İş Sürekliliği Yolculuğunuzda Neredesiniz?
Bu makalede, iş sürekliliğinin günümüz dijital çağındaki kritik öneminden başlayarak, çok bölgeli felaket kurtarma (DR) stratejilerini AWS ve Terraform gibi güçlü araçlarla nasıl hayata geçirebileceğinizi kapsamlı bir şekilde inceledik. RTO ve RPO gibi temel metrikleri, farklı DR modellerini (Pilot Light, Warm Standby) ve Terraform'un IaC prensipleriyle otomasyon, tutarlılık ve hız sağlama yeteneğini ele aldık. Adım adım bir Pilot Light senaryosu üzerinden AWS VPC, Subnet, RDS replikasyonu, S3 Cross-Region Replication ve Route 53 ile DNS failover mekanizmalarını Terraform kod örnekleriyle gösterdik.
Ayrıca, maliyet optimizasyonu, güvenlik en iyi uygulamaları (IAM, şifreleme) ve otomatik test süreçlerinin (Game Day, CI/CD) önemine değinerek, DR kurulumunuzu daha da güçlendirecek ileri düzey teknikleri tartıştık. Unutulmamalıdır ki, felaket kurtarma bir ürün değil, bir süreçtir. Sürekli izleme, düzenli testler ve değişen iş ihtiyaçlarına göre ayarlamalar yapmak, başarılı bir DR stratejisinin temel taşlarıdır. AWS'nin sunduğu küresel altyapı ve Terraform'un otomasyon yetenekleri sayesinde, işletmeler artık felaketlere karşı daha dayanıklı, esnek ve hızlı bir şekilde toparlanabilen sistemler inşa edebilirler. Bu sayede, beklenmedik kesintiler karşısında bile operasyonlarınızı sorunsuz bir şekilde sürdürebilir ve müşteri güvenini koruyabilirsiniz. İş sürekliliği yolculuğunuzda bu rehberin size ışık tutmasını umuyoruz.
Sıkça Sorulan Sorular
Çok bölgeli felaket kurtarma kurulumu hakkında en sık karşılaşılan sorulara ve cevaplarına göz atalım:
-
Çok bölgeli DR ne kadar maliyetli?
Maliyet, seçtiğiniz DR stratejisine (Soğuk, Ilık, Sıcak Bekleme), RTO/RPO hedeflerinize ve kullanılan kaynakların ölçeğine göre büyük ölçüde değişir. Pilot Light ve Warm Standby modelleri, aktif-aktif bir setup'a göre daha düşük maliyetlidir çünkü yedek bölgede daha az kaynak çalışır durumda tutulur. Veri replikasyonu, depolama ve bölgeler arası veri transferi de maliyet kalemleridir. Maliyet optimizasyonu için kullanılmayan kaynakları kapatmak ve doğru depolama sınıflarını seçmek önemlidir.
-
RTO/RPO hedeflerimi nasıl belirlemeliyim?
RTO ve RPO hedefleri, işinizin kritikliği ve finansal kayıpları tolere etme yeteneğinizle doğrudan ilişkilidir. İş birimlerinizle yakın çalışarak, her uygulama veya hizmet için maksimum kabul edilebilir kesinti süresini (RTO) ve maksimum kabul edilebilir veri kaybını (RPO) belirleyin. Bu hedefler, genellikle bir İş Etki Analizi (Business Impact Analysis - BIA) sonucunda ortaya çıkar. Daha düşük hedefler, daha yüksek maliyet ve karmaşıklık anlamına gelir.
-
Veri tutarlılığını nasıl sağlarım?
Veri tutarlılığı, DR kurulumunun en kritik yönlerinden biridir. RDS için Read Replica'lar (eşzamansız replikasyon) veya Multi-AZ dağıtımları (senkron replikasyon), S3 için Cross-Region Replication (CRR) gibi AWS hizmetleri ile veri replikasyonunu sağlayabilirsiniz. Uygulamanızın veritabanı dışındaki (örneğin dosya sistemindeki) verileri için EBS anlık görüntüleri veya EFS yedeklemeleri de bölgeler arası kopyalanabilir. Uygulama seviyesinde, veritabanına yazmadan önce verilerin replike edildiğinden emin olmak için ek mantıklar geliştirilebilir.
-
Bu kurulumu test etmek ne kadar sürer?
DR testlerinin süresi, altyapının karmaşıklığına ve otomasyon seviyesine bağlıdır. Manuel testler günler sürebilirken, Terraform ve diğer otomasyon araçlarıyla yapılan testler saatlere hatta dakikalara inebilir. Önemli olan, testleri düzenli olarak ve gerçek bir felaket senaryosunu taklit edecek şekilde yapmaktır. Bu testler, planınızdaki eksiklikleri ve iyileştirme alanlarını ortaya çıkaracaktır.
-
Tek bir bölge yetmez miydi?
Tek bir AWS bölgesinde bile yüksek erişilebilirlik sağlamak mümkündür (örneğin, Multi-AZ dağıtımları). Ancak, tek bir bölgenin tamamen devre dışı kalmasına neden olabilecek (doğal afet, geniş çaplı elektrik kesintisi vb.) bölgesel bir felaket durumunda, tüm uygulamanız kesintiye uğrar. Çok bölgeli DR, bu tür geniş ölçekli felaketlere karşı ek bir koruma katmanı sağlayarak işinizin çok daha dayanıklı olmasını garanti eder. Bu, risk toleransınıza ve işinizin kritiklik seviyesine göre verilmesi gereken bir karardır.