Our organization just concluded its annual, third-party penetration test and red team engagement. The scope included our entire external attack surface, and I'm writing to share a data point that might be useful for teams evaluating DDoS solutions, specifically Akamai Prolexic. The TL;DR is that the **volumetric and protocol attack mitigation was entirely transparent and effective**, but the exercise reinforced critical nuances about the shared responsibility model in cloud DDoS.
The testers, following an agreed-upon protocol, launched a series of application-layer attacks (which we handled with our WAF) and subsequently escalated to volumetric TCP-state exhaustion and UDP amplification attacks directly against our public IP space. Our Prolexic configuration is in "always-on" mode for our critical /24 netblock. From our internal monitoring and the final debrief, here's what we observed:
* **Zero traffic impact on origin:** Our internal traffic graphs (via Prometheus/Grafana, sampling at 5-second intervals) showed no deviation in legitimate request rate or latency during the volumetric phases. The mitigation was initiated at the edge, and the scrubbing centers performed as advertised.
* **Attack visibility was comprehensive, but delayed:** The Prolexic portal's attack analytics provided a clear post-event breakdown. However, the real-time alerting latency was approximately 90 seconds from attack onset to our PagerDuty integration. This is acceptable for automated mitigation but underscores the need for **supplemental, origin-based traffic anomaly detection** for rapid internal awareness.
* **Cost implications were nil:** A significant concern with always-on DDoS protection can be data transfer costs for scrubbed traffic. Since the attacks were filtered at the edge, our cloud provider's egress bills showed no spike. Prolexic's pricing model absorbed the volumetric load completely.
The critical takeaway, however, is what Prolexic does *not* do. The pen testers successfully identified and stressed several application logic flaws (e.g., expensive search queries, parameter manipulation). Prolexic was, correctly, entirely blind to these. This serves as a perfect case study for the separation of duties:
```yaml
# Conceptual Infrastructure Layers
1. Network/Volumetric (L3/L4): Prolexic Responsibility - ✅ Handled.
2. Protocol (e.g., SYN flood, Fragmentation): Prolexic Responsibility - ✅ Handled.
3. Application (L7): WAF & Application Logic - ❌ Prolexic is not a WAF.
```
In conclusion, if your primary threat model is network-flooding attacks aiming for downtime, Prolexic operates as a robust, set-and-forget system. It passed this real-world test under controlled conditions. However, teams must invest equally in:
* Rigorous application security testing.
* A capable WAF (we use a separate vendor).
* Internal observability to detect traffic anomalies that might slip through logic-based rules.
The annual test validated the infrastructure portion of our investment. The real work remains in the application layer.
-- alex