Amazon SAA-C03: Depolama ve Veri Yaşam Döngüsü — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

S3 Depolama Sınıfları ve Maliyet/Gecikme Spektrumu

S3 depolama sınıfları; GB başına depolama maliyetine karşılık erişim gecikmesi, minimum depolama süresi ve GB başına erişim ücretleri arasında bir denge kuran bir spektrumda yer alır. Doğru seçim yapmak, nesne depolamada maliyet optimizasyonu için en büyük tek kaldıraçtır.

S3 Standard varsayılan seçenektir: üç veya daha fazla AZ’de on bir dokuzlu dayanıklılık, milisaniye düzeyinde gecikme, erişim ücreti yok, en yüksek GB başına fiyat. Standard-IA ve One Zone-IA depolama maliyetini yaklaşık %40-50 düşürür, ancak GB başına erişim ücreti, 30 günlük minimum faturalandırılabilir süre ve 128 KB minimum nesne boyutu ekler (daha küçük nesneler 128 KB olarak faturalandırılır, bu da tasarrufu azaltır). One Zone-IA, tek bir AZ’de depolama yaparak maliyeti daha da düşürür — yalnızca tek bir AZ kaybının tolere edilebildiği, yeniden üretilebilir ikincil kopyalar için uygundur.

S3 Intelligent-Tiering, erişim desenlerinin bilinmediği, öngörülemediği veya büyük bir veri kümesi genelinde değiştiği her durumda doğru seçimdir. Gözlemlenen erişime dayanarak nesneleri otomatik olarak sık, seyrek, anlık arşiv, arşiv ve derin arşiv katmanları arasında taşır ve nesne başına küçük bir izleme ücreti alır. Sık ve seyrek erişim katmanları arasında erişim ücreti ve minimum süre olmaması nedeniyle, 128 KB ve üzeri nesneler içeren veri gölleri ve karma iş yükleri için en güvenli varsayılan seçenektir. Nesnelerin kalıcı olarak sık erişimli (ekstra izleme maliyeti) veya on yıl boyunca kalıcı olarak soğuk (Deep Archive çok daha ucuzdur) olduğunu zaten bildiğiniz durumlarda yanlış bir seçimdir.

Glacier Instant Retrieval, üç ayda bir veya daha seyrek erişilen veriler için arşiv fiyatlarında milisaniye düzeyinde erişim sağlar — tıbbi görüntüler, talep edildiğinde anında sunulması gereken uyumluluk PDF’leri gibi. Glacier Flexible Retrieval dakikalar ile saatler arasında değişen erişim süreleri sunar. Glacier Deep Archive, yaklaşık olarak ayda 1$/TB maliyetiyle AWS’deki en ucuz katmandır ve 12 saatlik standart (veya 48 saatlik toplu) erişim süresi ve 180 günlük minimum süreye sahiptir — 7-10 yıllık yasal saklama ve teyp yedekleme için doğru yanıttır.

İki baskın maliyet tuzağı, birbirinin zıttı olan hatalardır. Uzun süreli, nadiren okunan veriler için Standard’ı seçmek para yakmaktır çünkü Standard’ın soğuk depolama için bir fiyat avantajı yoktur — yıllarca Standard’da tutulan 5 TB’lık bir veri seti, Deep Archive’daki aynı veriden kat kat daha pahalıya mal olur. Tersine, yepyeni nesneleri doğrudan Standard-IA veya Glacier’a taşımak bir tuzaktır, çünkü nesneler hala sık erişimliyken 30/90/180 günlük minimum ücretler ve erişim ücretleri, elde edilen tasarrufu aşar. Glacier Flexible veya Deep Archive, senkron bir okuma bekleyen herhangi bir iş yüküyle de kesinlikle uyumsuzdur — bir HTTP GET isteği için bekleyen bir kullanıcı, dakikalar ile 12 saat arasında değişen bir erişim SLA’sını tolere edemez. Glacier Instant Retrieval, anlık erişimle uyumlu tek Glacier katmanıdır.

Yaşam Döngüsü Politikaları ve Sürüm Yönetimi

Yaşam döngüsü yapılandırması, bir bucket’a eklenen ve nesneleri yaşına, etiketine veya ön ekine göre taşıyan ya da süresini dolduran bildirimsel bir JSON/YAML’dir. Geçişler günde bir kez değerlendirilir ve yalnızca belirtilen yaşa ulaşıldıktan sonra tetiklenir — Days: 30 geçişi, ilk 30 gün boyunca Standard ücretlerinin uygulanacağı anlamına gelir. Geçişler giderek daha soğuk katmanlara doğru olmalıdır ve 128 KB’den küçük nesneler Standard’dan IA’ya taşınmaz, çünkü nesne başına düşen ek maliyet tasarrufu aşar; önce küçük nesneleri tar/zip veya S3 Batch Operations aracılığıyla birleştirin.

