AWS S3 Cross-Region Replication Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

Üretim ortamında bir S3 bucket’ınız var, içinde kritik veriler var ve bir gün AWS’nin bir bölgesinde problem çıkıyor. Ya da yasal zorunluluklar gereği verilerinizi farklı coğrafyalarda tutmanız gerekiyor. İşte tam bu noktada S3 Cross-Region Replication (CRR) devreye giriyor. Bu yazıda, CRR’yi sıfırdan kuracağız, gerçek dünya senaryolarına bakacağız ve sık yapılan hataları ele alacağız.

S3 Cross-Region Replication Nedir?

S3 CRR, bir bucket’taki nesneleri otomatik olarak farklı bir AWS bölgesindeki başka bir bucket’a kopyalayan bir özelliktir. Asenkron çalışır, yani kopyalama işlemi gerçek zamanlı değil ama genellikle birkaç dakika içinde tamamlanır. Replikasyon sadece yeni yüklenen veya güncellenen nesneleri kapsar; CRR’yi etkinleştirmeden önce mevcut nesneler otomatik olarak kopyalanmaz. Bunu baştan bilmek önemli çünkü bunu atlayan çok sistem yöneticisi gördüm.

Ne zaman kullanmalısınız?

  • Felaket kurtarma (Disaster Recovery) senaryolarında aktif-pasif ya da aktif-aktif yapı kurmak istediğinizde
  • GDPR veya yerel veri yasaları gereği farklı bölgelerde veri kopyası tutmanız gerektiğinde
  • Kullanıcılarınıza coğrafi olarak yakın bölgeden veri sunarak gecikmeyi azaltmak istediğinizde
  • Compliance gereksinimlerini karşılamak için veri kopyalaması yapmanız zorunlu olduğunda

Ön Gereksinimler

Başlamadan önce şunları hazırlamanız gerekiyor:

  • Kaynak (source) ve hedef (destination) bucket’ların farklı AWS bölgelerinde olması zorunlu. Aynı bölge içinde çoğaltma yapmak istiyorsanız o özellik Same-Region Replication (SRR) olarak ayrı bir başlık.
  • Her iki bucket’ta da versiyonlama (versioning) aktif olmalı. Bu zorunlu bir şart, atlamayın.
  • Uygun IAM izinlerine sahip olmanız gerekiyor.
  • AWS CLI kurulu ve yapılandırılmış olmalı.

Ortamı Hazırlamak

Önce senaryo belirleyelim: eu-west-1 (İrlanda) bölgemizde production verilerimiz var ve bunları us-east-1 (Kuzey Virginia) bölgesine replike edeceğiz. Bucket isimlerimiz production-data-ireland ve dr-backup-virginia olsun.

Bucket’ları Oluşturma

Önce kaynak bucket’ı oluşturalım:

aws s3api create-bucket 
  --bucket production-data-ireland 
  --region eu-west-1 
  --create-bucket-configuration LocationConstraint=eu-west-1

Şimdi hedef bucket’ı oluşturalım. us-east-1 için LocationConstraint parametresine gerek yok, bu bölge AWS’nin default bölgesi:

aws s3api create-bucket 
  --bucket dr-backup-virginia 
  --region us-east-1

Versiyonlamayı Aktifleştirme

Her iki bucket için de versiyonlamayı açmak zorunlu. Bu adımı atlarsanız replikasyon kuralı kaydetemezsiniz:

# Kaynak bucket için versiyonlama
aws s3api put-bucket-versioning 
  --bucket production-data-ireland 
  --versioning-configuration Status=Enabled

# Hedef bucket için versiyonlama
aws s3api put-bucket-versioning 
  --bucket dr-backup-virginia 
  --versioning-configuration Status=Enabled

Versiyonlamanın aktif olduğunu doğrulayalım:

aws s3api get-bucket-versioning --bucket production-data-ireland
aws s3api get-bucket-versioning --bucket dr-backup-virginia

Her ikisi de "Status": "Enabled" döndürmeli.

IAM Rolü ve Politikası Oluşturma

CRR’nin çalışması için S3’ün kaynak bucket’tan nesne okuyup hedef bucket’a yazabilmesi gerekiyor. Bunun için özel bir IAM rolü oluşturmamız gerekiyor.

Trust Policy Oluşturma

Önce S3 servisinin bu rolü üstlenebilmesi için trust policy dosyası oluşturalım:

cat > s3-replication-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

Replication İzin Politikası Oluşturma

