DEV Community: Alexey Baltacov

Putting Amazon Cognito Behind CloudFront Without Making the Origin the Public Path

Alexey Baltacov — Mon, 20 Jul 2026 11:41:35 +0000

Amazon Cognito hosted UI is convenient: you get OAuth 2.0 endpoints, OIDC discovery, managed login pages, token endpoints, logout endpoints, and federation plumbing without running your own identity provider.

But the default shape has an awkward property: users and clients talk directly to the Cognito domain.

For corporate applications, you may want the public entry point to be a company-owned domain on your own CloudFront distribution instead:

https://auth.mycorpdomain.com

instead of:

https://mycorp-auth.auth.us-east-1.amazoncognito.com

The reason is not only cosmetic. During the whole login conversation, users stay on a domain your company owns. The auth flow can be embedded into the corporate site or launched from the application UI without making users feel like they left your environment and landed on an AWS-owned hostname.

It also gives you the CloudFront edge advantages around the login surface without pretending auth traffic is a caching problem. Users connect to a local AWS edge presence, TLS terminates closer to them, time to first byte can improve for edge-handled responses such as redirects and blocks, and AWS can carry traffic across its own network toward the origin. At the same edge, a CloudFront-scope AWS WAF Web ACL can apply DDoS protection, login protection, rate limits, bot controls, IP reputation, managed rule groups, custom rules, and simple route handling such as /login, keeping most abusive traffic from ever reaching the Cognito-hosted UI or the regional WAF associated with the user pool.

This article walks through a practical version of that pattern.

The architecture

The target shape:

Browser / OIDC client
        |
        v
CloudFront distribution: auth.mycorpdomain.com
        |
        | adds X-Edge-Origin-Secret
        v
Cognito hosted UI domain
        |
        v
User pool

There are two WAF layers:

A CloudFront-scope Web ACL attached to the CloudFront distribution.
A regional Web ACL associated with the Cognito user pool that only allows requests carrying a secret header added by CloudFront.

There is also one small edge function:

A CloudFront Function on viewer response rewrites Cognito Location headers from the Cognito origin domain back to auth.mycorpdomain.com.

And one static object:

A recreated /.well-known/openid-configuration document served from S3 or another static origin, because OIDC clients need discovery metadata that points at the public CloudFront hostname.

Most user-facing login protection should happen at the CloudFront layer: DDoS protection, login-specific protection, rate limits, path controls, IP reputation, bot controls, geographic policies, managed rule groups, custom rules, and any cheap static redirect for /login. This is separate from caching. For auth traffic, cache hit ratio is not the point. The value is local edge presence, fast edge decisions, AWS network acceleration toward the origin, and stopping bad traffic before it reaches the Cognito path. The regional Cognito WAF remains important, but its main job in this pattern is origin-bypass protection. It should reject direct requests that did not come through CloudFront.

Why not only use CloudFront?

CloudFront can add a custom header to origin requests. That is useful, but it does not stop someone from directly calling the Cognito domain unless the origin also enforces the header.

With many AWS origins, you can make the origin trust CloudFront through a native origin access feature or a resource policy. S3 has Origin Access Control. Some services can restrict access with IAM or resource policies, VPC-only paths, security groups, or other service-native controls.

Cognito hosted UI does not give you that kind of origin access control. You cannot attach application code to the hosted UI, and you cannot write a resource policy that says "only this CloudFront distribution may call this Cognito domain."

The practical way to create one-way stickiness from the public CloudFront hostname to Cognito is:

CloudFront adds X-Edge-Origin-Secret: <random value> on origin requests sent to Cognito.
A regional AWS WAF Web ACL on the Cognito user pool allows requests with that exact header.
Direct calls to the Cognito hosted UI domain do not have the header, so the regional WAF blocks them.

Step 1: create the secret once

Use SSM Parameter Store for the shared secret header value. Set and rotate the value through your secret-management process, not in Terraform source.

Create or rotate the value outside Terraform, for example:

aws ssm put-parameter \
  --name /mycorp/auth/origin-secret \
  --type SecureString \
  --value "$(openssl rand -base64 48)" \
  --overwrite

Terraform should only read the current value:

data "aws_ssm_parameter" "edge_origin_secret" {
  name            = "/mycorp/auth/origin-secret"
  with_decryption = true
}

Do not put the real header value, a placeholder value, or a managed aws_ssm_parameter value in the Terraform module. If Terraform owns the value, it is too easy to leak it into source, state workflows, review systems, or logs.

