CDN and WAF configuration checklist for overseas traffic

"Overseas access is slow" is not enough to act on. Measure the time the origin took to answer separately from the time that answer took to reach the user. If the first is the problem, the application and the database are the place to look; if the second is, moving the delivery path closer is the answer.

Measure from where the users actually are. Pick three regions with real traffic, time the same page at the same hour, and keep those numbers as a baseline. Only measuring the same way afterwards shows where the improvement came from. A single reading from the office network is not a baseline.

Giving every file the same retention either delays updates or crowds the origin. Separate files that change often, files that sit for a long time, and pages that differ per person, then set retention and refresh behaviour for each. Images, video and static files come first. Screens visible only to signed-in users stay out of the cache, and responses carrying personal data must not linger at the edge.

Decide in advance what gets cleared on release and how. Use versioned filenames for swap-in replacement and immediate invalidation where that fits, and check what goes into the cache key. Unnecessary values in the key split one file into several copies and the hit ratio falls. Tracking parameters on advertising traffic are the common case.

Bringing delivery closer means nothing if origin calls stay flat. Collect hit ratio and origin request volume by content type, find the paths with a low hit ratio, and fix the headers and rules behind them. Compare monthly origin traffic before and after and record it. Delivery cost is charged on what leaves the origin, so that number is the saving.

Decide what to serve when the origin does not answer. A fallback response rule absorbs sudden traffic spikes and origin failures at the edge. Check this item before scaling the origin server up.

On a service with heavy overseas traffic, block rules written by region alone shut out customers as well. Establish which regions genuine users arrive from and allow those first, then judge everything else on behaviour. Request frequency, path, client information and whether sensitive paths such as sign-in and payment are being touched all form the basis for that judgement. Even from the same region, human traffic and automated harvesting move differently.

Rules are not set once and left. Review the block log, adjust false positives, and check weekly whether genuine users are caught among the blocked requests. Known attack pattern filtering, restricting administrative paths and automatic certificate renewal are handled at the same edge. A record of what was blocked and why is what keeps the rules improving.

Cutover redirects where the domain points to the edge, so no application code changes. Certificates and DNS settings move, and during the transition the direct origin path stays open so traffic can be split across both. The same method applies to a service already in production.

Ramp up in the quietest hours in stages and roll back immediately if anything looks wrong. Fix the rollback condition and who makes the call before the work starts, and nothing has to be debated on the day. For the first week after cutover, read the regional response times and the block log daily.