Bu politika, S3’ün hangi işlemleri hangi bucket’larda yapabileceğini tanımlıyor:

cat > s3-replication-permission-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetReplicationConfiguration",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::production-data-ireland"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectVersionForReplication",
        "s3:GetObjectVersionAcl",
        "s3:GetObjectVersionTagging"
      ],
      "Resource": "arn:aws:s3:::production-data-ireland/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateDelete",
        "s3:ReplicateTags"
      ],
      "Resource": "arn:aws:s3:::dr-backup-virginia/*"
    }
  ]
}
EOF

IAM Rolünü Oluşturup Politikaları Bağlama

# Rolü oluştur
aws iam create-role 
  --role-name s3-crr-role 
  --assume-role-policy-document file://s3-replication-trust-policy.json

# İzin politikasını oluştur
aws iam create-policy 
  --policy-name s3-crr-policy 
  --policy-document file://s3-replication-permission-policy.json

# Politikayı role bağla (policy ARN'ı kendi hesap ID'niz ile değiştirin)
aws iam attach-role-policy 
  --role-name s3-crr-role 
  --policy-arn arn:aws:iam::YOUR_ACCOUNT_ID:policy/s3-crr-policy

Replikasyon Kuralını Yapılandırma

IAM rolümüz hazır. Şimdi kaynak bucket’a replikasyon kuralını ekleyelim. Burada farklı senaryolar için farklı konfigürasyonlar mümkün.

Tüm Nesneleri Replike Etme (Temel Senaryo)

cat > replication-config.json << 'EOF'
{
  "Role": "arn:aws:iam::YOUR_ACCOUNT_ID:role/s3-crr-role",
  "Rules": [
    {
      "ID": "full-bucket-replication",
      "Status": "Enabled",
      "Filter": {
        "Prefix": ""
      },
      "Destination": {
        "Bucket": "arn:aws:s3:::dr-backup-virginia",
        "StorageClass": "STANDARD_IA"
      },
      "DeleteMarkerReplication": {
        "Status": "Enabled"
      }
    }
  ]
}
EOF

aws s3api put-bucket-replication 
  --bucket production-data-ireland 
  --replication-configuration file://replication-config.json

Burada StorageClass olarak STANDARD_IA seçtim. DR amaçlı replikasyonda genellikle bu tercih edilir çünkü bu verilere sık erişilmez, maliyeti düşürür.

Prefix Bazlı Replikasyon (Belirli Klasörleri Replike Etme)

Sadece logs/ ve backups/ klasörlerini replike etmek istediğiniz bir senaryo düşünün. Birden fazla kural tanımlayabilirsiniz:

cat > replication-config-prefix.json << 'EOF'
{
  "Role": "arn:aws:iam::YOUR_ACCOUNT_ID:role/s3-crr-role",
  "Rules": [
    {
      "ID": "replicate-logs",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Destination": {
        "Bucket": "arn:aws:s3:::dr-backup-virginia",
        "StorageClass": "GLACIER_IR"
      },
      "DeleteMarkerReplication": {
        "Status": "Disabled"
      }
    },
    {
      "ID": "replicate-backups",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "backups/"
      },
      "Destination": {
        "Bucket": "arn:aws:s3:::dr-backup-virginia",
        "StorageClass": "STANDARD"
      },
      "DeleteMarkerReplication": {
        "Status": "Enabled"
      }
    }
  ]
}
EOF

Log dosyaları için GLACIER_IR seçtim; bu arşiv verisi için mükemmel bir seçim ve maliyeti ciddi oranda düşürüyor.

Mevcut Nesneleri Replike Etme

Başta söylediğim gibi CRR sadece kural oluşturduktan sonraki nesneleri kopyalar. Mevcut nesneler için S3 Batch Operations kullanmanız gerekiyor. Önce bir inventory oluşturup ardından batch job çalıştırabilirsiniz, ama küçük bucket’lar için en pratik yol aws s3 sync komutunu kullanmak:

aws s3 sync 
  s3://production-data-ireland 
  s3://dr-backup-virginia 
  --source-region eu-west-1 
  --region us-east-1 
  --storage-class STANDARD_IA

Büyük bucket’lar için bu komut çok uzun sürebilir. Paralel çalıştırmak için şöyle bir yaklaşım kullanabilirsiniz:

#!/bin/bash
# Paralel sync scripti - prefix'e göre böl
PREFIXES=("2023/" "2024/" "logs/" "backups/" "configs/")
SOURCE_BUCKET="production-data-ireland"
DEST_BUCKET="dr-backup-virginia"

for prefix in "${PREFIXES[@]}"; do
  aws s3 sync 
    "s3://${SOURCE_BUCKET}/${prefix}" 
    "s3://${DEST_BUCKET}/${prefix}" 
    --source-region eu-west-1 
    --region us-east-1 
    --storage-class STANDARD_IA &
done

wait
echo "Tüm sync işlemleri tamamlandı."

Replikasyon Durumunu İzleme

Replikasyonun çalışıp çalışmadığını birkaç farklı şekilde kontrol edebilirsiniz.

Nesne Replikasyon Durumunu Kontrol Etme

# Bir nesnenin replikasyon durumunu kontrol et
aws s3api head-object 
  --bucket production-data-ireland 
  --key test-file.txt 
  --query "ReplicationStatus"

Dönen değerler:

  • PENDING: Replikasyon henüz tamamlanmadı
  • COMPLETED: Replikasyon başarıyla tamamlandı
  • FAILED: Replikasyon başarısız oldu
  • REPLICA: Bu nesne bir replikadır (hedef bucket’ta görürsünüz)

Test Dosyası Yükleyip Kontrol Etme

# Test dosyası yükle
echo "CRR Test $(date)" > /tmp/crr-test.txt
aws s3 cp /tmp/crr-test.txt s3://production-data-ireland/crr-test.txt

# Birkaç dakika bekleyin, sonra durumu kontrol edin
sleep 60
aws s3api head-object 
  --bucket production-data-ireland 
  --key crr-test.txt

# Hedef bucket'ta var mı kontrol et
aws s3 ls s3://dr-backup-virginia/crr-test.txt --region us-east-1

CloudWatch Metrikleriyle İzleme

Replikasyon gecikmesini ve başarısızlıklarını izlemek için CloudWatch alarmı kurmak iyi bir pratiktir:

# Replikasyon gecikmesi için CloudWatch alarmı
aws cloudwatch put-metric-alarm 
  --alarm-name "S3-CRR-Replication-Latency-High" 
  --alarm-description "CRR replikasyon gecikmesi 5 dakikayı aştı" 
  --metric-name ReplicationLatency 
  --namespace AWS/S3 
  --dimensions 
    Name=SourceBucket,Value=production-data-ireland 
    Name=DestinationBucket,Value=dr-backup-virginia 
    Name=RuleId,Value=full-bucket-replication 
  --statistic Average 
  --period 300 
  --threshold 300000 
  --comparison-operator GreaterThanThreshold 
  --evaluation-periods 2 
  --alarm-actions arn:aws:sns:eu-west-1:YOUR_ACCOUNT_ID:alerts-topic

Şifreli Bucket’larda CRR Kurulumu

Üretim ortamında bucket’larınız muhtemelen şifreli. Bu durumda IAM rolünüze KMS izinleri de eklemeniz gerekiyor.

Kaynak bucket KMS anahtarı için izinler:

cat > kms-source-policy.json << 'EOF'
{
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "arn:aws:kms:eu-west-1:YOUR_ACCOUNT_ID:key/SOURCE_KEY_ID"
}
EOF

Hedef bucket KMS anahtarı için izinler:

cat > kms-dest-policy.json << 'EOF'
{
  "Effect": "Allow",
  "Action": [
    "kms:Encrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "arn:aws:kms:us-east-1:YOUR_ACCOUNT_ID:key/DEST_KEY_ID"
}
EOF

Bu izin bloklarını daha önce oluşturduğunuz s3-replication-permission-policy.json dosyasına eklemeniz gerekiyor. Ayrıca replikasyon konfigürasyonunuzda da şifreleme bilgisini belirtmelisiniz:

# Şifreli hedef için destination bloğu
{
  "Destination": {
    "Bucket": "arn:aws:s3:::dr-backup-virginia",
    "StorageClass": "STANDARD_IA",
    "EncryptionConfiguration": {
      "ReplicaKmsKeyID": "arn:aws:kms:us-east-1:YOUR_ACCOUNT_ID:key/DEST_KEY_ID"
    }
  }
}

Sık Yapılan Hatalar ve Çözümleri

Versiyonlama aktif değil hatası: En sık karşılaşılan problem. CRR etkinleştirilmeden önce her iki bucket’ta da versiyonlama açık olmalı. Açmayı unuttuysanız yukarıdaki put-bucket-versioning komutunu çalıştırın.

IAM rolü izin problemi: Replikasyon başlıyor ama nesneler geçmiyor. FAILED durumundaki nesneleri görmek için:

aws s3api list-objects-v2 
  --bucket production-data-ireland 
  --query "Contents[?ReplicationStatus=='FAILED']"

Farklı hesaplar arası replikasyon: Kaynak ve hedef bucket farklı AWS hesaplarındaysa hedef bucket’a bucket policy eklemeniz gerekiyor. Kaynak hesabın IAM rolüne hedef bucket’a yazma izni vermek için:

cat > dest-bucket-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SOURCE_ACCOUNT_ID:role/s3-crr-role"
      },
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateDelete",
        "s3:ReplicateTags",
        "s3:GetBucketVersioning",
        "s3:PutBucketVersioning"
      ],
      "Resource": [
        "arn:aws:s3:::dr-backup-virginia",
        "arn:aws:s3:::dr-backup-virginia/*"
      ]
    }
  ]
}
EOF

