Amazon SAA-C03: Inhaltsbereitstellung, Edge & Leistungsoptimierung — Lernleitfaden

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

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Amazon CloudFront: Was es ist und warum es hilft

Amazon CloudFront ist ein global verteiltes Content Delivery Network, das auf über 600 Points of Presence aufbaut. Seine Aufgabe ist es, das TLS des Betrachters am nächstgelegenen Edge-Standort zu beenden und entweder sofort zwischengespeicherte Antworten auszuliefern oder Cache-Misses über das private Backbone von AWS als Proxy an den Origin weiterzuleiten. Der Performance-Vorteil ist zweifach: Cache-Hits reduzieren die Round-Trip-Time auf einstellige Millisekunden und entlasten den Origin vollständig, während Cache-Misses immer noch von der optimierten TLS/TCP-Terminierung am Edge, der Unterstützung von HTTP/2 und HTTP/3, der Wiederverwendung von Keep-Alive-Verbindungen zum Origin und dem Transit über das Backbone profitieren, der das störanfällige öffentliche Internet meidet.

Ein weit verbreitetes Missverständnis ist, dass CloudFront nur statische Assets beschleunigt. Einen ALB hinter CloudFront mit einer CachingDisabled-Policy zu platzieren, verbessert dennoch die Performance dynamischer APIs, da der Handshake des Betrachters am lokalen PoP abgeschlossen wird, anstatt das Internet bis zur Origin-Region zu durchqueren. Kombiniert man das mit einer gemischten Workload – zum Beispiel /static/* von S3 und /api/* von einem ALB ausgeliefert – kann eine einzige Distribution beides bewältigen:

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

Route 53 Alias-Records verweisen dann www.example.com auf d123.cloudfront.net der Distribution – Alias-Records sind kostenlos und werden direkt zu den Anycast-IPs von CloudFront aufgelöst.

Zertifikate müssen in us-east-1 liegen

Für jede CloudFront-Distribution, die über eine Custom Domain bereitgestellt wird, muss das clientseitige TLS-Zertifikat in AWS Certificate Manager in us-east-1 (N. Virginia) ausgestellt sein, unabhängig davon, wo sich der Origin-Bucket, der ALB oder die Benutzer befinden. CloudFront ist ein globaler Service, dessen Control Plane in us-east-1 verankert ist; die Edge-Standorte beziehen das Zertifikat aus dieser Region. Ein ACM-Zertifikat in eu-west-1 anzufordern, nur weil sich der S3-Bucket zufällig dort befindet, ist ein fehlerhaftes Muster – die Distribution wird es niemals sehen.

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

Wenn Sie TLS ein zweites Mal zwischen CloudFront und einem ALB-Origin terminieren, befindet sich dieses origin-seitige Zertifikat in der Region des ALB. Nur das clientseitige Zertifikat ist an us-east-1 gebunden. Dieselbe Regel gilt für Edge-optimierte Custom Domains von API Gateway (die intern eine von AWS verwaltete CloudFront-Distribution verwenden): Das Zertifikat muss sich in us-east-1 befinden. Regionale API-Gateway-Endpunkte hingegen verwenden ein Zertifikat aus der eigenen Region der API.

Origin Access Control für S3-Origins

Einen S3-Bucket hinter CloudFront zu platzieren, den Bucket aber öffentlich zu lassen, verfehlt den Zweck: Betrachter umgehen CloudFront, indem sie direkt auf den S3-REST-Endpunkt zugreifen. Dabei werden WAF, Geo-Restriktionen, Signed URLs und die Vorteile des Caching umgangen – und potenziell Daten offengelegt.

Die moderne Lösung ist Origin Access Control (OAC), welche die veraltete Origin Access Identity (OAI) ersetzt. OAC verwendet SigV4-Signierung, unterstützt SSE-KMS, funktioniert in jeder S3-Region (einschließlich derer, die nach 2022 eingeführt wurden) und unterstützt dynamische Anfragen. Block Public Access bleibt aktiviert, es sind keine ACLs erforderlich, und die Bucket Policy gewährt Lesezugriff nur für den CloudFront Service Principal, weiter eingeschränkt durch den spezifischen ARN der Distribution:

{
  "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 funktioniert zwar noch, sollte aber als veraltet betrachtet werden – wählen Sie für neue Projekte immer OAC.

Korrektheit des Caches

Die Effektivität des Caches hängt von den Cache-Control- und Expires-Headern ab, die der Origin zurückgibt, kombiniert mit den Min/Default/Max-TTLs der CloudFront-Cache-Policy. Unveränderliche Assets mit Fingerprinting sollten aggressiv gecacht werden; HTML-Grundgerüste, die auf sie verweisen, sollten kurzlebig sein, damit sich Deployments verbreiten; authentifizierte JSON-Daten sollten überhaupt nicht im gemeinsam genutzten CDN zwischengespeichert werden:

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

Zwei symmetrische Fallen sind weit verbreitet. Erstens: Wenn der Origin keine Cache-Header sendet, greift CloudFront auf die Standard-TTL der Distribution zurück und kann dynamische Antworten unbemerkt für Stunden cachen. Zweitens: Ein pauschales Cache-Control: no-cache auf Assets, die gecacht werden sollten, zwingt jede Anfrage zurück zum Origin und hebelt das CDN aus.

Die gefährlichste Falle ist das Caching personalisierter Antworten ohne die richtigen Header. Wenn /account/dashboard HTML zurückgibt, das spezifisch für Benutzer A ist, der Origin aber no-store weglässt und die Cache-Policy keinen Auth-Header oder Cookie in den Cache-Schlüssel aufnimmt, wird der Edge-Standort die Seite von Benutzer A problemlos an Benutzer B ausliefern. Kennzeichnen Sie solche Antworten entweder mit private, no-store oder nehmen Sie die Sitzungs-ID in den Cache-Schlüssel auf und akzeptieren Sie die geringere Trefferquote.

In einem Szenario zur Kostenoptimierung, in dem eine Auto-Scaling-Gruppe mit EC2 On-Demand-Instanzen statische Inhalte ausliefert, besteht die korrekte Neugestaltung darin, die Assets nach S3 zu verschieben, CloudFront mit OAC davor zu schalten und die ASG zu eliminieren oder zu verkleinern. Dies verlagert die Kosten von stundenbasierter Rechenleistung auf anfragebasierte Auslieferung, was für statische Workloads um Größenordnungen günstiger ist.

Signed URLs, Signed Cookies und Geo-Restriktion

CloudFront unterstützt Signed URLs (zeitlich begrenzter, optional IP-eingeschränkter Zugriff auf ein einzelnes Objekt – ein gekaufter Video-Download, ein einmaliger PDF-Link) und Signed Cookies (Zugriff auf viele Objekte, die einem Pfadmuster entsprechen – ein authentifizierter Abonnent, der einen Katalog durchsucht). Beide verwenden eine Trusted Key Group, deren öffentlicher Schlüssel in CloudFront hochgeladen wird; der private Schlüssel signiert eine Richtlinie, die das Ablaufdatum, den Quell-IP-Bereich oder das URL-Muster festlegt.

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

Dies unterscheidet sich von einer S3 Presigned URL, die CloudFront umgeht und direkten Zugriff auf den Bucket gewährt. Kombinieren Sie CloudFront Signed URLs mit OAC, und der Bucket bleibt durchgängig privat.

Geo-Restriktion erzwingt Positiv- oder Negativlisten auf Länderebene auf Distributionsebene, bevor Anfragen den Cache oder den Origin erreichen. Sie verwendet die von CloudFront gepflegte GeoIP-Datenbank und ist der kostengünstige Mechanismus zur Durchsetzung von Lizenz-Embargos, der nicht durch Cache-Umgehung ausgehebelt werden kann. Für feinere Logik (z. B. auf Bundesland-Ebene, Header-Kombinationen) sollte man auf eine CloudFront Function oder Lambda@Edge zurückgreifen; für eine vollständige Regel-Engine verwendet man WAF.

AWS Global Accelerator

Global Accelerator ist kein CDN und führt kein Caching durch. Er stellt zwei statische Anycast-IPv4-Adressen (oder BYOIP) bereit, die von AWS-Edge-Standorten weltweit angekündigt werden. TCP- oder UDP-Verbindungen von Clients treten am nächstgelegenen Edge-Standort in das AWS-Backbone ein und werden über das private Netzwerk von AWS zum fehlerfreiesten Endpunkt (ALB, NLB, EC2 oder Elastic IP) in einer oder mehreren Regionen geroutet. Diese sind in Endpunktgruppen mit Traffic Dials und Gewichtungen zusammengefasst.

Die statischen IPs bieten drei konkrete Vorteile: Clients und Firewall-Allowlists ändern sich nie, selbst wenn das Backend neu strukturiert wird; ein regionales Failover wird in Sekunden abgeschlossen, indem der Datenverkehr bei Änderungen des Health-Checks zwischen Endpunktgruppen verschoben wird, wodurch die DNS-TTL-Propagierung vollständig umgangen wird; und der TCP-Handshake wird am Edge-Standort terminiert, während die Langstreckenübertragung über das Backbone von AWS läuft.

Wählen Sie Global Accelerator, wenn:

• Das Protokoll nicht-HTTP ist: UDP für Gaming oder VoIP, MQTT, SIP, SFTP, benutzerdefiniertes TCP.
• Sie statische IPs für Allowlisting in Unternehmen oder für mobile Apps benötigen, die Adressen fest codieren.
• Sie ein regionales Failover im Sub-Minuten-Bereich für zustandsbehaftete Aktiv-Aktiv-Deployments benötigen.
• Die Workload dynamisch und nicht zwischenspeicherbar ist, sodass ein CDN wenig Mehrwert bietet.

Wählen Sie CloudFront, wenn:

• Inhalte zwischenspeicherbar sind (Bilder, Videosegmente, statisches HTML, API-Antworten mit TTLs).
• Sie Edge-Computing über Lambda@Edge oder CloudFront Functions nutzen möchten.
• Sie WAF, signierte URLs/Cookies oder Field-Level Encryption am Edge-Standort benötigen.

Zwei Fallen, die es zu vermeiden gilt. Die Wahl von CloudFront, um „unsere Gaming-Server weltweit schneller zu machen“, scheitert, da Gaming UDP verwendet und nicht zwischenspeicherbar ist – hier ist Global Accelerator erforderlich. Umgekehrt ist die Wahl von Global Accelerator für eine statische Website teuer (feste stündliche Gebühr plus Kosten pro GB) und verzichtet auf Caching – CloudFront würde den Origin-Egress drastisch reduzieren. Für eine global verteilte, aber in einer einzigen Region betriebene HTTP-API, bei der die Benutzer die Latenz tolerieren, kann einfaches latenzbasiertes Routing mit Route 53 ausreichend und günstiger als beide Alternativen sein.

Route 53-Routing-Richtlinien für globalen Datenverkehr

Route 53 wählt aus, zu welchem Endpunkt ein Client auflöst; CloudFront oder Global Accelerator kümmern sich dann um die Verbindung. Drei Richtlinien dominieren globale Architekturen.

Latenzbasiertes Routing misst die tatsächliche Netzwerklatenz vom Standort des Resolvers zu jeder Region und gibt die schnellste zurück. Verwenden Sie es für identische Stacks in mehreren Regionen, wenn Sie möchten, dass Benutzer zu der Region geleitet werden, die im Moment am schnellsten ist.

Geoproximity-Routing ist koordinatenbasiert statt latenzbasiert: Sie deklarieren den Standort (oder die AWS-Region) jedes Endpunkts, und Route 53 leitet Benutzer zum geografisch nächstgelegenen. Sein besonderes Merkmal ist ein Bias-Wert (−99 bis +99), der den effektiven Servicebereich erweitert oder verkleinert – nützlich, um den Datenverkehr während eines regionalen Starts schrittweise zu verlagern oder eine Region für Wartungsarbeiten zu leeren. Geoproximity erfordert Route 53 Traffic Flow (Traffic-Richtlinien) und wird typischerweise mit einem regionalen NLB oder ALB in jeder Region kombiniert.

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

Failover-Routing verwendet ein Primär/Sekundär-Paar, das an Health-Checks gebunden ist. Es handelt sich um ein Failover auf DNS-Ebene, das von TTL und Resolver-Caching abhängt und daher langsamer ist als das Data-Plane-Failover von Global Accelerator – wählen Sie Failover-Routing für einfache Aktiv-Passiv-Szenarien, bei denen eine Minute DNS-Propagierung tolerierbar ist, und Global Accelerator, wenn es um Sekunden geht.

Diese Richtlinien lassen sich kombinieren. Ein gängiges globales Muster: Latenz- oder Geoproximity-Records von Route 53 verweisen auf Global Accelerator (für TCP/UDP) oder CloudFront (für zwischenspeicherbares HTTPS), mit Health-Check-basierten Failover-Records darunter als Sicherheitsnetz. Die Schichtung ist beabsichtigt: Route 53 wählt die Region aus, Global Accelerator oder CloudFront wählen den Edge-Standort und den Pfad über das Backbone, und ein regionaler Load Balancer wählt das Ziel innerhalb der Region aus.

API Gateway-Endpunkttypen und benutzerdefinierte Domains

API Gateway bietet drei Endpunkttypen mit unterschiedlichen Topologien:

Edge-optimierte Endpunkte kapseln die API in einer von AWS verwalteten CloudFront-Distribution, die Sie nicht direkt konfigurieren können. Das ist praktisch für eine schnelle globale Reichweite, aber einschränkend, wenn Sie Ihre eigenen Cache-Verhaltensweisen, WAF-Regeln oder Origin-Request-Richtlinien wünschen. Das idiomatische Muster für maximale Kontrolle ist ein regionaler Endpunkt, dem eine vom Kunden verwaltete CloudFront-Distribution vorgeschaltet ist.

Die Platzierung von Zertifikaten folgt der Regel von CloudFront: Edge-optimierte benutzerdefinierte Domains erfordern ein ACM-Zertifikat in us-east-1; regionale Endpunkte erfordern das Zertifikat in derselben Region wie die API. HTTP-APIs erzwingen mindestens TLS 1.2; REST-APIs unterstützen Sicherheitsrichtlinien bis zu TLS 1.3.

ACM-Zertifikate: Ausgestellt, validiert, importiert

ACM stellt öffentliche TLS-Zertifikate kostenlos aus, erneuert sie automatisch und lässt sich direkt in CloudFront, API Gateway, ALB, NLB und andere AWS-Services integrieren. Die Validierung erfolgt entweder durch DNS-Validierung (ACM gibt Ihnen einen CNAME, den Sie in Route 53 oder einem beliebigen DNS-Anbieter platzieren; solange der Eintrag besteht, erneuert ACM das Zertifikat automatisch auf unbegrenzte Zeit) oder durch E-Mail-Validierung (manuelles Durchklicken bei jeder Erneuerung, fehleranfällig für die Automatisierung). Die DNS-Validierung ist der korrekte Standard für alle Produktionsumgebungen.

Von ACM ausgestellte Zertifikate können nicht exportiert und nicht außerhalb der integrierten AWS-Services verwendet werden. Wenn eine regulatorische oder geschäftliche Anforderung eine bestimmte Drittanbieter-CA vorschreibt – zum Beispiel eine REST-API, die mit einem bestimmten kommerziellen Aussteller verketten und TLS 1.3 erzwingen muss – können Sie kein von ACM ausgestelltes Zertifikat verwenden. Beziehen Sie das Zertifikat von der erforderlichen CA und importieren Sie es in ACM. Hängen Sie es dann an eine regionale API-Gateway-Custom-Domain mit einer TLS-1.3-Sicherheitsrichtlinie an.

Die Falle bei Importen ist zweifach: Importierte Zertifikate erneuern sich nicht automatisch (erneuter Import vor Ablauf ist erforderlich, sonst fällt der Endpunkt hart aus), und ACM validiert die Zertifikatskette beim Import nicht – ein fehlerhaftes Zwischenzertifikat (Intermediate) wird erst beim Handshake mit echten Clients bemerkt. Testen Sie die vollständige Kette vor der Einführung mit einem strikten Client.

S3 Transfer Acceleration vs. CloudFront

CloudFront optimiert Downloads; S3 Transfer Acceleration optimiert Uploads. Transfer Acceleration nutzt dasselbe CloudFront-Edge-Netzwerk in umgekehrter Richtung: PUTs gelangen am nächstgelegenen Edge-Standort ins Netz und werden über das AWS-Backbone zur Region des Ziel-Buckets transportiert. Die Stärke des Dienstes zeigt sich, wenn eine global verteilte Gruppe von Benutzern große Objekte in einen Bucket in einer einzigen Region hochlädt – zum Beispiel, wenn Außendiensttechniker weltweit mehrere Gigabyte große Zeichnungen nach us-east-1 hochladen.

Beide Funktionen können auf demselben Bucket koexistieren: Aktivieren Sie Transfer Acceleration und stellen Sie eine CloudFront-Distribution mit OAC für Downloads bereit. Bei kleinen Objekten oder Clients, die sich bereits in der Nähe der Bucket-Region befinden, verursacht Transfer Acceleration zusätzliche Kosten ohne Nutzen – verwenden Sie das S3 Transfer Acceleration Speed Comparison Tool, um Messungen durchzuführen, bevor Sie sich dafür entscheiden. Clients müssen den s3-accelerate-Endpunkt verwenden, damit die Beschleunigung wirksam wird.

AWS WAF für Schutz auf Layer 7

AWS WAF inspiziert HTTP(S)-Anfragen, bevor sie die geschützte Ressource erreichen. Es wird an CloudFront-Distributionen, ALBs, API-Gateway-Stages, AppSync-APIs, Cognito-Benutzerpools, App-Runner-Services und Verified-Access-Instanzen angehängt. Eine Web-ACL enthält Regeln, die auf URI, Header, Query-Strings, Body (standardmäßig bis zu 8 KB, erweiterbar auf 64 KB bei ALB/API Gateway), IP-Sets und Geolokalisierung passen.

Die gebräuchlichsten Bausteine sind die AWS Managed Rules: AWSManagedRulesCommonRuleSet und AWSManagedRulesKnownBadInputsRuleSet decken die wichtigsten OWASP-Exploits ab; AWSManagedRulesSQLiRuleSet und XSS-Match-Statements behandeln Injection-Angriffe. Benutzerdefinierte Regeln fügen Geo-Matching (Länder-Allowlists/Blocklists für Compliance), IP-Set-Matches und ratenbasierte Regeln hinzu. Letztere zählen die Anfragen pro Quell-IP über ein gleitendes Fünf-Minuten-Fenster und blockieren, sobald ein Schwellenwert überschritten wird. Ratenbasierte Regeln sind die erste Verteidigungslinie gegen HTTP-Floods und Credential Stuffing:

{
  "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": {}}
}

Die Region ist entscheidend. Web-ACLs für CloudFront sind global und müssen in us-east-1 erstellt werden. Web-ACLs für regionale Ressourcen (ALB, API Gateway usw.) werden in der Region der Ressource selbst erstellt.

Um eine statische Website auf S3 zu schützen, können Sie WAF nicht an den Bucket anhängen – S3 ist keine von WAF unterstützte Ressource. Das korrekte Muster ist CloudFront + OAC vor dem Bucket, wobei die Web-ACL an die Distribution angehängt wird. Dass der Bucket nur über CloudFront erreichbar ist, stellt sicher, dass der gesamte Verkehr inspiziert wird.

Firewall Manager für Multi-Account-WAF-Governance

Die Verwaltung von WAF pro einzelnem Konto skaliert nicht. In einer Organisation startet ein Team einen neuen ALB, ohne die unternehmensweiten Basiseinstellungen anzuhängen, und die Compliance-Haltung verschlechtert sich unbemerkt. AWS Firewall Manager löst dieses Problem mit organisationsweiten Richtlinien, die für alle relevanten Konten und Ressourcen durchgesetzt werden.

Voraussetzungen: AWS Organizations mit allen aktivierten Funktionen, ein designiertes Firewall-Manager-Administratorkonto und aktiviertes AWS Config in jedem Mitgliedskonto. Die Richtlinientypen umfassen AWS WAF, AWS Shield Advanced, Sicherheitsgruppen (Audit und Nutzung), Network Firewall, Route 53 Resolver DNS Firewall und Firewalls von Drittanbietern.

Eine WAF-Richtlinie kann eine „erste“ Regelgruppe (die vor anwendungseigenen Regeln ausgewertet wird), eine „letzte“ Regelgruppe (danach) erzwingen oder die Web-ACL vollständig ersetzen. Neue ALBs oder CloudFront-Distributionen, die dem Ressourcenbereich entsprechen, erhalten automatisch das unternehmensweite Regelwerk, und nicht konforme Ressourcen werden markiert und – abhängig von den Behebungseinstellungen – automatisch korrigiert. Immer wenn in einem Szenario von „mehreren Konten“, „zentraler Verwaltung“ oder „konsistenten WAF-Regeln in der gesamten Organisation“ die Rede ist, lautet die Antwort Firewall Manager und nicht WAF pro Konto.

Shield Standard vs. Shield Advanced

Anzunehmen, dass WAF allein DDoS-Angriffe stoppt, ist ein kritischer Fehler. WAF arbeitet mit den Anfragen, die es erreichen – es ist hervorragend gegen Application-Layer-Floods, Credential Stuffing und bekannte Exploit-Signaturen – aber große volumetrische Angriffe auf den Layern 3/4 (SYN-Floods, UDP-Reflection) werden von AWS Shield absorbiert.

Shield Standard ist standardmäßig und ohne zusätzliche Kosten aktiviert. Es wehrt gängige L3/L4-Angriffe automatisch ab und gilt für CloudFront, Route 53 und Global Accelerator, mit grundlegendem Schutz für ELB, EC2 und andere Ressourcen. Es bietet keine angriffsspezifische Transparenz, keine Einbindung des Shield Response Teams und keinen Kostenschutz.

Shield Advanced (3.000 $/Monat pro Organisation, einjährige Verpflichtung) fügt hinzu:

Die Annahme, dass Shield Standard für „großangelegte DDoS-Angriffe mit Kostenschutz und Expertenreaktion“ ausreicht, ist falsch, eben weil Standard keine Transparenz, keinen Kostenschutz und keinen SRT-Zugriff bietet. Wenn der Ursprung eine EC2-Instanz hinter einem ELB ist und das DNS bei einem Drittanbieter liegt (sodass Route 53 Alias-Tricks keine Option sind), ist das empfohlene Muster, Shield Advanced auf dem ELB zu aktivieren und die Anwendung mit CloudFront (ebenfalls durch Shield Advanced geschützt) zu versehen, um den Mitigation-Perimeter an den Edge zu verlagern und die Angriffsfläche, die die Region erreicht, zu verkleinern.

Die korrekte, mehrschichtige Sicherheitsarchitektur ist: Shield für L3/L4-Volumenangriffe, WAF für L7-Filterung, CloudFront oder Global Accelerator als Edge-Einstiegspunkt, an den beide Dienste angebunden sind, und Firewall Manager, um die Richtlinie über alle Konten hinweg durchzusetzen.

← Netzwerk · Alle Domänen · Datenbanken →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →