DEV Community: Alexey Baltacov

Protect Your Web Site with AWS WAF and CloudFront

Alexey Baltacov — Sun, 22 Mar 2026 12:58:57 +0000

Protect Your On-Premises Website with AWS WAF and Amazon CloudFront

Protecting web applications—regardless of where they run—with a scalable, highly available, and cost-effective edge layer is a cornerstone of modern architecture. This article walks through a hands-on proof of concept (PoC) that leverages AWS WAF for security, CloudFront for global caching and performance, and a serverless pipeline for on-the-fly HTTP context modification.

You’ll learn how to:

Enhance availability and reduce origin load by caching static and dynamic content at the edge.
Secure traffic with AWS WAF rules before it ever reaches CloudFront.
Offload requests from the origin to minimize connectivity and costs.
Modify any part of the HTTP request or response—including headers, query strings, and body—using a Lambda-powered proxy.

Sensitive data and IP addresses in screenshots have been blurred.

1. Introduction

Disclaimer: I understand this guide—demonstrating how to proxy and modify HTTP content—might resemble instructions used by phishing site creators. That was never my intention; these techniques are meant solely for legitimate security, performance, and reliability purposes.

Traditional WAF appliances and CDNs can be expensive, rigid, and complex to manage—particularly when you need to retrofit existing on-premises applications. By combining AWS WAF and Amazon CloudFront, you get:

Edge Security: AWS WAF blocks malicious requests at AWS’s global PoPs, shielding your origin.
Global Caching: CloudFront serves cached content from locations closest to your users, reducing latency and origin hits.
Origin Offload: Less network traffic and compute on your servers, lowering TCO.
On-the-Fly HTTP Manipulation: Inject, strip, or rewrite headers and body content without touching origin code.

We’ll demonstrate these capabilities using a simple IP-lookup service (noc.co.il) to keep the PoC lean and focused on edge mechanics.

2. Evaluating Origin Compatibility

For this PoC, we chose a simple IP-lookup service (noc.co.il) to isolate edge mechanics. Our goals were to verify that the origin would:

Respond over HTTPS without client interruptions.
Trust and reflect standard proxy headers (X-Forwarded-For).
Parse header values as plain text (no validation), allowing us to spoof or inject values.

2.1 Initial Compatibility Test

We first obtained the curl command via the browser’s Copy as cURL option:

curl 'https://noc.co.il/' \
  -H 'Accept: text/html' \
  --compressed

Running this returned the expected HTML shell of the IP lookup page:

$ curl -s -D - --compressed https://noc.co.il/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
...
<html>My IP: 203.0.113.10</html>

2.2 Testing `X-Forwarded-For`

Next, we injected a fake IP via the X-Forwarded-For header to see if the service honors it:

curl -s -D - \
  -H "X-Forwarded-For: 198.51.100.24" \
  --compressed \
  https://noc.co.il/

Findings:

The response body included both our real IP and 198.51.100.24, confirming the header was trusted.
No header validation errors occurred.

2.3 Spoofing Non-existent Addresses

To verify lack of validation, we added another bogus IP:

curl -s \
  -H "X-Forwarded-For: 198.51.100.24, 300.300.300.300" \
  https://noc.co.il/ | tee response.html

Inspecting response.html in a browser showed the exact header text echoed in the page—demonstrating the origin parses the header as raw text.

Sidebar: Because CloudFront automatically appends X-Forwarded-For, this origin behavior is crucial for forwarding the true client IP downstream.

3. Solution Architecture Overview

3.1 Original Architecture

In the initial approach, I fronted the origin directly with AWS WAF and CloudFront, without any additional proxy layer.

Clients -> AWS WAF -> CloudFront -> Original Site (noc.co.il)

AWS WAF: Enforces IP allow-lists and managed security rules at AWS edge locations before traffic reaches CloudFront.
CloudFront: Distributes and caches content globally, forwarding only necessary headers to the origin.
Original Site: The unmodified noc.co.il endpoint, responding directly to CloudFront requests.

3.2 Final Architecture (With API Gateway Proxy)

To overcome response-body limitations, I introduced an API Gateway/Lambda proxy between CloudFront and the origin. The Lambda function serves as a reverse proxy for dynamic HTML, while static assets like favicon.ico are served directly from S3 via a separate behavior.

AWS WAF: Applies IP filters and managed rules at the AWS edge.
CloudFront: Uses two cache behaviors:

/favicon.ico -> S3 origin for static assets with optimized TTLs.
/* -> API Gateway for dynamic HTML via the reverse-proxy Lambda.
1. API Gateway (REST API Reverse Proxy Mode): Receives viewer requests for dynamic content and invokes the Lambda reverse-proxy function.
2. Lambda Function (Reverse Proxy):
Fetch: Makes an HTTP request to https://noc.co.il including path and query parameters.
Modify: Reads and parses the HTML response body.
Return: Sends the modified HTML back through API Gateway and CloudFront while preserving the original status code and headers.
1. S3 Origin: Serves the custom favicon.ico directly from edge caches, bypassing API Gateway.

4. Detailed Implementation

4.1 Certificate Management

Generate a Let’s Encrypt certificate for your custom domain (noc.ittools.net).

Import it into ACM in us-east-1 for CloudFront.

4.2 AWS WAF Setup

IP Sets: Define trusted IPv4/IPv6 addresses such as office and datacenter ranges.

Web ACL: Allow traffic from the IP sets and set the default action to Block.

Rate-based rules (optional): Throttle anomalous request spikes.

4.3 CloudFront Distribution

Configure the CloudFront distribution with the cache behavior and origin request policy that match your proxy design.

Attach your AWS WAF Web ACL to this distribution.
Enable response headers policies to add HSTS, CSP, and custom headers at the edge.

4.4 Reducing Origin Connectivity

Caching at CloudFront dramatically cuts down on requests to your origin:

Static assets (images, CSS, JS) are served from edge caches for configurable TTLs.
Dynamic content hits origin only on cache misses—adjustable via cache keys (headers, cookies, query strings).

This offload not only improves performance but reduces bandwidth and compute costs on your servers.

4.5 Full HTTP Context Access and Modification

Neither CloudFront Functions nor Lambda@Edge allow modifying response bodies. Additionally, since both CloudFront and API Gateway automatically append their own X-Forwarded-For entries, we need a reverse proxy to:

Fetch the original HTML from https://noc.co.il while preserving query strings and path.
Inject a custom <link rel="icon" href="/favicon.ico" /> into the <head>.
Strip the two trailing IP addresses added by CloudFront and API Gateway from any comma-separated IP lists embedded in the HTML body.
Return the modified HTML through API Gateway and CloudFront while preserving the origin’s headers and status codes.

To achieve this, configure API Gateway in REST API reverse-proxy mode and invoke a Lambda function like this:

import os
import http.client
import re
from urllib.parse import urlencode

# Configuration
REMOVE_IP_COUNT = int(os.environ.get("REMOVE_IP_COUNT", "2"))
FAVICON_URL = os.environ.get("FAVICON_URL", "/favicon.ico")
ORIGIN_HOST = os.environ.get("ORIGIN_HOST", "noc.co.il")
ORIGIN_PATH = os.environ.get("ORIGIN_PATH", "")


def lambda_handler(event, context):
    # 1) Parse client request info
    method = event.get("httpMethod", "GET")
    client_path = event.get("path", "/")
    qs_params = event.get("queryStringParameters") or {}
    query_str = f"?{urlencode(qs_params)}" if qs_params else ""

    # 2) Build the upstream path
    origin_path = (ORIGIN_PATH.rstrip("/") + client_path) or "/"
    origin_path += query_str

    # 3) Copy headers except Host
    headers = {
        k: v
        for k, v in (event.get("headers") or {}).items()
        if k.lower() != "host"
    }

    # 4) Fetch from the real origin
    conn = http.client.HTTPSConnection(ORIGIN_HOST, 443, timeout=30)
    conn.request(method, origin_path, headers=headers)
    resp = conn.getresponse()
    body_bytes = resp.read()
    conn.close()

    # 5) Decode HTML
    body = body_bytes.decode("utf-8", errors="replace")

    # 6) Inject favicon link right after <head>
    body = re.sub(
        r"(<head\b[^>]*>)",
        rf"\1<link rel=\"icon\" href=\"{FAVICON_URL}\" type=\"image/png\">",
        body,
        count=1,
        flags=re.IGNORECASE,
    )

    # 7) Remove the last N IPv4s from every comma-separated list
    def strip_trailing_ips(match):
        seq = match.group(0)
        parts = re.split(r"\s*,\s*", seq)
        if len(parts) > REMOVE_IP_COUNT:
            parts = parts[:-REMOVE_IP_COUNT]
        return ", ".join(parts)

    body = re.sub(
        r"\b(?:\d{1,3}\.){3}\d{1,3}(?:\s*,\s*(?:\d{1,3}\.){3}\d{1,3})+",
        strip_trailing_ips,
        body,
    )

    # 8) Build the API Gateway Lambda-proxy response
    out_bytes = body.encode("utf-8")
    return {
        "statusCode": resp.status,
        "headers": {
            "Content-Type": resp.getheader("Content-Type", "text/html"),
            "Content-Length": str(len(out_bytes)),
        },
        "body": body,
        "isBase64Encoded": False,
    }

This pattern gives you full control over outgoing responses without touching the origin code.

5. Final Results

Below is a comparison of the original IP lookup page and the modified version, showing the injected favicon and response changes.

Original Site

Modified Site

6. High Availability, Security, and CDN Benefits

DDoS Mitigation: AWS WAF integrates with AWS Shield at no extra cost for CloudFront distributions.
Global Failover: Edge caches can continue serving content even if the origin is briefly unreachable.
Cost Efficiency: Pay only for WAF rule evaluations, Lambda invocations, and data transfer—no upfront hardware.

6.1 Amazon CloudFront as a CDN

Amazon CloudFront is AWS’s global content delivery network, designed to accelerate both static and dynamic content by caching it at edge locations worldwide. Key benefits include:

Reduced latency: Delivers content from the closest edge location to end users.
Customizable cache behaviors: Control TTLs, forwarded headers, query strings, and cookies per path pattern.
Dynamic content support: Forward dynamic requests to any HTTP origin and selectively cache or bypass content.
Security integrations: AWS WAF, TLS termination at the edge, and Origin Access Control for private S3 buckets.
Invalidation and versioning: Invalidate cache on demand or use versioned URLs for instant updates.
Pay-as-you-go pricing: Based on data transfer, request counts, and invalidation usage.

6.2 Origin Failover with Multiple Origins

To maximize availability, CloudFront supports Origin Groups—a primary/secondary origin configuration that automatically fails over if the primary origin becomes unhealthy.

Primary origin: Your default origin, such as API Gateway or a custom origin.
Secondary origin: A fallback endpoint, such as another region, an on-premises endpoint, or a static S3 bucket.
Health checks: CloudFront monitors the primary origin using configurable HTTP(S) health checks.
Failover logic: On health-check failure, requests are routed to the secondary origin with minimal latency impact.

Configuration steps:

In the CloudFront distribution, create two origins.
Define an origin group linking both origins and specify health-check parameters.
Update cache behaviors to use the origin group as the target.

This failover capability ensures that even if your primary backend experiences downtime, CloudFront can seamlessly serve content from an alternate source.

7. Conclusion

By fronting any website—on-premises or in the cloud—with AWS WAF and CloudFront, you achieve:

Enhanced availability through aggressive edge caching and failover.
Robust security with customizable WAF rules at every PoP.
Minimal origin load via cache offload and selective forwarding.
Complete HTTP context manipulation using CloudFront Functions, Lambda@Edge, or, in very specific cases, API Gateway and Lambda for dynamic transformations.

Note: Normally the API Gateway + Lambda part is not required, since many HTML body changes can be made on the origin web server directly and these workarounds are unnecessary.

This architecture transforms legacy and modern applications alike into resilient, secure, and performant cloud-edge services.

Appendix A: Edge Compute Options — CloudFront Functions vs Lambda@Edge

AWS CloudFront provides two serverless compute options at the edge—CloudFront Functions and Lambda@Edge—each tailored to different use cases.

Parallels to F5 iRules:

F5 iRules allow TCP, UDP, and HTTP inspection and manipulation on traditional load balancers.
CloudFront Functions provide similar lightweight header- and URL-based logic at the edge, executing JavaScript within milliseconds.
Lambda@Edge extends these capabilities with richer runtimes and more advanced traffic steering and content transformation.
Both CloudFront serverless options and F5 iRules enable granular control over HTTP flows, but CloudFront offloads compute to a global CDN with pay-as-you-go billing.

Limitations:

CloudFront Functions cannot perform network calls or access request bodies.
Lambda@Edge offers more runtime and compute but incurs higher latency and cost for short-lived tasks.

This appendix clarifies compute options independently of the PoC’s specific Lambda reverse-proxy implementation.

Appendix B: Pricing Notes

The original LinkedIn article includes AWS WAF and CloudFront pricing examples. Before publishing on DEV, verify current pricing in the official AWS pricing pages because service prices can change over time. The original article listed example monthly Web ACL, rule, request, data transfer, request, invalidation, and certificate price points. (linkedin.com)

References

AWS WAF Rate Limiting Based on Origin Response

Alexey Baltacov — Sun, 22 Mar 2026 11:24:42 +0000

Introduction

You have a public website fronted by Amazon CloudFront that serves static files from S3. Customers access these files via direct URLs and must be able to download any file at any time without interference. At the same time, you want to stop malicious actors from crawling your entire bucket.

The Challenge

Goal: Prevent automated scanning of all URLs while still allowing legitimate customers unlimited downloads of the specific files they need.
Constraint: No user login or authentication. Files are freely downloadable, so you cannot simply gate them behind a sign-in flow.

Why Plain AWS WAF Rate Limiting Is Not Enough

AWS WAF lets you define rate-limit rules keyed by source IP or by fingerprinting mechanisms such as JA3 and JA4. In theory, you could set:

A low limit such as 10 requests per minute, which blocks scanners effectively but risks blocking legitimate high-throughput customers.
A high limit, which lets scanners creep through, especially if attackers distribute requests across IPs or devices.

The result is an uncomfortable trade-off: too low hurts real users, too high fails to stop attackers.

AWS WAF's View of Origin Responses and ATP Rules

By default, custom AWS WAF rules only inspect request attributes. They do not know whether your origin returned 200 OK or 404 Not Found.

The only built-in AWS WAF rules that inspect responses are the Account Takeover Prevention (ATP) managed rules. Those require you to map login fields and are designed for authentication endpoints, not static file downloads.

Why Lambda@Edge Alone Cannot Solve It

Lambda@Edge runs per request and has no built-in shared global state. It cannot maintain counters across all executions, so by itself it cannot enforce a global request threshold.

A Hybrid Approach: WAF + Lambda@Edge

You can combine WAF's global counting capabilities with Lambda@Edge's ability to modify HTTP responses.

1) Primary WAF Rate-Limit Rule (Soft Threshold)

Type: Rate-based statement, for example 10 requests per 5 minutes
Action: Count (not Block)
Custom response header: Insert X-RateLimit-Exceeded: true

AWS WAF prefixes custom header names with x-amzn-waf-. So if you specify X-RateLimit-Exceeded, downstream components will see:

x-amzn-waf-x-ratelimit-exceeded

2) Secondary WAF Rate-Limit Rule (Hard Threshold)

Type: Rate-based statement with a much higher threshold, for example 1,000 requests per 5 minutes
Action: Block

This immediately stops heavy-volume attacks at the WAF layer, prevents excessive Lambda@Edge invocations, and reduces cost.

3) Lambda@Edge Function (Origin Response Trigger)

Trigger: CloudFront Origin Response event

exports.handler = async (event) => {
  const response = event.Records[0].cf.response;
  const headers = response.headers;

  // AWS WAF prefixes headers with x-amzn-waf-
  const flag = headers['x-amzn-waf-x-ratelimit-exceeded'];

  if (flag && flag[0].value === 'true' && response.status !== '200') {
    return {
      status: '429',
      statusDescription: 'Too Many Requests',
      headers: {
        'content-type': [{ key: 'Content-Type', value: 'text/html' }]
      },
      body: '<html><body><h1>Rate Limit Reached</h1><p>Please try again later.</p></body></html>'
    };
  }

  return response;
};

Associate and Deploy

Attach your Web ACL, containing both rate-limit rules and any ATP group you choose to use, to the CloudFront distribution.
Deploy the Lambda@Edge function through the CloudFront console or the AWS CLI.

Testing

Legitimate Access

Repeatedly fetch an existing file. The soft-limit counter will increment, but users will still receive the file until the hard threshold is crossed.

Scanning Attempts

Request many non-existent URLs. Errors quickly hit the soft threshold, causing your custom 429 response page. Extreme traffic volumes hit the hard threshold and are blocked at WAF before Lambda@Edge runs.

Demo video

Benefits of This Pattern

Precision: Rate limits are tied to actual Not Found or error responses.
User Experience: Legitimate customers getting 200 OK responses are not blocked unless they truly exceed your thresholds.
Cost Efficiency: High-volume attacks are stopped before Lambda@Edge runs.
AWS-native design: Uses AWS WAF, CloudFront, and Lambda@Edge without adding external state stores or proxy layers.

References

Originally published on LinkedIn on May 8, 2025.

Making Amazon Bedrock AgentCore Gateway Accessible (Only Through CloudFront)

Alexey Baltacov — Mon, 16 Feb 2026 19:21:51 +0000

tags: aws, architecture, genai, security, AWScommunity, AWScommunityBuilders

Amazon Bedrock AgentCore Gateway makes it straightforward to expose GenAI-powered APIs.

AWS provides an official pattern for attaching a custom domain using CloudFront:

Client -> CloudFront -> AgentCore Gateway

Official documentation:
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-custom-domains.html

For many use cases, this approach is sufficient.

But what if the requirement is stronger?

This endpoint must only be reachable through a specific CloudFront distribution.

That is where architectural boundaries matter.

The Hidden Exposure Problem

Even when:

CloudFront is placed in front
AWS WAF is attached
A custom domain is configured

The underlying AgentCore Gateway service endpoint remains publicly accessible.

CloudFront functions as a reverse proxy, not a strict isolation boundary.

AgentCore supports resource-based policies:

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/resource-based-policies.html

These policies primarily control who can invoke the gateway (IAM principals, AWS accounts, and supported condition keys).

This model works well for internal service-to-service communication.

However, for public-facing APIs:

External consumers do not authenticate using IAM.
Authentication typically relies on OAuth, JWT, API keys, or custom headers.
The endpoint must remain internet-reachable for legitimate users.

As a result, even if legitimate traffic flows through CloudFront, the underlying Gateway endpoint may still be reachable directly from the internet unless additional controls are introduced.

IAM-based restrictions do not remove that exposure because the service endpoint itself remains public.

For environments with strict ingress isolation requirements, this becomes a critical gap.

Compare This to S3 + CloudFront (OAI / OAC)

Amazon S3 provides a native enforcement primitive:

Only CloudFront can access this bucket.

With CloudFront Origin Access Identity (OAI) or Origin Access Control (OAC), an S3 bucket can be made private and restricted to a specific CloudFront distribution.

Example S3 bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccessOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123ABC456XYZ"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-private-bucket/*"
    }
  ]
}

In this model:

The bucket is not public.
Direct internet access fails.
Only the CloudFront identity is permitted.

AgentCore does not currently provide an equivalent isolation construct.

An additional boundary must therefore be introduced.

Architecture for Enforcing CloudFront-Only Access

To enforce CloudFront-only reachability, the following architecture can be implemented:

Example:

Public entry point: ext-clients-api-57x9abc.mycompany.com
Required Host header downstream: gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

Enforcing CloudFront-Only at the Network Layer

The Application Load Balancer (ALB) is publicly addressable, but it does not need to be publicly reachable.

Inbound traffic can be restricted using AWS Managed Prefix Lists for CloudFront:

https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html

AWS maintains a managed prefix list containing CloudFront origin-facing IP ranges.

Attach this managed prefix list to the ALB security group and allow inbound HTTPS only from:

com.amazonaws.global.cloudfront.origin-facing

This ensures:

Only CloudFront edge locations can establish TCP connections to the ALB.
Direct internet traffic to the ALB is blocked at the security group level.
IP spoofing cannot bypass the restriction.

Without CloudFront, the ALB is not reachable.

This creates a true network enforcement boundary.

Where AWS WAF and DDoS Protection Fit

This design enables layered protection.

CloudFront (Edge Layer)

CloudFront is automatically protected by AWS Shield Standard, which provides DDoS mitigation at the edge.

AWS WAF at CloudFront can provide:

Rate-based rules (anti-abuse and scraping protection)
IP reputation filtering
Geo restrictions
AWS Managed Rule Groups
AWS Bot Control
Account Takeover Prevention (ATP)
Authentication field inspection
Header validation
Payload size limits

Malicious traffic can be filtered before reaching the infrastructure.

ALB (Ingress Layer)

AWS WAF can also be attached to the ALB to enforce:

Verification of a secret header injected by CloudFront
Strict Host header validation
Additional managed rule groups
Authentication flow inspection

Even if the ALB DNS name is discovered:

Direct connection attempts fail due to managed prefix list restrictions.
Spoofed requests fail due to header validation and WAF rules.

This results in three enforcement layers:

Edge (Shield + WAF)
Network (managed prefix list restriction)
Application (ALB WAF + listener rules)

The Technical Challenge: TLS vs Host Header

When placing an ALB in front of AgentCore:

The ALB must terminate TLS using a certificate for a custom domain, for example:
ext-clients-api-57x9abc.mycompany.com
Downstream routing may require a different HTTP Host header, for example:
gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

These belong to different protocol layers:

TLS SNI hostname controls certificate validation.
HTTP Host header controls routing logic.

AgentCore does not support accepting arbitrary custom domains inbound.

This mismatch must be resolved before traffic reaches AgentCore.

The Solution: CloudFront Origin Modification

CloudFront Functions allow modification of:

domainName (origin connection hostname for TLS/SNI)
hostHeader (HTTP Host header sent to the origin)

Example:

import cf from 'cloudfront';

const ORIGIN_DOMAIN_NAME = 'ext-clients-api-57x9abc.mycompany.com';
const OVERRIDE_HOST_HEADER = 'gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com';

function handler(event) {
  const request = event.request;

  cf.updateRequestOrigin({
    domainName: ORIGIN_DOMAIN_NAME,
    hostHeader: OVERRIDE_HOST_HEADER
  });

  return request;
}

This allows:

TLS validation against the ALB certificate.
ALB routing based on the required Host header.
External clients to interact only with the custom domain.
AgentCore to remain accessible only through the controlled CloudFront -> ALB -> PrivateLink path.

Final Outcome

This architecture provides:

Custom domain support
Edge-level DDoS protection (Shield Standard)
Advanced WAF protections (rate limiting, ATP, bot control, managed rules)
Network-level CloudFront-only enforcement
Ingress validation at ALB
Private connectivity via VPC endpoint
Strong ingress isolation for GenAI workloads

The default AWS pattern is well suited for standard deployments.

When strict CloudFront-only reachability is required, an architectural boundary is necessary.

CloudFront + managed prefix lists + ALB + PrivateLink + layered WAF provides that boundary.

AWS WAF Intro Guide

Alexey Baltacov — Thu, 06 Feb 2025 23:00:31 +0000

With this guide you will not become an AWS WAF expert, but will get a bit of taste about its capabilities.

1. Introduction and Overview of AWS WAF

AWS Web Application Firewall (WAF) is a managed security service designed to help protect your web applications or APIs from common web exploits and bots. AWS WAF lets you create rules to monitor (count), block, or allow traffic based on criteria such as:

IP addresses
HTTP headers
URI paths
Request size
SQL injection attempts
Cross-Site Scripting (XSS) patterns
Request rate (rate-based rules)

Additionally, when you use AWS WAF, you automatically get the protections of AWS Shield Standard at no additional cost. AWS Shield Standard is a built-in DDoS protection service for AWS resources (including CloudFront and Route 53) that mitigates common network and transport layer attacks. Together, AWS WAF and AWS Shield Standard provide a layered defense approach: WAF focuses on Layer 7 (application layer) threats, while Shield Standard covers volumetric and SYN flood-type attacks (Layers 3 and 4).

1.1 Resources Protected by AWS WAF

You can attach AWS WAF to the following AWS resources:

Amazon CloudFront (for global distribution and caching)
Amazon API Gateway (REST APIs)
Application Load Balancer (ALB)
AWS AppSync (GraphQL APIs)
Amazon Cognito user pools
AWS App Runner service
AWS Verified Access instance

Additionally, when you use CloudFront with AWS WAF, you can protect any external or internal origin behind CloudFront, including on-premises servers or third-party cloud environments. CloudFront acts as a secure reverse proxy, letting you apply WAF inspection rules to all inbound requests before they reach your origin, regardless of whether that origin is hosted inside or outside of AWS.

Attaching WAF to these resources allows you to inspect and filter incoming requests based on rules you define (custom rules) or rules you enable from AWS Managed Rule Sets, all while benefiting from the baseline DDoS protections of AWS Shield Standard.

2. Applying AWS WAF: CloudFront vs. Other Resources

2.1 AWS WAF with CloudFront

When integrated with CloudFront, AWS WAF inspects and can block traffic at the edge, before it reaches your origin. Key advantages include:

Global Edge Presence: Requests are processed at CloudFront edge locations.
CDN and Caching: CloudFront’s CDN reduces latency and offloads your origin by caching content.
Secure Reverse Proxy: By placing CloudFront in front of your application (whether it’s hosted within AWS, on-premises, or another cloud), you effectively use it as a secure reverse proxy that can filter traffic globally.
AWS Shield Standard: Automatically protects CloudFront distributions (and other supported AWS resources) against most common DDoS attacks at no extra cost.
If your application needs more nuanced logic than WAF alone can provide, you can extend functionality using:
CloudFront Functions: Lightweight JavaScript functions for short-running tasks (up to 1ms) like inspecting headers or rewriting URIs.
Lambda@Edge: A more robust solution if you need to read or modify request/response bodies, implement complex authentication flows, or handle sophisticated transformations.

_Important: If AWS WAF blocks a request at the edge, CloudFront Functions and Lambda@Edge will not trigger for that request.
_

2.2 AWS WAF with Regional Services

AWS WAF can also operate at a regional level by attaching to:

Application Load Balancer (ALB)
Amazon API Gateway (REST APIs)
AWS AppSync (GraphQL APIs)
Amazon Cognito user pools
AWS App Runner service
AWS Verified Access instance

This approach is suitable for applications or microservices that do not require global edge distribution or caching. Key differences from the CloudFront approach include:

1. Latency and Caching

CloudFront + WAF: Security measures at the edge, lower latency, potential cost savings from caching.
Regional Services + WAF: Traffic is inspected regionally without inherent CDN caching.

2. Scope and Customization

CloudFront can use CloudFront Functions or Lambda@Edge for advanced transformations.
Regional Services can still use custom or managed WAF rules, but do not benefit from global caching.

3. Protecting External Origins

CloudFront + WAF can protect non-AWS origins by pointing the distribution to external servers.
Regional services typically secure traffic within AWS unless you design a specific pattern.

3. AWS Managed Rules

AWS Managed Rules are pre-configured, continuously updated rule sets provided by AWS to protect against a wide range of threats. By enabling these managed rules in your AWS WAF, you can quickly cover many common web attacks without having to define every pattern or behavior manually.

3.1 Coverage for OWASP Top 10

Many AWS Managed Rules are designed to help address OWASP Top 10 vulnerabilities, such as:

Injection (SQLi, NoSQL, Command Injection)

The AWSManagedRulesSQLiRuleSet identifies and blocks SQL injection attempts.
Common malicious payloads and known injection vectors are covered.

Broken Authentication and Session Management

Combined with Account Takeover Prevention (ATP), WAF can detect brute force or credential stuffing attempts on login endpoints.

Sensitive Data Exposure

Managed Rules can flag suspicious payloads or unusual request patterns that might indicate data exfiltration (in conjunction with rate-based rules and SSL/TLS).

XML External Entities (XXE)

Certain AWS Managed Rule Groups include checks for XML-based threats and malicious entity references.

Broken Access Control

While some aspects of access control are application-specific, AWS Managed Rules can detect attempts to bypass security controls using known exploit patterns, suspicious HTTP methods, or path tampering.

Security Misconfiguration

Common Rule Sets automatically update to address vulnerabilities in common frameworks and platforms, reducing the risk of misconfiguration exposure.

Cross-Site Scripting (XSS)

AWSManagedRulesCommonRuleSet includes signatures for detecting malicious scripts and XSS payloads.

Insecure Deserialization

Some advanced Managed Rule Groups check for known malicious serialization formats and exploit payloads.

Using Components with Known Vulnerabilities

AWS regularly updates the Managed Rule Sets to address newly disclosed CVEs, helping you keep pace with emerging threats.

Insufficient Logging and Monitoring

Although logging itself is not a “rule,” AWS WAF integrates with S3, CloudWatch, and Kinesis Firehose for monitoring. Suspicious requests are clearly tagged and logged, aiding your threat detection strategy.

3.2 Examples of AWS Managed Rule Sets

AWSManagedRulesCommonRuleSet: Covers a broad range of general vulnerabilities, including XSS, HTTP request smuggling, and some injection signatures.
AWSManagedRulesSQLiRuleSet: Specifically targets SQL injection patterns.
AWSManagedRulesAmazonIpReputationList: Blocks or labels requests from known malicious IP addresses or botnets.
AWSManagedRulesLinuxRuleSet (or similar specialized sets): Target vulnerabilities specific to Linux-based systems.

3.3 Complementing Managed Rules with Custom Logic

While AWS Managed Rules provide excellent baseline coverage, you should monitor traffic in “Count” mode initially to identify potential false positives and tune your rules. You can then add:

Custom rules for application-specific logic (e.g., blocking certain user agents or disallowed query parameters).
Rate-based rules to mitigate brute force or scraping attempts.
Account Takeover Prevention (ATP) for deeper login endpoint protection.

This layered approach (managed rules plus custom refinements) helps ensure robust, OWASP-aligned protection without sacrificing application availability.

4. AWS WAF Fraud Control – Account Takeover Prevention (ATP)

4.1 Overview of ATP

Account Takeover Prevention (ATP) is part of AWS WAF Fraud Control, designed to detect and mitigate unauthorized login attempts:

Analyzes Login Attempts: Monitors login traffic to identify suspicious behavior (credential stuffing, brute force).
Risk-Based Scoring: ATP assigns risk scores to login attempts based on factors like repeated login failures or IP reputation.
Integration with WAF: You can create WAF rules to allow, count, block, or require CAPTCHA on requests flagged by ATP.

By spotting anomalies in login patterns, ATP helps prevent account takeover incidents before they escalate.

4.2 Benefits of Using Email Addresses as Usernames with ATP

When combining ATP with email-based usernames (your application should use usernames in email format), you gain several security and operational advantages:

Easier Parsing and Validation: An email format (username@domain.com) is consistent, enabling simpler checks for malicious or disposable domains.
Domain Intelligence: ATP or custom WAF rules can label or block logins from suspicious or disposable email domains.
Reduced Guesswork: Attackers must guess valid email addresses, which can be less trivial than typical username formats like admin or test.
Improved Logging: Email addresses provide a clearly identifiable username in the logs for investigating suspicious activity.
Easier MFA and Recovery: Users often prefer logging in with an email address, simplifying password resets and integrating MFA flows.
Leverage Compromised Credentials Databases:

AWS obtains threat intelligence including email/password pairs from public data breaches to help detect credential stuffing or attempts using known compromised credentials.
Because users commonly reuse email addresses across different services, ATP can cross-reference these compromised credential sets more effectively when your primary username field is an email.
This synergy helps AWS WAF quickly flag suspicious login attempts, especially when an attacker attempts known leaked email/password pairs from security breaches.

5. Best Practices and Well-Architected Approach for Building Your Rule Base

5.1 Start with Managed Rules, Then Layer Custom Rules

Baseline Protections (Managed Rules): Quickly address common threats (SQLi, XSS, bad bots) by enabling relevant AWS Managed Rule Sets.
Custom Rules: Tailor rules to your application’s business logic (e.g., block suspicious headers, limit request sizes, or restrict certain paths).
Rate-Based Rules: Mitigate DDoS or brute-force attacks by capping requests from a single IP address over a specified period.
JS Challenge and Captcha: Implement JS challenge and captcha in your application in order to reduce DDoS by automated browsers, CLI and other tools.

5.2 “Count” Mode + Labels, Then Block

A major best practice is to start all rules in “Count” mode and add labels:

Configure each rule to Count rather than block initially.
Assign a label to requests that match the rule (e.g., SuspiciousSQLi, XSSAttempt).
Observe logs to verify these matches are legitimate threats or anomalies.
Implement a final, catch-all blocking rule that blocks requests carrying labels deemed malicious.

This approach helps reduce false positives while ensuring you have visibility into what would be blocked before actively cutting off traffic as well as centralized control over custom block page headers and responses

5.3 Extend with CloudFront Functions or Lambda@Edge

In cases where AWS WAF rules do not cover a specific use case or you need more dynamic logic, consider:

CloudFront Functions: Lightweight JavaScript for short-running tasks (up to 1 ms) like inspecting headers, rewriting URIs, or adding custom headers.
Lambda@Edge: A more robust solution for reading/modifying request or response bodies, implementing complex authentication flows, or dynamic transformations.

Note: If WAF blocks a request, CloudFront Functions or Lambda@Edge will not run for that request.

5.4 Align with AWS Well-Architected Security Pillar

Design your WAF rule base according to AWS’s Well-Architected Security Pillar:

Identification: Label and log events to understand potential threats.
Proactive Protection: Use a combination of managed and custom rules.
Least Privilege: Only allow known safe patterns or domains.
Automation: Deploy and manage WAF using Infrastructure as Code (CloudFormation, Terraform) for consistency and repeatability.

6. Rule Groups and Rule Labels

6.1 Rule Groups

A Rule Group is a container for one or more WAF rules:

AWS Managed Rule Groups: Quick to enable, provide coverage for broad classes of attacks.
Custom Rule Groups: Let you organize your own rules by function (e.g., IP restrictions, user-agent blocks, country blocks).

6.2 Rule Labels

When a request matches a rule, WAF can attach labels for tracking or later decision-making. For example:

SQLiDetected
BadBotTraffic
DisallowedCountry

You can create a final rule that blocks requests carrying specific labels. Labels also appear in WAF logs, helping you analyze and correlate different rule matches.

7. Custom Responses in WAF Rule Actions

AWS WAF supports custom responses for Block actions. Instead of returning a generic 403 Forbidden, you can define:

Custom HTTP Status Code (e.g., 403, 404, 502, etc.)
Custom Headers (e.g., to convey an error reason to the client)
Custom HTML or text Body for the response This feature is useful when you want to provide a branded or instructive error page, or add extra troubleshooting information for the user. Since the request is already blocked, no further edge functions (CloudFront Functions or Lambda@Edge) will execute for that request.

Example: You might choose to return a 403 status with a short HTML body:

{ "Name": "MyWebACL", "Scope": "CLOUDFRONT", "DefaultAction": { "Allow": {} }, "Rules": [ { "Name": "BlockWithCustomResponse", "Priority": 1, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "x-bad-header" } }, "PositionalConstraint": "EXACTLY", "SearchString": "bad-value", "TextTransformations": [{ "Priority": 0, "Type": "NONE" }] } }, "Action": { "Block": { "CustomResponse": { "ResponseCode": 403, "CustomResponseBodyKey": "CustomHTMLResponse", "ResponseHeaders": [ { "Name": "X-Custom-Error", "Value": "BlockedByWAF" } ] } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockWithCustomResponseRule" } } ], "CustomResponseBodies": { "CustomHTMLResponse": { "ContentType": "TEXT_HTML", "Content": "<html><body><h1>Access Denied</h1><p>Your request has been blocked.</p></body></html>" } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "MyACLMetric" } }

In this example, any request including a header x-bad-header: bad-value is blocked, returning a 403 code with a custom HTML body.

8. Limitations

While AWS WAF is powerful and flexible, you should be aware of some important constraints and limitations:

Rule Capacity (WCU – WAF Capacity Units)

Each rule (or statement within a rule) consumes a certain number of WCUs based on its complexity. For example, ByteMatchStatement or IP match conditions generally have lower WCU usage, while Regex match statements and complex logical operators can use more.
There is a maximum WCU limit for each Web ACL. If your rules exceed that limit, you cannot add them all to the same Web ACL. You may need to simplify your rules or optimize your rule groups.
Monitor your rule WCU usage (in the AWS console or via the CLI) to ensure you stay within allowed capacity.

Regex Complexity

Very complex regex patterns can quickly use up available WCUs. Simplify your patterns or break them into multiple statements where possible.

Logging Latency

WAF logs are almost real time when using Cloudwatch and typically appear with a short delay in S3 or Kinesis

Regional vs. Global

WAF on CloudFront is global; on ALB, API Gateway, etc., it’s regional.

Cost

Each rule, managed rule group, and request passing through WAF contributes to your monthly bill. Monitor usage carefully.

Inspection Header Size

WAF regional inspects up to a certain size for request headers/body (e.g., first 16 KB).
WAF Global (Cloudfront) supports up to 64 KB headers/body inspection

Requests exceeding this limit may not be fully inspected.

Blocking Halts Edge Functions

If a request is blocked by WAF, CloudFront Functions or Lambda@Edge will not run for that request.

9. Practical Information about Working with Labels

Defining Labels: Specify labels in your WAF rule actions (console or CLI).
Combining Labels: Multiple rules can label the same request.
Match on Labels: A final rule can check if a request has any suspicious labels and block it.
Debugging: Inspect WAF logs to see which labels are assigned and confirm the accuracy of your rules.

10. Protecting Resources Outside AWS Using CloudFront

One advantage of CloudFront + WAF is the ability to protect external (non-AWS) origins:

Create a CloudFront distribution that points to your on-premises or third-party cloud origin.
Attach a WAF Web ACL to that distribution.
Enable caching for static or cacheable content to reduce load on the external origin.

Secure Reverse Proxy: CloudFront, acting as a secure reverse proxy, inspects all traffic with WAF at the edge before forwarding it to your external servers.
This setup provides global edge security and performance benefits even if your origin is not hosted on AWS.

11. AWS Managed Protections for OWASP Top 10

The OWASP Top 10 is a standard awareness document outlining the most critical web application security risks. AWS WAF addresses several OWASP Top 10 vulnerabilities via AWS Managed Rules and additional features:

Injection

(SQLi, NoSQL, Command Injection)

AWSManagedRulesSQLiRuleSet helps block SQL injection attempts.
Custom rules can detect command injection patterns.
Broken Authentication and Session Management

ATP helps mitigate brute force or credential stuffing.
Rate-based rules can address repeated login attempts.
Sensitive Data Exposure

WAF can block suspicious payloads that may indicate data exfiltration.
Combine with SSL/TLS for encrypted data in transit.

XML External Entities (XXE)

Custom or third-party rules detect malicious XML patterns.

Broken Access Control

WAF custom rules can enforce strict path or header-based controls.
Labels help track role-based or token-based access attempts.

Security Misconfiguration

AWS Managed Rule Sets automatically update to address new vulnerabilities.
Custom rules detect unusual HTTP methods or suspicious headers.

Cross-Site Scripting (XSS)

AWSManagedRulesCommonRuleSet includes patterns for typical XSS vectors.

Insecure Deserialization

Advanced rule sets can detect malicious serialization formats.
Using Components with Known Vulnerabilities
Regular updates to AWS Managed Rules help protect against newly disclosed CVEs.

Insufficient Logging and Monitoring

WAF logging (to S3, CloudWatch, or Kinesis) provides robust, centralized monitoring.
Combine with Athena or OpenSearch for advanced log analysis.

12. Pricing Model

12.1 AWS WAF Pricing

AWS WAF pricing typically includes four main components:

Web ACLs

You pay a monthly charge for each web ACL that you create (e.g., around USD $5 per month per web ACL, depending on the region).
Rules
Each rule (custom or managed) in your web ACL adds a small monthly cost - often USD $1 per rule per month.

Rule Groups

Enabling an AWS Managed Rule Group or a third-party rule group from AWS Marketplace can incur a monthly subscription (for the group itself), plus the cost for each rule inside the group if applicable.

Request Volume

You pay for each million web requests inspected by AWS WAF. The typical rate is around USD $0.60–$1.00 per million requests (exact cost varies by region).

Important:

Prices vary by AWS Region.
Third-party managed rule groups may have higher subscription costs than AWS-managed rule sets.
Overuse of large or complex rules can drive up monthly costs. Monitor usage carefully.

12.2 CloudFront Pricing

Amazon CloudFront has its own separate billing model. Main cost factors include:

Data Transfer Out

You pay for data transferred from CloudFront edge locations to your users. Rates vary by geographic region and volume.

Requests

You pay for HTTPS/HTTP requests served by CloudFront. Pricing can be on the order of USD $0.01 per 10,000 requests in many regions.

CloudFront Functions / Lambda@Edge

CloudFront Functions: Billed by the number of function invocations (e.g., $0.10 per 1 million invocations).
Lambda@Edge: Billed by the number of requests plus compute time (GB-seconds).

Optimization Tip: Caching effectively in CloudFront can drastically reduce the number of origin fetches, which lowers data transfer costs and can also reduce Lambda@Edge invocations. However, caching does not reduce the number of WAF inspections, as every client request that hits CloudFront is still processed by WAF (unless previously blocked or allowed by another mechanism).

13. AWS WAF vs. Incapsula (Imperva) vs. Cloudflare vs. AWS WAF with CloudFront

Below is a high-level comparison table, including a separate row for AWS WAF with CloudFront:

Key Takeaways:

AWS WAF (Regional Services): Ideal for apps that don’t require global edge caching or are purely regional.
AWS WAF with CloudFront: Global edge distribution, built-in CDN and caching, extends protection to external origins. Additionally, combining AWS WAF with CloudFront Functions and Lambda@Edge provides extended customization flexibility, allowing deep control over each and every HTTP parameter within the session, from rewriting headers to injecting custom logic for advanced routing or security checks.
Incapsula & Cloudflare: Third-party global security/CDN solutions with their own pricing, feature sets, and potential integration complexities.

14. Conclusion

AWS WAF is a powerful, flexible solution for safeguarding both AWS-hosted and external web applications. With managed rules, custom rules, labels, and a layered “count then block” strategy, you can tailor your defenses while minimizing false positives. Integrating CloudFront adds global edge coverage, caching, and the option to use CloudFront Functions or Lambda@Edge for advanced logic.

Furthermore, AWS Shield Standard is included at no additional cost, protecting your AWS resources from common network and transport-layer DDoS attacks, while WAF focuses on application-layer threats.

Account Takeover Prevention (ATP) further boosts security by analyzing login attempts for suspicious behavior, making it especially effective when users log in with email addresses. This consistency aids in detection and labeling of potentially malicious traffic and benefits from AWS’s threat intelligence on compromised credentials from public data breaches.

Key Implementation Steps

Enable AWS Managed Rules for immediate protection against common attacks, including OWASP Top 10 vulnerabilities.
Add Custom Rules to address your application’s unique security needs.
Leverage Rule Labels and test in “Count” mode before enforcing blocks.
Adopt a Final Blocking Rule that triggers on suspicious labels (e.g., SQLiDetected, ATPHighRisk).
Use CloudFront as a secure reverse proxy to protect both AWS and external origins, taking advantage of edge caching.
Implement ATP to mitigate unauthorized login attempts, benefiting from standardized email-based usernames and compromised credential checks.
Monitor Limitations such as WAF Capacity Units (WCU), inspection header size, and overall request volume to ensure your rules function effectively at scale.
Use Custom Responses in block actions for branded or instructive error pages.
Leverage AWS Shield Standard for built-in DDoS protection, covering the network and transport layers at no extra cost.
Manage Costs by monitoring the number of web ACLs, rules, and request volume. Optimize with CloudFront caching to reduce origin fetches.
Regularly Review OWASP Top 10 and confirm your AWS Managed Rule Sets (and custom rules) align with emerging vulnerabilities. By following these best practices and leveraging AWS WAF’s advanced features, you can establish a well-architected, scalable, and cost-effective defense against evolving threats- both within and beyond the AWS ecosystem.

DEV Community: Alexey Baltacov

Protect Your Web Site with AWS WAF and CloudFront

Protect Your On-Premises Website with AWS WAF and Amazon CloudFront

1. Introduction

2. Evaluating Origin Compatibility

2.1 Initial Compatibility Test

2.2 Testing X-Forwarded-For

2.3 Spoofing Non-existent Addresses

3. Solution Architecture Overview

3.1 Original Architecture

3.2 Final Architecture (With API Gateway Proxy)

4. Detailed Implementation

4.1 Certificate Management

4.2 AWS WAF Setup

4.3 CloudFront Distribution

4.4 Reducing Origin Connectivity

4.5 Full HTTP Context Access and Modification

5. Final Results

Original Site

Modified Site

6. High Availability, Security, and CDN Benefits

6.1 Amazon CloudFront as a CDN

6.2 Origin Failover with Multiple Origins

7. Conclusion

Appendix A: Edge Compute Options — CloudFront Functions vs Lambda@Edge

Appendix B: Pricing Notes

References

AWS WAF Rate Limiting Based on Origin Response

Introduction

The Challenge

Why Plain AWS WAF Rate Limiting Is Not Enough

AWS WAF's View of Origin Responses and ATP Rules

Why Lambda@Edge Alone Cannot Solve It

A Hybrid Approach: WAF + Lambda@Edge

1) Primary WAF Rate-Limit Rule (Soft Threshold)

2) Secondary WAF Rate-Limit Rule (Hard Threshold)

3) Lambda@Edge Function (Origin Response Trigger)

Associate and Deploy

Testing

Legitimate Access

Scanning Attempts

Demo video

Benefits of This Pattern

References

Making Amazon Bedrock AgentCore Gateway Accessible (Only Through CloudFront)

The Hidden Exposure Problem

Compare This to S3 + CloudFront (OAI / OAC)

Architecture for Enforcing CloudFront-Only Access

Enforcing CloudFront-Only at the Network Layer

Where AWS WAF and DDoS Protection Fit

CloudFront (Edge Layer)

ALB (Ingress Layer)

The Technical Challenge: TLS vs Host Header

The Solution: CloudFront Origin Modification

Final Outcome

AWS WAF Intro Guide

1. Introduction and Overview of AWS WAF

1.1 Resources Protected by AWS WAF

2. Applying AWS WAF: CloudFront vs. Other Resources

2.1 AWS WAF with CloudFront

2.2 AWS WAF with Regional Services

1. Latency and Caching

2. Scope and Customization

3. Protecting External Origins

3. AWS Managed Rules

3.1 Coverage for OWASP Top 10

Injection (SQLi, NoSQL, Command Injection)

Broken Authentication and Session Management

Sensitive Data Exposure

XML External Entities (XXE)

Broken Access Control

Security Misconfiguration

Cross-Site Scripting (XSS)

Insecure Deserialization

Using Components with Known Vulnerabilities

Insufficient Logging and Monitoring

3.2 Examples of AWS Managed Rule Sets

3.3 Complementing Managed Rules with Custom Logic

4. AWS WAF Fraud Control – Account Takeover Prevention (ATP)

4.1 Overview of ATP

2.2 Testing `X-Forwarded-For`