Is AED a full DDoS platform or one component of one?

It is the edge component of a portfolio. AED is designed to sit inline and make high-confidence network- and transport-layer decisions on its own; network-wide detection and large-scale scrubbing are the roles of Sightline and TMS respectively. That is a coherent decomposition for a carrier, and it is the single most important thing to understand before pricing AED as though it were a complete answer.

What does the threat-intelligence dependency mean in practice?

AED's filtering quality is described by the manufacturer as informed by NETSCOUT's threat intelligence, which is delivered from outside the customer's network. The questions that follow are answerable with documentation: what telemetry, if any, leaves the customer network when intelligence features are enabled; in which jurisdiction it is processed; and how mitigation behaves if the feed is unavailable. Ask for the answers in writing rather than inferring them.

Does AED handle application-layer attacks?

It performs some application-layer work, but the design emphasis stated by the manufacturer is on stateless network- and transport-layer filtering, with fuller analytics belonging to the wider ecosystem. For a buyer whose primary problem is Layer 7, that shape is the thing to test rather than assume, in both directions.

What should an AED incumbent establish before renewing?

Which components the current protection actually depends on, and what each costs at renewal separately. A deployment that began as one appliance frequently ends as a stack of licensed components, and the renewal conversation is easier when the dependency map is written down first. The [alternatives assessment](/netscout-arbor-aed-alternatives/) works through the rest.

Vendor profile

NETSCOUT Arbor Edge Defense: Architecture, Capabilities and Trade-offs

Last updated: August 2026 · Inline edge filtering, ecosystem-shaped · Reading time ~12 min

One compact pale gatepost in sharp focus taking a broad amber flood head-on and reducing it to a thin teal-green thread, with three much larger structures standing unlit and hazy behind it, joined to the post only by two slender filaments.

Arbor Edge Defense (AED) is an inline, stateless mitigation appliance for the network edge, whose design centre is high-confidence Layer 3 and Layer 4 filtering informed by NETSCOUT's threat intelligence. Fuller network-wide visibility and scrubbing capacity come from the wider Arbor ecosystem — Sightline and TMS — rather than from the edge appliance alone.

Best for: carriers and large enterprises already invested in the Arbor ecosystem

Arbor is the incumbent name in carrier-grade DDoS defence, and Arbor Edge Defense is the part of that portfolio that sits in the traffic path at a customer’s edge. Reading it as a standalone product is the most common way a comparison goes wrong: AED is designed as one component of a decomposition, and its strengths and its costs both follow from that.

At a glance

Appliance	Value	Evidence
Manufacturer	NETSCOUT	Vendor-stated
Category	On-premises appliance, edge mitigation	Vendor-stated
Deployment	Inline at the network edge	Vendor-stated
Documented design centre	Stateless L3/L4 filtering, informed by NETSCOUT threat intelligence	Vendor-stated
Own global scrubbing cloud	Yes, through the wider NETSCOUT/Arbor portfolio rather than the edge appliance	Vendor-stated
Published capacity figures	Not reproduced here — model-specific, check the current datasheet	Not verified for this profile
Best-fit environment	Carriers and large enterprises already invested in the Arbor ecosystem	Editorial inference

Architecture

AED is deployed inline at the network edge, ahead of the stateful infrastructure it protects Netscout AED. Its stated position is that of a stateless first line: it makes decisions about packets without building the per-session state that a firewall would, which is what allows it to remain useful during exactly the state-exhaustion attacks that take a firewall out.

In the wider portfolio, network-wide detection is the role of Arbor Sightline Arbor Sightline, which consumes flow telemetry from across an operator’s network, and large-scale scrubbing is the role of TMS. A carrier design normally uses all three; an enterprise design frequently uses AED alone and inherits the ecosystem’s shape without the ecosystem’s coverage.

Detection and classification

The manufacturer positions AED’s filtering as high-confidence and informed by NETSCOUT’s threat intelligence, which is compiled outside the customer network and delivered to the appliance. This is a genuine architectural choice with real advantages: an intelligence feed sees attack infrastructure long before any single customer does.

It is also a dependency, and the honest way to evaluate it is to ask what changes when the feed is unavailable rather than to treat the question as hostile. Every intelligence-assisted product degrades when its feed is cut; what differs is how far, against which attack classes, and for how long.

Layer 3 and Layer 4 mitigation

This is the documented design centre. Stateless filtering at the edge is what AED is built to do, and the incumbency of the Arbor name in carrier environments rests on this work rather than on breadth.

Layer 7 mitigation

Application-layer coverage exists but is not where the manufacturer places the emphasis; fuller application-layer analytics in the Arbor world generally involve the wider ecosystem. A buyer whose primary problem is an application-layer flood should treat Layer 7 depth as something to measure in a proof of concept rather than as a specification line to compare.

Capacity and packet-rate considerations

