Opsphere
← All articles

Akamai: Trace WAF Blocks and Origin Errors Together

Akamai: Trace WAF Blocks and Origin Errors Together

Abstract edge and origin investigation structures

Akamai is a global content delivery network, cloud security, and edge computing provider that speeds up digital experiences, absorbs large traffic events, and enforces security controls close to the end user. For engineering teams, the practical payoff is lower latency, stronger availability during spikes or attacks, and edge-layer defenses that reduce load on origin infrastructure. The sections below cover how requests flow through Akamai’s edge network, and how teams pair that visibility with origin and observability data during an incident.

TL;DR:

  • A rollout requires a DNS CNAME to an edge hostname, Property Manager rules, a CPS certificate, and staging tests before production activation.
  • Akamai may cost more than bundled hyperscaler CDNs; choose it when origins span clouds, deeper security expertise, or stronger DDoS protection justify added configuration.
  • Akamai reporting shows edge errors but omits application logs, database and container health, and deployment history, so teams need observability data to diagnose causes.
  • Property Manager tracks versions and activations, but regulated teams still need to route WAF and property changes through existing approval and audit workflows.
Opsphere
opsphere.io
Connect Edge Signals to Incidents
Opsphere brings Akamai signals together with cloud, observability and engineering context to help teams investigate incidents from one interface.
Explore operational intelligence

Table of Contents

What Akamai is and who relies on it

Akamai operates as a combined CDN, cloud security, and distributed compute provider, positioning itself differently from pure-play CDNs by layering web application protection, DDoS mitigation, and API security directly onto its delivery network. That combination is what draws its typical buyer: enterprises running mission-critical digital experiences where downtime or a breach carries direct revenue and reputational risk.

The buyer profile tends to concentrate in a few patterns:

  • Retail and media companies with global audiences that need consistent page load times across regions.
  • Financial services and healthcare organizations with strict uptime and compliance requirements.
  • Enterprises facing frequent or large-scale DDoS and bot traffic that would otherwise strain origin servers.

Akamai’s scale backs up that positioning. Public filings describe a massively distributed global infrastructure and report full-year 2025 revenue of $4.208 billion, split across security, delivery, and cloud compute products. That revenue base is consistent with Akamai’s enterprise focus, though smaller teams may find the platform offers more capability and configuration than they need.

How Akamai routes and caches requests

Akamai’s delivery model starts with DNS. A domain is pointed, via CNAME, to an Akamai edge hostname, which routes end-user requests to a nearby edge server rather than directly to the origin. According to Akamai’s own Cloud Embed documentation, this CNAME-to-edge-hostname mapping is the mechanism that puts Akamai’s network between users and the origin infrastructure.

Once traffic lands on the edge, Property Manager governs behavior. A property combines a base configuration with a delivery policy: a set of rules that match incoming requests (by path, header, or other criteria) and apply caching, redirect, or security behaviors accordingly. The same Cloud Embed documentation describes Property Manager, run from Akamai Control Center, as the tool for setting both the base configuration and per-subcustomer delivery policies.

Caching follows a predictable sequence: the edge server checks for a cached copy matching the request, serves it if valid, and falls back to the origin when the cache misses or a cache-control directive requires revalidation. Typical cache-control patterns include short TTLs for dynamic API responses and long TTLs with versioned URLs for static assets.

HTTPS delivery runs through the Certificate Provisioning System (CPS), which issues and renews certificates tied to edge hostnames before a property goes live.

A typical rollout follows this sequence:

  1. Create the edge hostname and map the DNS CNAME.
  2. Build the property’s base configuration and delivery policy in Property Manager.
  3. Provision the TLS certificate through CPS.
  4. Define caching and security rules for the matched paths.
  5. Test in staging, then activate to production (Go-Live).

Pro Tip: Test property activations in the staging network before production Go-Live. A rule that matches too broadly can silently change caching or security behavior for paths you did not intend to touch.

