Edge protection

Exam tasks: 3.1 (edge security strategy, edge protection with CloudFront headers, WAF, IoT policies, OWASP Top 10, S3 CORS and Shield Advanced, rules for geography, rate limiting and client fingerprinting, OCSF and third-party WAF integrations)

The decision: which layer of the attack are you stopping (flood, abusive client, malicious payload, direct origin access), and which edge service stops it before it costs you capacity?

Matching the threat to the edge controlCopy Anchor Link

AWS WAF building blocksCopy Anchor Link

The new console calls a web ACL a protection pack (web ACL). The API still uses WebACL.

• Where it attaches: CloudFront, Application Load Balancer, API Gateway REST APIs, AppSync, Cognito user pools, App Runner, Amplify and Verified Access. Not NLB, and not EC2 directly.
• Scope: CloudFront protection packs are global and must be created in us-east-1. Every other resource uses a regional protection pack in its own Region.
• Rules are evaluated by priority. The first terminating action (Allow, Block, CAPTCHA or Challenge after failure) stops evaluation. Count records a match, adds labels and moves on.
• Default action (Allow or Block) applies when nothing matches. Allow-by-default with block rules is normal for public sites. Block-by-default suits an API used only by known partners.
• Labels let one rule tag a request and a later rule act on the tag. Managed rule groups emit labels you can match, which is how you override one noisy rule without dropping the group.
• Capacity: each rule costs WCUs. A protection pack has 1,500 WCUs included, and you can pay for more up to 5,000.
• Body inspection looks only at the first part of the body: 16 KB by default for CloudFront, API Gateway, Cognito, App Runner and Verified Access (raise to 64 KB for a fee), and a fixed 8 KB for ALB and AppSync. Set the oversize handling to Match or Block for APIs that must not accept uninspected payloads.

Rule statements worth knowingCopy Anchor Link

Rate-based rulesCopy Anchor Link

• Count requests per aggregation key over an evaluation window of 60, 120, 300 (default) or 600 seconds.
• Keys: source IP (default), IP from a header such as X-Forwarded-For, ASN, or custom keys combining headers, cookies, query arguments, URI path, HTTP method, labels, JA3 or JA4 fingerprint.
• Count all with a scope-down statement rate limits a whole class of traffic, for example all POST /login requests from one country.
• A scope-down statement narrows what gets counted. To throttle only one path or User-Agent, put the match in the scope-down, not in a separate rule.
• The action can be Block, Count, CAPTCHA or Challenge, never Allow. The limit is approximate, not exact.

Managed rule groupsCopy Anchor Link

• ATP and ACFP need you to tell WAF the login or registration path and where the username and password sit in the request. Add the application integration SDK (JavaScript or mobile) so clients get tokens, which makes Challenge and silent verification work.
• Deploy a new managed group in Count first, read the labels in the logs, then switch to its default actions. Override one rule to Count if it blocks good traffic.
• Pin a version of a managed group if you need change control. Otherwise AWS updates it automatically.

Shield Standard vs Shield AdvancedCopy Anchor Link

• Grant the SRT access with a role (AWSShieldDRTAccessPolicy) and, if they need your logs, access to the WAF log bucket.
• Protection groups treat several resources as one for detection, for example all ALBs behind one app.
• Resilience still comes from architecture: CloudFront and Route 53 absorb traffic at the edge, Auto Scaling absorbs what gets through, and a small attack surface means fewer targets.

CloudFront as a security layerCopy Anchor Link

Security headersCopy Anchor Link

• A response headers policy adds headers to every response without touching the origin: HSTS (Strict-Transport-Security), X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy, Content-Security-Policy, and CORS headers.
• Managed policies such as SecurityHeadersPolicy cover the common set. Create a custom policy for your own CSP.
• CloudFront Functions are the lightweight option for custom header logic. Use Lambda@Edge only when you need the network, the body or longer run time.

Keeping viewers off the originCopy Anchor Link

• Signed URLs (one object) and signed cookies (many objects) restrict who can fetch content. Use trusted key groups, not the root-user CloudFront key pair.
• Geographic restrictions on the distribution allow or block whole countries. Use WAF geo match instead when you need exceptions, labels or combination with other conditions.
• Set a modern TLS security policy for viewers, redirect HTTP to HTTPS, and use HTTPS to the origin.

S3 CORSCopy Anchor Link

• CORS tells a browser which other origins may read responses from your bucket with JavaScript. It isn't access control: curl and servers ignore it, and a CORS rule never grants S3 permissions.
• A CORS configuration lists rules with AllowedOrigins, AllowedMethods, AllowedHeaders, ExposeHeaders and MaxAgeSeconds. S3 answers the browser's OPTIONS preflight from the first matching rule.
• Troubleshooting: a browser error saying Access-Control-Allow-Origin is missing means no rule matched the origin, method or requested headers. Behind CloudFront, forward the Origin header (or use a CORS response headers policy), or cached responses will lack CORS headers.

Central management with Firewall ManagerCopy Anchor Link

• Needs AWS Organizations, a Firewall Manager administrator account (the management account or a delegated one) and AWS Config turned on in the member accounts and Regions.
• Policy types: WAF, Shield Advanced, security groups (common, content audit, usage audit), network ACLs, Network Firewall, Route 53 Resolver DNS Firewall, and third-party firewalls (Palo Alto Networks Cloud NGFW, Fortinet FortiGate CNF).
• A WAF policy puts a first and last rule group around each account's own rules. The security team owns the baseline, and application teams can still add rules in between.
• Auto remediation applies the policy to new resources that match tags or resource types as they appear.

Integrations: OCSF and third-party rulesCopy Anchor Link

• Amazon Security Lake normalizes logs into the Open Cybersecurity Schema Framework (OCSF) in Parquet. Native sources include CloudTrail, VPC Flow Logs, Route 53 resolver query logs, Security Hub findings, EKS audit logs and WAF logs.
• A third-party or custom source (an on-premises WAF, a CDN, a SaaS app) must deliver OCSF-formatted Parquet to its own S3 prefix, partitioned by Region, account and event day. Subscribers (a SIEM, Athena) then query everything in one schema. See Logging strategy.
• Third-party WAF rules come as AWS Marketplace managed rule groups: subscribe, then add them to a protection pack like any managed group.
• WAF logs go to CloudWatch Logs, S3 or Data Firehose, and the destination name must start with aws-waf-logs-. Redact fields such as the Authorization header in the logging configuration.

AWS IoT policiesCopy Anchor Link

• Devices authenticate to IoT Core with X.509 certificates (or custom authorizers). An IoT Core policy attached to the certificate authorizes iot:Connect, iot:Publish, iot:Subscribe and iot:Receive.
• Use policy variables such as iot:Connection.Thing.ThingName in resource ARNs, so each device can only use its own client ID and topics. A wildcard iot:* on * lets one stolen certificate impersonate the fleet.
• Revoke or deactivate a compromised device certificate. AWS IoT Device Defender audits over-permissive policies and shared certificates.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• How AWS WAF works
• AWS Shield Advanced capabilities
• Restricting access to an Amazon S3 origin with OAC
• Using cross-origin resource sharing (CORS) in S3