Amazon SAA-C03: İçerik Dağıtımı, Edge ve Performans Optimizasyonu — Ç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.

Amazon CloudFront: Nedir ve Neden Faydalıdır?

Amazon CloudFront, 600’den fazla varlık noktası (PoP) üzerine kurulu, küresel olarak dağıtılmış bir içerik dağıtım ağıdır. Görevi, izleyici TLS bağlantısını en yakın kenar konumunda sonlandırmak ve ya önbelleğe alınmış yanıtları anında sunmak ya da önbellekte bulunamayan istekleri (cache miss) AWS’in özel omurga ağı üzerinden origin’e proxy’lemektir. Performans avantajı iki yönlüdür: önbellek isabetleri (cache hit) gidiş-dönüş süresini tek haneli milisaniyelere düşürür ve origin’in yükünü tamamen alır; önbellek isabetsizlikleri (cache miss) ise kenar konumundaki optimize edilmiş TLS/TCP sonlandırması, HTTP/2 ve HTTP/3 desteği, origin’e olan keep-alive bağlantılarının yeniden kullanılması ve gürültülü genel internetten kaçınan omurga ağı transitinden fayda sağlar.

Yaygın bir yanılgı, CloudFront’un yalnızca statik varlıkları hızlandırdığıdır. CloudFront’un arkasına CachingDisabled politikasıyla bir ALB yerleştirmek, izleyicinin el sıkışması (handshake) işleminin interneti aşıp origin Region’a gitmek yerine yerel PoP’ta tamamlanması sayesinde dinamik API performansını yine de iyileştirir. Bunu karma bir iş yüküyle birleştirin — örneğin S3’ten sunulan /static/* ve bir ALB’den sunulan /api/* — ve tek bir dağıtım (distribution) her ikisini de yönetebilir:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Ardından Route 53 alias kayıtları, www.example.com adresini dağıtımın d123.cloudfront.net adresine yönlendirir — alias kayıtları ücretsizdir ve doğrudan CloudFront’un anycast IP’lerine çözümlenir.

Sertifikalar us-east-1’de Yaşar

Özel bir alan adı (custom domain) üzerinden hizmet veren herhangi bir CloudFront dağıtımı için, AWS Certificate Manager’daki izleyiciye yönelik TLS sertifikası, origin bucket’ının, ALB’nin veya kullanıcıların nerede olduğundan bağımsız olarak mutlaka us-east-1 (N. Virginia) bölgesinde oluşturulmalıdır. CloudFront, kontrol düzlemi (control plane) us-east-1’e sabitlenmiş küresel bir hizmettir; kenar konumları sertifikayı bu Region’dan çeker. S3 bucket’ınız orada bulunduğu için eu-west-1 bölgesinde bir ACM sertifikası talep etmek hatalı bir yaklaşımdır — dağıtım (distribution) bu sertifikayı asla göremez.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

CloudFront ile bir ALB origin’i arasında TLS’i ikinci kez sonlandırırsanız, bu origin’e yönelik sertifika ALB’nin bulunduğu Region’da yer alır. Yalnızca izleyici sertifikası us-east-1’e zorunludur. Aynı kural, API Gateway’in kenar optimizasyonlu (edge-optimized) özel alan adları için de geçerlidir (bunlar dahili olarak AWS tarafından yönetilen bir CloudFront dağıtımı kullanır): sertifika us-east-1’de olmalıdır. Buna karşılık, Bölgesel (Regional) API Gateway uç noktaları, API’nin kendi Region’ından bir sertifika alır.

S3 Origin’leri için Origin Access Control

Bir S3 bucket’ını herkese açık bırakıp önüne CloudFront koymak amacını boşa çıkarır: izleyiciler doğrudan S3 REST uç noktasına erişerek CloudFront’u atlar, böylece WAF, coğrafi kısıtlamalar, imzalı URL’ler ve önbellek avantajlarını es geçmiş olur ve potansiyel olarak verileri açığa çıkarır.

Modern çözüm, eski Origin Access Identity (OAI) yönteminin yerini alan Origin Access Control (OAC)‘dir. OAC, SigV4 imzalamasını kullanır, SSE-KMS’i destekler, 2022’den sonra açılanlar da dahil olmak üzere her S3 Region’ında çalışır ve dinamik istekleri destekler. Block Public Access açık kalır, ACL’lere gerek yoktur ve bucket politikası, yalnızca CloudFront hizmet kimliğine (service principal) okuma erişimi verir ve bu erişim de belirli distribution ARN’ı ile daha da kısıtlanır:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI hala çalışmaktadır ancak eski (legacy) kabul edilmelidir — yeni işler için daima OAC’yi seçin.

Önbellek Doğruluğu

Önbellek etkinliği, origin’in döndürdüğü Cache-Control ve Expires başlıklarına ve CloudFront önbellek politikasının minimum/varsayılan/maksimum TTL değerlerine bağlıdır. Parmak izli (fingerprinted), değiştirilemez (immutable) varlıklar agresif bir şekilde önbelleğe alınmalı; bunlara referans veren HTML iskeletleri, dağıtımların yayılması için kısa ömürlü olmalı; kimliği doğrulanmış JSON ise paylaşılan CDN’de kesinlikle önbelleğe alınmamalıdır:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

İki simetrik tuzak yaygındır. Birincisi, eğer origin hiçbir önbellek başlığı (header) göndermezse, CloudFront dağıtımın varsayılan TTL değerini kullanır ve dinamik yanıtları saatlerce sessizce önbelleğe alabilir. İkincisi, önbelleğe alınması gereken varlıklara toptan Cache-Control: no-cache uygulamak, her isteği origin’e geri gönderir ve CDN’i işlevsiz kılar.

En tehlikeli tuzak, kişiselleştirilmiş yanıtları uygun başlıklar (header) olmadan önbelleğe almaktır. Eğer /account/dashboard A kullanıcısına özel bir HTML döndürüyorsa ancak origin no-store başlığını eklemezse ve önbellek politikası önbellek anahtarına (cache key) bir kimlik doğrulama başlığı veya cookie’si dahil etmiyorsa, kenar konumu A kullanıcısının sayfasını B kullanıcısına memnuniyetle sunacaktır. Bu tür yanıtları ya private, no-store olarak işaretleyin ya da oturum tanımlayıcısını önbellek anahtarına dahil edip daha düşük isabet oranını (hit ratio) kabul edin.

Statik içerik sunan bir EC2 On-Demand örneklerinden oluşan Auto Scaling grubunun olduğu bir maliyet optimizasyonu senaryosunda, doğru yeniden tasarım, varlıkları S3’e taşımak, önüne OAC ile CloudFront koymak ve ASG’yi ortadan kaldırmak veya küçültmektir. Bu, maliyeti saatlik işlem gücünden istek başına teslimata kaydırır ki bu, statik iş yükleri için kat kat daha ucuzdur.

İmzalı URL’ler, İmzalı Cookie’ler ve Coğrafi Kısıtlama

CloudFront, imzalı URL’leri (tek bir nesneye zaman sınırlı, isteğe bağlı olarak IP kısıtlamalı erişim — satın alınmış bir video indirmesi, tek seferlik bir PDF bağlantısı gibi) ve imzalı cookie’leri (bir yol deseniyle (path pattern) eşleşen birçok nesneye erişim — bir katalogda gezinen kimliği doğrulanmış bir abone gibi) destekler. Her ikisi de, public anahtarı CloudFront’a yüklenmiş olan güvenilir bir anahtar grubu (trusted key group) kullanır; private anahtar ise son kullanma tarihi, kaynak IP aralığı veya URL desenini belirten bir politikayı imzalar.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Bu, CloudFront’u atlayan ve doğrudan bucket erişimi sağlayan bir S3 presigned URL’sinden farklıdır. CloudFront imzalı URL’lerini OAC ile eşleştirin, böylece bucket uçtan uca özel kalır.

Coğrafi kısıtlama (Geo-restriction), istekler önbelleğe veya origin’e ulaşmadan önce, dağıtım (distribution) seviyesinde ülke bazında izin listeleri veya engelleme listeleri uygular. CloudFront tarafından bakımı yapılan GeoIP veritabanını kullanır ve lisans ambargolarını uygulamak için ucuz ve önbelleği atlamayı engelleyen bir mekanizmadır. Daha hassas mantıklar için (eyalet düzeyinde, başlık kombinasyonları gibi) bir CloudFront Function veya Lambda@Edge’e başvurun; tam bir kural motoru için ise WAF kullanın.

AWS Global Accelerator

Global Accelerator bir CDN değildir ve önbelleğe alma yapmaz. AWS uç konumlarından küresel olarak duyurulan iki statik anycast IPv4 adresi (veya BYOIP) sağlar. İstemci TCP veya UDP bağlantıları, en yakın uç konumdan AWS omurgasına girer ve AWS’nin özel ağı üzerinden, trafik kadranları ve ağırlıklarla uç nokta grupları halinde gruplandırılmış bir veya daha fazla Bölgedeki en sağlıklı uç noktaya (ALB, NLB, EC2 veya Elastic IP) yönlendirilir.

Statik IP’ler üç somut fayda sağlar: arka uç yeniden mimarilendirilse bile istemciler ve güvenlik duvarı izin listeleri asla değişmez; bölgesel yük devretme, sağlık kontrolü değişikliklerinde trafiği uç nokta grupları arasında kaydırarak saniyeler içinde tamamlanır ve DNS TTL yayılımını tamamen atlar; ve TCP el sıkışması uçta sonlanır, uzun mesafeli iletim ise AWS’nin omurgası üzerinden çalışır.

Şu durumlarda Global Accelerator’ı seçin:

• Protokol HTTP dışıdır: Oyun veya VoIP için UDP, MQTT, SIP, SFTP, özel TCP.
• Kurumsal izin listeleri veya adresleri sabit kodlayan mobil uygulamalar için statik IP’lere ihtiyacınız vardır.
• Durum bilgisi tutan (stateful) aktif-aktif dağıtımlar için bir dakikanın altında bölgesel yük devretmeye ihtiyacınız vardır.
• İş yükü dinamiktir ve önbelleğe alınamaz, bu nedenle bir CDN çok az değer sunar.

Şu durumlarda CloudFront’u seçin:

• İçerik önbelleğe alınabilir (resimler, video segmentleri, statik HTML, TTL’li API yanıtları).
• Lambda@Edge veya CloudFront Functions aracılığıyla uçta hesaplama (edge compute) istersiniz.
• Uçta WAF, imzalı URL’ler/çerezler veya alan düzeyinde şifrelemeye ihtiyacınız vardır.

Kaçınılması gereken iki tuzak. “Oyun sunucularımızı küresel olarak daha hızlı hale getirmek” için CloudFront’u seçmek, oyun trafiğinin UDP tabanlı ve önbelleğe alınamaz olması nedeniyle başarısız olur — Global Accelerator gereklidir. Tersine, statik bir web sitesi için Global Accelerator’ı seçmek pahalıdır (sabit saatlik ücret artı GB başına ücret) ve önbelleğe alma avantajını kaybettirir — CloudFront, kaynak çıkış (origin egress) maliyetini önemli ölçüde azaltırdı. Kullanıcıların gecikmeyi tolere edebildiği, küresel olarak dağıtılmış ancak tek Bölgeli bir HTTP API için, sadece Route 53 gecikme tabanlı yönlendirme yeterli ve her ikisinden de daha ucuz olabilir.

Küresel Trafik için Route 53 Yönlendirme Politikaları

Route 53, bir istemcinin hangi uç noktayı çözümleyeceğini seçer; ardından CloudFront veya Global Accelerator bağlantıyı yönetir. Üç politika küresel mimarilerde baskındır.

Gecikme tabanlı yönlendirme, çözümleyicinin konumundan her bir Bölgeye olan gerçek ağ gecikmesini ölçer ve en hızlı olanı döndürür. Kullanıcıları o an en hızlı olan Bölgeye çekmek istediğiniz, birden çok Bölgedeki özdeş yığınlar için kullanın.

Coğrafi yakınlık tabanlı yönlendirme, gecikme tabanlı olmaktan ziyade koordinat tabanlıdır: her bir uç noktanın konumunu (veya AWS Bölgesini) siz beyan edersiniz ve Route 53 kullanıcıları coğrafi olarak en yakın olana gönderir. Ayırt edici özelliği, etkin hizmet alanını genişleten veya daraltan bir eğilim (bias) değeridir (−99 ila +99) — bu, Bölgesel bir lansman sırasında trafiği kademeli olarak kaydırmak veya bakım için bir Bölgedeki trafiği boşaltmak için kullanışlıdır. Coğrafi yakınlık, Route 53 trafik akışı (trafik ilkeleri) gerektirir ve genellikle her Bölgedeki bölgesel bir NLB veya ALB ile eşleştirilir.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Yük devretme (failover) yönlendirmesi, sağlık kontrollerine bağlı bir birincil/ikincil çifti kullanır. Bu, TTL ve çözümleyici önbelleğe almasına tabi olan, DNS düzeyinde bir yük devretmedir, bu nedenle Global Accelerator’ın veri düzlemi (data-plane) yük devretmesinden daha yavaştır — bir dakikalık DNS yayılımının tolere edilebilir olduğu basit aktif-pasif durumlar için yük devretme yönlendirmesini, saniyelere ihtiyacınız olduğunda ise Global Accelerator’ı seçin.

Bu politikalar birleştirilebilir. Yaygın bir küresel model: Route 53 gecikme veya coğrafi yakınlık kayıtları, Global Accelerator’ı (TCP/UDP için) veya CloudFront’u (önbelleğe alınabilir HTTPS için) işaret eder ve altında bir güvenlik ağı olarak sağlık kontrollü yük devretme kayıtları bulunur. Katmanlama kasıtlıdır: Route 53 Bölgeyi seçer, Global Accelerator veya CloudFront uç konumu ve omurga üzerindeki yolu seçer ve bölgesel bir yük dengeleyici Bölge içindeki hedefi seçer.

API Gateway Uç Nokta Türleri ve Özel Alan Adları

API Gateway, farklı topolojilere sahip üç uç nokta türü sunar:

Uç için optimize edilmiş uç noktalar, API’yi, AWS tarafından yönetilen ve doğrudan yapılandıramayacağınız bir CloudFront dağıtımına sarar. Bu, hızlı küresel erişim için kullanışlıdır ancak kendi önbellek davranışlarınızı, WAF kurallarınızı veya kaynak istek politikalarınızı istediğinizde sınırlayıcıdır. Maksimum kontrol için deyimsel model, müşteri tarafından yönetilen bir CloudFront dağıtımı tarafından ön yüzde sunulan Bölgesel bir uç noktadır.

Sertifika yerleşimi CloudFront’un kuralını takip eder: uç için optimize edilmiş özel alan adları us-east-1‘de bir ACM sertifikası gerektirir; Bölgesel uç noktalar, sertifikanın API ile aynı Bölgede olmasını gerektirir. HTTP API’ler minimum TLS 1.2’yi zorunlu kılar; REST API’ler TLS 1.3’e kadar güvenlik politikalarını destekler.

ACM Sertifikaları: Oluşturulan, Doğrulanan, İçe Aktarılan

ACM, genel TLS sertifikalarını ücretsiz olarak oluşturur, otomatik olarak yeniler ve CloudFront, API Gateway, ALB, NLB ve diğer AWS hizmetleriyle doğrudan entegre olur. Doğrulama, ya DNS doğrulaması (ACM, Route 53’e veya herhangi bir DNS sağlayıcısına yerleştirmeniz için size bir CNAME verir; kayıt var olduğu sürece ACM sonsuza dek otomatik olarak yeniler) ya da e-posta doğrulaması (her yenileme için manuel tıklama gerektirir, otomasyon için kırılgandır) ile yapılır. DNS doğrulaması, üretim ortamındaki her şey için doğru varsayılan yöntemdir.

ACM tarafından oluşturulan sertifikalar dışa aktarılamaz ve entegre AWS hizmetleri dışında kullanılamaz. Mevzuat veya iş gereksinimi, belirli bir üçüncü taraf CA’yı zorunlu kıldığında — örneğin, belirli bir ticari sertifika sağlayıcısına zincirlenmesi ve TLS 1.3’ü zorunlu kılması gereken bir REST API — ACM tarafından oluşturulmuş bir sertifika kullanamazsınız. Sertifikayı gerekli CA’dan alın ve ACM’ye içe aktarın, ardından TLS 1.3 güvenlik politikasıyla Bölgesel bir API Gateway özel alan adına ekleyin.

İçe aktarmadaki tuzak iki yönlüdür: içe aktarılan sertifikalar otomatik olarak yenilenmez (süre dolmadan önce yeniden içe aktarılmazsa uç nokta tamamen başarısız olur) ve ACM içe aktarma sırasında zinciri doğrulamaz — bozuk bir ara sertifika yalnızca gerçek istemcilerden gelen handshake sırasında ortaya çıkar. Dağıtımdan önce tüm zinciri katı bir istemciye karşı test edin.

S3 Transfer Acceleration ve CloudFront Karşılaştırması

CloudFront indirmeleri optimize eder; S3 Transfer Acceleration ise yüklemeleri optimize eder. Transfer Acceleration, aynı CloudFront edge ağını tersten kullanır: PUT istekleri en yakın edge konumundan girer ve hedef bucket’ın Bölgesine AWS omurgası üzerinden ulaşır. Özellikle dünya geneline yayılmış bir kullanıcı grubunun tek bir Bölgedeki bir bucket’a büyük boyutlu nesneler yüklediği durumlarda öne çıkar — örneğin, dünya çapındaki saha mühendislerinin us-east-1‘e multi-gigabaytlık çizimler yüklemesi gibi.

Bu iki özellik aynı bucket üzerinde bir arada bulunabilir: Transfer Acceleration’ı etkinleştirin ve indirmeler için OAC ile bir CloudFront dağıtımı sunun. Küçük nesneler veya zaten bucket’ın Bölgesine yakın olan istemciler için Transfer Acceleration, fayda sağlamadan maliyeti artırır — karar vermeden önce ölçüm yapmak için S3 Transfer Acceleration hız karşılaştırma aracını kullanın. Hızlandırmanın devreye girmesi için istemcilerin s3-accelerate uç noktasını kullanması gerekir.

Katman 7 Koruması için AWS WAF

AWS WAF, HTTP(S) isteklerini korunan kaynağa ulaşmadan önce denetler. CloudFront dağıtımlarına, ALB’lere, API Gateway aşamalarına, AppSync API’lerine, Cognito kullanıcı havuzlarına, App Runner hizmetlerine ve Verified Access örneklerine eklenir. Bir web ACL; URI, başlıklar, sorgu dizeleri, gövde (varsayılan olarak 8 KB’a kadar, ALB/API Gateway’de 64 KB’a kadar genişletilebilir), IP setleri ve coğrafi konuma göre eşleşen kurallar içerir.

En yaygın yapı taşları AWS Yönetilen Kuralları‘dır: AWSManagedRulesCommonRuleSet ve AWSManagedRulesKnownBadInputsRuleSet, OWASP’ın en bilinen zafiyetlerini kapsar; AWSManagedRulesSQLiRuleSet ve XSS eşleşme ifadeleri ise enjeksiyon saldırılarını ele alır. Özel kurallar; coğrafi eşleşme (uyumluluk için ülke izin/engelleme listeleri), IP seti eşleşmeleri ve oran tabanlı kurallar ekler — bu kurallar, kayan beş dakikalık bir pencerede kaynak IP başına istek sayısını sayar ve bir eşik aşıldığında engelleme yapar. Oran tabanlı kurallar, HTTP flood ve kimlik bilgisi doldurma (credential stuffing) saldırılarına karşı ilk savunma hattıdır:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Bölge kuralları önemlidir. CloudFront için web ACL’leri globaldir ve us-east-1‘de oluşturulmalıdır. Bölgesel kaynaklar (ALB, API Gateway, vb.) için web ACL’leri ise kaynağın kendi Bölgesinde oluşturulur.

S3’teki statik bir siteyi korumak için WAF’ı bucket’a ekleyemezsiniz — S3, WAF destekli bir kaynak değildir. Doğru model, bucket’ın önüne CloudFront + OAC koymak ve web ACL’yi bu dağıtıma eklemektir. Bucket’a yalnızca CloudFront üzerinden erişilebilmesi, “tüm trafiği denetle” ilkesini gerçeğe dönüştüren şeydir.

Çoklu Hesap WAF Yönetişimi için Firewall Manager

WAF’ı tek tek hesap bazında yönetmek ölçeklenebilir değildir. Bir Organization genelinde, bir ekip kurumsal temel yapılandırmayı eklemeden yeni bir ALB başlattığında, uyumluluk durumu sessizce geriler. AWS Firewall Manager, kapsam dahilindeki hesaplara ve kaynaklara uygulanan organizasyon çapındaki politikalarla bu sorunu çözer.

Ön koşullar: Tüm özelliklerin etkinleştirildiği AWS Organizations, atanmış bir Firewall Manager yönetici hesabı ve her üye hesapta etkinleştirilmiş AWS Config. Politika türleri; AWS WAF, AWS Shield Advanced, güvenlik grupları (denetim ve kullanım), Network Firewall, Route 53 Resolver DNS Firewall ve üçüncü taraf güvenlik duvarlarını kapsar.

Bir WAF politikası, bir “ilk” kural grubunu (uygulamaya ait kurallardan önce değerlendirilir), bir “son” kural grubunu (sonra değerlendirilir) zorunlu kılabilir veya web ACL’yi tamamen değiştirebilir. Kaynak kapsamıyla eşleşen yeni ALB’ler veya CloudFront dağıtımları, kurumsal kural setini otomatik olarak alır ve uyumlu olmayan kaynaklar işaretlenir ve — düzeltme ayarlarına bağlı olarak — otomatik olarak düzeltilir. Bir senaryoda “birden çok hesap”, “merkezi olarak yönetme” veya “organizasyon genelinde tutarlı WAF kuralları” ifadeleri geçtiğinde, cevap hesap başına WAF değil, Firewall Manager’dır.

Shield Standard ve Shield Advanced

Yalnızca WAF’ın DDoS’u durdurduğunu varsaymak kritik bir hatadır. WAF, kendisine ulaşan istekler üzerinde çalışır — uygulama katmanı flood’ları, kimlik bilgisi doldurma (credential stuffing) ve bilinen exploit imzalarına karşı mükemmeldir — ancak Katman 3/4’teki büyük hacimli saldırılar (SYN flood’ları, UDP yansıtma) AWS Shield tarafından absorbe edilir.

Shield Standard, varsayılan olarak ücretsiz bir şekilde etkindir. Yaygın L3/L4 saldırılarına karşı otomatik olarak savunma yapar ve CloudFront, Route 53 ve Global Accelerator için geçerlidir; ELB, EC2 ve diğer kaynaklar için temel koruma sağlar. Saldırıya özgü görünürlük, Shield Müdahale Ekibi (Shield Response Team) ile etkileşim veya maliyet koruması sağlamaz.

Shield Advanced (kuruluş başına aylık 3.000 ABD doları, bir yıllık taahhüt) şunları ekler:

“Maliyet koruması ve uzman müdahalesi ile büyük ölçekli DDoS” için Shield Standard’ın yeterli olduğunu varsaymak yanlıştır, çünkü Standard sürümünde görünürlük, maliyet koruması ve SRT erişimi yoktur. Origin bir ELB arkasındaki EC2 olduğunda ve DNS üçüncü bir tarafta barındırıldığında (dolayısıyla Route 53 alias hileleri bir seçenek olmadığında), önerilen model, ELB üzerinde Shield Advanced’i etkinleştirmek ve uygulamayı CloudFront (yine Shield Advanced korumalı) ile ön plana alarak azaltma çevresini edge’e taşımak ve Region’a ulaşan saldırı yüzeyini küçültmektir.

Doğru katmanlı duruş şudur: L3/L4 hacimsel saldırılar için Shield, L7 filtrelemesi için WAF, her iki hizmetin de bağlandığı edge giriş noktası olarak CloudFront veya Global Accelerator ve politikayı tüm hesaplarda zorunlu kılmak için Firewall Manager.

← Ağ Oluşturma ve Bağlanabilirlik · Tüm alanlar · Veritabanları ve Önbellekleme →

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

Amazon'a göz atın →