Putting a CDN in front of a site without configuring it carefully delivers a fraction of the benefit and conceals several problems. Cache hit ratio stays mediocre because the application sends headers that prevent storage, origin traffic drops far less than anyone expected, and the bill goes up for a service that was supposed to bring it down. Adding a CDN is the easy part. Configuring it correctly is the actual work, and it looks much the same whichever provider sits in front.
The platforms we work with
Cloudflare is where most of our clients start, and where this site runs. Cache Rules and Workers decide what is stored and what logic runs at the edge, the managed WAF rulesets and Bot Management or Super Bot Fight Mode handle hostile traffic, Turnstile replaces CAPTCHA on forms, and Cloudflare Tunnel or authenticated origin pulls keep the origin off the public internet. For many organisations it is also the cheapest way to get all of that from one vendor.
Amazon CloudFront is the natural choice when the origin already lives in AWS. The work is in cache and origin request policies that keep the cache key small, Origin Shield to cut origin fetches, Origin Access Control so S3 buckets answer only CloudFront, CloudFront Functions and Lambda@Edge for request logic, and AWS WAF with Bot Control and Shield in front. Real-time logs into your pipeline show what the distribution is actually doing.
Akamai is the platform where our security experience runs deepest: App & API Protector and Bot Manager policies taken from alert to enforcement on enterprise accounts, alongside the Property Manager rule trees, cache key design and Site Shield that make delivery efficient. We have written up how we take an Akamai WAF and Bot Manager to enforcement.
Fastly suits teams that want fine-grained control: VCL or Compute for logic at the edge, surrogate keys for purging related objects in milliseconds, and the Next-Gen WAF. Where a client already runs on Azure Front Door or Google Cloud CDN because the rest of the estate is there, we work within it rather than adding another vendor.
Cache strategy
Optimisation starts with measurement. We analyse logs to establish the real hit ratio broken down by content type, then identify precisely what is preventing caching. The causes are usually predictable whatever the platform: missing or overly conservative Cache-Control headers, session cookies sent with every static asset request, tracking parameters in URLs that fragment the cache key across thousands of variants of the same file, and Vary headers on attributes that do not affect the response.
From there we build explicit rules per content class. Fingerprinted static assets can be cached effectively forever, since any change produces a new filename. HTML documents need short freshness windows paired with purge on deploy, ideally by tag rather than by URL. API responses identical across users can hold for a few seconds, which at high request rates removes a substantial share of origin load. Personalised content uses tightly controlled cache key variation rather than whatever the platform does by default. A tiered or shielded cache layer between the edge and the origin then turns the remaining misses into one origin fetch instead of hundreds.
Security at the edge
The web application firewall always goes into observation mode first, whether it is Cloudflare’s managed rules, AWS WAF, Akamai App & API Protector or Fastly’s Next-Gen WAF. We run the rule set against live traffic without blocking, review what would have been stopped, identify false positives and tune accordingly. Enforcement is then enabled by category, incrementally. A WAF that blocks legitimate checkout requests costs more than having no WAF at all.
Bots need their own policy rather than a WAF rule. Search engines and monitoring services should pass, impersonators should not, and the automation aimed at login, checkout and search needs a response chosen per endpoint: a challenge where a person can solve it once, slowing or alternate content where blocking would only teach the attacker to change tactics.
Volumetric DDoS protection comes from the provider’s network capacity, but application-layer attacks need specific configuration: rate limiting on expensive or sensitive endpoints and rules built around behavioural patterns rather than signatures alone. We also lock the origin down so backend servers accept connections only from the CDN, through Cloudflare Tunnel, CloudFront Origin Access Control, Akamai Site Shield or authenticated origin pulls. A CDN in front of an origin that remains directly reachable provides protection that exists mainly on paper, and attackers find the origin address faster than most teams expect.
TLS is managed end to end: issuance, automated renewal, cipher suite configuration, HSTS policy and expiry monitoring with alerting well before the deadline. Expired certificates remain one of the most common causes of avoidable downtime.
Configuration as code
CDN settings changed by hand in a console are the reason nobody can say why a rule exists. We keep the configuration in Terraform, using each provider’s own Terraform support, review changes like any other code, test them on a staging hostname or staging network first, and keep the previous version ready to restore. Logs go to your own pipeline, so a change can be tied to a real user metric rather than a dashboard nobody watches.
Who this is for
The service fits online retailers with seasonal traffic peaks, publishers and content platforms, SaaS providers serving users across multiple countries, and any organisation paying more for egress than its traffic pattern warrants.
It also suits organisations that configured a CDN some years ago and have not revisited the settings since, and those weighing a move between providers or running more than one. Enterprise accounts on any platform are a frequent case: the contract is signed, the features are paid for, and the person who set it up has left. Those engagements do not need to be large to be worth doing.
Edge optimisation and EU considerations
Beyond caching, the edge supports modern compression, format negotiation for images based on browser support, HTTP/3, and application logic executed close to the user. Redirects, A/B allocation and authentication checks moved out of the origin application and into the edge have a direct effect on response time and on how much origin capacity is needed.
For European clients, edge configuration also carries data protection implications. We configure log retention and field-level redaction so that request logs do not accumulate personal data unnecessarily, and we can constrain processing and caching behaviour to support GDPR obligations.