Core services: delivery, security, and cloud infrastructure

Akamai’s product surface spans three areas that engineering teams interact with differently.

On the delivery side, CDN and edge compute capabilities cache content closer to users and reduce round-trip time, while absorbing traffic spikes before they reach origin servers. On the security side, a Web Application Firewall (WAF) inspects requests against configured rule sets, DDoS mitigation absorbs volumetric and protocol-level attacks at the edge, and API security applies schema and behavior-based checks to API traffic. Teams running these controls should expect alerts tied to specific rule matches or thresholds rather than generic blocked-traffic notices.

On the infrastructure side, Cloud Infrastructure Services extend Akamai’s footprint into compute and storage closer to the edge. Akamai’s fourth-quarter 2025 results report year-over-year revenue growth in both Guardicore Segmentation and API Security, and in Cloud Infrastructure Services, signaling continued investment in these categories rather than the delivery network alone.

Ownership of these capabilities usually splits by function:

  • SRE and platform teams typically own CDN configuration, caching rules, and origin health.
  • SecOps teams typically own WAF policy tuning, DDoS response, and API security rules.
  • Platform engineering typically owns Cloud Infrastructure Services provisioning and integration into deployment pipelines.

What to expect during evaluation and onboarding

Practitioner sentiment on Akamai is consistent across review platforms. Gartner Peer Insights and TrustRadius feedback indicates large enterprises favor Akamai for availability, resilience, and deep security expertise, while also noting it can cost more than hyperscaler-bundled CDN options. Practitioners describe that cost as justified when Akamai offloads significant traffic volume and backs it with expert incident support.

Configuration complexity shows up early. Property Manager’s rule-matching model and the breadth of security configuration options mean initial rollouts often benefit from engineers who have worked with Akamai before, or from Akamai’s own account and professional services during the first few properties.

Budget planning should account for:

  • Engineering time for property configuration, certificate provisioning, and hostname setup.
  • Testing cycles across staging and production networks before Go-Live.
  • Possible managed or professional services for complex security rule tuning.

Escalate to Akamai technical support or your account team when WAF false positives affect production traffic, when a property activation produces unexpected caching behavior, or when a DDoS event exceeds the scope of self-service mitigation controls.

How Opsphere connects Akamai signals to your incident workflow

Akamai’s edge network generates its own signals: WAF hits, property rule matches, edge hostname errors, DDoS mitigation events. None of those signals, on their own, tell you whether the problem originated at the edge or further back in your stack. That correlation work, matching an edge event to origin health, a recent deployment, or a backend dependency, is where we built Opsphere as the operational intelligence layer sitting alongside Akamai.

In practice, that means connecting Akamai edge data to the same investigation context as your infrastructure, observability, and deployment tools, without duplicating Akamai’s own telemetry. Specific workflows we support:

  • Identifying whether a spike in blocked requests traces to a legitimate WAF policy match or a misconfigured rule.
  • Correlating a WAF policy hit with a property configuration change made in the same window.
  • Tracing a rise in origin 5xx errors back to a specific route, origin pool, or recent infrastructure change.
  • Validating a fix by confirming edge behavior and origin health recovered together, not just one or the other.

Pro Tip: When a WAF rule starts blocking legitimate traffic, check the property’s recent rule changes before touching the WAF policy itself. The two are often connected.

The Opsphere Akamai integration brings these signals into the same investigation surface as your origin and observability data in read-only mode, so teams can correlate them without manually switching across dashboards.

Connecting Akamai to your DevOps and SRE toolchain

Akamai exposes its configuration and telemetry through APIs: the Property Manager API for managing delivery configurations, the Certificate Provisioning System API for certificate lifecycle management, and reporting and security APIs for pulling WAF and traffic data programmatically. These APIs let teams version property configurations alongside application code and manage changes through the same pull-request workflows used for infrastructure.

