Oracle Cloud gives you two different places to run a web application firewall, and a DDoS test's first job is to work out which one your traffic actually passes through.
Oracle Cloud Infrastructure (OCI) turns on always-on DDoS protection at the network and transport layers for every tenancy, at no charge. It absorbs the volumetric and protocol floods, SYN floods, UDP reflection, malformed-packet storms, before they reach your VCN. That layer does its job.
Above it, OCI is a full-featured cloud: a managed web application firewall, flexible load balancers, network security groups, autoscaling instance pools. So unlike a deliberately simple platform, the OCI finding is rarely a control that is missing. It is a control that is present, configured, and quietly out of the request path, or in the path but set to observe rather than block.
This is the OCI-specific instance of structured DDoS testing. It reads much like an AWS DDoS test or an Azure one, the same questions about detection scope and the detection-to-mitigation interval, but with two OCI wrinkles worth naming up front. The WAF exists in two separately configured enforcement models. And the network firewall is split across security groups and security lists that can each behave statefully or statelessly.
Where OCI's managed protection stops
Picture the request path as a stack of controls, each defending one layer.
OCI's automatic mitigation covers L3 and L4: it absorbs the network-edge floods before they reach your virtual cloud network. Network security groups and security lists filter L3/L4 at the VCN, by rule. A flexible load balancer terminates TLS and spreads connections, and the WAF, wherever you attached it, inspects the HTTP request.
Then traffic reaches your compute, and whether anything above L4 engaged depends entirely on choices that are invisible from a bandwidth graph: which WAF enforcement point sits in the live path, what mode its rules are in, and whether the instance is reachable around the load balancer at all.
That configuration surface, not the network pipe, is where an OCI workload usually fails first.
At a glance: what an OCI DDoS test validates
| OCI control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Automatic DDoS protection | Always-on L3/L4 absorption across the network | Detection-to-mitigation interval for this profile; that every public IP is in scope |
| Security groups / security lists | Stateful or stateless L3/L4 filtering at the VCN | Whether direct instance access is denied; whether a stateless rule left the state table as the bottleneck |
| Flexible / network load balancer | TLS termination and connection distribution | The connection and bandwidth ceiling for the configured shape; whether backends are reachable around it |
| Web application firewall | Inspect and filter HTTP at the edge or the LB | Which enforcement point is in the live path, and whether its rules block or merely log |
| Compute capacity | Serve the application | The instance or pool ceiling; conntrack, accept queue, ports, the layer that fails first |
| Instance-pool autoscaling | Absorb load by adding instances | The scale-out window, and whether elasticity turns an outage into a runaway bill |
The recurring theme: OCI supplies every layer of control, but each one has a switch, and the test exists to read the switches under load rather than in the console.
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 OCI two of them have a mode that decides whether they do anything at all.
Automatic network-layer DDoS protection
OCI enables always-on DDoS protection at the network edge for every tenancy, at no charge and with no configuration. It operates at L3/L4.
It absorbs the common volumetric and protocol classes, SYN floods, UDP reflection, malformed-packet floods, carpet-bombing across an address range, before they reach a VNIC. Because you do not configure it, it is easy to credit it with more reach than it has. It handles packets. It does not read HTTP.
Treat its exact thresholds as published-doc material to confirm at test time, not as a fixed number to quote. The property worth measuring is the detection-to-mitigation interval for your traffic shape, and that every public entry point in the tenancy is actually in its scope.
Network security groups and security lists
OCI gives you two L3/L4 firewall primitives, and they are not the same tool. A security list is attached to a subnet and applies to everything in it. A network security group (NSG) is attached to individual VNICs, and it can name another NSG as the source of a rule.
That NSG-as-source capability is the cleanest origin lock OCI offers, and most deployments never use it. It lets a backend accept traffic only from the load balancer's NSG, by identity, without hard-coding an address range.
Both primitives can hold stateful or stateless rules. A stateless rule skips connection tracking, which sounds like a way to dodge state-table exhaustion, but it also means return traffic needs its own explicit rule and the device offloads no state. Under a connection flood, whether a given path is stateful or stateless changes which resource becomes the layer of first failure. The test should know, per path, which it is.
Flexible and network load balancers
OCI offers a flexible load balancer (L7, HTTP/HTTPS, TLS termination, sized by a minimum and maximum bandwidth) and a network load balancer (L4, source-IP preserving, built for throughput).
The flexible balancer's shape sets its ceiling. A TCP connection flood or a slow-read attack consumes connection slots and bandwidth allocation without filling the pipe, and a balancer sized for normal peak can start shedding while every network graph still looks calm. A test has to find that shedding point for the configured shape.
Neither balancer inspects the application request on its own. The L7 story lives in the WAF you attach, which is where OCI's most common false green hides.
The web application firewall, and its two enforcement points
This is the OCI control that most rewards a careful test, because OCI runs a WAF in two structurally different places.
One model is an edge policy: you route the domain through Oracle's edge network by CNAME, and the WAF enforces globally at Oracle points of presence in front of the origin. This is the model that carries the richer bot management, JavaScript and CAPTCHA challenges, threat-intelligence feeds, good-bot allowlisting.
The other model is a WAF attached to a load balancer: a firewall resource that references a WAF policy and enforces regionally, at the flexible load balancer itself.
They are configured separately, and a policy in one is not a policy in the other. The failure this produces is specific and common: an edge policy is authored and reviewed, everyone believes the site is protected, but the public DNS record points straight at the load balancer, which has no WAF attached. Every rule sits in front of a door the traffic never uses. The mirror image happens too, an LB-attached WAF that only ever sees the fraction of traffic routed to that balancer.
On top of that sits the mode question shared by every managed WAF. An OCI WAF capability can be set to log or observe a match rather than block it. A policy that is genuinely in the path, with its protection rules in observe mode, produces clean dashboards and stops nothing. This is the OCI member of a family that spans every edge: AWS WAF COUNT, Azure WAF Detection mode, Cloud Armor preview: true, Cloudflare's Log action, and OCI's observe action all mean the same thing. It logged. It did not block.
Compute capacity and instance-pool autoscaling
OCI compute runs as VM or bare-metal shapes, and can scale through an instance pool with an autoscaling configuration keyed on a metric or a schedule.
A single fixed instance behaves like any fixed machine: it has a set core count, fixed memory, kernel limits on conntrack, accept queue depth, and ephemeral ports, and it does not grow under load. A bare-metal shape raises those ceilings but does not remove the property, when it saturates it stays saturated until the attack stops or you intervene.
An autoscaling instance pool changes the failure mode rather than removing it, exactly as an autoscaler does anywhere. It trades the abrupt tip-over for a scale-out window, the minutes between the load arriving and a new instance taking traffic, and it introduces a cost surface, an attack that succeeds at forcing scale-out converts a near-free flood into an infrastructure bill. Both edges are worth measuring: how long the window is, and how far the bill can run.
What OCI DDoS testing actually surfaces
A useful test is organized around the gaps that recur on OCI estates. They follow from the shape above: solid L3/L4, a capable L7 stack, and several switches that decide whether the L7 stack is doing anything.
The enforcement-point seam is the headline finding
On a cloud with a single WAF attachment, the common finding is a misconfigured rule. On OCI the common finding is upstream of the rules entirely: the WAF is real and well-authored, but it is not the thing the live traffic passes through.
The test drives application-layer traffic at the public entry point the way a real client reaches it, follows the actual DNS and routing, and watches which enforcement point engages. Frequently the answer is neither, an edge policy that traffic bypasses and a load balancer with no firewall attached, or one of the two carrying rules while the live path uses the other.
This is not a subtle gap. It is the difference between "OCI's WAF protects us" as an inventory fact and as a path fact. The inventory says a policy exists. The path decides whether it matters.
Observe mode: present, in path, and inert
Once the test confirms which enforcement point carries the traffic, the next question is whether its rules block or only log.
An OCI WAF policy whose protection capabilities sit in observe mode 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 the WAF logged against what actually reached the origin, not to trust either number alone.
The valuable output here is a per-rule statement: for each capability meant to defend a class, did the request stop at the WAF, or did it arrive at the backend with a log line trailing behind it.
Instance exposure past the load balancer
A load balancer and a WAF in front of it do nothing if each backend instance is independently reachable on its own public IP.
This is the origin IP exposure problem in OCI form. A backend keeps a public IP because a subnet was public by default, or an instance was launched with one for convenience and never stripped, and its address then leaks through historical DNS, certificate transparency logs at crt.sh, or an IP baked into a client bundle. The full mechanics are in how attackers bypass CDN protection.
The OCI lock has two clean forms. Put backends in a private subnet with no public IP, and let the load balancer reach them. Then use an NSG whose ingress rule names the load balancer's NSG as the only permitted source for the application ports, the identity-based lock OCI's NSG model makes possible. The defining test is a direct connection to a backend's address from outside that source. It must be refused.
If you front the stack with the edge WAF instead, the same rule applies one layer out: the origin accepts traffic only from Oracle's published WAF edge ranges, and you verify a shared secret or header the edge injects so a spoofed source range cannot walk in behind it.
The instance ceiling and the scale-out window
With a fixed instance or a bare-metal shape 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. The test's job is to find which limit goes first for this shape and workload, and at what offered rate.
With an autoscaling pool, the same offered load produces a different trace: goodput dips as the running instances saturate, then recovers across the scale-out window while new instances boot and register. Measuring the depth and length of that dip, and the cost it accrues, is the autoscaling-specific outcome.
Detection covers L3/L4, and stops there
OCI's automatic mitigation detects and absorbs at the network layer. There is no platform-side detection of an application-layer flood unless the WAF 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 your WAF placement and mode, and on a default deployment, with the WAF at the wrong enforcement point or in observe mode, it is effectively infinite.
Mapping attack classes to OCI 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 automatic mitigation's domain, with security groups and security lists as the configured backstop. The test confirms it engages for this profile and that every public IP is in scope, not just the ones behind a balancer.
- Connection-state floods (TCP connection flood, slow-read, half-open) are absorbed by the load balancer up to its shape, then by the instance's conntrack and accept queue. This class reveals the connection ceiling and, where a path runs stateless rules, a different failure point than a stateful one.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) are the WAF's job, if the WAF is in the path and in block mode. This class is where the enforcement-point seam and observe 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 WAF'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.
OCI authorization: the acceptable-use gate
Oracle's cloud 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.
A high-volume simulated flood against an OCI target can read to the platform as an outbound attack (if you source it from OCI) or an inbound one, and either can trigger automated action against the tenancy or the target. Oracle's own always-on mitigation may also engage against your test traffic, which is itself a result worth capturing, but not one to trip unannounced.
The durable instruction is procedural, because specific policies and contact processes change. Before any OCI DDoS test, read Oracle's current cloud testing and acceptable-use policy, and coordinate the test window through the supported channel if your plan approaches volumes their systems would flag.
Authorization from the legal owner of the target is mandatory regardless of platform policy. The OCI gate sits 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 OCI test informative and safe is the one that governs any production-adjacent test, with an OCI contour.
Environment selection
The strongest first target is a staging environment built from the same Terraform or Resource Manager stack as production: the same shapes, the same NSG and security-list rules, the same load-balancer configuration, the same WAF policy attached at the same enforcement point, in a separate compartment or VCN.
A faithful mirror exercises the real configuration, including the enforcement-point placement, without touching live traffic. Where a finding can only be confirmed in production, the reachability of a real backend's public IP, for instance, a tightly scoped canary with explicit abort criteria does the job.
Scope as a bounding document
The scope names the exact resources: instance OCIDs and their addresses, the load balancers, the NSGs and security lists in force, the WAF policy and which enforcement point it is bound to, the instance pools and their autoscaling configuration. It sets the vectors and maximum rates, the windows, the kill switch, and the escalation path.
On OCI specifically, it should record which backends carry a public IP and whether each is locked to the load balancer's NSG, and which enforcement point the live DNS resolves through, because the test will deliberately probe both.
Measurement per control
Each control gets a measured outcome. Automatic mitigation: detection-to-mitigation interval and IP coverage for L3/L4. Security groups: 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. WAF: which enforcement point engaged, and per rule, whether it blocked or logged. Compute: the offered rate at which goodput collapsed, and for a pool, the depth and length of the scale-out dip and the cost it accrued.
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 OCI deployment that changes when a WAF enforcement point is moved, a subnet is made public, or an autoscaling policy is retuned 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 Oracle Cloud DDoS testing?
Controlled, authorized generation of attack-shaped traffic against OCI-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment, automatic-mitigation coverage, security-group and security-list rules, load-balancer ceilings, which WAF enforcement point is in the path and whether it blocks, and instance or pool capacity, rather than testing whether OCI's protection works in general.
Does Oracle Cloud protect against DDoS attacks?
At the network and transport layers, yes: OCI provides free, always-on L3/L4 DDoS mitigation for every tenancy. Application-layer protection comes from the OCI web application firewall, which you must attach at an enforcement point that sits in the live traffic path and configure to block rather than only observe, or HTTP floods and slow attacks pass through it.
What is the difference between the OCI edge WAF and the load-balancer WAF?
The edge WAF enforces globally at Oracle points of presence, reached by pointing your domain's DNS through Oracle's edge, and carries the richer bot-management and challenge features. The load-balancer WAF enforces regionally at a flexible load balancer. They are configured separately, so a test must confirm which one the live traffic actually traverses.
Do you need Oracle's permission to run a DDoS test?
Treat it as required. Oracle's cloud terms restrict simulated denial-of-service traffic, its systems can act on traffic that resembles an attack including against your own resources, and its own mitigation may engage. Read the current policy, coordinate a high-volume test through the supported channel, and obtain written authorization from the target owner regardless.
Can you DDoS test OCI without disrupting production?
Yes. Test a staging mirror built from the same stack first, 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 OCI resilience is actually decided
The durable knowledge from a test separates cleanly from the perishable. Five years from now, OCI will still absorb volumetric floods at the network edge, an instance will still have a kernel that fails before the pipe does, and the WAF will still run in two places. Those are stable.
What you have to keep re-verifying is everything built on top:
- which WAF enforcement point the live DNS resolves through, after the last migration that moved it
- whether the policy in that path still blocks, or a change quietly returned a rule to observe mode
- whether every backend is still locked to the load balancer's NSG, or a new instance came up with a public IP
- whether a stateful path stayed stateful, or a rule change offloaded the state and moved the failure point
- the autoscaling bounds, chosen against a traffic peak and a budget the service has since outgrown
OCI does not ship a fragile platform. It ships a complete set of controls and hands you the switches. The fragility, when it exists, is not in any one control. It is in the distance between the control that is configured and the control that is in the path, and that distance does not appear on a dashboard. It appears the first time real attack-shaped traffic follows the route a live client takes, which is exactly why you send that traffic yourself, before someone else sends theirs.