aws s3api put-bucket-policy 
  --bucket dr-backup-virginia 
  --policy file://dest-bucket-policy.json 
  --region us-east-1

Delete marker replikasyonu dikkat: DeleteMarkerReplication aktifken kaynak bucket’ta silinen nesnelerin delete marker’ları da hedef bucket’a gider. Eğer hedef bucket’ı gerçek bir DR yedek olarak kullanıyorsanız ve yanlışlıkla yapılan silmelerin yayılmasını istemiyorsanız bu özelliği Disabled olarak bırakın.

Replikasyon Kuralını Doğrulama ve Silme

# Mevcut replikasyon konfigürasyonunu görüntüle
aws s3api get-bucket-replication --bucket production-data-ireland

# Replikasyon kuralını kaldır
aws s3api delete-bucket-replication --bucket production-data-ireland

Maliyet Optimizasyonu Önerileri

CRR’nin maliyeti çeşitli bileşenlerden oluşuyor:

  • Veri transfer ücreti: Bölgeler arası veri transferi ücretlendirilir. Ne kadar veri kopyalandığına dikkat edin.
  • Depolama ücreti: Hedef bölgedeki depolama ücreti de ekleniyor. STANDARD_IA veya GLACIER_IR kullanmak burada ciddi tasarruf sağlar.
  • PUT isteği ücreti: Her replike edilen nesne için PUT isteği ücreti ödenir.

Akıllıca bir yaklaşım: Tüm veriyi STANDARD olarak değil, erişim sıklığına göre farklı storage class’larda tutmak. Log dosyaları ve eski yedekler için GLACIER_IR, kritik ve sık erişilen veriler için STANDARD_IA iyi bir denge noktası.

Ayrıca Object Lifecycle Policy ile hedef bucket’taki nesneleri belirli süre sonra otomatik olarak daha ucuz bir tier’a taşıyabilirsiniz:

aws s3api put-bucket-lifecycle-configuration 
  --bucket dr-backup-virginia 
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "move-to-glacier",
        "Status": "Enabled",
        "Filter": {"Prefix": ""},
        "Transitions": [
          {
            "Days": 90,
            "StorageClass": "GLACIER"
          }
        ]
      }
    ]
  }'

Sonuç

S3 Cross-Region Replication, doğru kurulduğunda son derece güvenilir ve yönetimi kolay bir felaket kurtarma çözümü sunuyor. Temel adımlar aslında basit: iki bucket, versiyonlama, IAM rolü ve replikasyon kuralı. Ama şifreli bucket’lar, cross-account senaryolar ve mevcut verilerin taşınması gibi konular dikkat istiyor.

Üretim ortamına geçmeden önce yapmanız gereken birkaç şey var: Test bucket’larıyla tüm senaryoyu bir kez daha deneyin, CloudWatch alarmlarını mutlaka kurun ve replikasyon durumunu periyodik olarak kontrol eden bir script yazın. Ayrıca DR planınızda “hedef bucket’tan nasıl geri döneceğiz?” sorusunu da yanıtlamanız gerekiyor, ki bu başlı başına ayrı bir yazı konusu.

Son olarak, Replication Time Control (RTC) özelliğini de araştırmanızı öneririm. SLA gerektiren senaryolarda nesnelerin 15 dakika içinde replike edileceğini garanti ediyor, ek maliyeti var ama kritik workload’lar için değer.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir