Is it called Thunder TPS or A10 Defend now?

Both names are in circulation, and this is worth getting right in a tender document. As of August 2026 the manufacturer's Thunder TPS product URL resolves to a page presented as A10 Defend, so A10 Defend is the current marketing name for the line. Thunder TPS remains the name most operators use and appears throughout older documentation. Write both into the requirement so a bid is not excluded on nomenclature.

Why does this product appear mostly in service-provider designs?

Because its emphasis — density in a compact footprint, out-of-path integration with BGP and flow telemetry — matches the shape of a scrubbing centre rather than the shape of a single enterprise edge. That is a design intent rather than a limitation, and it is the reason the operational model can feel heavier than a smaller organisation needs.

Does out-of-path deployment change what it can decide?

Yes, in a way worth understanding rather than accepting as a footnote. Out-of-path removes steady-state risk and adds a diversion delay at the start of every incident, because moving traffic is a routing change rather than an instruction. For short bursts that delay can be the whole event.

Vendor profile

A10 Thunder TPS and A10 Defend: Architecture, Capabilities and Trade-offs

Last updated: August 2026 · Density for scrubbing-centre designs · Reading time ~11 min

A very wide amber flood funnelled inward by two guide vanes into one small block whose internal lattice is unusually fine, emerging on the far side as a narrow teal-green thread.

A10's DDoS line is built for mitigation density in a compact footprint, with an emphasis on volumetric and protocol-layer defence plus DNS protection, and integration with BGP and flow telemetry for out-of-path deployment. The manufacturer now markets this line as A10 Defend; the Thunder TPS name remains current in the field and in older documentation.

Best for: high-density scrubbing-centre builds and large service providers

A10’s DDoS line is the one most consistently described in terms of density: a large amount of mitigation capacity in a small amount of rack, integrated with the routing and telemetry that a scrubbing centre already runs. That design intent explains both where it fits well and where it feels like more machine than the problem requires.

At a glance

Appliance	Value	Evidence
Manufacturer	A10 Networks	Vendor-stated
Category	On-premises appliance, scrubbing-centre oriented	Vendor-stated
Current product naming	A10 Defend; Thunder TPS still in field use	Primary source — vendor URL now resolves to A10 Defend
Deployment	Out-of-path with BGP and flow integration; inline modes not verified here	Partly verified
Documented design centre	Mitigation density, volumetric and protocol layer, DNS protection	Vendor-stated
Own global scrubbing cloud	Not verified for this profile	Unknown
Published capacity figures	Not reproduced here — model-specific, check the current datasheet	Not verified for this profile
Best-fit environment	Scrubbing-centre builds and large service providers	Editorial inference

A note on naming

The manufacturer now presents this line as A10 Defend A10 Defend. The Thunder TPS name is still in everyday use among operators and appears throughout documentation written before the change. A requirement document that names only one of the two risks excluding a compliant bid or confusing an evaluation, so name both.

Architecture

Positioned for mitigation density with an emphasis on volumetric and protocol-layer defence plus DNS protection, and integration with BGP and flow telemetry for out-of-path deployments A10 Defend. Management at scale is a distinct component of the portfolio rather than a per-box concern, which again reflects the service-provider design centre.

Detection and classification

Out-of-path detection normally works from flow telemetry, which is strong evidence for volume and structurally weak evidence for anything small or slow. Where an operator needs application-layer judgement, establish which component provides it and whether it is in the quoted configuration.

Layer 3 and Layer 4 mitigation

The documented strength, together with DNS protection. For a carrier this is the work that matters most, and density is what makes it economic at scale.

Layer 7 mitigation

Depth relative to purpose-built application-layer designs is not verified for this profile. Where an application-layer requirement exists, treat it as something to measure with replayed traffic rather than as a specification line.

Capacity and packet-rate considerations

Not reproduced here. Density is the product’s headline property, which makes it especially important to take the number from the current datasheet for the quoted model and to require packets per second at a stated packet size alongside bits per second.

Multi-tenancy

Not verified for this profile. For a provider intending to sell protection, per-customer policy separation, per-customer reporting and tenant isolation behaviour are the properties to establish against the quoted model.

HA, bypass and failure modes

For out-of-path deployment the availability question moves to the diversion path: what happens if diversion fails, how long convergence takes, and what the fallback is. For inline deployment, establish bypass mechanism, power-loss behaviour and measured failover time.

Management and telemetry

Managed at scale through a separate management component. Establish whether that component is in the quoted price, what it retains, and in which formats it exports — a scrubbing-centre build usually needs per-customer reporting rather than aggregate graphs.

Data and control-plane dependencies

Not verified for this profile. Establish whether any manufacturer-operated service is consulted during classification, and what changes if it is unreachable.

Integrations

BGP and flow telemetry integration is central to the out-of-path model. Third-party integration breadth is not verified for this profile.

Regional support

Not verified for this profile, and support depth varies by market for every manufacturer here. Validate local presence and out-of-hours arrangements in your geography before committing.

Licensing and TCO characteristics

A scrubbing-centre design is a multi-component purchase by nature: mitigation, detection, management and the routing integration around them. Price the whole shape over five years rather than the appliance alone.

Strengths

Mitigation density that makes a scrubbing-centre build economic. Mature out-of-path integration with the routing and telemetry an operator already has. A design intent that matches service-provider reality rather than being adapted to it.

Limitations and unknowns

The operational model is heavier than a single-edge enterprise usually needs.
Application-layer depth, multi-tenancy, cloud dependencies and current model capacities were not verified for this profile.
Regional support depth varies by market and should be validated locally.
The naming change means older documentation and current documentation use different product names for the same line.

Best fit

Carriers, MSSPs and large hosting providers building or extending a scrubbing centre, where density and out-of-path integration are the deciding properties.

Poor fit

A single enterprise edge that needs immediate application-layer decisions, where the diversion delay and the operational model both work against the requirement.

POC questions

Measure diversion time end to end, from detection to mitigating, on your own routing.
Test a short burst — shorter than your measured diversion time — and record what reaches the origin.
Test at small packet sizes and record the packet rate at which behaviour changes.
If reselling: configure two tenants with different policies and verify isolation and per-customer reporting.
Establish which components the tested configuration required, and price all of them.
Confirm in writing which product name the quotation refers to.

Sources

Frequently asked questions

Is it called Thunder TPS or A10 Defend now?: Both names are in circulation, and this is worth getting right in a tender document. As of August 2026 the manufacturer's Thunder TPS product URL resolves to a page presented as A10 Defend, so A10 Defend is the current marketing name for the line. Thunder TPS remains the name most operators use and appears throughout older documentation. Write both into the requirement so a bid is not excluded on nomenclature.
Why does this product appear mostly in service-provider designs?: Because its emphasis — density in a compact footprint, out-of-path integration with BGP and flow telemetry — matches the shape of a scrubbing centre rather than the shape of a single enterprise edge. That is a design intent rather than a limitation, and it is the reason the operational model can feel heavier than a smaller organisation needs.
Does out-of-path deployment change what it can decide?: Yes, in a way worth understanding rather than accepting as a footnote. Out-of-path removes steady-state risk and adds a diversion delay at the start of every incident, because moving traffic is a routing change rather than an instruction. For short bursts that delay can be the whole event.

Sources

A10 Defend — DDoS protection services
A10 Networks · vendor documentation · accessed 2026-08-15
Checked on 15 August 2026. The manufacturer's Thunder TPS product URL now resolves to this page, which is the evidence for the current naming.

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors