You did not build one system with a weak spot. You built two strong systems and left an attacker the wire between them.
That is the awkward truth of hybrid infrastructure. The cloud leg is fronted by a global anycast edge that eats volumetric traffic before your configuration is consulted. The on-premise leg is a defensive chain you assembled yourself: transit headroom, a scrubbing relationship, stateful devices at the boundary. Each leg, tested alone, can look healthy. Neither test tells you anything about the part that makes it hybrid.
Because the thing that makes it hybrid is not the two environments. It is the coupling between them. The interconnect that carries east-west traffic. The DNS or global load balancer that decides which leg a user lands on. The failover logic that shifts load from one to the other when something goes wrong. Those seams are where a hybrid estate actually fails under attack, and they are exactly the parts that a single-environment test, by construction, cannot exercise.
So a hybrid-cloud DDoS test is not two tests stapled together. It is a test of the connective tissue, which is the one attack surface neither leg owns and neither leg's test reaches.
What hybrid-cloud DDoS testing validates
Hybrid-cloud DDoS testing is the practice of verifying that an application spanning both cloud and on-premise infrastructure stays available under attack, with the focus on the seams that join the two: the private interconnect, the traffic-steering layer that routes users between legs, and the failover paths that move load from one environment to the other. It measures whether protection is symmetric across both legs, whether the link between them survives, and whether a failure in one environment stays contained instead of cascading into the other.
It is a spoke of a complete DDoS testing methodology, and it sits on top of the single-environment spokes rather than replacing them. You still test each leg on its own terms: the cloud leg the way you would test AWS, Azure, or GCP, and the on-premise leg the way you would test any self-hosted estate. This post is about what those tests leave out: the behavior that only exists because the two are wired together.
The distinction worth holding onto is between a leg and a seam.
| A leg | A seam | |
|---|---|---|
| What it is | One environment: the cloud VPC, or the on-premise data center | The connective tissue: interconnect, DNS/GSLB steering, failover path |
| Who tests it | The single-environment spokes (AWS, Azure, GCP, on-premise) | Only a hybrid test, because a seam needs both legs present to exist |
| The failure | That leg saturates or its controls misfire | Load crosses between legs in a way neither leg was provisioned for |
| What the test validates | Capacity, control enforcement, origin reachability on that leg | Symmetric protection, interconnect survival, contained failover, steering integrity |
Get that split straight and the discipline follows. Test only the legs, and you will certify two healthy environments and miss the coupling that takes both of them down together.
Why the seam is the target
There is a general principle underneath this, the same one that drives multi-vector testing: defenses are validated in isolation but deployed in composition. A hybrid estate is that principle made physical. Two environments, each provisioned and defended against its own expected load, joined by links that were sized for steady-state east-west traffic and a DNS layer that was configured for convenience, not for adversarial pressure.
An attacker does not care that each leg passed its own test. An attacker looks for the cheapest path to denial, and in a hybrid estate the cheapest path is almost never the middle of a well-defended leg. It is the seam, for three reasons.
The seam is provisioned for the wrong load. The interconnect was sized for backups and replication, not for the redirected flood that arrives when the cloud edge sheds traffic toward the origin.
The seam is asymmetrically defended. One leg has a managed scrubbing edge; the other does not. Same application, same name, two front doors, and only one of them is locked.
The seam is a control loop the attacker can drive. Failover and health-checked steering are automation that moves load in response to observed conditions. Anything that moves load in response to conditions is something an attacker can aim, if they can influence the conditions.
None of this shows up when you test a leg. It only shows up when both legs are present and the traffic is allowed to cross between them, which is the definition of a hybrid test.
The interconnect: a finite pipe you forgot was finite
Start where hybrid estates fail first: the link between the two legs.
A site-to-site VPN, an AWS Direct Connect virtual interface, an Azure ExpressRoute circuit, a leased cross-connect: whatever joins your legs, it is a finite resource, and it is finite in a way that is easy to under-count. The headline number is bandwidth, and bandwidth is usually the least of it. The real ceiling is state and packets per second.
A VPN concentrator has a crypto throughput limit and a tunnel-count limit that both sit well below the raw link speed. An ExpressRoute or Direct Connect endpoint terminates on gateways with their own packet-per-second and flow-count budgets. And on the far side of any of these, the first thing the traffic meets is usually a stateful firewall whose connection table fills long before the pipe does. This is the same connection-table exhaustion that makes a stateful device the layer of first failure on any perimeter, except here it governs the one link that both environments depend on to function as a single system.
The dangerous property is that the interconnect is a shared dependency. When it saturates, it does not take down one service. It severs the east-west path that stateful sessions, replication, authentication callbacks, and internal APIs all ride. A volumetric flood that never touches your public front end at all, aimed instead at the internal-facing side of the link or simply large enough to fill it, can leave both legs running and unable to talk to each other. Each environment's own dashboards look healthy. The application is down anyway, because half of it is on the other side of a wall.
Testing the interconnect means measuring its throughput ceiling in the units that actually bind, packets per second and concurrent flows, not the marketing bandwidth, and confirming what happens to cross-leg traffic when that ceiling is reached. Does the link degrade gracefully, shedding low-priority replication first, or does it collapse and take interactive sessions with it? Is there any protection on the private link at all, or was it assumed safe because it is private?
Asymmetric protection: the attacker picks the weaker leg
Here is the finding that most often turns a hybrid estate's careful architecture against it.
Your application answers to one name. That name resolves, depending on the day and the steering policy, to a cloud front end behind a managed DDoS edge, or to an on-premise front end behind whatever you built. If those two front doors are not defended to the same standard, the attacker does not have to beat the strong one. They resolve the name, observe which leg they land on, and if it is the hard one, they force their way to the soft one.
Forcing the soft one is often trivial. A DNS-only record that exposes the origin address, a geographic steering policy that hands certain regions straight to the on-premise leg, a failover rule that can be tripped, any of these lets an attacker select the target. The managed cloud edge, with its anycast absorption and its scrubbing, is not bypassed by defeating it. It is bypassed by addressing the other leg, which was never behind it.
The chart is illustrative and the numbers are invented; the shape is the point. Both curves belong to the same application. The cloud leg sheds load at its edge and stays flat; the on-premise leg, with no managed absorption in front of it, takes the flood in proportion to the offered rate and passes its own capacity while the protected leg is still comfortable. The application's resilience is not the average of the two legs. It is the weaker one, because the attacker gets to choose.
The test that surfaces this is deceptively simple: from an external position, enumerate every path to the application and confirm each one lands behind equivalent protection. Not "is there a DDoS edge," but "is there a DDoS edge in front of every front door, in the same enforcement mode." The asymmetry is almost never intentional. It is the residue of building the two legs at different times, by different teams, to different standards, and never testing them as one target.
Failover that becomes a cascade
The most valuable thing hybrid architecture is supposed to buy you is failover. If one leg is in trouble, health checks notice and traffic shifts to the other. Under a DDoS, that mechanism can turn from a safety net into an accelerant.
Consider the sequence. The on-premise leg comes under attack and its front end starts failing health checks. The steering layer does exactly what it was told to do: it withdraws the on-premise leg and points the name at the cloud leg. Now two things happen at once, and neither is in the runbook.
First, the legitimate load that was on the on-premise leg piles onto the cloud leg, which was provisioned for its own share, not the sum. Second, and this is the part that makes it a cascade, the attack follows. The adversary is resolving the same name you just re-pointed. When the record flips to the cloud leg, the flood flips with it, because the attacker's traffic is steered by the identical DNS you use to steer everyone else. Your failover mechanism has become a targeting oracle: it tells the attacker where you just moved the workload, and it moves the workload there for them.
If the cloud leg's edge is strong enough to absorb the relocated flood, the cascade stops there and failover did its job. If it is not, or if the failover path itself, a secondary load balancer, a backup interconnect, a cold-standby cluster, was never sized or defended for real attack conditions, the second leg follows the first. You have now converted a single-leg outage into a whole-application outage, using your own resilience feature as the delivery mechanism.
Testing failover under attack means triggering it deliberately, while the attack is running, and watching where the traffic goes. Does the surviving leg have the headroom for combined legitimate load plus a relocated flood? Does the flood actually relocate, confirming the steering is attacker-observable? Is the failover path itself, the standby capacity and the link to it, defended to the same standard as the primary, or is it a quiet single point of failure that has never carried real load? A failover you have never exercised under adversarial conditions is a hypothesis, not a control.
Traffic steering: the seam that routes the other seams
Underneath the asymmetry problem and the cascade problem sits one shared mechanism: the layer that decides which leg a user reaches. In a hybrid estate that is usually DNS, often with a global server load balancer or health-checked routing policy on top, and it is both the coordination point for everything above and a target in its own right.
As a target, it is the subject of DNS DDoS testing: if resolution for your name fails, both legs become unreachable at once regardless of how healthy they are, because nobody can find either one. Hybrid raises the stakes, because the steering layer is not just resolving a name, it is the arbiter of your failover. Degrade it and you have not just an availability problem, you have lost the ability to move load away from a leg under attack. The one control you most need during an incident is the one an attacker has reason to hit first.
As a control loop, steering is only as trustworthy as its inputs. Health checks that probe a shallow endpoint, a static page that stays up while the real application is failing, will report a leg as healthy through an attack and never trigger the failover you are counting on. Health checks that probe too deep, or with too tight a timeout, will flap under load and trigger failover you did not want, oscillating traffic between legs and amplifying the damage. Testing steering means testing what its health checks actually measure under attack, and whether the routing decisions they drive are ones you would make on purpose.
Designing a hybrid test
Authorization spans two owners, and the boundary between them
A hybrid test inherits the authorization burden of both legs and adds the seam. The cloud leg is governed by the provider's simulated-attack policy, the same structural gate described for AWS, Azure, and GCP: notification or approval above defined intensity thresholds, which change and which you confirm against current published policy rather than assume. The on-premise leg has no platform gate but does have a carrier and possibly a scrubbing provider whose own auto-mitigation can act on your test traffic.
The interconnect is the part that belongs to neither and both. A cross-region link and a provider-managed circuit may traverse infrastructure with its own acceptable-use terms; generating flood-shaped traffic across it can trip protections you did not know were in the path. Map who owns each segment of every seam before you generate a single packet across it. Owner authorization on both ends is mandatory regardless.
Scope the blast radius across the coupling
Everything in running a test without disrupting production applies here, with one hybrid-specific hazard: the coupling means a test aimed at one leg can escape into the other. Saturate the interconnect and you have affected replication and internal APIs for the whole estate, not the one service under test. Trigger a real failover during a test and you have moved production traffic onto standby capacity mid-experiment. Define the blast radius in terms of the seams, not just the legs, and decide in advance whether failover is in scope (you want to test it) or out of scope (you pin routing so the test cannot trip it).
Model the cross-leg traffic, not just the front-door flood
A hybrid test that only fires at the public front end misses the interconnect and the east-west failure modes entirely. The realistic model includes the internal traffic the seams carry, replication, session state, service-to-service calls, so that when a seam degrades you can see which internal dependency fails first and what it takes down with it. The front-door flood is half the test. The other half is what happens to the traffic that was supposed to cross between legs while that flood is running.
What to measure
Which seam fails first, and what it severs
The single most useful output of a hybrid test is the ordering: under combined pressure, does the interconnect saturate before either front end, does a stateful device at the boundary exhaust first, does the steering layer flap before anything else breaks? Each seam that fails severs a different set of dependencies, and knowing the order tells you where the leverage is. A datasheet will never tell you which of your seams is the long pole.
Whether protection is symmetric, expressed as the gap
For every external path to the application, the metric is not a single ceiling but the difference between legs: how much offered load each front door absorbs before the origin behind it feels it. The gap between the strong leg and the weak one is the number that matters, because the attacker operates at the weak leg's ceiling, not the average.
Whether failover contained or cascaded
Run the failover under attack and record the binary outcome plus the margin: did the surviving leg hold, and by how much headroom, or did it follow the first leg down? Capture whether the attack relocated with the steering change, because that confirms the failover is attacker-observable and reframes it from a pure safety feature into a lever the adversary can also pull.
Frequently asked questions
How is hybrid-cloud DDoS testing different from testing each environment separately?
Testing each environment separately validates the legs; hybrid testing validates the seams between them. A cloud test and an on-premise test can both pass while the interconnect that joins them saturates, the protection between them is asymmetric, or a failover cascades one leg's outage into the other. Those failure modes only exist when both legs are present and traffic is allowed to cross, which is precisely what a single-environment test excludes.
What is the most common hybrid-specific finding?
Asymmetric protection. The application answers to one name that resolves to two front doors, one behind a managed DDoS edge and one not, and the attacker simply addresses the weaker one. The strong edge is not defeated; it is bypassed by targeting the leg that was never behind it. The fix is to confirm every path to the application lands behind equivalent protection in the same enforcement mode.
Can failover make a DDoS worse?
It can. When a leg under attack fails its health check, steering shifts the shared name to the other leg, and the attack, resolving that same name, follows the change onto the surviving leg along with the first leg's legitimate load. If the second leg cannot absorb the combined traffic, or the failover path itself was never defended for attack conditions, a single-leg outage becomes a whole-application one. Failover has to be tested under attack, not just in a calm drill.
Is the private interconnect really an attack surface if it is not public?
Yes, in two ways. It is a finite, stateful resource whose real ceiling is packets per second and connection state, well below its rated bandwidth, so it can be saturated by cross-leg or internal-facing traffic. And when it fills, it severs the east-west path both legs depend on, taking the application down while each environment's own monitoring still reports healthy. Private does not mean unbounded, and it does not mean unreachable.
Does a hybrid test replace the single-environment tests?
No. It sits on top of them. You still test each leg on its own terms for capacity, control enforcement, and origin reachability. The hybrid test adds the layer none of those reach: symmetric protection across legs, interconnect survival, contained failover, and steering integrity. Skip the leg tests and you have gaps inside each environment; skip the hybrid test and you have gaps in the coupling that only appears when they run as one system.
The wire between them
Every other environment in a DDoS testing program is about a single place: how much a cloud leg or an on-premise estate can absorb before it bends. Hybrid is about two places and the space between them, and the space between them is the part no single test was ever pointed at.
The durable output of a hybrid test is not a throughput number for either leg, which drifts with every capacity change on either side. It is a map of the coupling: where the interconnect's real ceiling sits and what it severs when it is reached, which of your two front doors is the weaker one and by how much, whether your failover contains an outage or relocates it, and what your steering layer actually measures before it moves production traffic. That map is what you still understand a year from now, after both legs have been re-sized twice.
Hybrid resilience is not the resilience of the stronger leg, or even the weaker one. It is the resilience of the seam, and the seam is the one thing you built that neither environment's test was ever designed to see. The attack that takes down a hybrid estate rarely overwhelms either half. It gets in through the fact that they are joined.