30 gün boyunca sık erişimli, sonrasında soğuk, bu süre boyunca anlık erişim gerektiren, dört yıl saklanan ve uygun hijyene sahip bir iş yükü için kanonik bir politika:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Sık karşılaşılan bir sürüm yönetimi tuzağı: sürümlemenin etkin olduğu bir bucket’ta, mevcut nesnelerin süresini dolduran bir yaşam döngüsü kuralı yalnızca silme işaretçileri ekler; önceki sürümler sessizce birikir ve faturalandırılmaya devam eder. Mevcut olmayan sürümler, kendi açık NoncurrentVersionTransitions ve NoncurrentVersionExpiration kurallarını gerektirir. Benzer şekilde, her zaman AbortIncompleteMultipartUpload kuralını ekleyin — yetim kalmış çok parçalı yükleme bölümleri konsol listesinde görünmez ve süresiz olarak depolama maliyeti oluşturur.

Karma desenler için — örneğin, ilk ay ML eğitimi için sık erişimli olan, ardından bir yıl boyunca üç ayda bir sorgulanan ve sonrasında arşivlenen IoT telemetrisi gibi — doğru yanıt, ilk yıl için Intelligent-Tiering kullanmak (sınıfın eğitim yoğunlukları ve boş günler arasında otomatik optimizasyon yapmasına izin vererek) ve ardından 365. günde Deep Archive’a zamanlanmış bir geçiş yapmaktır.

Sürüm Oluşturma, MFA Delete ve Object Lock

Sürüm oluşturma (versioning) bir kez etkinleştirildiğinde yalnızca askıya alınabilir (suspended-only); kapatılamaz. Her PUT işlemi yeni bir sürüm ID’si oluşturur; DELETE işlemi ise veriyi kaldırmak yerine bir silme işareti (delete marker) ekler. Sürüm oluşturma, yanlışlıkla üzerine yazmaya karşı koruma sağlar ancak bu, verinin değiştirilemez (immutability) olduğu anlamına gelmez: s3:DeleteObjectVersion iznine sahip herhangi bir principal, belirli bir sürümü kalıcı olarak silebilir. MFA Delete, kök hesabın (root account) sürümleri kalıcı olarak silmek veya sürüm oluşturma durumunu değiştirmek için bir MFA token’ı sunmasını gerektirir. Bu, yüksek değerli bucket’lar için yanlışlıkla silme açığını kapatır ancak yetkili bir aktörün verileri yok etmesini yine de engellemez.

Gerçek anlamda değiştirilemezlik (immutability) için, sürüm oluşturma gerektiren ve genellikle bucket oluşturulurken etkinleştirilmesi gereken S3 Object Lock kullanılır. Sıkça karıştırılan iki modu vardır:

Saklama süresi, nesne başına (Retain-Until-Date) veya son kullanma tarihi olmayan bir Legal Hold (Yasal Saklama) aracılığıyla uygulanabilir. Bir yıl sık erişilen (hot), dokuz yıl arşivlenmiş ve on yıl boyunca silinmemesi gereken muhasebe kayıtları için doğru model, on yıllık saklama süresine sahip Compliance modunda Object Lock ile 365. günde Deep Archive’a yaşam döngüsü (lifecycle) geçişinin birleştirilmesidir. Governance modu, yasal bir zorunluluk için kabul edilebilir bir alternatif değildir — bir düzenleyici kurum, “izinleri olan biri bunu silebilirmiş” ifadesini değiştirilemezlik olarak kabul etmeyecektir.

Mevcut bir PDF kümesine tek bir işte saklama süresi uygulamak için, bir S3 Inventory manifestosu tarafından yönlendirilen S3 Batch Operations kullanın. Batch Operations; milyarlarca anahtar üzerinde saklama, etiketleme, PUT-copy ile yeniden şifreleme, Lambda çağırma gibi büyük ölçekli değişiklikler için yönetilen (managed) çözümdür; elle yazılmış döngüsel betikler doğru bir model değildir.

Şifreleme: SSE-S3, SSE-KMS ve Bucket Keys

