Amazon SCS-C02: Edge & Application Security — Study Guide

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

CloudFront Geo Restriction and Country-Level Blocking

CloudFront offers two mechanisms to block traffic by country, and choosing between them matters for cost and functionality. The built-in geo restriction feature (also called geoblocking) is configured directly on the distribution and evaluates requests at the edge against a country allowlist or blocklist derived from the viewer’s IP. It is free, requires no rule evaluation, and returns HTTP 403 before any origin fetch occurs. For simple compliance scenarios — “block visitors from country X” — this is the cheapest and simplest option.

The alternative is a WAF geo match statement, which is more flexible: you can combine country matches with URI paths, headers, rate limits, or negate them (“allow country A only for /admin”). WAF is required when the logic is conditional; geo restriction alone cannot express “block country X only for a specific path.” Choose native geo restriction when the requirement is a flat country block and you want to avoid WAF’s per-request cost.

Signed URLs versus Signed Cookies for Private Content

CloudFront supports two ways to serve authorized private content while keeping the origin (S3 bucket, ALB, or Media origin) hidden behind an origin access control or custom header:

• Signed URLs: each URL carries a signature and policy. Ideal for a single-file download or when you need per-file access control (e.g., a one-off software installer link).

• Signed cookies: the client receives a CloudFront-Policy, CloudFront-Signature, and CloudFront-Key-Pair-Id cookie set once by your authentication service. All subsequent requests to matching path patterns are authorized automatically without rewriting URLs.

For HLS video streaming, where a single playback session fetches thousands of .ts segments referenced by a manifest, signed cookies are dramatically simpler. Rewriting every segment URL in the manifest with a distinct signed URL is possible but adds latency and complexity. Set the cookie after the subscriber authenticates against your internal user store, scoped to the streaming path pattern.

A canonical policy for a wildcard signed cookie looks like this:

{
  "Statement": [{
    "Resource": "https://d123.cloudfront.net/videos/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1735689600},
      "IpAddress":    {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

Pair this with an origin access control (OAC) or a secret custom header validated by WAF at the origin so users cannot bypass CloudFront and hit the origin directly.

AWS WAF: Managed Rules, ATP, and Rate-Based Rules

Attach the Web ACL to the CloudFront distribution rather than to a regional ALB when the workload sits behind CloudFront. Edge attachment terminates malicious requests at one of hundreds of POPs — closer to the attacker — which reduces origin load during DDoS and lowers egress from the origin because blocked traffic never traverses your VPC. Attaching WAF only to the ALB means the volumetric flood still reaches the Regional load balancer and consumes LCUs, and cross-Region attacks are handled by a single Region rather than the global edge network.

Key rule groups to combine:

• AWS managed rule sets: AWSManagedRulesCommonRuleSet (OWASP top-10-style), AWSManagedRulesKnownBadInputsRuleSet, and AWSManagedRulesAmazonIpReputationList give broad coverage with near-zero tuning.

• Account Takeover Prevention (ATP): AWSManagedRulesATPRuleSet inspects the login endpoint you designate, tracks credential stuffing patterns, checks submitted credentials against a compromised-credentials database, and blocks bots reusing leaked passwords. Configure it with the exact login path and JSON body field names for the username and password.

• Rate-based rules: limit the number of requests from any single IP over a 5-minute window (for example 2,000 requests). Scope them by URI or method so scraping of /search does not affect anonymous browsing of /. Rate rules mitigate Layer 7 volumetric attacks and brute-force enumeration.

A trimmed WAF rule block:

Rules:
  - Name: RateLimitLogin
    Priority: 1
    Action: { Block: {} }
    Statement:
      RateBasedStatement:
        Limit: 500
        AggregateKeyType: IP
        ScopeDownStatement:
          ByteMatchStatement:
            SearchString: /api/login
            FieldToMatch: { UriPath: {} }
            PositionalConstraint: STARTS_WITH
            TextTransformations: [{ Priority: 0, Type: LOWERCASE }]

ACM Certificates, DNS Validation, and CloudFront

For CloudFront, the certificate must be provisioned in ACM in us-east-1 (N. Virginia) regardless of where your origin lives — this is a hard requirement because CloudFront is a global service that reads certificates from that Region. Regional services like ALB read from the ALB’s own Region.

Always use DNS validation with a CNAME record in Route 53 for any public certificate you want to auto-renew. ACM auto-renews DNS-validated certificates as long as the validation CNAME remains published; Route 53 makes this trivial (the console offers “Create records in Route 53” during request). Email validation, by contrast, sends confirmation to five addresses at the domain (admin@, administrator@, hostmaster@, postmaster@, webmaster@) plus the WHOIS contact. These mailboxes are frequently non-existent or quarantined by corporate mail filters, so renewals fail 60 days before expiry and cause preventable outages. There is no way to automate email validation clicks.

The correct renewal pattern for multi-Region ALBs is: request a DNS-validated ACM certificate per Region, publish the validation CNAME in Route 53 once, attach the certificate to the ALB listener, and let ACM handle renewal and redeployment. Human involvement ends at issuance.

DNSSEC and Route 53

Enable DNSSEC signing on the Route 53 hosted zone to prevent DNS spoofing and cache poisoning against your domain. Route 53 manages the KSK in KMS (asymmetric ECC key in us-east-1); you must publish the DS record at the registrar. Note that DNSSEC signing protects the resolution of your zone — it does not encrypt DNS traffic (that is DoH/DoT) and does not affect CloudFront’s TLS.

Response Headers: Policies versus Lambda@Edge

CloudFront does not automatically inject security headers such as Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, or Content-Security-Policy. If your origin cannot be modified (a legacy S3 site, a third-party origin), you have two options:

• Response headers policy: a native, declarative CloudFront feature. Attach a managed or custom policy to a cache behavior to add HSTS, CORS, security, and custom headers. This should be the default choice — no code, no cold starts, no cost per invocation.

• Lambda@Edge (viewer response or origin response): use when you need dynamic logic, such as varying CSP nonces per request or rewriting headers based on request attributes. Trades simplicity for flexibility and adds per-request cost.

Managed response headers policy SecurityHeadersPolicy covers the common baseline in one attachment.

Common Pitfalls Explained

Requesting public ACM certificates with email validation is fragile precisely because renewal depends on humans reading mail sent to generic addresses that most organizations do not monitor or route to spam. DNS validation with Route 53 removes the human loop entirely.

Attaching WAF only to the ALB looks equivalent on paper but forces attack traffic into your Region and consumes ALB capacity. Edge-attached WAF on CloudFront blocks at hundreds of POPs, so a distributed flood is absorbed globally and origin egress stays low — critical during a DDoS.

Assuming CloudFront automatically adds security headers leads to failed penetration tests. The distribution proxies whatever headers the origin sends; you must explicitly attach a response headers policy or Lambda@Edge function to inject X-Frame-Options: DENY, HSTS, and CSP.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a globally distributed customer portal and an internal reports portal on AWS. Public traffic is routed through Amazon CloudFront to Application Load Balancers for dynamic APIs and to S3 origins for private reports; DNS is in Route 53 and TLS certificates are issued by AWS Certificate Manager (ACM).

Challenge: Attackers are scraping and credential-stuffing accounts from several countries, bypassing CloudFront by hitting origin endpoints directly to download private reports, and causing origin overload and data exposure.

Recommended Approach:

1. Configure CloudFront as the sole public entry point and apply CloudFront Geo Restriction to block offending countries; enable Origin Access Control (OAC) and lock S3/ALB origin policies so only CloudFront can fetch origin content.
2. Serve per-user private reports with CloudFront signed URLs (short TTL) rather than signed cookies so each download is individually authorized and auditable.
3. Attach AWS WAF to the CloudFront distribution using AWS Managed Rules, enable AWS WAF Bot Control (advanced threat protection) and create rate-based rules plus CAPTCHA challenges to mitigate scraping and credential stuffing.
4. Provision TLS certs in ACM (us-east-1 for CloudFront distributions) using DNS validation via Route 53, and publish Route 53 Alias records to the CloudFront distro.
5. Enable DNSSEC on the Route 53 hosted zone, enable CloudFront and WAF access logs to S3, and create CloudWatch alarms and optional AWS Shield Advanced for DDoS visibility and alerting.

Rationale: Forcing all traffic through CloudFront with OAC and WAF enforces least-privilege origin access, Geo Restriction and rate-based/WAF protections stop abusive traffic, signed URLs provide per-object authorization, and ACM+DNS validation with DNSSEC ensures trusted TLS and DNS integrity per AWS best practices.

AWS WAF Rules and Integration with ALB and CloudFront

AWS WAF is a Layer 7 firewall that evaluates HTTP(S) requests against a Web ACL composed of ordered rules. Each rule inspects request attributes (URI, headers, body, query string, source IP) and returns a terminating action (Allow, Block, Challenge, CAPTCHA) or a non-terminating action (Count). Web ACLs attach to CloudFront distributions, Application Load Balancers, API Gateway, AppSync, Cognito user pools, and App Runner services. When attached to CloudFront the ACL runs at the edge and must be created in the us-east-1 (Global) scope; for ALB it must be in the same Region as the load balancer.

Rate-based rules track the number of requests arriving from a single IP (or a forwarded-IP header, or an aggregate key such as a URI + IP combination) over a rolling five-minute window. When the count exceeds the configured threshold the rule action fires until the rate drops back below the limit. Because AWS WAF continuously updates the offender list in seconds, rate-based rules are the canonical answer for high-volume abuse from a small, rotating set of IPs — you do not have to hand-curate an IP set, and operational overhead is essentially zero after the initial rule is deployed.

{
  "Name": "RateLimitPerIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitPerIP"
  }
}

IP sets are reusable lists of CIDR ranges referenced by rules with an IPSetReferenceStatement. They are the right primitive when you have a deterministic block/allow list — for example, geographically restricted admin endpoints or known-bad ranges from threat intelligence feeds. Custom rules combine multiple statements with logical AndStatement, OrStatement, and NotStatement operators, letting you express conditions like “block requests to /login from countries other than the US that also lack a specific header.”

CloudFront as a DDoS Mitigation Layer and Origin Protection

CloudFront absorbs volumetric and state-exhaustion attacks at the AWS edge, well before traffic reaches your ALB or EC2 fleet. Every edge location runs AWS Shield Standard automatically, providing SYN flood and reflection attack mitigation at no charge. Putting CloudFront in front of an ALB shrinks the attack surface to the edge network and enables edge-scope WAF, geo-restriction, and TLS termination.

The mitigation is only effective if attackers cannot bypass CloudFront by hitting the ALB DNS name directly. Two mechanisms harden this path. First, configure CloudFront to inject a secret custom origin header (for example X-Origin-Verify: <random-value>) and configure an ALB listener rule that returns 403 for any request missing that exact header value. Rotate the secret periodically via AWS Secrets Manager. Second, restrict the ALB security group to the AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing, which contains the CloudFront edge IP ranges.

ALBListenerRule:
  Type: AWS::ElasticLoadBalancingV2::ListenerRule
  Properties:
    Actions:
      - Type: fixed-response
        FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
    Conditions:
      - Field: http-header
        HttpHeaderConfig:
          HttpHeaderName: X-Origin-Verify
          Values: ["!Ref OriginSecret"]
      - Field: http-header
        HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
    Priority: 1

Simply attaching a WAF ACL to the ALB without forcing traffic through CloudFront leaves the ALB endpoint publicly resolvable. Attackers who discover the DNS name (via certificate transparency logs, historical DNS, or subdomain enumeration) can attack it directly, bypassing all edge protections. This is the single most common architectural mistake in “CloudFront + ALB” designs.

Shield Advanced Metrics, Alarms, and Notifications

Shield Advanced adds enhanced detection, 24/7 access to the Shield Response Team, cost protection for scaling during attacks, and application-layer attack visibility. It does not, however, automatically send email or SMS when an attack occurs. Notifications must be wired up explicitly through CloudWatch.

Shield Advanced publishes the DDoSDetected metric (value 1 while an attack is in progress) and DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, and DDoSAttackRequestsPerSecond per protected resource in the AWS/DDoSProtection namespace. Create a CloudWatch alarm on DDoSDetected >= 1 with an SNS topic as the alarm action; SNS then fans out to email, SMS, chat, or a Lambda responder.

aws cloudwatch put-metric-alarm \
  --alarm-name ShieldDDoSDetected \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts

Assuming Shield Advanced will “just email you” is a frequent misconception — without the CloudWatch alarm plus SNS subscription, the only signal is the Shield console and the AWS Health Dashboard event.

AWS Network Firewall with Automated Lambda Blocking

Network Firewall is a stateful, VPC-attached Layer 3–7 firewall that inspects traffic traversing subnet route tables. Its policy consists of stateless and stateful rule groups; stateful rule groups use Suricata-compatible syntax. Because the rule groups are managed by API, they are ideal targets for event-driven automation.

A common pattern responds to GuardDuty findings (for example UnauthorizedAccess:EC2/RDPBruteForce or Backdoor:EC2/C&CActivity). Security Hub aggregates the finding, EventBridge matches an event pattern and invokes a Lambda function, and the Lambda calls UpdateRuleGroup to insert a drop rule targeting the offending IP or the compromised instance’s ENI.

def handler(event, _):
    ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
    new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
    rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
    rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
    nfw.update_rule_group(
        RuleGroupArn=RG_ARN,
        UpdateToken=rg["UpdateToken"],
        RulesSource={"RulesString": rules})

Network Firewall is the correct choice when you need to block bidirectional traffic to/from an EC2 instance or CIDR at the VPC edge — WAF only inspects HTTP requests destined for supported Layer 7 endpoints, so it cannot stop outbound C2 traffic or non-HTTP protocols.

Logging, Monitoring, and Safe Rollout with Count

Enable WAF logging on every Web ACL and stream to CloudWatch Logs, S3, or Kinesis Data Firehose. Logs include the matched rule, action, request headers, and (with redaction rules) sanitized bodies. Sampled requests in the console give a quick view but only retain the last 3 hours and 100 samples per rule; full logs are necessary for audit and forensics.

The Count action is essential for safe rule rollout. Deploy new managed rule groups (for example AWSManagedRulesCommonRuleSet or the Bot Control group) with rule action overrides set to Count first. Watch the CountedRequests CloudWatch metric and log entries for false positives — legitimate traffic that would have been blocked. Only after tuning exclusions do you flip the actions to Block. Deploying managed rules straight to Block without a Count phase routinely causes outages when a rule such as SizeRestrictions_BODY blocks a legitimate large upload endpoint, or when CrossSiteScripting_BODY fires on a rich-text editor payload. The remediation is not to disable the whole group but to add a scope-down statement or a rule action override for the specific rule that misfires.

Pair WAF metrics (BlockedRequests, AllowedRequests, CountedRequests) with CloudWatch alarms so a sudden spike in blocks — or a sudden collapse in allowed traffic — pages the on-call engineer, closing the loop between edge protection and operational awareness.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a customer-facing web application in a multi-AZ VPC using Application Load Balancers (ALBs) fronting ECS services, and distributes static and dynamic content via CloudFront. The team uses AWS WAF but has had limited automation for network-layer threats and inconsistent logging across services.

Challenge: A recent volumetric and application-layer traffic spike targeted login endpoints and caused ALB CPU exhaustion while probing for credential stuffing; the security team needs rapid DDoS mitigation, consistent origin protection, automated blocking of malicious IPs, and safe rollouts of stricter rules.

Recommended Approach:

1. Enable CloudFront in front of the ALB for global edge mitigation, configure the ALB to accept traffic only from CloudFront by validating a custom origin header and restricting inbound access with a CloudFront-managed prefix list or known IP ranges.
2. Deploy AWS WAFv2 with managed AWS rule sets plus custom rate-based and bot-detection rules; attach the WAF to both the CloudFront distribution and the ALB. Initially set new custom rules to COUNT mode to collect telemetry.
3. Enroll the account in AWS Shield Advanced and associate the CloudFront distribution and ALB; create CloudWatch metric alarms using Shield/DDoS metrics and forward alarms to an SNS topic for on-call notifications and runbook triggers.
4. Centralize logs: stream CloudFront, ALB, WAF, and AWS Network Firewall logs into Kinesis Data Firehose → S3 and enable CloudWatch metrics/dashboards to monitor rule match counts from COUNT mode.
5. Deploy AWS Network Firewall in the VPC with stateful rule groups and enable its logging; create CloudWatch metric filters for suspicious patterns and a Lambda that is triggered by alarms to automatically update the Network Firewall rule group to add offending IPs to a deny list.
6. After observing traffic in COUNT mode and dashboards for an agreed observation window, flip high-confidence WAF rules to BLOCK and keep automated Network Firewall updates with safe rollbacks and versioning of rule groups.

Rationale: Using CloudFront as the edge layer with WAF and Shield Advanced provides layered DDoS protection, while centralized logging, COUNT-mode rule validation, and automated Lambda-driven Network Firewall updates offer safe, observable, and automated network defense consistent with AWS best practices.

← Networking · All domains · Governance →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →