I've spent three years in DDoS work, and one thing keeps surprising me: how differently each cloud behaves the moment you try to automate it at scale. We run DDactic across 23+ cloud providers now, and what started as "just add another integration" turned into debugging metadata IP collisions, GCP's silent instance deletion, Scaleway's broken cloud-init on snapshots, and the Great Firewall blocking our C2 servers in mainland China.
ddactic.net?ref=mastodon
I spent the last 60 days shipping 363,000 lines of code across 8 programming languages and 23+ cloud platforms. One person. One AI coding assistant. No venture capital. The honest version of this story isn't about the code count. It's about where AI actually helps and where it completely falls apart.
ddactic.net?ref=mastodon
A few weeks ago I wrote that no WAF inspects gRPC payloads, enforces per-method rate limits, or distinguishes legitimate streams from attack traffic.
ddactic.net?ref=mastodon
A scrubbing center is not a guarantee. It's a routing decision, and most CISOs blur three different things into one.
Scrubbing center, in the strict sense: your origin IPs stay publicly announced, but the BGP path routes through a scrubbing provider's network. Akamai Prolexic Routed, Cloudflare Magic Transit, Lumen DDoS Mitigation, AT&T DDoS Defense. The provider cleans L3/L4 volumetric upstream and forwards via GRE/IPSec to your origin.
Three modes:
- Always-on: BGP announcement is permanent. Every packet through the scrubbing ASN. Strongest posture, most expensive, you pay clean-bandwidth too.
- On-demand: announcement flips only during an attack, via flow analysis or manual escalation. Fine if you can tolerate the diversion delay. Short bursts end before mitigation arrives.
- On-prem appliance (Radware DefensePro, Netscout Arbor TMS, A10 Thunder TPS): hardware at your ISP uplink. Strong against volumetric L3/L4, until the uplink itself saturates and the box never sees the traffic.
A separate category is inherited L3/L4 protection baked into fully-managed components. Cloudflare CDN absorbs volumetric at every PoP. AWS CloudFront includes Shield Standard at the edge. Akamai App & API Protector, Fastly, Imperva front your DNS via CNAME and absorb L3/L4 + L7 at the edge. But "managed" isn't a uniform label. CloudFront is edge-distributed and handles terabit floods. AWS API Gateway and ALB are also managed and also get Shield Standard, but they're regional, not edge-distributed, with a much lower L3/L4 ceiling. Same vendor, three different inherited postures.
Common DDactic finding: edge-distributed managed component on the marketing .com, regional managed components quietly carrying the API surface, origin IPs publicly resolvable elsewhere, no BGP scrubbing in path. The "scrubbing center" the CISO described in the meeting only protects the front door.
What our recon detects per asset:
- Origin IP announced by a scrubbing ASN (Prolexic, Magic Transit, Lumen, AT&T): true BGP scrubbing confirmed, always-on
- Cloud-proxy or edge-distributed managed component in CNAME chain (Cloudflare, Akamai, Fastly, Imperva, Gcore, F5, CloudFront): vendor and edge presence flagged, inherited L3/L4 confirmed
- Regional managed components (API Gateway, ALB, App Service): vendor flagged, inherited L3/L4 limited to regional capacity
- Hyperscaler dedicated protection (AWS Shield Advanced, GCP Cloud Armor, Azure DDoS Standard): not externally visible, customer-side config check required
- On-prem appliances behind the ISP uplink: invisible to passive recon
The harder conversation isn't "do you have protection." It's "which layer, which mode, on which assets, validated when."
Hot take: "I built this with AI" is usually the wrong message.
ddactic.net?ref=mastodon
Every TLS certificate you've ever issued is public.
ddactic.net?ref=mastodon
