DEV Community: Alexey Baltacov

Precision Canary Deployments for Static Content: Navigating High-Stakes Tech Migrations

Alexey Baltacov — Wed, 06 May 2026 13:26:02 +0000

Precision Canary Deployments for Static Content: Beyond the "Big Bang" Release

Big frontend migrations rarely fail because of one obvious bug.

They fail because production is messy.

A move from a legacy React SPA to a Next.js static build, a routing-model change, or a full redesign can look straightforward on paper because the site is "just static files." In production, the real risk is the combination of browser state, CDN caching, routing behavior, and customer sessions already in flight.

That is where a precision canary earns its keep.

Instead of sending 50% of traffic to a new build and hoping for the best, you can start with 0.1% or even 0.01%, observe what happens under real conditions, and expand only when the evidence says you should.

For engineers, that cuts blast radius. For executives, it turns a risky migration into a controlled rollout with a fast rollback path.

Executive summary

A precision canary for static content does four important things:

It keeps the initial risk very small.
It makes the routing decision before the cache lookup, so stable and canary traffic stay separated.
It avoids cookies by using an anonymous, deterministic routing key such as JA4, then JA3, with a final fallback when neither is available.
It allows instant rollback by changing one edge decision instead of waiting for DNS behavior to settle.

Why static-site migrations still fail in production

Staging environments are useful, but they are not production. They do not contain months of real browser state, cached assets, half-complete sessions, or every unusual client combination that appears on the public internet.

Here are the common ways large static-site releases fail.

1. Hidden client state

Real users arrive with old service workers, outdated cached files, old localStorage data, and long-lived tabs. A new build can be technically correct and still break when it meets that real-world state.

2. Session fragmentation

If a user lands on the new version for one request and the old version for the next, state and routing assumptions can collide. The result is often a broken session, confusing UI behavior, or JavaScript errors that never appeared in testing.

3. Routing surprises

A migration from hash routing to history-based routing changes the rules. A page that works during client-side navigation can still fail on refresh if the origin or edge does not return the expected fallback document.

4. Business impact arrives before technical certainty

When a public site supports revenue, leads, sign-ins, or brand trust, the cost of a bad release is not just a higher bug count. It is lost conversion, increased support load, and rollback stress at the worst possible moment.

Why DNS weighting is not the best fit here

A common first idea is to split traffic at the DNS layer with Route 53 weighted records.

That can work in some scenarios, but it is a weak fit for high-stakes frontend migrations because it sits outside the request path, where the decision really needs to happen.

Route 53 weighting

Pros

Easy to understand
Native AWS capability
Fine for coarse traffic shifts

Cons

Rollback is slower because DNS behavior is not instantly consistent everywhere
It cannot easily support tester overrides with headers
It does not naturally keep a single viewer pinned to a deterministic version during the migration

Why CloudFront Functions is the better control point

With CloudFront Functions, the routing decision happens at the edge on the request itself.

That gives you better operational control:

Instant rollback by changing edge logic or configuration
Very fine rollout precision using basis points
QA and executive preview paths through explicit overrides
Better routing consistency without relying on cookies

Important trade-off: AWS notes that CloudFront Functions run on every viewer request, while Lambda@Edge origin-request logic runs only on cache misses. For highly cacheable workloads, Lambda@Edge can be more cost-efficient. For this article, the recommendation stays with CloudFront Functions because the main goal is fast, precise rollout control during a risky migration, not minimizing function invocations.

Architecture at a glance

The pattern is straightforward:

Keep one CloudFront distribution.
Define two origins: stable and canary.
Run a viewer-request CloudFront Function.
Decide which origin to use before the cache lookup.
Add a small header such as x-canary-origin so the cache key stays isolated between stable and canary objects.

This matters because without cache isolation, CloudFront can serve a cached canary object to a stable user, or vice versa.

The routing principle: deterministic, anonymous, cookie-free

For this use case, the goal is not personal identity. The goal is consistent traffic assignment.

A good order of precedence is:

Explicit header override for QA or controlled previews
Explicit query override for one-off testing
JA4 fingerprint when available
JA3 fingerprint if JA4 is not available
Fallback hash using user-agent + viewer.ip

That gives you a cookie-free strategy that is still stable enough for production rollout control.

This article assumes the site is always served over HTTPS. That matters because JA4 and JA3 are derived from the TLS handshake and are only available on HTTPS requests.

Practical decision flow

Why basis points matter

Percentages are often too coarse.

For a large migration, 1% can already represent a meaningful amount of real traffic. Using basis points (BPS) gives you a much finer dial:

1 BPS = 0.01%
10 BPS = 0.1%
100 BPS = 1%

That lets you run a true smoke test in production before the rollout is visible to a meaningful share of customers.

CloudFront Function example

The following function shows the core pattern:

manual overrides first
deterministic cookie-free routing second
cache isolation always
stable fallback when viewer fingerprints are missing

Important: the sample below assumes JavaScript runtime 2.0 because origin selection helper methods require it.

import cf from 'cloudfront';

const CONFIG = {
  OLD_ORIGIN_ID: 'origin-production',
  NEW_ORIGIN_ID: 'origin-canary',

  // Basis points: 1 = 0.01%, 10 = 0.1%, 100 = 1%
  CANARY_BPS: 10
};

function getHeaderValue(headers, name) {
  var header = headers[name.toLowerCase()];
  return header && header.value ? header.value : '';
}

// ES5-safe deterministic 32-bit hash for bucketing
function stableHash(value) {
  var hash = 2166136261;
  for (var i = 0; i < value.length; i++) {
    hash ^= value.charCodeAt(i);
    hash += (hash << 1) + (hash << 4) + (hash << 7) + (hash << 8) + (hash << 24);
  }
  return hash >>> 0;
}

function pickRoutingKey(request, viewer) {
  var headers = request.headers;

  // Prefer JA4, then JA3. Both are anonymous TLS-derived fingerprints.
  var ja4 = getHeaderValue(headers, 'cloudfront-viewer-ja4-fingerprint');
  if (ja4) return 'ja4:' + ja4;

  var ja3 = getHeaderValue(headers, 'cloudfront-viewer-ja3-fingerprint');
  if (ja3) return 'ja3:' + ja3;

  // Final fallback: still deterministic, but less stable than JA4/JA3
  var userAgent = getHeaderValue(headers, 'user-agent');
  var ip = (viewer && viewer.ip) ? viewer.ip : 'unknown';
  return 'uaip:' + userAgent + '|' + ip;
}

function applyManualOverride(request) {
  var headers = request.headers;
  var querystring = request.querystring || {};

  // 1) QA header override
  var qaVersion = getHeaderValue(headers, 'x-qa-version');
  if (qaVersion === 'canary') return true;
  if (qaVersion === 'stable') return false;

  // 2) One-off query override
  if (querystring.canary) {
    var forceCanary = querystring.canary.value === '1';

    // Remove the test flag so it does not accidentally affect cache behavior
    delete request.querystring.canary;

    return forceCanary;
  }

  return null;
}

function handler(event) {
  var request = event.request;
  var viewer = event.viewer || {};

  var useNewOrigin = applyManualOverride(request);

  if (useNewOrigin === null) {
    var routingKey = pickRoutingKey(request, viewer);
    var bucket = stableHash(routingKey) % 10000;
    useNewOrigin = bucket < CONFIG.CANARY_BPS;
  }

  // Keep stable and canary cache entries isolated
  request.headers['x-canary-origin'] = {
    value: useNewOrigin ? 'new' : 'old'
  };

  if (useNewOrigin) {
    cf.selectRequestOriginById(CONFIG.NEW_ORIGIN_ID);
  } else {
    cf.selectRequestOriginById(CONFIG.OLD_ORIGIN_ID);
  }

  return request;
}

What this code gets right

This version is designed to align with the operational goals in this article.

It does not use cookies

That keeps the mechanism lightweight and avoids introducing a separate persistence layer just to keep users on the same version.

It prefers the most stable anonymous signal available

JA4 first, then JA3, gives you a better routing key than raw IP alone. When those fingerprints are unavailable, the function still behaves predictably.

Header-name note: AWS documentation presents these as CloudFront-Viewer-JA4-Fingerprint and CloudFront-Viewer-JA3-Fingerprint, but inside a CloudFront Functions event object you access them in lowercase as cloudfront-viewer-ja4-fingerprint and cloudfront-viewer-ja3-fingerprint.

It keeps cache entries separated

The x-canary-origin request header is the critical separator. Include this header in the cache key so stable and canary content never share the same cached object.

It supports controlled previews

Executives, QA, or launch managers can view the canary safely using a header or a one-off query switch without changing the default rollout.

Required distribution configuration

The code is only part of the solution. The distribution settings matter just as much.

1. Two origins

Define one origin for the current production build and one for the canary build.

2. Viewer-request CloudFront Function

Associate the function with the cache behavior that serves the site.

3. Enable the CloudFront-generated fingerprint headers

CloudFront needs to add the viewer fingerprint headers so the function can inspect them:

