Cloud & Edge
Edge security and CDN on Cloudflare and Akamai.
We review, design, and migrate edge platforms on Cloudflare and Akamai: DNS, TLS, caching, WAF, bot, and API protection, with a rollback path for each change. Our engineers have led staged DNS, SSL, WAF, and bot migrations covering hundreds of domains, and the result is an edge your team can understand, change safely, and reason about from code.
Platforms
Who this is for
Platform, web, and operations teams that run many domains, zones, or properties and feel the edge configuration has outgrown anyone’s memory. Typical starting points: a migration between CDN providers or onto Cloudflare, an account inherited after a reorganization, legitimate users caught by security rules, sporadic 5xx errors, or assets that never seem to cache. If you run Akamai and Cloudflare side by side, or are moving between them, the transition and the period when both platforms carry traffic are planned together.
Your edge has grown. Has your architecture kept up?
Most edge configurations are not badly built. They are built in layers: a rule added during an incident, a setting copied from an old zone or property, an API token created for a script nobody runs any more. Individual rules can look right while the overall system becomes hard to operate.
Large migrations rarely fail on the technology. They fail on the record nobody knew about, the origin firewall that still blocks the new edge, or a rollback that waits on nameserver caches. We connect DNS, TLS, caching, application security, and origin behavior into one architecture that your team can own.
What you get
01
An edge configuration review. On Cloudflare, configuration is pulled through the API, so every zone is checked the same way; Akamai properties and security configurations are reviewed against the same areas. Findings are ranked by severity and effort, and the report leads with the few that are both high-impact and cheap to fix.
02
Baselines in code. TLS, WAF, bot, API, and cache settings captured in Terraform. Existing Cloudflare configuration is imported with cf-terraforming, so nothing changes by surprise and the account stays consistent after the engagement.
03
Staged migrations. DNS, SSL, WAF, and bot migrations in waves, with validation steps and a written rollback for each wave.
04
Origin hardening. Real client IPs restored and trusted only from Cloudflare’s published ranges; origins reachable only through Cloudflare (an allow-list, Authenticated Origin Pulls, or Cloudflare Tunnel); timeouts checked against Cloudflare’s documented limits; and cache headers the edge can trust.
05
Reporting. After each wave, a report per zone built from Cloudflare’s GraphQL Analytics API: edge and origin status codes, cache hit ratio for cacheable paths, and security events by rule.
06
Runbooks and a handover session, so the next change does not depend on remembering what was done.
How it works
The work follows the four-stage delivery model. Each stage ends with a written acceptance check and a way back.
Architecture
Every zone and record is exported and classified: web, API, mail, verification, or unknown. Unknown is a blocker, not a footnote. We list which origins allow-list client IPs, rate-limit by source IP, or log client addresses, because all of them will start seeing Cloudflare addresses. Mail hosts stay DNS-only. If DNSSEC is enabled at the registrar, it is handled before the nameserver change, and existing CAA records must allow the certificate authorities Cloudflare uses.
Onboarding
One baseline is built once and applied everywhere: SSL/TLS mode Full (strict) with a valid origin certificate, consistent minimum TLS and HTTPS settings, cache rules for static paths with the origin’s
Cache-Controlas the contract, and the managed WAF rulesets every zone inherits. HSTS is held back until every hostname serves HTTPS and the rollback window has closed: Cloudflare warns that a site can become unreachable for the wholemax-ageperiod if HTTPS goes away while HSTS is active.Migration
DNS first, proxy second. Lower TTLs ahead of time, import the zone with every record set to DNS-only (proxying is on by default during onboarding) so resolution is identical to before, change nameservers, wait for the zone to go active and for edge certificates to issue, open origin firewalls to Cloudflare’s published ranges, and only then switch records to proxied, in waves. Once a zone is on Cloudflare, rolling a hostname back is one toggle from proxied to DNS-only. Reversing a nameserver change waits on the registry and on resolvers’ cached delegation, which you do not control.
Support
New WAF and bot rules start in observe mode where the plan includes a log action, and otherwise go live on a low-risk subset first. Real events are reviewed, exceptions are written for legitimate traffic such as payment callbacks, partner integrations, and monitoring, and only then do rules challenge or block. After launch, rules are tuned from evidence and the runbooks stay current.
Limits
Zero downtime is the design goal, not a guarantee. Some features depend on the Cloudflare plan: for example, Cloudflare documents the Log action for WAF custom rules as an Enterprise feature, so availability is checked before a design relies on it. On a full setup, Universal SSL covers the root domain and first-level subdomains; deeper hostnames need another certificate type, and partial (CNAME) setups behave differently. Each of these is checked per hostname in the inventory. The same rule applies on Akamai: product and contract entitlements are confirmed before a design depends on them.
Questions
What does a Cloudflare account audit cover?
Six areas: TLS and edge, DNS exposure, application security, performance, Zero Trust, and account governance. Configuration is collected through the API, and each finding gets a severity and an effort estimate, so the first fixes are the few that are high-impact and cheap. Changes then ship in phases, starting in observe mode where the plan allows it.
How do you migrate hundreds of domains without downtime?
Our engineers have led staged migrations covering hundreds of domains. The method moves DNS and traffic as separate steps, groups domains by risk into waves, and gates each wave on written criteria. Once a zone is active, a hostname rolls back with one toggle. Downtime is designed out wave by wave; it is not promised.
Can you move us between Akamai and Cloudflare?
Yes, in either direction. The work starts from an inventory of your hostnames, rules, and origins rather than a feature checklist. Each configuration is mapped to its equivalent on the target platform, and anything without a direct equivalent is flagged early. Hostnames then move in waves, so both platforms carry traffic during the transition and each wave has a rollback.
Why are my assets not cached?
Most cases trace to the origin. By default, Cloudflare does not cache a response that sets a cookie, and Cache-Control values such as private or no-store prevent caching. Query strings, including tracking parameters, are part of the default cache key and can fragment it. Origin headers, cookies, and cache keys are checked before any edge rule changes.
Why do I see sporadic 520 or 524 errors?
A 524 means Cloudflare connected to the origin, but the origin did not send an HTTP response before Cloudflare’s proxy read timeout, 125 seconds by default. Long work belongs in a background job. A 520 means the origin returned an empty, unknown, or unexpected response. The pattern of errors over time usually points at the origin-side fix.
What access do you need?
For an audit, read-only API access to the zones or properties in scope, a list of owners per domain, and your change calendar. Where a later task needs write access, it is scoped to that task and agreed with you in advance. Every token used is listed in the handover document, so you can review it and revoke it.