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.
Akamai
Akamai is where we go deepest, and it is the platform where the gap between a configuration that works and one that performs is widest. Almost everything that matters lives in the Property Manager rule tree: which behaviours are set on the default rule and inherited downwards, how match criteria are ordered, and where two rules overlap so that the later one quietly undoes the earlier. Configurations that have been edited by several teams over several years accumulate exactly this kind of damage, and it does not show up in a dashboard. We read the rule tree, explain what each branch is doing, and rewrite it as a structure someone can still reason about in two years.
On the delivery side that means caching behaviours and TTLs set per content type rather than globally, cache key design that ignores tracking parameters instead of fragmenting one object into thousands of variants, CP codes arranged so reporting attributes traffic to the team that generates it, Tiered Distribution to keep origin fetches down, SureRoute and prefetching for what cannot be cached, and purge driven through the CCU API by cache tag or CP code rather than by long lists of URLs. Where an object store fits the shape of the problem we use NetStorage as origin, and Image & Video Manager to stop the application from maintaining its own derivative pipeline.
Logic that does not belong in the origin application moves to the edge. EdgeWorkers with EdgeKV cover request rewriting, token validation, personalisation and API shaping close to the user. Cloudlets cover the cases that do not need code at all: Edge Redirector for bulk redirect maps that would otherwise sit in the application, Visitor Prioritization as a waiting room for sale events, Phased Release for gradual rollout, Input Validation at the perimeter.
Security uses the same stack rather than a bolted-on one: App & API Protector policy tuned against real traffic, including migrations from Kona Site Defender where that is still in place, Bot Manager and Client Reputation for automation, rate policies on the endpoints that actually cost money, Prolexic for network-layer volumetrics, and Site Shield with mutual TLS so the origin only ever answers Akamai. Certificates run through CPS on the Enhanced TLS network with expiry monitored independently of the platform.
None of this is worth much without evidence, so we wire DataStream 2 into your log pipeline and use mPulse to tie a configuration change to a real user metric rather than a synthetic one. Changes are activated on the staging network and tested there first, kept in Terraform or PAPI snippets in your repository, and promoted between environments as versioned code. Fast fallback exists for the case where we are wrong, and knowing it is there is what makes it reasonable to change anything at all.
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: 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. 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.
This site runs on Cloudflare Workers with cache rules written by hand for each asset class. We do not configure anything for clients that we have not put into our own production.
Security at the edge
The web application firewall always goes into observation mode first. 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.
Volumetric DDoS protection comes from the provider’s network capacity, but application-layer attacks need specific configuration: rate limiting on expensive or sensitive endpoints, managed challenges for suspicious automation, and rules built around behavioural patterns rather than signatures alone. We also configure origin shielding so backend servers accept connections only from the CDN network, via authenticated origin pulls, IP allowlists or Cloudflare Tunnel. 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.
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. These platforms have changed substantially, and a configuration untouched since 2020 typically uses less than half of what is now available, including capabilities that would cut both cost and latency.
Enterprise Akamai accounts are a particular case. The contract is signed, the properties are live, the products are being paid for, and the person who set it up has usually left. We are often brought in to answer a narrow version of that: why offload is stuck, whether the WAF can safely be enforced, what the account is paying for and not using, or how to bring Edge DNS and Global Traffic Management into the same failover plan as the rest of the estate. 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 through Workers. We have moved redirects, A/B allocation and authentication checks out of origin applications and into the edge, with a direct effect on response time and origin capacity requirements.
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. Typical results include a substantially lower time to first byte for users far from the origin region, reduced egress spend, and the removal of traffic-peak bottlenecks that previously required year-round over-provisioning.