Step 2: configure CloudFront origin headers

Use the Cognito hosted UI domain as a custom origin.

Example origin values:

CloudFront alias: auth.mycorpdomain.com
Cognito origin:  mycorp-auth.auth.us-east-1.amazoncognito.com

Terraform sketch:

resource "aws_cloudfront_distribution" "auth" {
  enabled         = true
  is_ipv6_enabled = true
  aliases         = ["auth.mycorpdomain.com"]

  origin {
    origin_id   = "cognito-hosted-ui"
    domain_name = "mycorp-auth.auth.us-east-1.amazoncognito.com"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }

    custom_header {
      name  = "X-Edge-Origin-Secret"
      value = data.aws_ssm_parameter.edge_origin_secret.value
    }
  }

  default_cache_behavior {
    target_origin_id       = "cognito-hosted-ui"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods         = ["GET", "HEAD"]

    cache_policy_id          = aws_cloudfront_cache_policy.auth_disabled.id
    origin_request_policy_id = aws_cloudfront_origin_request_policy.auth_all.id

    function_association {
      event_type   = "viewer-response"
      function_arn = aws_cloudfront_function.rewrite_cognito_location.arn
    }
  }

  web_acl_id = aws_wafv2_web_acl.cloudfront_auth.arn

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate.auth.arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }
}

Amazon Cognito hosted UI is HTTPS. Keep origin_protocol_policy = "https-only". The http_port argument appears in Terraform because CloudFront custom origins require the field, but this configuration does not send origin traffic to Cognito over HTTP.

For auth endpoints, caching should usually be disabled or extremely conservative. OAuth requests carry query strings, cookies, state, nonce, code challenges, and other values that should not be collapsed into a shared cached object.

Example cache policy:

resource "aws_cloudfront_cache_policy" "auth_disabled" {
  name        = "mycorp-auth-caching-disabled"
  default_ttl = 0
  max_ttl     = 0
  min_ttl     = 0

  parameters_in_cache_key_and_forwarded_to_origin {
    enable_accept_encoding_brotli = false
    enable_accept_encoding_gzip   = false

    cookies_config {
      cookie_behavior = "none"
    }

    headers_config {
      header_behavior = "none"
    }

    query_strings_config {
      query_string_behavior = "none"
    }
  }
}

And an origin request policy that forwards what Cognito needs:

resource "aws_cloudfront_origin_request_policy" "auth_all" {
  name = "mycorp-auth-forward-all-viewer-values"

  cookies_config {
    cookie_behavior = "all"
  }

  headers_config {
    header_behavior = "allViewer"
  }

  query_strings_config {
    query_string_behavior = "all"
  }
}

Review your own requirements before forwarding every header. This is a simple starting point for hosted UI compatibility, not a universal least-privilege policy.

Step 3: add a CloudFront WAF redirect for `/login`

Users like clean URLs. OAuth endpoints do not.

You can make:

https://auth.mycorpdomain.com/login

return a redirect to:

https://auth.mycorpdomain.com/oauth2/authorize?client_id=...&response_type=code&scope=openid+email+profile&redirect_uri=...&code_challenge=...&code_challenge_method=S256

If the redirect target is static enough for your use case, AWS WAF custom responses can do this at the CloudFront Web ACL layer. WAF custom responses can use 3xx status codes and a Location header. You can also implement the same redirect in a CloudFront Function, but WAF is cheaper for this case because the target remains static as long as the user pool and app client configuration remain unchanged.

In production, make the redirect target depend on the current AWS state rather than a hand-copied URL. For example, Terraform can read the user pool client and construct the authorize URL from data sources, so each terraform apply checks the actual app client and domain values.

Terraform sketch:

resource "aws_wafv2_web_acl" "cloudfront_auth" {
  name  = "mycorp-auth-cloudfront"
  scope = "CLOUDFRONT"

  default_action {
    allow {}
  }

  rule {
    name     = "redirect-login"
    priority = 10

    action {
      block {
        custom_response {
          response_code = 302

          response_header {
            name  = "Location"
            value = "https://auth.mycorpdomain.com/oauth2/authorize?client_id=CLIENT_ID&response_type=code&scope=openid+email+profile&redirect_uri=https%3A%2F%2Fapp.mycorpdomain.com%2Fcallback"
          }
        }
      }
    }

    statement {
      byte_match_statement {
        field_to_match {
          uri_path {}
        }

        positional_constraint = "EXACTLY"
        search_string         = "/login"

        text_transformation {
          priority = 0
          type     = "NONE"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "redirect-login"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "mycorp-auth-cloudfront"
    sampled_requests_enabled   = true
  }
}

This looks odd because the WAF action is technically block, but the custom response is a 302. That is how AWS WAF custom responses work: the rule terminates evaluation and returns your response.

If your /login redirect needs dynamic PKCE generation, dynamic state, tenant selection, or request-specific logic, use application code, a CloudFront Function, or Lambda@Edge instead. WAF redirects are best for simple static redirects.

Step 4: rewrite Cognito `Location` headers

Cognito will often produce redirects that point back at the Cognito hosted UI domain:

Location: https://mycorp-auth.auth.us-east-1.amazoncognito.com/oauth2/...

If clients enter through CloudFront, keep them there:

Location: https://auth.mycorpdomain.com/oauth2/...

CloudFront Functions can run on viewer response and modify response headers before the response is returned.

Function:

function handler(event) {
  var response = event.response;
  var headers = response.headers;

  var publicHost = "auth.mycorpdomain.com";
  var cognitoHost = "mycorp-auth.auth.us-east-1.amazoncognito.com";

  if (headers.location && headers.location.value) {
    headers.location.value = headers.location.value
      .replace("https://" + cognitoHost, "https://" + publicHost);
  }

  return response;
}

Terraform:

resource "aws_cloudfront_function" "rewrite_cognito_location" {
  name    = "mycorp-auth-rewrite-cognito-location"
  runtime = "cloudfront-js-2.0"
  comment = "Rewrite Cognito hosted UI redirects to the public auth domain"
  publish = true
  code    = file("rewrite-cognito-location.js")
}

Keep this function intentionally small. It should not parse tokens, make authorization decisions, or become an identity service. Its job is only to keep redirects on the public hostname.

Step 5: protect Cognito with a regional WAF

Now attach a regional Web ACL to the Cognito user pool and allow only requests with the secret header.

The Web ACL should live in the same region as the user pool.

Keep the responsibility split clear: DDoS protection, login protection, rate limits, bot controls, managed rule groups, custom rules, and other broad controls should run on the CloudFront Web ACL. That lets CloudFront and AWS edge infrastructure handle hostile traffic before it reaches the Cognito service path. The regional Cognito WAF is the final origin-bypass control, not the place where you want internet-scale login floods to arrive first.

resource "aws_wafv2_web_acl" "cognito_origin" {
  name  = "mycorp-auth-cognito-origin"
  scope = "REGIONAL"

  default_action {
    block {}
  }

  rule {
    name     = "allow-cloudfront-origin-secret"
    priority = 10

    action {
      allow {}
    }

    statement {
      byte_match_statement {
        field_to_match {
          single_header {
            name = "x-edge-origin-secret"
          }
        }

        positional_constraint = "EXACTLY"
        search_string         = data.aws_ssm_parameter.edge_origin_secret.value

        text_transformation {
          priority = 0
          type     = "NONE"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "allow-cloudfront-origin-secret"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "mycorp-auth-cognito-origin"
    sampled_requests_enabled   = true
  }
}

Associate it with the user pool:

resource "aws_wafv2_web_acl_association" "cognito" {
  resource_arn = aws_cognito_user_pool.this.arn
  web_acl_arn  = aws_wafv2_web_acl.cognito_origin.arn
}

Test both paths:

curl -I https://auth.mycorpdomain.com/oauth2/authorize

should reach Cognito through CloudFront, while:

curl -I https://mycorp-auth.auth.us-east-1.amazoncognito.com/oauth2/authorize

should be blocked by the regional Web ACL because the secret header is missing.

Do not use a guessable value. The header is not a replacement for OAuth security. It is an origin-bypass control.

Step 6: recreate `openid-configuration`

OIDC clients discover provider metadata from:

/.well-known/openid-configuration

For Cognito user pools, the AWS-owned discovery document normally lives under the issuer host:

https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE/.well-known/openid-configuration

But if clients are configured to use:

https://auth.mycorpdomain.com

then discovery must return endpoints that send clients to auth.mycorpdomain.com, not the raw Cognito hosted UI domain.

This is not the same as hiding every Cognito identifier. OIDC clients need a real issuer and signing keys. The discovery document, jwks_uri, and ID token iss claim can still expose the Cognito issuer host, region, and user pool ID. That is normal for Cognito token validation.

The goal is narrower and more practical: keep the Cognito hosted UI domain out of the browser routing path, keep OAuth endpoints on the company-owned CloudFront hostname, and block direct use of the hosted UI origin with the regional WAF.

One practical approach is:

Fetch the original Cognito discovery document.
Create a modified copy.
Serve it from S3 behind the same CloudFront distribution at /.well-known/openid-configuration.

Example original shape:

{
  "issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE",
  "authorization_endpoint": "https://mycorp-auth.auth.us-east-1.amazoncognito.com/oauth2/authorize",
  "token_endpoint": "https://mycorp-auth.auth.us-east-1.amazoncognito.com/oauth2/token",
  "userinfo_endpoint": "https://mycorp-auth.auth.us-east-1.amazoncognito.com/oauth2/userInfo",
  "end_session_endpoint": "https://mycorp-auth.auth.us-east-1.amazoncognito.com/logout",
  "jwks_uri": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE/.well-known/jwks.json",
  "response_types_supported": ["code", "token"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "scopes_supported": ["openid", "email", "phone", "profile"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"],
  "claims_supported": ["sub", "email", "email_verified", "phone_number", "phone_number_verified"]
}

Modified public copy:

{
  "issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE",
  "authorization_endpoint": "https://auth.mycorpdomain.com/oauth2/authorize",
  "token_endpoint": "https://auth.mycorpdomain.com/oauth2/token",
  "userinfo_endpoint": "https://auth.mycorpdomain.com/oauth2/userInfo",
  "end_session_endpoint": "https://auth.mycorpdomain.com/logout",
  "jwks_uri": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE/.well-known/jwks.json",
  "response_types_supported": ["code", "token"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "scopes_supported": ["openid", "email", "phone", "profile"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"],
  "claims_supported": ["sub", "email", "email_verified", "phone_number", "phone_number_verified"]
}

What to replace:

authorization_endpoint
token_endpoint
userinfo_endpoint
end_session_endpoint
Any other OAuth endpoint value that uses the Cognito hosted UI domain

What not to replace blindly:

issuer
jwks_uri
Supported algorithms
Supported claims
Supported scopes
Supported auth methods
Any fields that describe token validation semantics rather than browser routing

The issuer is especially important. Cognito tokens are issued by the Cognito user pool issuer, commonly:

https://cognito-idp.<region>.amazonaws.com/<user_pool_id>

If you change the issuer in discovery but Cognito still signs tokens with the original issuer claim, strict OIDC clients can reject the tokens. Keep issuer behavior aligned with the actual tokens your user pool emits.

So yes, issuer and jwks_uri intentionally reveal that Cognito is the token issuer. They should not reveal the hosted UI origin as the normal authorization, token, userinfo, or logout endpoint after you rewrite those endpoint values, but they do reveal the Cognito user pool identity. Treat this pattern as origin-bypass prevention and corporate-domain continuity, not complete origin secrecy.

Serve the file from S3:

resource "aws_s3_object" "openid_configuration" {
  bucket       = aws_s3_bucket.auth_static.id
  key          = ".well-known/openid-configuration"
  content_type = "application/json"
  source       = "openid-configuration.json"
  etag         = filemd5("openid-configuration.json")
}

Then add a CloudFront behavior for the discovery path:

ordered_cache_behavior {
  path_pattern           = "/.well-known/openid-configuration"
  target_origin_id       = "auth-static"
  viewer_protocol_policy = "redirect-to-https"
  allowed_methods        = ["GET", "HEAD"]
  cached_methods         = ["GET", "HEAD"]
  cache_policy_id        = aws_cloudfront_cache_policy.discovery.id
}

The JWKS document can usually remain on the Cognito issuer host. Clients validating JWTs should follow jwks_uri and use the keys from the actual issuer.

Step 7: route CloudFront behaviors carefully

A useful distribution often has at least two origins:

Origin 1: Cognito hosted UI domain
Origin 2: S3 bucket for static discovery overrides

Behaviors:

/.well-known/openid-configuration -> S3 static origin
/*                                  -> Cognito origin

You might also choose to serve:

/.well-known/jwks.json

through CloudFront as a proxy or static copy, but do that carefully. Stale JWKS can break token validation during key rotation. In many cases, leaving jwks_uri pointed at the Cognito issuer is simpler and safer.

Step 8: monitor the bypass control

The regional Cognito WAF should have very boring metrics:

Allowed requests with the secret header.
Blocked direct requests without the secret header.

Create alarms for unexpected spikes in blocked direct traffic. They may indicate scanners, old clients, bad documentation, or someone using the origin URL directly.

Also log enough CloudFront and WAF data to debug OAuth flows:

CloudFront standard or real-time logs
AWS WAF logs for the CloudFront Web ACL
AWS WAF logs for the Cognito-origin Web ACL
Cognito user pool logs where applicable

Be careful with auth logs. They can contain sensitive query strings such as OAuth code, state, or provider-specific values. Set retention and access controls accordingly.

Common failure modes

The first common failure is forgetting response header rewrites. Login starts at the pretty domain, then one redirect sends the browser back to the Cognito domain.

The second is changing the OIDC issuer in discovery without changing the actual token issuer. Many clients validate that issuer in discovery matches the iss claim in the token.

The third is caching auth responses. Do not cache OAuth redirects, token responses, or user-specific hosted UI pages unless you deeply understand the cache key.

The fourth is rotating the origin secret in only one place. CloudFront and the regional WAF must agree on the value.

The fifth is assuming the secret header is a complete security boundary. It is only a way to prevent ordinary direct-origin bypass. OAuth client configuration, redirect URI validation, PKCE, token validation, TLS, WAF rules, and monitoring still matter.

Final checklist

CloudFront alias is the public auth hostname.
CloudFront forwards required query strings, cookies, and headers to Cognito.
CloudFront adds a high-entropy custom origin header.
CloudFront WAF handles edge controls such as /login redirect, DDoS protection, login protection, bot controls, rate limits, managed rule groups, and custom rules.
CloudFront Function rewrites Cognito Location headers to the public hostname.
Regional WAF is associated with the Cognito user pool.
Regional WAF default action blocks.
Regional WAF allow rule matches the CloudFront secret header.
/.well-known/openid-configuration is served from the public hostname.
Discovery OAuth endpoints point to the public hostname.
issuer and jwks_uri remain compatible with the tokens Cognito actually issues.
Direct requests to the Cognito hosted UI domain are blocked.
OAuth flows are tested end to end with a real OIDC client.

This pattern is not about hiding identity infrastructure as a security trick. OIDC metadata and tokens still identify Cognito as the issuer. It is about making one public auth edge, putting controls there, keeping the hosted UI origin out of the normal browser path, and making direct-origin access boringly unavailable.

References

CloudFront custom origin headers: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html
CloudFront Functions: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html
Cognito user pool OIDC endpoints: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-userpools-server-contract-reference.html
AWS WAF custom responses and redirects: https://docs.aws.amazon.com/waf/latest/developerguide/customizing-the-response-for-blocked-requests.html

Best Practices for Managing AWS WAF with Code

Alexey Baltacov — Thu, 16 Jul 2026 17:57:38 +0000

AWS WAF looks simple until it becomes important.

At first it is a few managed rule groups, an IP allowlist, maybe a rate limit on /login. Then a real application grows around it. You add exceptions. You tune false positives. You need different behavior for APIs, static assets, GraphQL, login pages, admin paths, mobile clients, partners, scanners, and known noisy endpoints.

If all of that logic lives as a pile of one-off console edits, the Web ACL eventually becomes a place people are afraid to touch.

The fix is not only "put it in Terraform." The better fix is to model AWS WAF like a small policy engine:

Rules classify traffic.
Labels carry facts about a request.
Cleanup rules make final allow/block decisions.
Terraform owns the shape, review history, and rollout process.

This article is the pattern I use for WAF-as-code when the ACL is expected to live for years, not weeks.

Start with ownership boundaries

The first mistake is putting every WAF object into one giant Terraform state. AWS WAF has several object types with different lifecycles:

Web ACLs
Rule groups
IP sets
Regex pattern sets
Logging configuration
Resource associations

Some are global for CloudFront. Some are regional. Some are shared by many ACLs. Some are application-specific.

A maintainable ownership model makes that visible. For example, you might manage these as separate Terraform states, separate workspaces, or separate pipeline units:

CloudFront Web ACLs
CloudFront IP sets
Regional Web ACLs per AWS region
Regional rule groups per AWS region
Reusable regex pattern sets

The exact directory structure is not important. What matters is that one change does not require planning every WAF object in the account.

For CloudFront-scope WAF resources, remember that AWS WAF uses CLOUDFRONT scope and the API endpoint is in us-east-1. Regional Web ACLs live in the region of the protected resource.

Keep rule bodies reviewable

Terraform HCL is good for resources, tags, providers, and wiring. Deeply nested WAF statements are not pleasant to review in HCL.

For larger ACLs, consider separating stable resource metadata from ordered rule logic. That can be done with YAML, JSON, generated HCL, or a purpose-built generator.

Example metadata shape:

name: example-edge-acl
scope: CLOUDFRONT
default_action: allow

visibility:
  cloudwatch_metrics_enabled: true
  sampled_requests_enabled: true
  metric_name: example-edge-acl

Example rule document:

rules:
  - name: classify_login_paths
    priority: 100
    action: count
    labels:
      - app:surface:login
    statement:
      byte_match:
        field: uri_path
        positional_constraint: STARTS_WITH
        search_string: /login

  - name: cleanup_rate_limited_login
    priority: 9000
    action: block
    statement:
      and:
        - label_match:
            scope: LABEL
            key: app:surface:login
        - label_match:
            scope: LABEL
            key: app:abuse:rate_limited

Whether you render YAML to JSON, generate dynamic HCL, or write the rules directly is an implementation detail. The important part is that reviewers can read the policy as policy.

Labels are the language of a mature ACL

AWS WAF labels are metadata attached to a request when a rule matches. Later rules can match those labels. Labels remain available until the Web ACL evaluation ends.

That means a WAF rule does not have to decide the final fate of a request immediately. It can say:

This request is on a login path.

or:

This request matched a noisy scanner signature.

or:

This request came from a trusted integration IP set.

Then later rules can combine those facts.

AWS also exposes label metrics, which makes labels useful for monitoring, not just enforcement.

Design label namespaces, not random labels

Random labels become a second naming problem. Treat labels like an internal API.

A useful label naming shape is:

<owner>:<namespace>:<specific_fact>

In AWS WAF terms, app:surface: or app:abuse: is a label namespace, and app:surface:login is a specific label. That distinction matters because label match statements can match either one exact label or a namespace.

Examples:

app:surface:login
app:surface:api
app:surface:admin

app:identity:trusted_integration
app:identity:internal_network
app:identity:anonymous

app:abuse:rate_limited
app:abuse:bad_bot
app:abuse:scanner

app:exception:legacy_client
app:exception:known_false_positive

The key is consistency. You want a reviewer to understand the purpose before reading the statement.

Bad:

matched-rule-17
temp_allow
new_api_fix
block_this

Better:

app:surface:graphql
app:exception:mobile_v1_encoding
app:abuse:sql_injection_signal

The label should describe a fact, not the desired action. app:surface:login is better than app:allow_login, because the same fact might be used by allow, count, challenge, and block logic later.

Use count rules for classification

In a label-first ACL, many early rules should use count.

For example, this rule identifies login traffic:

rule {
  name     = "classify-login-paths"
  priority = 100

  action {
    count {}
  }

  rule_label {
    name = "app:surface:login"
  }

  statement {
    or_statement {
      statement {
        byte_match_statement {
          field_to_match {
            uri_path {}
          }
          positional_constraint = "STARTS_WITH"
          search_string         = "/login"

          text_transformation {
            priority = 0
            type     = "NONE"
          }
        }
      }

      statement {
        byte_match_statement {
          field_to_match {
            uri_path {}
          }
          positional_constraint = "STARTS_WITH"
          search_string         = "/oauth2/authorize"

          text_transformation {
            priority = 0
            type     = "NONE"
          }
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "classify-login-paths"
    sampled_requests_enabled   = true
  }
}

This rule does not allow or block. It adds a fact to the request.

Later, a rate-based rule might add another fact:

rule {
  name     = "classify-login-rate-limit"
  priority = 200

  action {
    count {}
  }

  rule_label {
    name = "app:abuse:login_rate_limited"
  }

  statement {
    rate_based_statement {
      limit              = 300
      aggregate_key_type = "IP"

      scope_down_statement {
        label_match_statement {
          scope = "LABEL"
          key   = "app:surface:login"
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "classify-login-rate-limit"
    sampled_requests_enabled   = true
  }
}

Now you have two independent facts:

The request is for the login surface.
The request is over the login rate threshold.

That is much easier to reason about than one deeply nested monster rule.

Cleanup rules make the final decision

Cleanup rules are late-priority rules that convert labels into a final action.

Example:

rule {
  name     = "cleanup-block-rate-limited-login"
  priority = 9000

  action {
    block {}
  }

  statement {
    and_statement {
      statement {
        label_match_statement {
          scope = "LABEL"
          key   = "app:surface:login"
        }
      }

      statement {
        label_match_statement {
          scope = "LABEL"
          key   = "app:abuse:login_rate_limited"
        }
      }

      statement {
        not_statement {
          statement {
            label_match_statement {
              scope = "LABEL"
              key   = "app:identity:internal_network"
            }
          }
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "cleanup-block-rate-limited-login"
    sampled_requests_enabled   = true
  }
}

This reads like a sentence:

Block login traffic that is rate limited unless it is internal network traffic.

That is the point. Cleanup rules should be boring to review.

Example: managed rules without surprise blocking

Managed rule groups are valuable, but turning them on with blocking actions can be a noisy experience.

A safer pattern:

Add the managed rule group.
Override the rules to count.
Observe labels and sampled requests.
Add cleanup rules for the labels you are ready to enforce.

Sketch:

rule {
  name     = "aws-managed-common"
  priority = 1000

  override_action {
    count {}
  }

  statement {
    managed_rule_group_statement {
      name        = "AWSManagedRulesCommonRuleSet"
      vendor_name = "AWS"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "aws-managed-common"
    sampled_requests_enabled   = true
  }
}

Then block only a label namespace that you have reviewed:

rule {
  name     = "cleanup-block-known-bad-managed-rule-matches"
  priority = 9100

  action {
    block {}
  }

  statement {
    and_statement {
      statement {
        label_match_statement {
          scope = "NAMESPACE"
          key   = "awswaf:managed:aws:core-rule-set:"
        }
      }

      statement {
        not_statement {
          statement {
            label_match_statement {
              scope = "LABEL"
              key   = "app:exception:known_false_positive"
            }
          }
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "cleanup-block-known-bad-managed-rule-matches"
    sampled_requests_enabled   = true
  }
}

Important detail: for labels from a different context, such as a managed rule group, match the fully qualified label or namespace that AWS WAF reports. Do not guess. Pull it from sampled requests, logs, or the managed rule group metadata.

Example: exception rules as labels

Exceptions are where many Web ACLs become unreadable.

Try this instead:

rule {
  name     = "classify-known-mobile-client-encoding"
  priority = 300

  action {
    count {}
  }

  rule_label {
    name = "app:exception:mobile_v1_encoding"
  }

  statement {
    and_statement {
      statement {
        byte_match_statement {
          field_to_match {
            single_header {
              name = "user-agent"
            }
          }
          positional_constraint = "CONTAINS"
          search_string         = "ExampleClient/1."

          text_transformation {
            priority = 0
            type     = "LOWERCASE"
          }
        }
      }

      statement {
        byte_match_statement {
          field_to_match {
            uri_path {}
          }
          positional_constraint = "STARTS_WITH"
          search_string         = "/api/v1/upload"

          text_transformation {
            priority = 0
            type     = "NONE"
          }
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "classify-known-mobile-client-encoding"
    sampled_requests_enabled   = true
  }
}

Now every cleanup rule can decide whether that exception matters.

not_statement {
  statement {
    label_match_statement {
      scope = "LABEL"
      key   = "app:exception:mobile_v1_encoding"
    }
  }
}

That beats copying the same exception logic into five different block rules.

Example: allow is also a cleanup action

Sometimes the final action is allow.

For example, an integration endpoint might be default-deny:

/integrations/*

You can model that as:

100 classify integration path
110 classify trusted integration source IP
9000 allow integration path + trusted source
9010 block integration path

The last two rules are the cleanup pair:

rule {
  name     = "cleanup-allow-integration-api-from-trusted-networks"
  priority = 9000

  action {
    allow {}
  }

  statement {
    and_statement {
      statement {
        label_match_statement {
          scope = "LABEL"
          key   = "app:surface:integration_api"
        }
      }

      statement {
        label_match_statement {
          scope = "LABEL"
          key   = "app:identity:trusted_integration"
        }
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "cleanup-allow-integration-api-from-trusted-networks"
    sampled_requests_enabled   = true
  }
}

rule {
  name     = "cleanup-block-integration-api"
  priority = 9010

  action {
    block {}
  }

  statement {
    label_match_statement {
      scope = "LABEL"
      key   = "app:surface:integration_api"
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "cleanup-block-integration-api"
    sampled_requests_enabled   = true
  }
}

This is explicit. Partner traffic is not "allowed by accident" because a default action happened to be permissive.

Importing existing WAF resources

Many teams start with existing console-managed WAF resources. Do not rewrite them by hand and hope for the best.

Use an import-first workflow:

Create the Terraform skeleton.
Import the existing resource.
Run terraform plan.
Preserve live settings and tags unless the change is intentional.
Repeat until the plan is no-op.
Make one small intentional change.

For Terraform versions that support import blocks, the shape is:

import {
  to = aws_wafv2_web_acl.this
  id = "<web-acl-id>/<web-acl-name>/<scope>"
}

For classic CLI import:

terraform import aws_wafv2_web_acl.this \
  '<web-acl-id>/<web-acl-name>/<scope>'

The exact import ID format varies by resource type. Check the provider docs for each object.

The principle is more important than the command:

First prove Terraform can reproduce the current object. Then change it.

Use placeholders for environment-specific values

WAF policies often need values that should not be hardcoded:

IP set ARNs
Regex pattern set ARNs
SSM parameter values
Rule group ARNs
Account-specific prefixes
Secret header values
Remote-state outputs

A clean pattern is to keep placeholders in the rule document and render them at plan time:

rules:
  - name: classify-cdn-origin-secret
    priority: 100
    action: count
    labels:
      - app:identity:edge
    statement:
      byte_match:
        field:
          single_header: x-edge-origin-secret
        positional_constraint: EXACTLY
        search_string: "__EDGE_ORIGIN_SECRET__"

Then replace from Terraform:

data "aws_ssm_parameter" "edge_origin_secret" {
  name            = "/example/waf/origin-secret"
  with_decryption = true
}

locals {
  rendered_rules = replace(
    file("rules.yaml"),
    "__EDGE_ORIGIN_SECRET__",
    nonsensitive(data.aws_ssm_parameter.edge_origin_secret.value)
  )
}

Do not commit secrets to source control. If the value must be shared between CloudFront and WAF, store it in something like SSM Parameter Store and have both sides read it.

Rule priority is part of the design

Label-based ACLs depend on order.

One useful convention:

0000-0999 emergency rules
1000-1999 request surface classification
2000-2999 identity/source classification
3000-3999 managed rule groups in count mode
4000-4999 abuse signal classification
8000-8999 temporary experiments
9000-9999 cleanup allow/block/challenge rules

This makes reviews easier. A cleanup rule at priority 1500 should look wrong immediately.

A practical review checklist

Before merging a WAF change, ask:

Does this change affect CLOUDFRONT scope, regional scope, or both?
Is the Terraform plan no-op except for the intended change?
Are labels named as facts rather than actions?
Does every cleanup rule read like a clear sentence?
Are exceptions modeled once and reused through labels?
Are secrets and environment-specific values coming from a secure source?
Are managed rule labels copied from AWS output rather than guessed?
Is the rollout count-first where false positives are possible?
Are CloudWatch metrics enabled for the rules that matter?
Is there a rollback path that does not require console edits?

The mental model

The most useful shift is to stop thinking of AWS WAF as a list of independent firewall rules.

Think of it as a request evaluation pipeline:

request
  -> classify surface
  -> classify identity/source
  -> classify managed-rule signals
  -> classify exceptions
  -> cleanup decisions
  -> default action

Labels are the memory of that pipeline. Cleanup rules are where the policy becomes enforcement.

Once you adopt that shape, AWS WAF gets easier to review, easier to test, and much less scary to change.

References

AWS WAF labels: https://docs.aws.amazon.com/waf/latest/developerguide/waf-labels.html
AWS WAF rules that add labels: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-label-add.html
AWS WAF rules that match labels: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-label-match.html
AWS WAF custom responses: https://docs.aws.amazon.com/waf/latest/developerguide/waf-custom-request-response.html

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

Putting Amazon Cognito Behind CloudFront Without Making the Origin the Public Path

The architecture

Why not only use CloudFront?

Step 1: create the secret once

Step 2: configure CloudFront origin headers

Step 3: add a CloudFront WAF redirect for /login

Step 4: rewrite Cognito Location headers

Step 5: protect Cognito with a regional WAF

Step 6: recreate openid-configuration

Step 7: route CloudFront behaviors carefully

Step 8: monitor the bypass control

Common failure modes

Final checklist

References

Best Practices for Managing AWS WAF with Code

Start with ownership boundaries

Keep rule bodies reviewable

Labels are the language of a mature ACL

Design label namespaces, not random labels

Use count rules for classification

Cleanup rules make the final decision

Example: managed rules without surprise blocking

Example: exception rules as labels

Example: allow is also a cleanup action

Importing existing WAF resources

Use placeholders for environment-specific values

Rule priority is part of the design

A practical review checklist

The mental model

References

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

Step 3: add a CloudFront WAF redirect for `/login`

Step 4: rewrite Cognito `Location` headers

Step 6: recreate `openid-configuration`

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

2.2 Testing `X-Forwarded-For`