Not reproduced here. Capacity varies by model within the line, and a single figure attached to a product family describes the largest model rather than the unit that will be quoted. Take the number from the current datasheet for the specific model, and require it in packets per second at a stated packet size as well as in bits per second.

Multi-tenancy

Not verified for this profile. Operators intending to resell protection should ask specifically about per-customer policy separation, per-customer reporting and what one tenant’s incident does to another’s service, and get the answer against the model being quoted.

HA, bypass and failure modes

An inline device is part of the availability design, so its failure behaviour is a first-order question rather than a detail. What to establish: the bypass mechanism and whether it is hardware or software, the behaviour on power loss, the behaviour on software fault, and how long a failover takes in each case. Ask for the answers against the exact model.

Management and telemetry

Managed on its own and, in ecosystem deployments, alongside Sightline for network-wide visibility. What matters for a buyer is the export path: which formats the appliance emits, whether the detail an incident report needs is retained locally, and on whose schedule it can be exported.

Data and control-plane dependencies

The intelligence feed is the dependency to map. Where an entity has a data-residency obligation, the questions are which telemetry leaves the network, where it is processed, and whether the feature can be disabled without disproportionate loss of protection.

Integrations

Pairs with Arbor Sightline and TMS within the NETSCOUT portfolio. Third-party integration breadth is not verified for this profile.

Regional support

Not verified for this profile. Support depth varies by market for every manufacturer in this category, and the useful question is not whether an office exists but who answers at 3am local time and in which language.

Licensing and TCO characteristics

The recurring theme in mid-sized operator feedback is that ecosystem shape becomes cost shape: what begins as a single-appliance purchase can become a multi-product set of licences and support renewals as coverage requirements grow. This is not a defect — it is the consequence of a decomposition that a carrier genuinely wants — but it belongs in a five-year model rather than in a first-year quote.

Strengths

Maturity and incumbency in carrier environments. A stateless edge design that keeps working under the attack class that removes stateful devices. An intelligence feed with reach no single customer could reproduce. Tooling that operators have had a long time to build practice around.

Limitations and unknowns

Application-layer depth beyond the edge appliance involves further components.
The intelligence dependency needs an explicit answer on telemetry, jurisdiction and degraded-feed behaviour.
Multi-tenancy, regional support depth and current model capacities were not verified for this profile and should be established from current documentation.

Best fit

Carriers and large enterprises that want a stateless inline edge and either already run, or intend to run, the wider Arbor ecosystem.

Poor fit

Organisations that need application-layer depth from a single unit, and buyers who will price the edge appliance as a complete answer and be surprised by the components required to reach full coverage.

POC questions

With the intelligence feed disconnected, repeat the same application-layer test. Record both runs and compare.
Sustain a state-exhaustion attack while measuring goodput on legitimate sessions, not only blocked attack volume.
Test at 64-byte packet sizes as well as at large frames, and record the packet rate at which behaviour changes.
Trigger the bypass path deliberately and time the failover.
Export the telemetry an incident report would need, in your own format, on your own schedule.
Price years one to five including every component the coverage you tested actually required.

Sources

Frequently asked questions

Is AED a full DDoS platform or one component of one?: It is the edge component of a portfolio. AED is designed to sit inline and make high-confidence network- and transport-layer decisions on its own; network-wide detection and large-scale scrubbing are the roles of Sightline and TMS respectively. That is a coherent decomposition for a carrier, and it is the single most important thing to understand before pricing AED as though it were a complete answer.
What does the threat-intelligence dependency mean in practice?: AED's filtering quality is described by the manufacturer as informed by NETSCOUT's threat intelligence, which is delivered from outside the customer's network. The questions that follow are answerable with documentation: what telemetry, if any, leaves the customer network when intelligence features are enabled; in which jurisdiction it is processed; and how mitigation behaves if the feed is unavailable. Ask for the answers in writing rather than inferring them.
Does AED handle application-layer attacks?: It performs some application-layer work, but the design emphasis stated by the manufacturer is on stateless network- and transport-layer filtering, with fuller analytics belonging to the wider ecosystem. For a buyer whose primary problem is Layer 7, that shape is the thing to test rather than assume, in both directions.
What should an AED incumbent establish before renewing?: Which components the current protection actually depends on, and what each costs at renewal separately. A deployment that began as one appliance frequently ends as a stack of licensed components, and the renewal conversation is easier when the dependency map is written down first. The [alternatives assessment](/netscout-arbor-aed-alternatives/) works through the rest.

Sources

Arbor Edge Defense — inline DDoS protection
NETSCOUT · vendor documentation · accessed 2026-08-15
Official product page; the manufacturer's own positioning and the current product naming.
Arbor Sightline — network-wide visibility and DDoS detection
NETSCOUT · vendor documentation · accessed 2026-08-15

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