What is the best way to simulate an attack for a Prolexic failover test?

I'm a cloud architect at a mid-market fintech processor, and we've run on Prolexic for our public-facing API endpoints for about three years, handling scheduled failover tests quarterly as part of our SOC 2 controls.

1. Sanctioned Traffic Generation vs. DIY Cloud VMs
Prolexic does not offer a public "attack simulation" service. In my last renewal negotiation, their solution architect explicitly stated they cannot generate attack traffic toward your own protected IPs. The only sanctioned method is to open a support ticket to schedule a "controlled diversion test," which is a manual process where they temporarily route your traffic through a scrubber and confirm the path. It does not simulate attack traffic. For a true simulation, you must generate traffic yourself. I use a distributed set of cloud VMs (AWS EC2 and Google Cloud Compute, spread across regions) running a custom Go tool to send a high volume of benign UDP packets to a specific test port we allow through our edge ACLs. The key is to target a non-essential service port you can monitor and to cap the total aggregate bandwidth below the committed rate in your Prolexic contract, which for us is 2 Gbps. Exceeding that can incur overage fees.

2. Avoiding Blacklists and Collateral Damage
Your concern about IP blacklisting is correct. We isolate the test to a single test subdomain (e.g., `test-prolexic.example.com`) that points to the same protected IP. The traffic-generating VMs must not be sourced from your own corporate or production cloud ranges. We use ephemeral, pay-as-you-go instances from three different providers, and we pre-configure the Prolexic portal to have an "Always Mitigated" policy for that specific test FQDN, ensuring all traffic to it goes directly to a scrubbing center. This prevents any traffic from hitting our origin during the test. We also notify Prolexic support 48 hours in advance with the source IP ranges and time window; they whitelist those IPs at the scrubbing center to prevent any scrubber-side throttling.

3. Key Metrics and Observability During Failover
Beyond basic latency and uptime, you need to measure the Time to Mitigation (TTM) and the DNS/route propagation consistency. We use a script from multiple global vantage points (like Catchpoint and ThousandEyes) to query the DNS record for our test subdomain and trace the route every 30 seconds. In our tests, the DNS change to the scrubbing center IPs typically propagates globally within 60-90 seconds, but we've seen outliers up to 180 seconds in certain regions. The critical metric is the break in TCP sessions: existing connections to your origin will drop. You must verify your application handles those drops gracefully. We also log the traffic volumes received at our origin (should be zero) versus the volumes reported in the Prolexic portal's analytics to confirm 100% of traffic was scrubbed.

4. The Real Cost and Operational Overhead
The financial risk isn't in the test traffic cost (about $15-20 in cloud compute per test) but in potential overages and professional services. If your simulated attack exceeds your committed rate, the overage fee can be substantial (our contract cites $0.05 per GB over commitment). if you do not properly scope and notify, Prolexic may treat the test as a real event and engage their SOC, which could lead to a professional services charge. Our quarterly test process, including planning, coordination, tooling, and validation, takes about 8-10 person-hours from our networking team.

Given your goal of a safe, controlled simulation, I recommend the DIY cloud VM approach targeting a specifically configured test subdomain, but only after you have confirmed your contract's committed rate and established a clear communication protocol with your Prolexic technical account manager. The deciding factors are your internal networking team's bandwidth to build the tooling and your comfort with the potential financial exposure if your traffic profile is misconfigured.

> I use a distributed set of cloud VMs ... running a custom Go tool

Nice, we did something similar but with a much jankier approach -- just a Python script using scapy to blast SYN packets at a sacrificial test subdomain. The Go tool sounds way more elegant.

One thing I'd throw in: make sure your test traffic doesn't accidentally look like a known attack signature. We had a false alarm once because our SYN flood matched a Mirai variant pattern in the Prolexic dashboard. The scrubber kicked in before we even hit our cap. That was actually a good stress test of their detection logic, but it scared the hell out of our ops team.

Did you have any issues with cloud providers flagging your VMs for outbound abuse? I had to pre-warm AWS support to avoid getting the instances throttled.

The safest method is using distributed cloud VMs, but you need to manage your source IPs. Prolexic won't blacklist you; your cloud provider might.

Use a sacrificial test subdomain. I run this from a few regions using a simple script. Keep the total bandwidth below your cloud provider's abuse threshold. Watch for your test pattern getting flagged by the scrubber's signature detection. That's a good sign it's working.

Besides latency, track your source IPs in the Prolexic dashboard to confirm traffic is being scrubbed. The route change is visible in the traffic flow graphs.

That's a great point about the sacrificial test subdomain - we set up a dedicated `test-attack.ourdomain.com` just for this. Makes cleanup and monitoring so much easier.

I'm curious about the bandwidth threshold though. How do you determine what's "below your cloud provider's abuse threshold"? Is that published somewhere, or do you just start very low and ramp up? I'd hate to get a nastygram from AWS because I guessed wrong.

The abuse thresholds aren't published because they're dynamic and based on your account age, spending, and the target's complaints. Starting low and ramping is the only sane method.

But that's the wrong focus. Your real problem is egress cost, not abuse. Generating even 5 Gbps of traffic from a dozen cloud VMs for a 10-minute test can burn hundreds of dollars. You need to bake that into your test budget, and use instance types with cheap bandwidth, not the general-purpose ones.

Exactly, a sacrificial subdomain is perfect for isolating the blast radius. On the cloud abuse threshold, you're right - nobody publishes that number. I've found the trigger is usually complaint-based, not raw throughput. The provider's SOC sees your traffic hitting a known DDoS-protected IP (Prolexic's scrubbing center), so it's unlikely to generate a complaint from the "victim". I've never been flagged during a test.

The bigger issue is your own cloud provider's internal network abuse detection. I once had a GCP project's outbound bandwidth throttled mid-test because the flood of SYN packets from a single VM tripped an anomaly detector. Now I spread the load thinner across more regions with stricter per-instance rate limits in my tool.

What's your test duration? Keeping it under 5 minutes seems to fly under the radar.