For teams running GitOps-style deployment, this typically looks like storing property configuration as code, running changes through CI/CD before activation, and gating production Go-Live behind the same approval steps used for other infrastructure changes. That approach reduces the risk of a property rule change going to production without review, a common source of the incidents described in the previous section.

Where Akamai’s native APIs fall short is in cross-system correlation: they return Akamai-specific data, not a unified view that includes your origin servers, Kubernetes clusters, or CI/CD history. Closing that gap requires pulling Akamai’s API and reporting data into an operational context that also includes infrastructure and deployment history, which is the specific function our platform performs through read-only integrations rather than replacing Akamai’s own management APIs.

Teams evaluating integration work should map which Akamai APIs they need (configuration management, security reporting, or both) against their existing CI/CD and observability stack before building custom tooling, since the native APIs are stable but require deliberate work to connect to the rest of the toolchain.

Connecting Akamai to your DevOps and SRE toolchain — overview diagram

Running Akamai across multi-cloud and hybrid environments

Akamai sits in front of origin infrastructure regardless of where that infrastructure lives, which makes it common in multi-cloud and hybrid setups where origins span AWS, Google Cloud Platform, Azure, and on-premises data centers. The edge network abstracts the complexity of routing users to the right origin pool, which matters when different workloads or regions are served from different clouds.

A few patterns show up repeatedly in hybrid and multi-cloud deployments:

  • Using Akamai property rules to route traffic to different origins based on path or geography, rather than managing that logic in application code.
  • Standardizing WAF and DDoS policies at the edge so security posture stays consistent across clouds with different native security tooling.
  • Using Akamai as a single TLS termination and certificate management point across origins that would otherwise require separate certificate lifecycles per cloud.

The trade-off is that Akamai’s configuration becomes a shared dependency across teams owning different origins. A property rule change intended for one origin pool can affect traffic routed to another if path matching is too broad, which is why testing in staging before Go-Live matters more in multi-cloud setups than in single-origin deployments. Teams running this pattern benefit from visibility that spans both the edge configuration and the health of every origin behind it, since a routing change and an origin incident can look identical from the edge alone.

What Akamai’s monitoring tools show, and what they don’t

Akamai’s native reporting covers edge-side metrics: cache hit ratios, traffic volume by property, WAF rule matches, DDoS mitigation events, and origin response codes as observed at the edge. This data answers questions about what the edge network saw and how it responded, which is the right starting point for understanding delivery and security performance.

What edge-side reporting does not cover is the state of your origin infrastructure itself: application logs, database performance, container health, or deployment history. A spike in origin 5xx errors visible in Akamai’s reporting tells you something is wrong behind the edge, but not what changed or why. Closing that gap means pairing Akamai’s edge reporting with observability tools that cover origin infrastructure, and with a layer that can correlate the two in a single investigation rather than requiring an engineer to manually cross-reference timestamps across separate dashboards.

Edge signals correlated with origin context

This is the specific operational gap we built Opsphere to address: taking Akamai’s edge-side signals, WAF events, cache behavior, origin error rates as seen at the edge, and connecting them to the origin, infrastructure, and deployment context that explains why those signals changed. For teams already running observability stacks for their origin infrastructure, the value is in the correlation, not in replacing either system.

Security governance and compliance considerations

Enterprise security teams evaluating Akamai typically look at how its controls map to governance requirements rather than at individual features in isolation. WAF rule sets, API security policies, and DDoS mitigation configurations all need audit trails showing who changed what and when, since a misconfigured rule can affect production traffic as easily as a legitimate attack can.

Property Manager’s versioning and activation workflow provides that audit trail at the configuration level: every property version and activation is tracked, which supports change management requirements common in regulated industries. Certificate lifecycle management through CPS similarly gives security teams visibility into certificate expiration and renewal status across every edge hostname, reducing the risk of an expired certificate causing an outage.

For organizations with formal compliance obligations, the relevant governance question is usually less about whether Akamai’s controls exist and more about how they integrate with existing change management, incident response, and audit processes. A WAF rule change made directly in Akamai’s console, outside a tracked change management workflow, creates the same governance gap as an untracked infrastructure change anywhere else in the stack. Teams running Akamai in regulated environments generally extend their existing change approval and audit processes to cover property and security rule changes rather than treating Akamai’s configuration as a separate system exempt from those controls.

Akamai versus alternative approaches, from a platform engineering view

From a DevOps and platform engineering perspective, the choice usually isn’t Akamai versus a single alternative, it’s Akamai’s combined delivery-and-security model versus assembling equivalent capability from a hyperscaler’s native CDN, a separate WAF product, and a separate DDoS mitigation service.

Hyperscaler-bundled CDNs (native to AWS, Google Cloud Platform, or Azure) integrate tightly with that provider’s own infrastructure and billing, which simplifies operations for teams already committed to a single cloud. The trade-off, per practitioner feedback, is that Akamai is generally chosen specifically for cases where multi-cloud origin support, deeper security expertise, or higher-scale DDoS mitigation outweigh the convenience of a single-vendor bundle.

For platform teams, the practical decision criteria are: whether origins span multiple clouds (favoring Akamai’s cloud-agnostic edge), whether security requirements justify a dedicated WAF and DDoS mitigation provider versus a cloud-native bundle, and whether the team has the engineering capacity to manage Property Manager’s configuration model versus a more constrained, simpler native CDN console.

Neither path eliminates the need for cross-system investigation. Whichever CDN and security stack a team runs, correlating edge events with origin and infrastructure state remains a separate problem, and one that doesn’t go away based on which vendor sits at the edge.

Opsphere for Akamai incident workflows

We built Opsphere to give platform, SRE, and security teams a single place to correlate Akamai’s edge signals (WAF events, property rule changes, cache and origin error data) with origin infrastructure, deployment history, and observability context, without replacing Akamai’s own configuration or security tooling. A demo can walk through connecting your Akamai account alongside your existing cloud and observability integrations, using read-only access throughout.

Opsphere

To see how the Opsphere Akamai integration fits your current stack, check our pricing plans, including a Developer tier at 19 € per month and a free Community tier, or start from the platform overview.

FAQ

What is Akamai used for?

Akamai is used to deliver web and application content faster through its global edge network, while protecting that traffic with web application firewall rules, DDoS mitigation, and API security controls. Enterprises also use its Cloud Infrastructure Services for compute and storage closer to end users.

What is Akamai Technologies’ revenue?

Akamai reported full-year 2025 revenue of $4.208 billion in its public filings. Its fourth-quarter 2025 results also noted year-over-year growth in Guardicore Segmentation, API Security, and Cloud Infrastructure Services.

Where are Akamai servers located?

Akamai operates a massively distributed global edge network, with servers positioned close to end users across many regions and countries to reduce latency. The exact server count and specific locations are not published in detail in the sources reviewed for this article.

What is the difference between Akamai and AWS?

Akamai is a CDN, security, and edge compute provider that works across any origin infrastructure, including AWS, Google Cloud Platform, Azure, and on-premises data centers. AWS is a hyperscaler offering its own native CDN and security services that integrate tightly with AWS-hosted origins but are not designed to front origins hosted on other clouds.

How complex is it to configure Akamai for a new application?

Configuration complexity depends on how many properties, security rules, and origins are involved, but most teams work through edge hostname setup, Property Manager configuration, and certificate provisioning before a Go-Live. Practitioner feedback indicates larger enterprises often rely on experienced engineers or Akamai’s account services for initial rollouts given the platform’s configuration depth.

Sources

OOpsphere
Discuss Your Akamai Incident Workflow
Contact Opsphere to discuss how its operational intelligence platform connects Akamai signals with cloud and observability context.

This article is provided for general informational purposes only and does not constitute professional, legal, security, or compliance advice. Please evaluate recommendations against your organization’s specific environment and requirements.