A Linode DDoS test has to answer a question the brand quietly answers for you: you are hosting on Akamai, one of the largest DDoS mitigation providers in the world, so surely the attack surface is already covered.
The compute is Akamai's. The edge is also Akamai's. The trouble is that they are two different products, and nothing about running a workload on Linode puts the second one in front of the first.
Akamai acquired Linode in 2022 and now markets the compute platform as Akamai Connected Cloud. The rebrand is real, but it describes a portfolio, not an architecture. A Linode Compute Instance is a commodity virtual machine with a free network-layer DDoS floor and no managed web application firewall of its own. Akamai's App and API Protector, Prolexic, and CDN are separate services you provision, contract, and route traffic through on purpose.
So the headline finding on a Linode estate is not a misconfigured rule. It is the gap between the brand and the wiring: a team that believes it is protected because the logo on the invoice belongs to a mitigation company, running on an instance that no Akamai edge product actually sits in front of.
This is the Linode-specific instance of structured DDoS testing. The methodology is the same one that governs any environment. The contour is Linode's: a free L3/L4 floor like a budget VPS, no L7 defense at the compute layer, and a premium edge available in the same account that protects nothing until it is provisioned and in the path.
Where the Linode brand and the Linode architecture diverge
Picture the request path as a stack of controls, and separate the ones you inherit from the ones you have to buy and wire in.
At the bottom, Linode turns on free, always-on DDoS protection at the network and transport layers across its data centers. You inherit that floor the way you would on DigitalOcean: no configuration, no charge, L3/L4 only.
Above that floor, on the instance itself, the managed defenses stop. Linode ships a Cloud Firewall you attach and a NodeBalancer that distributes connections, but no managed WAF and no application-layer DDoS service at the compute-product layer. The HTTP flood, the slow read, and the application-logic abuse land on a machine you sized in advance.
The Akamai edge would change that picture entirely. But it is a separate product line, drawn at the top of the stack as optional, because until you put it in front of the origin and lock the origin to it, it is not defending the instance at all.
At a glance: what a Linode DDoS test validates
| Linode / Akamai control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Free network DDoS protection | Always-on L3/L4 volumetric and protocol absorption across data centers | Detection-to-mitigation interval for this profile; that every public instance IP is in scope |
| Cloud Firewall | Stateful L3/L4 filtering, applied per instance | Whether direct-to-instance access is denied; whether the state table is itself the bottleneck |
| NodeBalancer | TCP and HTTP/HTTPS connection distribution, TLS termination | The connection and request ceiling for the size; whether backends are reachable around it |
| The L7 layer (compute) | (not provided by the compute platform) | Whether anything rate-limits, scores, or filters application requests |
| Akamai edge (App & API Protector, Prolexic, CDN) | L7 WAF, bot defense, and edge-scale volumetric scrubbing | Whether it is provisioned and in the live path, and whether the origin is reachable around it |
| Compute instance | Serve the application | The single-node ceiling and which kernel limit gives way first, with no scale-out to soften it |
The recurring theme: on Linode, the strongest defenses in the catalog are the ones most likely to be absent from the path. The floor you inherit; the edge you have to build.
Any protection you put in front of the instance defends only the traffic that arrives through it. Whether every public hostname does is a separate check, covered in is your protection actually in the path.
The protection surface you are testing
Be precise about what each layer does, and whether it is actually present, before designing the test. On Linode that precision hinges on one distinction: the floor is native to the compute product, the ceiling is a separate Akamai service.
The free network floor: inherited, and L3/L4 only
Linode enables always-on DDoS protection at the network edge for all customers, at no charge and with no configuration. It operates at L3/L4, absorbing volumetric and protocol pressure upstream of the instance.
This is a genuine floor, and it is worth appreciating for what it is not. It is not a managed WAF, it does not read the application request, and it does not stop an HTTP flood that completes valid handshakes. A SYN flood or carpet-bombing across an instance range is its domain; a well-formed request storm is not.
The durable test step is to measure the detection-to-mitigation interval for your traffic profile and confirm that every public instance IP is in scope, not just the address behind a NodeBalancer.
Cloud Firewall
Linode's Cloud Firewall is a stateful L3/L4 filter you attach to an instance. Once applied, inbound is default-deny except for the rules you write.
A rule source can be an address or CIDR, which lets you lock an instance so it accepts application-port traffic only from the NodeBalancer or an upstream edge. That lock is the cleanest origin control the platform offers, and most deployments never set it.
Because the firewall is stateful, it tracks every connection, and that table is finite. Under a connection flood the firewall becomes both a control and a candidate layer of first failure. The test measures which gives way first: the network floor's L3/L4 absorption, the firewall's state table, or the instance behind them.
NodeBalancer
The NodeBalancer terminates TLS, runs health checks, and distributes connections across a backend pool. It handles TCP and HTTP/HTTPS, so it can route on application attributes, but it is a load balancer, not a WAF: it does not score requests, rate-limit by key, or filter attack patterns.
A TCP connection flood or a slow-read attack consumes connection slots without consuming much bandwidth. A balancer sized for normal peak can exhaust its slots while every bandwidth graph still looks idle. And because it distributes rather than inspects, it does nothing to stop an HTTP flood of valid requests from reaching the backends it is spreading load across.
The missing L7 layer at the compute tier
Like DigitalOcean, Linode's compute product offers no managed WAF and no application-layer DDoS service. The mechanics of that gap, why the single-node kernel becomes the layer of first failure, how an HTTP flood or a Slowloris-style slow attack lands directly on compute, and how to build the L7 layer the platform omits, are worked through in full for the near-identical shape in DigitalOcean DDoS testing.
Rather than re-derive it, the short version for Linode is the same: if an application-layer flood reaches the instance, the only thing in its way is what you put there.
The Akamai edge: the strongest control, and a separate product
This is the layer that makes a Linode test different from a plain-VPS test. The same account that runs the instance can front it with Akamai's edge, App and API Protector for L7 WAF and bot defense, Prolexic for BGP-based volumetric scrubbing, the Akamai CDN for absorption and caching. In front of a locked origin, that is one of the strongest DDoS postures available anywhere.
Two properties follow, and both are testable facts rather than assumptions.
First, it is a separate provisioning and contracting step. A Linode instance does not acquire App and API Protector because it lives in Akamai's cloud, any more than a server in a colo acquires a scrubbing contract by being in the building. The edge protects the origin only when traffic is actually routed through it.
Second, its value collapses the moment the origin is reachable around it. This is the origin IP exposure problem in Akamai form, and it is the same invariant that governs any edge in front of a separate origin, examined in depth for a productized third-party edge in IBM Cloud DDoS testing and for a pure edge in Cloudflare DDoS testing. The premium edge and the commodity origin are two different products that nothing forces to point at each other.
Compute instances and LKE
A Linode Compute Instance is a fixed-size virtual machine with kernel limits, conntrack table size, accept queue depth, and ephemeral port range, that cap concurrent work. It does not grow under load; when it saturates it stays saturated until the attack stops or you intervene. There is no autoscaler in the default path and no scale-out to soften the failure.
If you run Linode Kubernetes Engine instead, the failure modes shift to ingress chokepoints and autoscaler timing, covered in Kubernetes DDoS testing. Test it as a cluster, not as a bare instance.
What Linode DDoS testing actually surfaces
A useful test is organized around the gaps that recur on Linode estates. They follow from the shape above: an inherited L3/L4 floor, a premium edge that may not be in the path, and a fixed compute ceiling with nothing behind it.
The brand halo is the headline finding
On a cloud with a managed WAF in the account, the common finding is a rule left in a permissive mode. On Linode the prior question is whether an L7 defender is in the path at all, and the brand makes that question easy to skip.
The test verifies, in order, whether an Akamai edge product is provisioned for this workload, whether live traffic actually traverses it, and whether the origin refuses everything that does not arrive through it. It is entirely possible for an organization to hold an Akamai edge contract, apply it to some properties, and run a public-facing service on a Linode instance that no edge product fronts.
This is where a Linode test earns its keep, because the gap is invisible from inside the brand. The invoice says Akamai. The dashboard shows the edge products exist. Only attack-shaped traffic against the actual instance shows whether any of them is standing in front of it.
Origin exposure voids the edge
An Akamai edge in front of a Linode origin does nothing if the instance is independently reachable on its own public IP.
The instance's address leaks through historical DNS, certificate transparency logs at crt.sh, an A record that was never moved behind the edge, or an IP hard-coded in a client bundle. The full mechanics are in how attackers bypass CDN protection.
The lock is specific: attach a Cloud Firewall whose inbound rule allows the application ports only from the edge's published source ranges, and deny direct public access, ideally paired with an origin-authentication secret so a guessed address alone is not enough. The defining test is a direct connection to the instance's public IP from outside the allowed source. It must be refused. If it succeeds, the attacker skips App and API Protector, the CDN, and every L7 control in one move, and lands on the bare instance behind the free floor.
The fixed ceiling with nothing behind it
With no autoscaler in the default path, the instance's own 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 connections exhausts the accept queue, a flood of new TLS sessions burns CPU on handshakes. None of these fill the pipe; they fill a table or a core.
A fixed-size instance has no elasticity to soften that, so the number the test produces, the offered rate at which goodput collapses, is the number that matters. Identify which limit goes first for this instance type and workload. That single figure is worth more than any datasheet, and it is the same discipline whether the edge is present or not, because the edge is exactly what determines how much of the flood ever reaches that ceiling.
Linode authorization: two acceptable-use gates
A Linode DDoS test runs into two policies at once, because the platform and the edge are two products.
Linode's acceptable-use terms prohibit using its network to attack others, and its abuse systems watch for traffic that resembles an attack, including traffic you generate against your own instance. A high-volume simulated flood can read to the platform as an outbound attack if you source it from Linode, or an inbound one, and either can trigger automated action against the account.
If the target sits behind an Akamai edge product, a test through that edge is also traffic against an Akamai deployment, so Akamai's own testing guidance applies on top of Linode's. This is the same two-gate situation that arises whenever a managed edge fronts a separate origin.
The durable instruction is procedural, because specific policies and contact processes change. Before any Linode test, read the current Linode and Akamai acceptable-use and testing guidance, and coordinate the window with support if your plan approaches volumes their abuse systems would flag. Authorization from the legal owner of the target is mandatory regardless of platform policy, and the platform gates sit on top of that owner authorization, never in place of it. The same discipline of running the test without disrupting production applies in full.
Designing the test: environment, scope, and measurement
The structure that keeps a Linode test informative and safe is the one that governs any production-adjacent test, with a Linode contour.
Environment selection
The strongest first target is a staging environment built from the same Terraform or provisioning scripts as production: the same instance types, the same Cloud Firewall rules, the same NodeBalancer configuration, and critically the same edge state, either fronted by the same Akamai products or deliberately not, matching production. A mirror that adds the edge when production lacks it, or omits it when production has it, tests the wrong stack.
Where a finding can only be confirmed in production, the reachability of the instance'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 IDs and their public IPs, which Akamai edge products front which properties, the NodeBalancers, the Cloud Firewalls in force, and any LKE clusters in play. It sets the vectors and maximum rates, the test windows, the kill switch, and the escalation path.
On Linode specifically, the scope should record the edge state per property, because the test will deliberately compare an edge-fronted path against a direct-to-instance path to characterize the difference the edge makes, and to prove the direct path is closed.
Measurement per control
Each control gets a measured outcome. Free network protection: detection-to-mitigation interval and IP coverage for L3/L4. Cloud Firewall: whether direct-to-instance connections were refused, and whether the state table held. NodeBalancer: the connection and request rate at which it began shedding. Akamai edge: whether it was in the path, what it filtered, and whether the origin was reachable around it. Compute: the offered rate at which goodput collapsed and which kernel limit gave way first.
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.
Mapping attack classes to Linode controls
A thorough test exercises each layer against the control meant to defend it, including the layers where the defender is a separate product that may be absent. The mechanics of each class are covered in DDoS attack vectors, and real adversaries rarely send one class at a time, which is the subject of multi-vector DDoS testing.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, ACK flood, carpet-bombing) are the free network floor's domain. The test confirms it engages for this profile and that every public instance IP is in scope, not just the NodeBalancer frontend.
- Connection-state floods (TCP connection flood, slow-read, half-open) are absorbed by the NodeBalancer up to its size, then by the instance's conntrack and accept queue. This class reveals the connection ceiling and the state-table limit, which sit well below the bandwidth ceiling.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) have a managed defender only where an Akamai edge product is provisioned and in the path. Where it is absent, this class lands on the instance directly and tests whatever L7 control you added, or proves that none exists.
- Application-logic abuse (credential stuffing under any rate limit, expensive search, cart abuse) is the hardest class anywhere. App and API Protector's bot and API controls address part of it at the edge; the rest is an application-code concern that no platform solves for you.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. DDoS testing is engaged both as an ongoing subscription and as a discrete project.
The models suit different cadences. A Linode deployment that changes when an Akamai edge product is finally put in front of a service, when a NodeBalancer is resized, or when a new instance comes up outside the edge, 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, a common shape for the cost-conscious teams a value-priced compute platform serves well. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is Linode DDoS testing?
Controlled, authorized generation of attack-shaped traffic against Linode-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment: whether the free L3/L4 protection covers every instance IP, the Cloud Firewall rules, the NodeBalancer ceiling, whether an Akamai edge product is actually in the path, and the application-layer defenses you added, rather than testing whether Akamai's protection works in general.
Does Linode protect against DDoS attacks?
At L3/L4, yes: Linode provides free, always-on network-layer DDoS protection across its data centers. It does not include a managed WAF or application-layer DDoS protection at the compute-product layer, so HTTP floods, slow attacks, and application-logic abuse are defended only by what you add, whether that is an Akamai edge product in front of the origin or controls in your own stack.
If I host on Akamai, am I not already protected by Akamai's DDoS mitigation?
Not automatically. Akamai's edge products, App and API Protector, Prolexic, and the CDN, are provisioned and contracted separately from Linode compute. A Linode instance inherits the free L3/L4 floor but does not inherit the Akamai edge; that protection applies only when you route traffic through it and lock the origin so it cannot be reached around it.
Do you need permission to run a Linode DDoS test?
Treat it as required, and expect two policies. Linode's acceptable-use terms prohibit attack traffic and its abuse systems can act on traffic that resembles an attack, including against your own instance. If the target is fronted by an Akamai edge product, Akamai's testing guidance also applies. Read both, coordinate a high-volume test with support, and obtain written authorization from the target owner regardless.
What is the first thing to validate on a Linode deployment?
Whether an L7 defender is actually in the path. Confirm whether an Akamai edge product fronts the public-facing service, and whether the instance refuses any connection that does not arrive through it. Then measure the free floor's coverage across every public instance IP. The single most common false green is assuming the Akamai brand implies edge protection the architecture has not been wired to deliver.
Where Linode resilience is actually decided
The durable knowledge from a test separates cleanly from the perishable. Five years from now, a Linode instance will still be a fixed-size machine with a free L3/L4 floor and no managed WAF of its own, the strongest defenses in the catalog will still be separate Akamai products you have to provision and route through, and origin exposure will still void every one of them. Those are stable.
What you have to keep re-verifying is everything built on top:
- whether an Akamai edge product is still in the path for every public service, or a new one launched without it
- whether every instance's public IP is still firewalled to the edge source ranges, or one came up routable
- the NodeBalancer size, chosen against a traffic peak the service has since outgrown
- the instance's real failure rate, which drifts with every dependency added to the request path
- whether the origin-authentication secret is still enforced, or quietly dropped during a migration
Linode does not ship a fragile platform, and the parent company genuinely operates one of the best edges in the business. That is exactly what makes the brand halo dangerous: the protection is real and sitting one provisioning step away in the same account, which is easy to mistake for protection that is already switched on.
None of that shows up on a portfolio page. It shows up the first time real attack-shaped traffic reaches an instance the edge was never wired to cover, which is why you generate that traffic yourself, on a schedule you control, before someone else does it on theirs.