Edge security: CloudFront, WAF and Shield

Edge security strategy

Domain 3 starts at the edge: the first AWS component a request touches. Skill 3.1.1 asks you to choose an edge strategy from the threats you expect. The pattern behind almost every right answer is the same: stop attacks as far from your servers as possible, then make sure nobody can go around the edge to reach the origin directly.

$ aws ec2 describe-managed-prefix-lists \
    --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing \
    --query "PrefixLists[0].PrefixListId" --output text
pl-3b927c52

$ aws ec2 authorize-security-group-ingress --group-id sg-0alb \
    --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-3b927c52}]'

CloudFront security controls

CloudFront has its own security features before WAF even runs: locking the S3 origin with origin access control, letting only paying or signed-in users fetch files with signed URLs and cookies, blocking countries with geographic restrictions, and adding browser protections with security headers.

Signed URLs, geo restriction and security headers

Signed URLs and signed cookies are signed with a private key whose public key is in a trusted key group on the distribution (root-user CloudFront key pairs are legacy). Geographic restrictions allow or block whole countries for the whole distribution and return 403. A response headers policy adds security headers such as Strict-Transport-Security, Content-Security-Policy, X-Frame-Options and X-Content-Type-Options, which help against clickjacking, MIME sniffing and some XSS. Field-level encryption can encrypt chosen form fields at the edge with your public key so only one back-end service can read them.

$ aws cloudfront sign \
    --url https://d111111abcdef8.cloudfront.net/reports/q3.pdf \
    --key-pair-id K2JCJMDEHXQW5F \
    --private-key file://private_key.pem \
    --date-less-than 2026-10-10T12:00:00Z
https://d111111abcdef8.cloudfront.net/reports/q3.pdf?Expires=1791633600&Signature=...&Key-Pair-Id=K2JCJMDEHXQW5F

AWS WAF and OWASP Top 10 protection

AWS WAF inspects HTTP(S) requests and decides to allow, block, count or challenge them. It attaches to CloudFront, ALB, API Gateway REST APIs, AppSync, Cognito user pools, App Runner and Verified Access. For skill 3.1.2 you need to know how a web ACL (now also called a protection pack) evaluates rules and which managed rule groups cover the OWASP Top 10.

