--- title: "CDN Management, Optimization and Security" description: "Akamai specialists: Property Manager rule trees, EdgeWorkers, Cloudlets, App & API Protector tuning and Site Shield. Cloudflare and Fastly as well." url: "https://nixit.io/services/cdn-management/" lang: "en" --- # CDN Management, Optimization and Security We tune CDN platforms for higher cache hit ratios, effective WAF policy and lower cost, with deep specialisation in Akamai. 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. ## What you get - Property Manager rule tree reviewed and rewritten, with the change explained rule by rule - Every change activated and validated on the Akamai staging network before it reaches production - Property configuration held as Terraform or PAPI snippets in your repository, versioned like code - Documented cache strategy with explicit rules per content type and cache key design - Cache hit ratio measured before and after, with the resulting egress cost impact - WAF rules tuned against your real traffic, with false positives eliminated before enforcement - Origin cloaking so backend servers accept traffic only from the CDN ## Technologies Akamai Ion, Akamai Property Manager, Akamai EdgeWorkers, Akamai Cloudlets, App & API Protector, Akamai Bot Manager, Prolexic, Site Shield, Akamai Edge DNS, Global Traffic Management, DataStream 2, mPulse, NetStorage, Cloudflare, Cloudflare Workers, Fastly, Terraform ## Frequently asked questions ### How deep does your Akamai experience actually go? Deep enough to work in the rule tree rather than around it. That means Property Manager behaviours and criteria, cache key and CP code design, Tiered Distribution, SureRoute, purge through the CCU API by cache tag rather than by URL, EdgeWorkers and EdgeKV for logic at the edge, Cloudlets for redirects and visitor prioritisation, App & API Protector and Bot Manager policy, Site Shield for origin cloaking, and DataStream 2 feeding a log pipeline. It also means migrations off Kona Site Defender and property configuration managed through PAPI and the Terraform provider instead of by hand in Control Center. ### Should we move off Akamai to something cheaper? Often not, and we will say so. Contract commitments, media delivery requirements and a mature bot policy are all reasons the platform is worth keeping. In most cases the money is recovered by fixing what is already there: a rule tree that fragments the cache, offload sitting well below what the traffic allows, and products paid for but never configured. We look at that before proposing a migration, and if a move genuinely makes sense we plan it with the contract renewal date rather than against it. ### How much can correct cache configuration reduce bandwidth cost? On sites that have never been tuned, moving cache hit ratio from around 40 or 50 percent to above 90 percent is routine. Origin egress falls proportionally and origin servers can often be sized down as well. For high-traffic sites the monthly saving frequently exceeds the cost of the engagement itself. ### Why is our dynamic content not cached? Usually it can be, but it requires deliberate rules. Per-user personalised pages cannot be held in a shared cache, but API responses identical for all users, product listings and page fragments can be cached for short periods. At high request volumes the difference between zero and thirty seconds of caching is enormous. ### Will a WAF block legitimate users? It will if rules are switched straight into blocking mode without observation. We always start in log-only mode, analyse what would have been blocked against your actual traffic, remove the false positives, and only then enforce, category by category rather than all at once. ### Do you have production experience with Cloudflare or only theory? The site you are reading runs on Cloudflare Workers with hand-written cache rules for each asset class and separate policies for HTML documents and fingerprinted static files. We run in production what we configure for clients, which is a reasonable minimum standard to ask of any provider.