CloudFront-Viewer-JA4-Fingerprint
CloudFront-Viewer-JA3-Fingerprint

These headers are available to CloudFront Functions and Lambda@Edge, but only for HTTPS requests. AWS also notes that these TLS-related headers can be added to an origin request policy, but not to a cache policy.

4. Cache policy includes `x-canary-origin`

This is what keeps stable and canary cache objects isolated.

5. Query-string handling is deliberate

If you allow the ?canary=1 switch for testing, either:

remove it in the function, as shown above, or
make sure it is not part of the cache key

6. SPA or app-style routing fallback is explicit

If the migration changes routing behavior, make sure refreshes and deep links return the correct document.

7. Validate viewer fingerprint availability in your environment

JA3 and JA4 are excellent routing inputs when exposed to the function path, but you should validate their availability in your exact CloudFront setup before making them your only signal.

A rollout plan that works for both engineers and executives

A practical rollout plan looks like this:

Stage 1: 0.1% smoke test

Purpose: prove routing, cache isolation, and basic stability.

Watch for:

unexpected 404s
JavaScript startup failures
broken asset loading
obvious support noise

Stage 2: 1% early validation

Purpose: confirm that the new build survives real traffic patterns.

Watch for:

client-side error rates
performance regressions
login or session complaints
routing edge cases

Stage 3: 5% confidence build

Purpose: compare business and operational metrics against the stable path.

Watch for:

conversion rate
bounce rate
task completion
error budgets
support tickets

Stage 4: 25% operational proof

Purpose: verify team readiness, dashboards, alerts, and rollback confidence under broader load.

Stage 5: 100% cutover

Promote only when the migration risk is low enough for the new path to become the default.

What to measure during the canary

For technical teams:

404 rate by path
JavaScript error rate
asset load failures
Core Web Vitals or equivalent performance signals
origin error rate and CDN cache behavior

For business stakeholders:

conversion or lead generation
checkout or sign-in completion
bounce rate
support ticket volume
incident count during the rollout window

Important caveats

JA3 and JA4 are not identity

They are useful routing signals, not person-level identifiers. Their role here is to keep similar requests on the same side of the rollout decision, not to identify an individual user.

HTTPS matters

JA3 and JA4 come from the TLS Client Hello, so they are relevant only for HTTPS traffic.

The cache key is the safety line

If you remember only one implementation detail, remember this one: do not mix stable and canary objects in the same cache key.

Keep rollback boring

The best rollout is the one that can be reversed in seconds without debate. Edge-based selection gives you that option.

Final takeaway

A canary deployment for static content is not just a safer release tactic.

For major web migrations, it is a way to separate technical uncertainty from business risk.

By making the decision at the edge, using deterministic cookie-free routing, and isolating cache entries correctly, you can move from a fragile big-bang launch to a controlled rollout that both engineers and executives can support.

That is the real value: fewer surprises, faster rollback, and better evidence before full cutover.

Acknowledgments

Special thanks to @Moti Moskovich for his contribution to this article.

References

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

Precision Canary Deployments for Static Content: Navigating High-Stakes Tech Migrations

Precision Canary Deployments for Static Content: Beyond the "Big Bang" Release

Executive summary

Why static-site migrations still fail in production

1. Hidden client state

2. Session fragmentation

3. Routing surprises

4. Business impact arrives before technical certainty

Why DNS weighting is not the best fit here

Route 53 weighting

Why CloudFront Functions is the better control point

Architecture at a glance

The routing principle: deterministic, anonymous, cookie-free

Practical decision flow

Why basis points matter

CloudFront Function example

What this code gets right

It does not use cookies

It prefers the most stable anonymous signal available

It keeps cache entries separated

It supports controlled previews

Required distribution configuration

1. Two origins

2. Viewer-request CloudFront Function

3. Enable the CloudFront-generated fingerprint headers

4. Cache policy includes x-canary-origin

5. Query-string handling is deliberate

6. SPA or app-style routing fallback is explicit

7. Validate viewer fingerprint availability in your environment

A rollout plan that works for both engineers and executives

Stage 1: 0.1% smoke test

Stage 2: 1% early validation

Stage 3: 5% confidence build

Stage 4: 25% operational proof

Stage 5: 100% cutover

What to measure during the canary

Important caveats

JA3 and JA4 are not identity

HTTPS matters

The cache key is the safety line

Keep rollback boring

Final takeaway

Acknowledgments

References

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)

4. Cache policy includes `x-canary-origin`

2.2 Testing `X-Forwarded-For`