Her bucket’ın varsayılan şifrelemesi vardır. SSE-S3 (AES-256, S3 tarafından yönetilen anahtarlar) ücretsizdir ve anahtar yönetimi gerektirmez. SSE-KMS, bir KMS müşteri ana anahtarı (customer master key) kullanır ve anahtar başına CloudTrail denetim izleri, IAM tabanlı anahtar erişim politikaları ve anahtar rotasyon kontrolü sağlar. Bunun bedeli KMS API ücretleri ve daha da önemlisi, yüksek verimli okuma iş yüklerini darboğaza sokabilen KMS istek kısıtlamasıdır (request throttling). SSE-KMS’i, bu kontrollere gerçekten ihtiyaç duyduğunuzda (yasal onay, görevler ayrılığı, hesaplar arası anahtar paylaşımı) seçin. SSE-S3’ün gereksinimi karşıladığı durumlarda “güvende olmak için” varsayılan olarak SSE-KMS’i seçmek, gereksiz maliyet ve karmaşıklık ekler.

S3 Bucket Keys, SSE-KMS istek maliyetlerini çözmek için kullanılır. S3, CMK’dan kısa ömürlü, bucket düzeyinde bir anahtar oluşturur ve nesne başına veri anahtarlarını yerel olarak türetir. Bu sayede her nesne için bir KMS GenerateDataKey/Decrypt çağrısından kaçınılır ve KMS istek maliyetleri %99’a kadar azaltılır:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Gereksinim KMS’i zorunlu kılıyorsa, “KMS maliyetlerinden kaçınmak için” SSE-S3’e geçmek yanlış bir çözümdür — Bucket Keys, KMS’ten vazgeçmeden hem uyumluluk hem de maliyet hedeflerini karşılar.

Varsayılan bucket şifrelemesini etkinleştirmek, gelecekteki tüm yüklemelerin şifrelenmesini sağlar (şifrelenmemiş PUT işlemleri şeffaf bir şekilde şifrelenir). Şifrelenmemiş PUT işlemlerini tamamen reddetmek için, ilgili başlığa (header) sahip olmayan yazma işlemlerini reddedin:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Varsayılan şifreleme, mevcut şifrelenmemiş nesnelere hiçbir şey yapmaz. Bunları, her anahtarı yerinde üzerine yazan bir Copy işi yürüten S3 Inventory + Batch Operations aracılığıyla yeniden şifreleyin — bu, standart toplu yeniden şifreleme modelidir.

Geçici (ad-hoc) istemci tarafı şifreleme, varsayılan şifreleme ve KMS’e göre daha zayıftır: anahtar yönetimini uygulama ekiplerine dağıtır, CloudTrail KMS olayları aracılığıyla merkezi olarak denetlenemez ve Bucket Keys kullanamaz.

Bölgeler Arası Replikasyon ve Çok Bölgeli KMS Anahtarları

Cross-Region Replication (CRR), uyumluluk, felaket kurtarma (DR) veya gecikme (latency) amaçlarıyla nesneleri farklı bir Region’daki bir bucket’a eşzamansız olarak kopyalar. Same-Region Replication (SRR), uyumluluk ayrımı, log toplama ve hesaplar arası kopyalama amaçlarına hizmet eder. Her ikisi de kaynak ve hedefte sürüm oluşturma ve kaynak bucket’ın üstlendiği (assume) bir IAM rolü gerektirir. Bir bucket’ın başka bir Region’a yansıtılması gerektiğinde CRR, en az çaba gerektiren çözümdür — aws s3 sync betikleri yazmak, ObjectCreated olaylarına Lambda bağlamak veya zamanlanmış toplu kopyalamalar çalıştırmak operasyonel yük, yarış koşulları (race conditions) ve sessiz hatalar ortaya çıkarır. Ne CRR ne de SRR, varsayılan olarak mevcut nesneleri kopyalamaz; geçmiş verileri doldurmak (backfill) için S3 Batch Replication kullanın.

Şifreleme etkileşimleri, tasarımların genellikle başarısız olduğu noktalardır:

• SSE-S3 nesneleri şeffaf bir şekilde kopyalanır.
• SSE-KMS nesneleri varsayılan olarak kopyalanmaz — açıkça etkinleştirmeli, hedef Region’da bir hedef KMS anahtarı belirtmeli ve replikasyon rolüne kaynak anahtar üzerinde kms:Decrypt ve hedef anahtar üzerinde kms:Encrypt izinlerini vermelisiniz. Tek bir Region’a ait bir anahtar, başka bir Region’daki nesneleri şifreleyemez.
• İstemci tarafında şifrelenmiş nesneler, opak şifreli metin (ciphertext) olarak kopyalanır; istemcinin anahtar materyali orada mevcut değilse hedef Region hiçbir şey kazanamaz.

