On IBM Cloud, the edge that inspects your web traffic and sheds application-layer floods is a Cloudflare deployment you rent under a different name, and a DDoS test's first job is to confirm it is actually in front of your origin rather than sitting beside it.
IBM Cloud protects the network layers the way every large platform does: volumetric and protocol floods, SYN floods, UDP reflection, malformed-packet storms, are absorbed at the backbone edge before they reach your workload. That layer is part of the platform.
The application layer is a different story, and it is the one that makes IBM Cloud distinct. IBM's managed L7 defense, the web application firewall, rate limiting, bot management, and HTTP-flood mitigation, is delivered by Cloud Internet Services (CIS), a product built on Cloudflare's edge. It is not on by default. It is a service you provision, point your DNS through, and lock your origin to.
So the IBM Cloud finding is rarely a subtly misconfigured rule. It is more often structural: an edge that live traffic never reaches, because CIS was never placed in the path, or because the origin is still directly reachable around it.
This is the IBM-specific instance of structured DDoS testing. The origin-side questions read like an AWS DDoS test or an Oracle Cloud one, the same detection scope and detection-to-mitigation interval. The edge-side questions are Cloudflare's, tested in depth in Cloudflare DDoS testing, because the CIS edge is that edge. What is unique to IBM Cloud is the seam between the two: a Cloudflare edge and an IBM-native origin, provisioned separately, that a test has to prove are actually wired together.
Where IBM Cloud's protection sits
Picture the request path as a stack of controls, each defending one layer.
At the bottom, IBM's network absorbs L3/L4 volumetric floods at its backbone before they reach your virtual server or bare-metal host. Above that, IBM-native filtering, VPC security groups and network ACLs, or a classic-infrastructure gateway appliance, screens L3/L4 at your own perimeter, by rule.
The application layer lives out in front, at the CIS edge, if you put it there. CIS terminates the connection at Cloudflare's points of presence, applies the WAF and rate limits, and forwards clean traffic to your origin. Everything above L4 depends on that edge being provisioned, in the live path, and reaching an origin that refuses anyone else.
That last clause is where an IBM Cloud workload usually fails first: not in a control that is missing, but in the distance between the edge you configured and the origin a client can still reach directly.
At a glance: what an IBM Cloud DDoS test validates
| IBM Cloud control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Network-layer mitigation | Absorb L3/L4 volumetric and protocol floods at IBM's edge | Detection-to-mitigation interval for this profile; that every public entry point is in scope |
| Cloud Internet Services (Cloudflare edge) | L7 WAF, rate limiting, bot management, HTTP-flood mitigation | Whether CIS is provisioned and in the live path at all, and whether its rules block or only log |
| Security groups / network ACLs (VPC) | Stateful and stateless L3/L4 filtering at the VPC | Whether direct-to-instance access is denied; which primitive is the bottleneck under a connection flood |
| Classic gateway appliance | Perimeter firewall for classic infrastructure | Whether the appliance itself is the layer of first failure, and whether failover holds under load |
| Load balancer (ALB / NLB) | TLS termination and connection distribution | The connection and bandwidth ceiling for the configured size; whether backends are reachable around it |
| Compute (VSI / bare metal / IKS) | Serve the application | The instance or node ceiling; conntrack, accept queue, ports, and whether bare metal recovers at all |
The recurring theme: IBM Cloud gives you a capable edge and a capable origin, from what are effectively two different vendors, and the test exists to read the wiring between them under load rather than in two separate consoles.
The protection surface you are testing
Be precise about what each layer does before designing the test. The plan maps one-to-one onto these controls, and on IBM Cloud two of them, the edge and the origin lock, are the pair that decides whether the L7 stack does anything at all.
Network-layer DDoS mitigation
IBM Cloud absorbs common volumetric and protocol classes at its network edge before they reach your host: carpet-bombing across an address range, reflection floods, malformed-packet storms. This operates at L3/L4 and is a property of the platform rather than something you tune.
Treat its exact behavior and thresholds as current-documentation material to confirm at test time, not a fixed number to quote, because the specifics differ between classic and VPC infrastructure and change over time. The property worth measuring is the detection-to-mitigation interval for your traffic shape, and that every public entry point in your account is genuinely in scope. This layer handles packets. It does not read HTTP.
Cloud Internet Services: a Cloudflare edge you provision
This is the control that defines IBM Cloud's DDoS posture, and the one a test most rewards, because it is a full managed edge that is also entirely optional.
CIS is built on Cloudflare. When you route a hostname through it, the domain resolves to the edge's anycast addresses, and traffic transits Cloudflare's network, where the WAF, rate limiting, bot management, and autonomous DDoS mitigation apply before anything reaches IBM Cloud. The edge internals, the packet filter at ingress, the profiling that generates mitigation rules per zone, the managed rulesets, are Cloudflare's, and testing them is the subject of Cloudflare DDoS testing. There is no reason to re-derive that here. What matters for an IBM Cloud test is everything the shared architecture implies.
CIS is provisioned as a separate service instance, on a Standard or Enterprise plan, with its own configuration. A workload can run on IBM Cloud with no CIS in front of it at all, in which case the application layer has no managed edge and is defended only by whatever the origin and its load balancer can do themselves. That is a legitimate deployment, and it is also the first thing a test has to detect, because a bandwidth graph will not show it.
When CIS is present, the same mode question that governs every managed WAF applies. A CIS WAF rule can be set to a logging action rather than a blocking one. A rule that is genuinely in the path but only logging produces clean dashboards and stops nothing. This is the IBM member of a family that spans every edge: AWS WAF COUNT, Azure WAF Detection mode, Cloud Armor preview, and Cloudflare's Log action, which under CIS is the same action, all mean one thing. It matched. It did not block.
VPC security groups, network ACLs, and the classic split
IBM Cloud runs two generations of infrastructure, and which one you are on changes the perimeter primitives and where they fail.
VPC infrastructure gives you security groups, which are stateful and attach to an instance's network interface, and network ACLs, which are stateless and apply at the subnet. The stateful and stateless distinction matters under a connection flood: a stateless ACL tracks nothing and offloads no state, but every allowed connection then leans on the instance's own state table, so which primitive you rely on changes which resource becomes the layer of first failure.
Classic infrastructure predates VPC and is built on VLANs with gateway appliances doing perimeter enforcement. There, the appliance is a discrete device with its own throughput and session ceiling, and it can be the layer of first failure before either the pipe or the origin is. A test on classic infrastructure should treat the gateway as a component under test in its own right, including how its failover behaves under sustained load.
The test should know, per path, which generation and which primitive it is exercising, because the answers differ.
Load balancers
IBM Cloud offers a load balancer for VPC in two forms: an Application Load Balancer (L7, HTTP/HTTPS, TLS termination) and a Network Load Balancer (L4, high throughput). Classic infrastructure has its own load-balancing options.
The configured size sets the ceiling. A TCP connection flood or a slow-read attack consumes connection slots and bandwidth allocation without filling the pipe, so a balancer provisioned for normal peak can begin shedding while every network graph still looks calm. A test has to find that shedding point for the actual configuration.
Neither balancer inspects the application request on its own. The L7 story lives at the CIS edge, if it is in front, which is why the edge-in-path question dominates the rest of this test.
Compute: virtual servers, bare metal, and clusters
IBM Cloud's compute range includes a case most clouds treat as an afterthought and IBM treats as a first-class product: bare metal.
A virtual server instance behaves like any fixed VM: set cores, fixed memory, kernel limits on conntrack, accept queue depth, and ephemeral ports, and no growth under load unless an instance group scales it. A bare-metal server raises those ceilings substantially, but it does not change the property, and it has no autoscaler cushion by default. When a single fixed instance or a bare-metal host saturates, it stays saturated until the attack stops or you intervene. There is no scale-out window to hide behind, which makes the kernel limits the whole story.
IBM Cloud Kubernetes Service and Red Hat OpenShift add the orchestration layer, with the autoscaling failure modes that come with it, covered in Kubernetes DDoS testing: a scale-out window instead of a tip-over, and a cost surface where a successful flood becomes an infrastructure bill instead of an outage.
What IBM Cloud DDoS testing actually surfaces
A useful test is organized around the gaps that recur on IBM Cloud estates. They follow from the shape above: solid L3/L4, a capable but optional Cloudflare-powered edge, and an origin on separate infrastructure that has to be locked to that edge.
The edge-in-path seam is the headline finding
On a cloud where the WAF is an attachment inside the same account, the common finding is a misconfigured rule. On IBM Cloud the common finding is one layer earlier: the managed edge is a separate product, so the first question is whether it is in the live path at all.
The test drives application-layer traffic at the public hostname the way a real client reaches it, follows the actual DNS resolution, and watches whether it lands on the CIS edge or straight on the origin. Three outcomes are common. CIS is in front and enforcing, the healthy case. CIS is provisioned but a hostname resolves directly to the origin, so the edge is bypassed for that name. Or CIS was never provisioned, and there is no managed edge at all.
This is not a subtle gap. It is the difference between "IBM Cloud protects our application layer" as a purchasing fact and as a path fact. The account may hold a CIS instance. The DNS decides whether it matters.
Origin exposure: the edge protects a secret, not a server
Because CIS and your origin are separate systems, the edge only helps traffic that goes through it, and it rests on one secret: the origin's real address. If an attacker learns that address and the origin accepts connections from anywhere, the entire edge is bypassed in a single step.
This is the origin IP exposure problem in IBM Cloud form. The origin's address leaks through historical DNS, certificate transparency logs at crt.sh, a direct. or mail. record that someone needed to reach without the proxy, or an IP baked into a client bundle. The full mechanics are in how attackers bypass CDN protection.
The IBM Cloud lock has clean forms, and they depend on the shared Cloudflare architecture. Restrict the origin's inbound firewall, a VPC security group or a classic gateway rule, to the edge's published IP ranges. Require Authenticated Origin Pull, so the origin accepts a TLS connection only when it presents the client certificate the edge holds. The defining test is a direct connection to the origin's address from outside those ranges. It must be refused.
Log mode: present, in path, and inert
Once the test confirms CIS carries the traffic, the next question is whether its rules block or only log.
A CIS WAF rule set to a logging action passes attack traffic straight through while filling the logs with matches. A dashboard full of detections reads as protection and is the opposite. Separating the two requires the test to compare what CIS logged against what actually reached the origin, not to trust either number alone.
The valuable output is a per-rule statement: for each rule meant to defend a class, did the request stop at the edge, or did it arrive at the backend with a log line trailing behind it.
The bare-metal ceiling has no recovery
With a virtual server or a bare-metal host in the path, the kernel is usually the layer of first failure, and it gives way at a request rate that looks unremarkable on a bandwidth chart.
A connection flood fills the conntrack table. A burst of half-open or slow connections drains the accept queue. A flood of fresh TLS sessions burns cores on handshakes. None of these need to fill the pipe.
On bare metal the point is sharper, because there is no autoscaler to mask it. A cluster or an instance group can trade an abrupt tip-over for a slower scale-out dip. A fixed bare-metal host cannot: it saturates and stays there. The test's job is to find which limit goes first for this host and workload, and at what offered rate, because that number is the ceiling with nothing behind it.
Detection covers L3/L4, and stops there
IBM's network mitigation detects and absorbs at the network layer. There is no platform-side detection of an application-layer flood unless the CIS edge is in the path and configured to act, because nothing else above L4 is reading the request.
So the interval that matters splits in two. For L3/L4 it is the platform's, measurable and generally fast. For L7 it is a function of whether CIS is in front and enforcing, and on a deployment with no edge, or with the edge bypassed by a stray DNS record, it is effectively infinite.
Mapping attack classes to IBM Cloud controls
A thorough test exercises each layer against the control meant to defend it. The mechanics of each class are covered in DDoS attack vectors, and a real adversary rarely sends them one at a time, which is the point of multi-vector testing.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, ACK flood, carpet-bombing) are the network mitigation's domain, with security groups, network ACLs, or the classic gateway as the configured backstop. The test confirms it engages for this profile and that every public entry point is in scope.
- Connection-state floods (TCP connection flood, slow-read, half-open) are absorbed by the load balancer up to its size, then by the host's conntrack and accept queue, and on bare metal with no scale-out cushion behind it. This class reveals the connection ceiling and, on a stateless ACL path, a different failure point than a stateful one.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) are the CIS edge's job, if the edge is in the path and its rules block. This class is where the edge-in-path seam and log mode show up as measured breakthrough rather than as a config note.
- Application-logic abuse (credential stuffing under any rate limit, expensive-query floods, cart abuse) is the hardest class anywhere, and mostly an application-code concern that the edge's rate limiting and bot management can only blunt. Test what the rate-limit rule keys on, and whether it fires before the backend does.
IBM Cloud authorization: two acceptable-use gates
IBM Cloud's terms prohibit using the platform to attack others, and simulated denial-of-service traffic is treated differently from ordinary penetration testing. Respecting that is a prerequisite, not a formality.
IBM Cloud adds a wrinkle most single-vendor clouds do not have. Because the managed edge is Cloudflare, a test that drives traffic through the CIS edge is also traffic against a Cloudflare deployment, and Cloudflare's own testing policy applies to it in addition to IBM's. A high-volume simulated flood can read as an attack to either party's automated systems, and either can act on it.
The durable instruction is procedural, because specific policies and contact processes change. Before any IBM Cloud DDoS test, read IBM's current cloud acceptable-use and testing policy, confirm whether your plan through CIS also requires coordination on the Cloudflare side, and arrange the test window through the supported channel if your volumes would trip either platform's automation.
Authorization from the legal owner of the target is mandatory regardless of platform policy. The platform gates sit on top of that owner authorization, never in place of it. The discipline of running the test without disrupting production applies in full.
Designing the test: environment, scope, and measurement
The structure that keeps an IBM Cloud test informative and safe is the one that governs any production-adjacent test, with an IBM contour.
Environment selection
The strongest first target is a staging environment built from the same infrastructure-as-code as production: the same VPC or classic layout, the same security groups and ACLs, the same load-balancer configuration, and, crucially, the same CIS instance and DNS wiring, in a separate resource group.
A faithful mirror exercises the real configuration, including whether the edge is actually in the path, without touching live traffic. Where a finding can only be confirmed in production, the direct reachability of a real origin's IP being the usual one, a tightly scoped canary with explicit abort criteria does the job.
Scope as a bounding document
The scope names the exact resources: instance IDs and their addresses, whether each host is a virtual server or bare metal, the load balancers, the security groups and ACLs or the classic gateway in force, the CIS instance and which hostnames route through it. It sets the vectors and maximum rates, the windows, the kill switch, and the escalation path.
On IBM Cloud specifically, it should record which hostnames resolve through CIS and which resolve directly, and whether each origin is locked to the edge's ranges, because the test will deliberately probe both the through-edge path and the direct-to-origin path.
Measurement per control
Each control gets a measured outcome. Network mitigation: detection-to-mitigation interval and coverage for L3/L4. Security groups and ACLs: whether direct-to-instance connections were refused, and whether a stateless path shifted the bottleneck. Load balancer: the connection and bandwidth point at which it began shedding. CIS: whether the edge was in the path, and per rule, whether it blocked or logged. Compute: the offered rate at which goodput collapsed, and for bare metal, that it did not recover.
The deliverable is not "the site stayed up." It is a per-layer characterization: what engaged, at what threshold, in what order, and what a real user experienced while it did. Folding those numbers into a defensible posture is the subject of DDoS resilience testing.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. DDoS testing is procured both as an ongoing subscription and as a discrete project engagement.
The models suit different cadences. An IBM Cloud deployment that changes when CIS is placed in front of a new hostname, a subnet is made public, or a workload moves from classic to VPC maps naturally onto project engagements: the test happens when the change happens. A continuously deploying estate may prefer a standing capability.
Neither is universally correct. Annual-subscription commitments can price out a team whose real need is a handful of well-scoped tests a year. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is IBM Cloud DDoS testing?
Controlled, authorized generation of attack-shaped traffic against IBM Cloud-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment: network-mitigation coverage, whether the Cloud Internet Services edge is in the live path and blocking, security-group and ACL rules, load-balancer ceilings, and host or cluster capacity, rather than testing whether IBM's protection works in general.
Does IBM Cloud protect against DDoS attacks?
At the network and transport layers, IBM Cloud absorbs volumetric and protocol floods at its edge. Application-layer protection comes from Cloud Internet Services, which is built on Cloudflare and is a separately provisioned service. It only defends traffic that routes through it and whose rules are set to block rather than log, so an unprovisioned or bypassed edge leaves HTTP floods and slow attacks unmitigated.
Is IBM Cloud Internet Services the same as Cloudflare?
Cloud Internet Services is built on Cloudflare's edge, so its WAF, rate limiting, bot management, and DDoS mitigation behave like Cloudflare's. For testing, this means the edge-control mechanics are Cloudflare's, while the origin, networking, and compute underneath are IBM Cloud's own. A test has to confirm the two are wired together and the origin is locked to the edge.
Do you need permission to run an IBM Cloud DDoS test?
Treat it as required, and remember there may be two gates. IBM Cloud's terms restrict simulated denial-of-service traffic, and because the edge is Cloudflare, a test through Cloud Internet Services may also fall under Cloudflare's testing policy. Read both current policies, coordinate a high-volume test through the supported channel, and obtain written authorization from the target owner regardless.
Can you DDoS test IBM Cloud without disrupting production?
Yes. Test a staging mirror built from the same infrastructure-as-code first, including the same CIS wiring, then use a tightly scoped canary with explicit abort criteria for findings that can only be confirmed in production, origin reachability being the usual one. Scope, traffic caps, and a kill switch keep it non-destructive.
Where IBM Cloud resilience is actually decided
The durable knowledge from a test separates cleanly from the perishable. Five years from now, IBM Cloud will still absorb volumetric floods at its network edge, a bare-metal host will still have a kernel that fails before the pipe does, and the managed application-layer edge will still be a Cloudflare deployment sold as Cloud Internet Services. Those are stable.
What you have to keep re-verifying is everything built on top:
- whether every public hostname still resolves through CIS, after the last DNS change that added a record
- whether the rules in that edge still block, or a change quietly moved one to a logging action
- whether every origin is still locked to the edge's ranges, or a new instance came up reachable from anywhere
- whether a workload that moved from classic to VPC carried its perimeter rules with it, or lost them in the migration
- whether the bare-metal hosts that carry your peak load can still absorb it, given they have nothing to scale into
IBM Cloud does not ship a fragile platform. It ships a strong network, a first-class origin, and a Cloudflare edge you rent and wire in yourself. The fragility, when it exists, lives in the seam: the edge and the origin come from different places, and nothing forces them to point at each other. A dashboard will not show you the gap. It appears the first time attack-shaped traffic follows the route a live client takes, which is exactly why you send that traffic yourself, before someone else sends theirs.