WAF + CDN rollout across a multi-brand, multi-country domain portfolio

Overview

Goal: put AWS WAF in front of every public web and API endpoint across the brand portfolio to protect against OWASP Top-10 threats, geo-block traffic from high-risk jurisdictions, and centralize logging and monitoring through CloudWatch — without disturbing how internal users and services already reach the same backends via an internal load balancer.

[ External users / bots ] ──► [ Amazon CloudFront ]  ◄── ACM wildcard certs per brand
                                        │                   (*.brand1.com, *.brand2.se, ...)
                                 [ AWS WAF ]  ──► [ OpenSearch — logging ]
                                        │
                              [ Internal load balancer ]  ◄── internal users, unchanged path
                                        │
                          [ Ingress / EKS workloads ]

Infrastructure is managed as a single reusable Terraform module, so every brand domain gets the same WAF ruleset, logging configuration, and certificate handling rather than a hand-rolled one-off per domain.

1. Geo-fencing policy

Traffic is blocked from a list of countries aligned with EU sanctions guidance and the EU's published list of jurisdictions of concern — a mix of comprehensively sanctioned states and countries flagged for elevated fraud/AML risk in the financial sector specifically. This is public policy guidance, not company-specific data, and is reviewed periodically rather than hard-coded permanently, since sanctions guidance changes:

2. Domain scope

Every public brand domain across the portfolio was brought into scope, each with its own ACM wildcard certificate in us-east-1 (a CloudFront requirement) and its own set of subdomains routed through CloudFront + WAF. The full domain-by-domain scope for this rollout — domain names below are illustrative brand placeholders, not the real portfolio:

brand1.com — primary consumer brand

brand2.se — domestic brand + internal tooling

Remaining brand domains — international markets

Seven brand domains across four countries, roughly fifty individual and wildcard subdomains in total — every one of them backed by the same reusable Terraform module, the same WAF ruleset, and the same CloudWatch logging target, so onboarding domain fifty felt identical to onboarding domain one.

3. DEV/TEST as a dress rehearsal

Before touching a single production record, the same Terraform module was applied to dev-* and test-* subdomains and left running for a full test cycle:

• AWS managed rule groups plus custom rules tested against real application traffic patterns to confirm nothing legitimate gets blocked
• Geo-blocking confirmed with traffic simulated from both allowed and blocked regions
• Rate-limiting and IP allow-listing verified against known internal and partner ranges
• Application functionality tested end to end to confirm the WAF doesn't block legitimate traffic
• CloudWatch log groups and alarms confirmed to be receiving and triggering correctly

Additional recommendations worked through before production cut-over: simulating realistic traffic patterns to validate allowed vs. blocked requests, cross-region/edge-case testing for geo-blocking, integration tests against production-like clients to verify headers and redirects, and a final CloudWatch monitoring pass to confirm logs and alarms trigger as expected. DEV/TEST was treated explicitly as a dress rehearsal for exactly this reason — every issue found there is one that never reaches a customer.

4. Prerequisites & preparations

Preparations phase, end to end: roughly 1–2 hours, done well ahead of the actual cut-over window.

5. Cut-over steps

6. Estimated timeline

7. Rollback plan

• Revert to the previous Terraform configuration and re-apply
• Restore the internal load balancer's public IP
• Confirm both internal and public DNS resolve correctly back to the load balancer

8. Communication

The wider IT organization is notified ahead of the scheduled cut-over window, including the expected start/end time and who to contact if something looks wrong during the overnight monitoring period — a reversible plan is only as good as people knowing it's happening.

Pre-go-live checklist

• Terraform plan reviewed and approved by a second engineer
• ACM certificates issued and validated for every domain in scope
• DNS records verified with dig/nslookup before and after cut-over
• Load balancer configuration backed up
• Terraform IAM role confirmed least-privilege
• CloudWatch logging and alarms confirmed functional
• Cut-over window and rollback plan communicated to the wider team in advance