İki bağımsız CMK’yı yönetmenin tarihsel zorluğu, birden fazla Region’da aynı anahtar materyalini ve anahtar ID’sini (bir Region öneki ile) sunan AWS KMS multi-Region keys (çok bölgeli anahtarlar) ile çözülmüştür. Böylece kopyalanan bir nesnenin şifresi, Region’lar arası KMS çağrıları olmadan ve veri anahtarını yeniden sarmalamadan (re-wrapping) hedef Region’da çözülebilir. Bu, bölgesel bir yük devretme (Regional failover) durumunda kullanılabilir kalması gereken şifrelenmiş, kopyalanmış bucket’lar için standart modeldir.

Müşteri tarafından yönetilen bir KMS anahtarı altında hesaplar arası anlık görüntü (snapshot) ve nesne paylaşımı, hedef hesaptaki principal’ların anahtar politikası aracılığıyla kaynak anahtar üzerinde kms:Decrypt, kms:CreateGrant, kms:DescribeKey ve kms:ReEncrypt* izinlerine ve ayrıca eşleşen IAM izinlerine sahip olmasını gerektirir. AWS tarafından yönetilen anahtarlar (ör. aws/ebs, aws/s3) hesaplar arasında paylaşılamaz, bu nedenle hesaplar arası iş akışları için müşteri tarafından yönetilen anahtarlar zorunludur.

Genel Erişimi Engelleme ve CloudFront Erişimini Kısıtlama

S3 Genel Erişimi Engelleme (BPA) dört ayara sahiptir — yeni genel ACL’leri engelleme, mevcut genel ACL’leri yoksayma, yeni genel bucket politikalarını engelleme, genel bucket politikalarını kısıtlama — ve bu ayarlar bucket başına ve daha da önemlisi hesap düzeyinde yapılandırılabilir. Hesap düzeyindeki BPA, genel erişim izni verebilecek herhangi bir bucket politikasını geçersiz kılar ve “bu hesaptaki hiçbir nesne herkese açık olamaz” senaryosu için doğru kontroldür. Yalnızca bucket düzeyindeki politikalar kırılgandır: yeni bir bucket bu politika olmadan başlatılabilir; hesap düzeyindeki BPA ise varsayılan olarak kapalı (fail-closed) çalışır.

Bir üye hesaptaki yöneticinin BPA’yı devre dışı bırakmasını önlemek için, Organizations OU veya kök düzeyinde bir Service Control Policy katmanı ekleyin:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

S3 içeriğini yalnızca CloudFront üzerinden sunmak için, dağıtıma eski OAI’nin modern alternatifi olan bir Origin Access Control (OAC) ekleyin ve bucket politikasını dağıtım ARN’sine göre koşullandırın:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA, bucket üzerinde etkin kalır. Belirli bir kullanıcının özel nesnelere zamanla sınırlı erişimi (yükleme/indirme için son kullanma tarihi) için, imzalayan principal’ın izinlerini devralan gömülü bir imzaya sahip bir presigned URL (önceden imzalanmış URL) oluşturun.

Özel Ağ Yolları: Gateway Uç Noktaları

Bir VPC içindeki EC2’den S3’e giden trafik, AWS özel omurgasını otomatik olarak kullanmaz. Yapılandırma olmadan, S3 API çağrıları genel uç noktalara çözümlenir ve internet gateway veya NAT gateway üzerinden geçerek NAT veri işleme ücretlerine neden olur ve trafiği internete maruz bırakır. S3 (ve DynamoDB) için bir gateway VPC endpoint ücretsizdir, belirtilen route table’lara bir prefix-list rotası olarak eklenir ve trafiği AWS ağında tutar. S3 için ayrıca faturalandırılan ve erişimin on-premises’ten Direct Connect aracılığıyla kaynaklandığı durumlarda kullanışlı olan interface endpoint’ler (PrivateLink) de mevcuttur. Bucket’ın yalnızca onaylanmış VPC uç noktalarından erişilebilir olmasını zorunlu kılmak için uç noktayı bir aws:SourceVpce koşulu içeren bucket politikasıyla eşleştirin — bu, regülasyona tabi iş yükleri için standart bir modeldir.

Anında Dönüşüm için Object Lambda

S3 Object Lambda, GET/HEAD/LIST yoluna bir Lambda fonksiyonu ekler, böylece çağırana döndürülen nesne okuma anında dönüştürülür. Bu, her bir varyant (redakte edilmiş, yeniden boyutlandırılmış, yeniden biçimlendirilmiş) için verilerin kopyalanmasını önler ve temel bucket’ta tek bir doğruluk kaynağı (single source of truth) tutar. Tipik kullanım alanları: Analistler için PII (Kişisel Tanımlayıcı Bilgiler) redaksiyonu karşısında denetçiler için tam veri, kullanıcı başına görüntü filigranlama, eski istemciler için XML’den JSON’a dönüştürme. IAM ve bucket politikaları hala temel nesneye erişimi kontrol eder; Lambda yalnızca kendi execution role’ünün izin verdiği şeyleri görür.