{ "Name": "AWS-CRS", "Priority": 2,
  "Statement": { "ManagedRuleGroupStatement": {
      "VendorName": "AWS", "Name": "AWSManagedRulesCommonRuleSet",
      "RuleActionOverrides": [] } },
  "OverrideAction": { "Count": {} },
  "VisibilityConfig": { "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true, "MetricName": "crs" } }

Geography, rate limiting and fingerprinting

Skill 3.1.3 lists the edge controls by name: geography, geolocation, rate limiting and client fingerprinting. All four live in AWS WAF (with CloudFront geo restriction as the simple country option). They are the go-to answer for brute force, scraping and bots that rotate IP addresses.

Geo match, fingerprints and challenges

A geo match statement matches the client country (from the source IP, or a forwarded IP header) and adds labels with the country and, where known, the region (for example awswaf:clientip:geo:region:US-WA), so you can block by country or by state, or only for some paths. JA3 and JA4 fingerprints are hashes of the TLS Client Hello; the same bot software produces the same fingerprint even as its IPs change. Find a client’s fingerprint in the WAF logs. CAPTCHA asks a person to solve a puzzle; Challenge runs a silent browser check. Both issue a token so a good client isn’t asked again until it expires.

{ "Name": "login-rate-ja4", "Priority": 1, "Action": { "Block": {} },
  "Statement": { "RateBasedStatement": {
    "Limit": 100, "EvaluationWindowSec": 300, "AggregateKeyType": "CUSTOM_KEYS",
    "CustomKeys": [ { "JA4Fingerprint": { "FallbackBehavior": "MATCH" } } ],
    "ScopeDownStatement": { "ByteMatchStatement": {
      "SearchString": "/login", "FieldToMatch": { "UriPath": {} },
      "TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
      "PositionalConstraint": "STARTS_WITH" } } } },
  "VisibilityConfig": { "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true, "MetricName": "loginja4" } }

AWS Shield and Firewall Manager

DDoS attacks try to exhaust capacity rather than steal data. Shield Standard protects every account for free at layers 3 and 4. Shield Advanced adds layer 7 automation, a response team, cost protection and visibility, and Firewall Manager rolls these protections out across an organization.

AWS Firewall Manager

Firewall Manager centrally applies security policies across accounts in AWS Organizations: WAF web ACLs, Shield Advanced protections, security group policies (common groups, audits of overly open rules), Network Firewall, Route 53 Resolver DNS Firewall, network ACLs and third-party firewalls. It needs a delegated administrator account and AWS Config enabled in member accounts, and it automatically protects new accounts and resources that match the policy scope (for example by tag or resource type).

$ aws shield create-protection --name web-cf \
    --resource-arn arn:aws:cloudfront::111122223333:distribution/E2EXAMPLE

# Layer 7: add the Anti-DDoS managed rule group as the first rule of the web ACL
{ "Name": "anti-ddos", "Priority": 0, "OverrideAction": { "None": {} },
  "Statement": { "ManagedRuleGroupStatement": {
      "VendorName": "AWS", "Name": "AWSManagedRulesAntiDDoSRuleSet" } } }

$ aws shield associate-health-check --protection-id a1b2c3 \
    --health-check-arn arn:aws:route53:::healthcheck/abcd-1234

S3 CORS, IoT policies and edge integrations

Skills 3.1.2 and 3.1.4 also name some smaller edge topics: S3 CORS, AWS IoT policies, third-party WAF rules and ingesting edge logs in OCSF format. Each is one or two exam questions, usually about a misunderstanding.

IoT policies, third-party rules and OCSF

AWS IoT Core policies are attached to a device’s X.509 certificate (or Cognito identity) and allow actions such as iot:Connect, iot:Publish, iot:Subscribe and iot:Receive on specific client IDs and topics. Use policy variables like ${iot:Connection.Thing.ThingName} so each device can only use its own client ID and topics; a policy with iot:* on * lets one stolen device impersonate every other. Third-party WAF rules come as managed rule groups from AWS Marketplace sellers and are added to a web ACL like AWS rule groups. OCSF (Open Cybersecurity Schema Framework) is the common format used by Amazon Security Lake, which can collect AWS WAF logs natively and accepts custom sources (for example a third-party CDN or firewall) as OCSF records in Parquet, so you can query all edge logs together.

{ "Version": "2012-10-17", "Statement": [
  { "Effect": "Allow", "Action": "iot:Connect",
    "Resource": "arn:aws:iot:eu-west-1:111122223333:client/${iot:Connection.Thing.ThingName}" },
  { "Effect": "Allow", "Action": "iot:Publish",
    "Resource": "arn:aws:iot:eu-west-1:111122223333:topic/sensors/${iot:Connection.Thing.ThingName}/*" } ]}

Cheatsheet extras: DDoS attack types, the resiliency playbook and API Gateway throttling

Your cheat sheet spends a lot of space on DDoS (“worth quite a few points in the exam”) and on API Gateway throttling and caching. Sections 01–05 showed the AWS tools. This section fills the gaps: the attack types by name, the five-step resiliency playbook from the AWS DDoS whitepaper, how API Gateway protects itself with throttling, and perfect forward secrecy.

The DDoS resiliency playbook (from the whitepaper)

Perfect forward secrecy at the edge

Perfect forward secrecy (PFS) means each TLS session uses a fresh, temporary key. If someone steals the server’s private key later, recorded old sessions still can’t be decrypted. You get it by choosing a TLS security policy whose ciphers use ECDHE key exchange, on CloudFront (viewer and origin settings) and on ALB/NLB TLS listeners. Current predefined policies (for example ELBSecurityPolicy-TLS13-1-2-2021-06 and CloudFront TLSv1.2_2021) already prefer ECDHE. Older material says “pick the 2016-08 policy”; today pick a TLS 1.2/1.3 policy.

$ aws apigateway update-stage --rest-api-id a1b2c3 --stage-name prod --patch-operations \
  op=replace,path=/*/*/throttling/rateLimit,value=500 \
  op=replace,path=/*/*/throttling/burstLimit,value=1000 \
  op=replace,path=/cacheClusterEnabled,value=true \
  op=replace,path=/cacheClusterSize,value=0.5 \
  op=replace,path=/*/*/caching/ttlInSeconds,value=300 \
  op=replace,path=/*/*/caching/dataEncrypted,value=true

{ "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": { "StringNotEquals": { "aws:SourceVpce": "vpce-0abc1234" } } },
    { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*" } ] }

Lecture summary map

Day 1 on one screen.

1. Mind map

2. Match the requirement to the control

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 2.

Practice test questions (from your mock exams)

These 10 questions come from your own SCS-003 mock exams (the last 2 are new questions added in the October 2026 review for features AWS changed in 2025–2026), matched to today’s topics. Each one was checked against current AWS behaviour: where a mock answer used old features (OAI, Classic Load Balancer, Inspector Classic) the wording was updated, and the explanation says so. The source is shown at the end of each explanation, for example “(Mock 5 · Q12)”.

Hands-on lab (30 minutes, low cost)

1. Create a private S3 bucket with an index.html, then a CloudFront distribution with an OAC. Copy the bucket policy CloudFront suggests and check you can load the page via CloudFront but get 403 from the S3 URL.
2. Create a WAF web ACL (CloudFront scope, us-east-1) with the Core rule set in Count mode and a rate-based rule with limit 10 per 60 seconds. Attach it to the distribution.
3. Run a quick loop (for i in $(seq 30); do curl -s -o /dev/null -w "%{http_code} " https://DIST.cloudfront.net/; done) and watch the 403s start.
4. Send ?id=1%27%20OR%201=1 and find the Count match for the CRS or SQLi rule in sampled requests.
5. Turn on geo restriction to block your own country and see the 403, then remove it.
6. Clean up: detach and delete the web ACL (WAF charges per web ACL and rule per month), disable and delete the distribution, empty and delete the bucket. Don’t subscribe to Shield Advanced in a personal account: it has a one-year commitment.