AWS Edge Security with WAF Shield and CloudFront: Introduction
Why AWS Edge Security with WAF Shield and CloudFront Matters
In AWS Infrastructure Security: Why Architecture Comes First, we emphasize that security doesn’t start with IAM — it starts with architecture. It’s easy to treat AWS edge security with WAF Shield and CloudFront as an afterthought. Nothing can be further from the truth! In line with architecture, we should be reducing the attack surface early and stopping traffic even before it enters AWS regions. Therefore, we need to move beyond protecting only within the VPC and treat CloudFront as the first entry point. Always remember that most attacks originate from the public internet.
The Role of AWS Edge Services
AWS edge security enables teams to build a layered defence model, along with network security covered in Network Security by Design: Security Groups, NACLs, and VPC Architecture. The services include CloudFront, WAF, and Shield that comprise the edge layer and operate globally. The edge layer is placed before the origin infrastructure and blocks attacks from reaching in-VPC security.
What This Article Covers
This article covers how edge services provide both network-level (L3/L4) and application-layer defense (L7). For AWS Shield, it contrasts decisions around using Shield Standard vs Advanced. Whereas with WAF rule groups, it weighs when to use managed rule groups vs custom rule groups. It also shows how architecture uses edge services in conjunction with VPC controls to support layered defense.
What is AWS Edge Security with WAF, Shield, and CloudFront
Defining AWS Edge Security
The AWS edge layer is the first point of contact between users and AWS resources. It is therefore responsible for filtering traffic before reaching any region or VPC within AWS. These services are physically built on AWS global edge locations, where all external traffic must pass through before entering the AWS network. AWS edge security consists of services such as CloudFront and WAF, along with Shield, which filter, absorb, and inspect traffic early. Therefore, they provide early-stage attack-surface reduction and traffic control.
How the AWS Edge Layer Works
All internet traffic that enters the AWS network is first routed to the nearest CloudFront edge locations. CloudFront is responsible for TLS termination of all incoming traffic and normalization of HTTP requests, including their paths, headers, and query strings. AWS Shield works with CloudFront to provide DDoS protection by absorbing volumetric and network-layer attacks. AWS WAF also operates at CloudFront to inspect HTTP(S) requests and apply rules. This ensures that only validated traffic is forwarded to the origin infrastructure.
Why Edge Security Changes the Architecture
AWS edge security with WAF Shield and CloudFront enforces security before traffic reaches backend systems. Subsequently, it reduces the load on the compute, storage, and network resources. This defense layer rejects malicious or unnecessary traffic to reduce the attack surface within VPC and origin services. This enables the architecture to have layered defense across edge and in-VPC controls. This follows the architecture-first AWS security model, where reducing exposure at the perimeter is the primary control.
AWS Edge Security with WAF, Shield, and CloudFront: L3/L4 vs L7 Protection
What L3/L4 Protection Covers
AWS edge security with WAF Shield and CloudFront protects the network level that comprises IP-based traffic filtering and routing decisions. This involves TCP connection state tracking and UDP traffic filtering with port-level control. The edge, through Shield, protects against volumetric DDoS attacks by absorbing and filtering abnormal TCP and UDP traffic patterns. It acts as an absorption layer at the edge, where abnormal TCP and UDP traffic is effectively discarded before it reaches backend systems. However, it has no visibility into the HTTP payload or request content and operates only at early-stage traffic filtering prior to application processing.
What L7 Protection Covers
AWS edge security uses WAF to protect at the application layer by inspecting HTTP/HTTPS requests. This inspection includes analyzing headers, paths, query strings, and cookies for each HTTP/HTTPS request. It also uses sophisticated algorithms and machine learning to detect injection attacks such as SQL and XSS. From this inspection, it evaluates the intent and behavior patterns of these HTTP/HTTPS requests. Additionally, it applies rule-based filtering using managed and custom WAF rules to protect against application-layer abuse and exploits.
How AWS Combines L3/L4 and L7 at the Edge
AWS edge security with WAF Shield and CloudFront must protect at both the network layer (L3/L4) and the application layer (L7). At the network level, Shield mitigates against volumetric and network-layer attacks by detecting abnormal traffic patterns. Meanwhile, at the application layer, WAF inspects normalized HTTP(S) requests for any abnormalities. CloudFront, meanwhile, serves as the unified point of entry at the edge and normalizes all HTTP(S) requests. These three core services provide progressive filtering before any traffic reaches the origin infrastructure. Having separate services for the network and application layers enables the separation of concerns around their protection. It also establishes a layered defense across edge services for comprehensive coverage.
AWS Edge Security with WAF, Shield, and CloudFront: Shield Standard vs Advanced
What AWS Shield Standard Provides
AWS edge security with WAF Shield and CloudFront provides both Shield Standard and Advanced. Shield Standard is the default AWS service that always provides protection for all AWS customers. It provides automatic mitigation of common L3/L4 DDoS attacks that most IT systems are likely to experience. AWS provides it at no additional cost with no configuration required, and it integrates with CloudFront, Route53, and ALB. It provides protection for common volumetric and network-layer attacks that most systems are vulnerable to. However, its visibility is limited, as is control over mitigation actions.
What AWS Shield Advanced Adds
AWS Shield Advanced has enhanced detection and mitigation for large-scale DDoS attacks as they increase in sophistication and volume. It also provides advanced visibility over Standard with detailed metrics and attack diagnostics to allow greater control and tuning of mitigation responses. Additionally, it provides real-time alerting and reporting on attack activity to allow rapid response to attacks. Significantly, it also integrates with AWS WAF for coordinated protection of AWS resources and VPCs. Furthermore, it provides access to AWS DDoS Response Team (DRT) support when organizations are experiencing massive and sophisticated DDoS attacks. When teams implement Shield Advanced, they can obtain cost protection against scaling charges that occur during attacks.
When Shield Advanced Is Justified
AWS edge security with WAF Shield and CloudFront still entails grounded architectural decisions and tradeoffs, including cost. Applications that require Shield Advanced are typically those that are public-facing, high-value, and facing the internet, having strict uptime or SLA requirements. Also, applications that are candidates for Shield Advanced are those exposed to high traffic volumes or attack-prone endpoints. Additionally, when there is a need for detailed visibility into attack patterns and metrics, this justifies the cost for Shield Advanced. In many of these cases, there is a requirement for rapid incident response and DRT engagement. Also, this cost is justified when there is a risk of cost spikes resulting from auto-scaling during DDoS events. Finally, environments with regulatory, financial, or reputational impact should consider the added protection that Shield Advanced offers. However, there are still many cases where its cost is not warranted, and Shield Standard is sufficient.
AWS Edge Security with WAF, Shield, and CloudFront: WAF Rule Groups
Managed Rule Groups
AWS WAF evaluates HTTP(S) requests by applying a set of rules to determine if they are abnormal or not. Managed rule groups are prebuilt rules that are maintained by AWS or trusted vendors based on learned experience. Hence, they provide coverage for common threats such as SQL injection and Cross-site scripting (XSS). Their core advantage is that AWS security systems can quickly deploy them with minimal configuration. Furthermore, they enable automatic updates without manual rule maintenance, simplifying their management. They are generally suitable and comprehensive for providing baseline protection for most web applications. However, their customization is limited, and there is a risk of false positives, thereby restricting genuine requests.
Custom Rule Groups
When applying AWS Edge Security with WAF Shield and CloudFront, many applications exhibit specific behavior that requires tailored rules. These specific behaviors require matching on paths, headers, query strings, and IP conditions. A simple example is blocking /admin path access from non-corporate IP ranges. Additionally, more fine grain control over request evaluation logic is needed to evaluate very specific patterns not provided by managed rule sets. Custom rule sets also provide the ability to reduce false positives through tuning by using Count mode and adjusting rules accordingly and iteratively. However, custom rules are code and carry all the needed effort for software lifecycle management, including ongoing monitoring and rule maintenance. However, custom rules support business-specific logic and provide edge-case protection.
Trade-Offs and Real Usage
Architects need to make informed trade-offs between managed rule sets and custom rule sets depending on the applications that need protection. Managed rules provide quick deployment of baseline protection and low maintenance. However, when they are insufficient for application-specific behavior, it is necessary to refine them using custom rules. There is also the trade-off between false positives and missed threats, depending upon the sensitivity and criticality of applications. Therefore, a practical approach for architects is to begin with managed rules and then layer custom rules depending upon application requirements. This entails continuous monitoring and tuning based on observed traffic patterns. Therefore, architects can adopt a balanced approach combining coverage and precision.
CloudFront Security Policies
Enforcing Secure Communication
AWS Edge Security with WAF Shield and CloudFront should also deny malicious actors benefiting from communications with clients. This involves maintaining communication integrity and confidentiality while properly authenticating external parties. Integrity and confidentiality are maintained by enforcing encrypted data in transit between clients and the edge. CloudFront should redirect all HTTP requests to HTTPS at the edge and terminate TLS connections at CloudFront edge locations. Furthermore, CloudFront should enforce minimum TLS versions and secure cipher suites and use ACM certificates for trusted HTTPS delivery. Additionally, CloudFront should prevent protocol downgrade attacks in which attackers try to intercept messages and downgrade them to weaker protocols.
Security Headers and Access Controls
However, there are many other opportunities for attackers to intercept communications with clients. Attackers will try to change future requests from HTTPS to HTTP, so CloudFront should include the HTTP Strict Transport Security (HSTS) header on all HTTPS responses. Another technique attackers use is to clickjack users by embedding the site in an iframe, CloudFront should set X-Frame-Options to prevent these attempts. Attackers also try to get client browsers to load and execute malicious scripts. CloudFront prevents this by enforcing the Content Security Policy (CSP) with client browsers. Also, attackers may exploit when browsers guess file types, and the X-Content-Type-Options instructs browsers not to do this. Additionally, attackers can exploit browsers sharing URL information with other sites, where CloudFront uses Referrer-Policy to prevent this.
Attackers will also try to bypass CloudFront by using URLs of AWS resources. CloudFront should use OAC or OAI to restrict direct origin access, allowing only validated traffic to origin resources.
WAF + X-Forwarded-For Handling
Preserving Client Identity
One of the issues faced with AWS Edge Security using WAF Shield and CloudFront is that traffic loses client identity when it reaches the origin resources. Therefore, CloudFront forwards the original client IP address via the X-Forwarded-For header, which maintains client identity across the edge and origin layers. This prevents loss of client context behind edge infrastructure. This is needed for accurate request inspection and logging necessary for other security services such as CloudTrail. Additionally, it supports IP-based rules and rate limiting in WAF.
Using XFF in WAF Rules
Expanding upon the point of supporting WAF rules, WAF rules can extract the client IP from the X-Forwarded-For header. This allows WAF to apply IP-based allow and block rules to the request since it knows the originating client. There are also other cases where it is necessary to enable rate limiting to know client IP addresses. This also allows WAF to perform geo-based filtering using the location of the known client. Knowing the client also enables it to detect abusive patterns across distributed requests from the same client. Furthermore, it can validate trusted proxy sources to prevent header spoofing.
Protecting S3 Origins with WAF
Securing S3 Behind CloudFront
S3 is the most common AWS resource that external actors try to bypass CloudFront. However, AWS edge security with WAF Shield and CloudFront should make CloudFront the only entry point for clients accessing S3. Therefore, security architects should block direct public access to S3 buckets through the S3 Block Public Access settings. They should also couple this with applying WAF rules before any requests reach S3. Also, they must prevent bypassing edge security controls by enforcing origin access, setting up OAC or OAI access so that only CloudFront can access S3. This is reinforced by restricting bucket policies to CloudFront identities and avoiding exposing S3 URLs publicly.
Controlling Access to Origin
Elaborating on restricting origin access to CloudFront only, architects should enforce OAC or OAI for origins. This applies not only to S3 but also to other AWS resources, including ALBs and HTTP endpoints within AWS. As outlined above, architects should also limit S3 bucket policies to CloudFront identities. They should also apply such policies to other AWS resources that may be exposed. Additionally, they should remove public endpoints and direct access paths to prevent potential attacker access. To enforce OAC or OAI for origins, CloudFront adds the headers/tokens to the request. Correspondingly, the origin resource accepts the request if it can validate the CloudFront headers/tokens. Also, for non-S3 origins, it is necessary to apply network-level restrictions. Therefore, the architecture ensures that only validated edge traffic reaches the backend systems.
Edge vs In-VPC Controls
Edge Security Controls
AWS edge security with WAF Shield and CloudFront operates before traffic enters the AWS regions. Hence, it supports defense in depth at a different layer from In-VPC Controls. Security at the edge uses CloudFront as the global entry point that secures traffic with clients. The next layer is early traffic filtering using WAF and Shield, preventing malicious traffic from reaching AWS regions, thereby reducing the attack surface. AWS Shield mitigates DDoS attacks at the network layer (L3/L4), preventing such attacks from reaching AWS regions. Meanwhile, WAF mitigates attacks at the application layer by inspecting HTTP(S) requests to determine if they are malicious. Both WAF and Shield are supported by CloudFront that normalizes requests for consistent evaluation. While these controls may not block all attacks, as a minimum, they significantly reduce the load on AWS region controls.
In-VPC Security Controls
Security controls within VPCs enforce security within AWS regional boundaries, providing defense in depth from attacks. Significantly, they counteract any malicious traffic that was able to penetrate the edge, thereby protecting backend systems after edge validation. An important class of In-VPC security controls is security groups that provide security control at the instance-level. The other class is NACLs that filter subnet-level traffic in case malicious traffic was able to bypass security groups. Both these control types restrict access based on ports, protocols, and IP ranges, reducing the attack surface. Therefore, they purposely isolate workloads using subnet and routing design to establish strong boundaries around them. For a deeper comparison of how compute isolation and security responsibilities differ across AWS container and virtual machine platforms, see EC2 vs ECS vs EKS: Why AWS Compute Security Isn’t the Same.
Layered Security Architecture
AWS edge security with WAF Shield and CloudFront works with In-VPC security controls since no single security control will prevent all attacks. Therefore, architects should follow a layered defense strategy by applying multiple security controls across edge and VPC layers and removing single points of failure. Additionally, no single control is unnecessarily overloaded during an attack. Hence, first filter threats early at the edge to prevent backend exposure while enforcing internal boundaries within VPC environments. Combining network-level and application-layer protection at the edge further removes reliance on a single point of defence.
AWS Edge Security with WAF Shield and CloudFront: Conclusion
AWS Edge Security with WAF Shield and CloudFront prevents threats from reaching AWS regions and reduces their attack surfaces. CloudFront is the primary entry point that secures communications with clients while normalizing requests for consistent evaluation. Shield and WAF are combined to provide layered edge protection, with separate responsibilities at the network (L3/L4) and application layers, respectively. Architects can further enforce edge controls by preventing direct origin access to external clients. Another important function for CloudFront is adding headers to requests to preserve client identity for accurate inspection and evaluation.
Edge security reinforces defence against threats with in-VPC security controls through layered defense, so there is no single point of failure. By building this layer defense, security is built into the architecture and is not regarded as an afterthought.
AWS Edge Security with WAF Shield and CloudFront: Further Reading
AWS Documentation
Books and Advanced Learning
Affiliate Disclosure: As an Amazon Associate, I earn from qualifying purchases. This means that if you click on one of the Amazon links and make a purchase, I may receive a small commission at no additional cost to you. This helps support the site and allows me to continue creating valuable content.