Olay Bildirimleri

S3, olayları (s3:ObjectCreated:*, s3:ObjectRemoved:*, replikasyon ve yaşam döngüsü olayları) Lambda, SQS, SNS veya EventBridge’e yayar. Birden çok hedefe, nesne meta verilerine göre filtrelemeye veya hesaplar arası yönlendirmeye ihtiyacınız olduğunda EventBridge tercih edilir; yükleme sırasında küçük resim oluşturma gibi tek hedefli işlem hatları için doğrudan bildirimler daha basit ve daha ucuzdur. Bildirimler en az bir kez (at-least-once) teslim edilir, bu nedenle tüketicilerin idempotent (tekrarlanan işlemlerde aynı sonucu üreten) olması gerekir.

Verim Optimizasyonu: Multipart Upload ve Transfer Acceleration

100 MB’tan büyük nesneler için multipart upload en iyi uygulamadır; 5 GB’ın üzerinde ise zorunludur. Parçalar paralel olarak yüklenir, başarısız olan parçalar bağımsız olarak yeniden denenir ve verim eşzamanlılıkla (concurrency) ölçeklenir. Byte-range GET istekleri, indirmelerde eşdeğer paralellik sağlar. Belirtildiği gibi, sahipsiz (orphaned) parçalar için faturalandırmayı önlemek amacıyla her zaman bir AbortIncompleteMultipartUpload yaşam döngüsü kuralı ekleyin.

S3 Transfer Acceleration, yüklemeleri AWS omurgası üzerinden en yakın CloudFront edge noktasına yönlendirir — tek bir bucket’a yükleme yapan küresel olarak dağıtılmış istemciler için kullanılır. İndirmeler için, edge’de önbelleğe almak amacıyla S3’ün önüne CloudFront koyun. Transfer Acceleration yükleme odaklıdır; CloudFront ise indirme odaklıdır; birbiriyle ilişkili ancak farklı sorunları çözerler.

EBS: Birim Türleri, Şifreleme ve Snapshot’lar

EBS birimleri, tek bir EC2 instance’ına bağlı, AZ kapsamındaki blok cihazlardır. gp3 varsayılan genel amaçlı SSD’dir; gp2’ye göre en önemli avantajı, IOPS (16.000’e kadar) ve throughput (1.000 MiB/s’ye kadar) değerlerinin kapasiteden bağımsız olarak sağlanmasıdır. Bu, sırf performans hedeflerine ulaşmak için depolama alanını aşırı tahsis etme gibi gp2’ye özgü kötü bir pratiği ortadan kaldırır. io2 Block Express, gecikmeye duyarlı veritabanları için milisaniyenin altında gecikme süresiyle 256.000’e kadar IOPS sunar. st1 ve sc1, throughput odaklı sıralı (sequential) ve soğuk (cold) iş yükleri için HDD tabanlıdır. io1/io2’deki Multi-Attach özelliği mevcuttur ancak aynı AZ içinde, küme farkındalığına sahip (cluster-aware) bir dosya sistemi çalıştıran 16 instance ile sınırlıdır — bu genel bir “paylaşılan EBS” modeli değil, dar kapsamlı bir istisnadır. EBS’yi (örneğin bir load balancer arkasındaki) birden çok instance’a genel olarak bağlamaya çalışmak, her birimin özel bir blok cihaz olması nedeniyle tam olarak “sayfa yenilendiğinde bazı belgeler görünüyor, bazıları görünmüyor” belirtisine yol açan kategorik bir hatadır.

EBS birimleri, KMS tarafından sarmalanmış veri anahtarları kullanılarak AES-256 ile bekleme durumunda (at rest) şifrelenir. Şifreleme işlemi şeffaftır — performans kaybı olmaz, uygulama değişikliği gerektirmez. Bir birim şifrelendiğinde, ondan türetilen snapshot’lar ve birimler de şifrelenir; yerinde şifrelemeyi kaldıramazsınız. Her yeni birimin ve snapshot’ın, geliştiricinin hatırlamasına gerek kalmaksızın şifrelenmesi için Bölge başına varsayılan EBS şifrelemesini (EBS encryption by default) etkinleştirin:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Mevcut şifrelenmemiş birimler geriye dönük olarak şifrelenmez — düzeltme işlemi, snapshot alma, şifreleme ile kopyalama ve şifrelenmiş snapshot’tan yeni birim oluşturma adımlarını gerektirir.

Snapshot’lar, S3 tarafından yönetilen altyapıda saklanan artımlı, blok seviyesinde yedeklerdir — ancak ücretsiz değildirler (saklanan değişmiş bloklar için ödeme yaparsınız), kaynak birim silindiğinde kaybolmazlar ve onlara referans veren bir AMI’nin kaydı silindiğinde (deregistered) kaldırılmazlar. aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) veya AWS Backup aracılığıyla bunları EBS Snapshots Archive katmanına (%75 daha ucuz, 24–72 saatte geri yükleme) taşıyarak eskimesini sağlayın. Fast Snapshot Restore (FSR), belirli AZ’lerde bir snapshot’ı önceden ısıtır (pre-warms), böylece ondan başlatılan instance’lar anında tam performans sunar — hızlı bir şekilde ölçeklenmesi (scale-out) gereken autoscaling gruplarının arkasındaki AMI’ler için etkinleştirin.

Recycle Bin (Geri Dönüşüm Kutusu), silinen EBS snapshot’larını ve AMI’leri bir geri yükleme penceresine (1 gün ila 1 yıl) alır. Bu özellik olmadan, snapshot silme işlemi anında ve kalıcıdır:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Uzun vadeli uyumluluk (compliance) verilerini saklamak için yalnızca günlük EBS snapshot’larına güvenmek yaygın bir mimari hatasıdır — snapshot’lar sıcak (warm) depolamaya daha yakın fiyatlandırılır ve açıkça arşiv katmanlarına geçiş gerektirir.

Amazon EFS: Linux Filoları için Paylaşılan POSIX

EFS, bir Bölge’deki birden çok AZ’de bulunan binlerce EC2, ECS, EKS veya Lambda istemcisinden ve Direct Connect veya VPN aracılığıyla şirket içi (on-premises) sunuculardan aynı anda bağlanabilen (mountable), tam yönetilen, elastik, POSIX uyumlu bir NFSv4.1 dosya sistemidir. Tanımlayıcı özelliği, aynı dosya sisteminin, özdeş dosya tanıtıcıları (file handles) ve bayt seviyesinde anlamsallık (semantics) ile her istemci tarafından aynı anda görülebilmesidir. Bu nedenle EFS, bir load balancer arkasındaki bir Linux filosunun ortak bir dosya setini — kullanıcı yüklemeleri, yapılandırma dosyaları, paylaşılan ev dizinleri — paylaşması gerektiğinde doğru yanıttır.

Bağlantı hedefleri (Mount targets), yapılandırdığınız her AZ alt ağında (subnet) bulunur. amazon-efs-utils yardımcısı, taşıma sırasında TLS (TLS in transit) ve IAM ile bağlanma yetkilendirmesini (mount authorization) sağlar:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFS depolama sınıfları iki boyuta ayrılır. Yaşam döngüsü yönetimi (Lifecycle management), 7–90 gün boyunca erişilmeyen dosyaları Standard’dan Infrequent Access’e ve isteğe bağlı olarak Archive’a taşıyarak depolama maliyetini %92’ye kadar düşürür; Intelligent-Tiering ise erişim olduğunda dosyaları geri taşır. One Zone sınıfları, verileri tek bir AZ’de ~%47 daha ucuza saklar — geliştirme/test veya yeniden üretilebilir veriler için uygundur, ancak bir AZ arızası sırasında veri kaybının kabul edilemez olduğu durumlar için asla uygun değildir. Halihazırda EFS Standard-IA üzerinde çalışan bir iş yükü için maliyet optimizasyonu hamlesi, herhangi bir uygulama değişikliği yapmadan EFS One Zone-IA’ya geçmektir.

Performansın iki bağımsız ayarı vardır. Performans modu (Performance mode) (oluşturma sırasında ayarlanır): General Purpose en düşük gecikme süresine sahiptir ve meta veri ağırlıklı web sunumu için doğrudur; Max I/O ise Elastic tarafından geçersiz kılınan eski bir seçenektir. Throughput modu (Throughput mode): Bursting boyuta göre ölçeklenir (GB başına 50 KB/s temel, temel seviyenin altındayken burst kredileri), Provisioned boyuttan bağımsız olarak sabit bir MB/s için ödeme yapar ve Elastic — mevcut varsayılan — kapasite planlaması olmadan otomatik olarak 10+ GB/s’ye kadar ölçeklenir. Sürekli yük altındaki küçük bir dosya sistemi, burst kredilerini tüketebilir ve düşük bir temel seviyeye kadar kısıtlanabilir (throttle), bu nedenle küçük alana sahip ağır I/O’lu iş yükleri Elastic veya Provisioned kullanmalıdır.

EFS, yüksek IOPS’lu blok depolamanın bir alternatifi değildir. Her EFS I/O işlemi, ağ üzerinden bir NFS RPC çağrısıdır, bu nedenle tek yazıcılı (single-writer), milisaniye altı, işlem günlüğü (transaction-log) tarzı iş yükleri EBS io2 Block Express üzerinde olmalıdır — tek bir birim, milisaniye altı gecikmeyle 256.000 IOPS sunar ki EFS’nin işlem başına bu performansı yakalaması mümkün değildir. EFS ayrıca, Deep Archive’a kıyasla soğuk (cold) veriler için fahiş fiyatlıdır; uyumluluk verilerini “kolay olduğu için” EFS’de tutmak savunulamaz bir durumdur.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx, protokole ve iş yüküne göre seçilen yönetilen dosya sistemlerinden oluşan bir ailedir:

FSx for Windows File Server, Active Directory üzerinden Kerberos ile birlikte yerel SMB 2.0/3.1.1, NTFS ACL’ler, DFS Ad Alanları ve gölge kopyalar (shadow copies) sunar. Multi-AZ dağıtımları, bir AZ’de aktif bir dosya sunucusu ve başka bir AZ’de eşzamanlı olarak çoğaltılan bir yedek (standby) sunucu ile tek bir yük devretme (failover) DNS adı oluşturur. AD entegrasyonu isteğe bağlı değildir: FSx, AWS Managed Microsoft AD’ye veya erişilebilir durumdaki kendi kendine yönetilen bir AD’ye katılmalıdır ve istemciler, etki alanı SID’lerine karşı etki alanı kullanıcıları olarak kimlik doğrulaması yapar. AD’yi atlamak veya istemcileri, ormanlar arası güven (cross-forest trust) ilişkisi olmayan güvenilmeyen bir ormandaki (untrusted forest) bir dosya sistemine yönlendirmek, paylaşım görünür olmasına rağmen erişim reddedildi şeklindeki klasik belirtiyi ortaya çıkarır. FSx for Windows, Windows dosya paylaşımlarının lift-and-shift (olduğu gibi taşıma) yöntemiyle taşınması için doğrudan kullanılabilecek hedeftir.

FSx for Lustre, HPC, ML eğitimi, EDA ve genomik çalışmaları için tasarlanmış paralel bir POSIX dosya sistemidir — binlerce istemci, saniyede yüzlerce GB’lık aktarım hızı, milisaniyenin altında meta veri erişimi sunar. En kritik AWS özelliği, S3 ile olan veri deposu ilişkisidir (data repository association): nesne anahtarları (object keys) Lustre ad alanında dosyalar olarak görünür ve ilk erişimde tembel yükleme (lazily loaded) ile yüklenir (veya

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

ile önceden yüklenebilir); yeni/değiştirilmiş dosyalar ise zamanlanmış olarak veya isteğe bağlı bir şekilde S3’e geri aktarılır. Standart HPC kullanım modeli şöyledir:

1. Şirket içi (on-prem) veri setlerini S3’e kopyalayın (DataSync veya Storage Gateway aracılığıyla).
2. Bu bucket’a bağlı bir Lustre dosya sistemi oluşturun.
3. Tüm Spot çalışanlarına (worker) bağlayın (mount); girdileri okuyun, çıktıları hat hızında (line rate) yazın.
4. Sonuçları, kalıcı uzun vadeli depo olarak kalacak olan S3’e aktarın.
5. İş bittiğinde Lustre dosya sistemini silin.

Lustre Scratch dağıtımlarında replikasyon yoktur ve donanım arızasında veri kaybı yaşanır — en ucuz ve en hızlı seçenektir, geçici iş verileri için uygundur. Persistent dağıtımlar, daha yüksek dayanıklılık için bir AZ içinde çoğaltma yapar. Aktarım hızı, TiB başına MB/s (50/125/250/500/1000) olarak sağlanır, bu da kapasiteyi performanstan ayırır.

FSx for NetApp ONTAP çoklu protokol çözümüdür: aynı veri üzerinde eş zamanlı olarak NFS, SMB ve iSCSI desteği sunar; ayrıca anlık görüntüler (snapshots), SnapMirror replikasyonu, FlexClone’lar ve tekilleştirme (deduplication) özelliklerine sahiptir. Multi-AZ yedekliliği ile protokoller arası erişime ihtiyaç duyan karma Linux NFS ve Windows SMB paylaşımlarını birleştirirken veya şirket içi NetApp’ten geçiş yaparken ONTAP’ı seçin. FSx for OpenZFS, NFS üzerinden ZFS özelliklerine (anlık görüntüler, klonlar) ihtiyaç duyan Linux iş yükleri için özel bir boşluğu doldurur. ONTAP’ın çoklu protokol gücünü diğer varyantlarla karıştırmayın.

Yanlış seçim yaparsanız net bir şekilde başarısız olursunuz: paylaşılan bir iş yükü için EBS, bir Windows SMB paylaşımı için EFS veya AD entegreli bir Windows paylaşımı için Lustre kullanmak tamamen yanlış seçimlerdir — öncelikle protokolü ve erişim modelini eşleştirin.

Storage Gateway: Hibrit Erişim

Storage Gateway, bulut depolama alanını sanki yerelmiş gibi sunar. Bu, veriyi taşıyan DataSync’ten farklıdır.

Medya kütüphanesini S3’e taşımış ancak hala şirket içinde (on-prem) düşük gecikmeli okumalara ihtiyaç duyan bir render uygulaması için S3 File Gateway en uygun çözümdür — NFS/SMB erişimi, yerel önbellek ve seyrek erişilen (cold) nesnelerin S3’ten isteğe bağlı olarak çekilmesi. FSx File Gateway şube çözümüdür: merkezi bir bulut FSx paylaşımının LAN hızında SMB önbelleğidir, EC2 örnekleri arasında paylaşılan erişim için bir çözüm değildir (EC2 örnekleri FSx’i doğrudan bağlamalıdır). Volume Gateway, iş yükü dosya semantiği yerine blok tabanlı iSCSI kullandığında uygulanır. Tape Gateway, mevcut yedekleme yazılımları altında fiziksel teyp kütüphanelerinin yerini alır.

Veri Aktarımı ve Geçişi

AWS DataSync, NFS, SMB, HDFS ve nesne depolarından S3, EFS veya FSx’e veri taşımak için kullanılan aracı tabanlı (agent-based) bir çevrimiçi geçiş hizmetidir — açık kaynaklı araçlardan 10 kata kadar daha hızlıdır ve şifreleme, bütünlük doğrulaması, zamanlama ve POSIX meta verileri ile NTFS ACL’lerinin korunması gibi özellikler sunar. Milyonlarca küçük dosya ve derin hiyerarşilere sahip büyük ölçekli bir SMB geçişi için en az ek yük getiren çözüm, DataSync kullanarak FSx for Windows’a geçiş yapmaktır: SMB korunur, ACL’ler/zaman damgaları bozulmaz, küçük dosya aktarım hızı paralel transferler ile yönetilir ve uygulama değişikliği gerekmez. Böyle bir veri setini doğrudan S3’e taşımak bir tuzaktır — nesne depolama, derin ön eklerdeki (deep prefixes) küçük dosyaların listelenmesini verimsiz bir şekilde yapar ve SMB istemcileri bucket’ları bağlayamaz.

AWS Snow Family, çevrimdışı veri aktarımı için fiziksel cihazlar gönderir: Snowcone (8 TB’a kadar, uç (edge) için dayanıklılaştırılmış), Snowball Edge (~80 TB’a kadar kullanılabilir, işlem (compute) seçenekleriyle) ve Snowmobile (exabyte ölçeğinde). Pratik kural: ağ üzerinden aktarım bir haftadan uzun sürecekse, Snowball daha ucuz ve daha hızlıdır.

AWS Transfer Family, S3 veya EFS tarafından desteklenen SFTP, FTPS, FTP ve AS2 protokollerini sunar — harici iş ortaklarının standart dosya aktarım protokollerini kullanmaya devam etmesi gerektiğinde doğru çözümdür.

AWS Backup, Bölgeler Arası Kopyalama ve Vault Lock

AWS Backup; EBS, EFS, FSx, RDS, DynamoDB, S3 ve daha fazlası için politikaları merkezileştirir. Bir yedekleme planı; zamanlamayı, sıcak saklama süresini, soğuk depolamaya geçişi ve Bölgeler Arası/hesaplar arası kopyalama eylemlerini tanımlar:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

Soğuk depolamaya geçiş, en az 90 gün sıcak saklama ve ek olarak en az 90 gün soğuk depolamada kalmayı gerektirir; yanlış yapılandırılmış yaşam döngüleri reddedilir. Gerçek anlamda çok yıllı yasal saklama gereksinimleri için, yöneticilerin bile saklama süresini kısaltmasını engelleyen AWS Backup Vault Lock (WORM) ile birlikte kullanın. Bu, SEC 17a-4 ve benzeri yönetmelikleri karşılar. Bölgeler arası kopyalama bölgesel DR (Felaket Kurtarma) senaryolarını ele alırken; hesaplar arası kopyalama, yedekleri üretim hesabının etki alanından (blast radius) izole ederek fidye yazılımı (ransomware) ve içeriden gelen tehdit senaryolarını ele alır.

Seçim Yardımcı Tablosu

← Sunucusuz ve Olay Odaklı Mimariler · Tüm alanlar · Veri Aktarımı ve Migrasyon →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →