On a multi-tenant platform, the attack is usually aimed at one customer and the outage is felt by all of them.
DDoS testing for SaaS is a controlled, authorised test of whether an attack aimed at one tenant stays with that tenant, measured by the service the other tenants receive while it runs, not by whether the platform as a whole stayed up. The readers it has in mind are the SREs and platform owners running one service for hundreds of customers, and whoever has to phone those customers after an incident.
Nothing about getting a test approved and bounded is special to SaaS; that groundwork is laid out once in the complete guide to DDoS testing. This post stays on the part that only exists when many customers share one system: who the attacker is really aiming at, how far the damage spreads, and which shared pieces turn a single customer's bad day into everyone's.
Why does one customer's attack become everyone's outage?
Because the customer is the target and the platform is the shared ground they stand on. Anything pooled between tenants carries the attack from the one who was aimed at to the ones who were not.
You inherit every customer's enemies
A company that runs its own website has a threat model shaped by its own business. A SaaS platform has the union of its customers' threat models.
One customer is a gambling operator during a big fixture. Another is a political campaign, another a school district in exam week, another a small retailer with an extortionist on its back. None of them told you, and the attacker was not thinking about you at all.
So the question worth asking on a SaaS team is which of your customers someone would attack, and what those customers share with everyone else.
The target is a hostname you do not own
The attacker usually aims at the customer's address: acme.yourapp.example, or more often the customer's own branded domain, portal.acme.example, pointed at your edge with a CNAME.
That hostname is theirs. Its DNS is in their account, its reputation is theirs, and it may be the only thing the attacker knows. But every packet sent to it lands on your shared edge, your shared TLS terminators and your shared application tier.
Pooled resources pass the damage on
In a pooled design, tenants share application workers, database clusters, caches and job queues. Under attack, the targeted tenant's traffic consumes those pools, and the other tenants queue behind it.
The pool does not know that tenant B was never attacked. It only knows it is full.
How far does the blast radius reach in each tenancy model?
As far as the tenant's resources are shared. A dedicated stack contains the attack; a fully pooled one hands it to every tenant; cells and shuffle sharding sit in between and let you choose the fraction.
Silo, pool and bridge
The common vocabulary for tenancy models is silo (each tenant gets its own stack), pool (everything shared) and bridge (some layers shared, some dedicated).
From a DDoS point of view, the only question about each layer is whether it is shared. A siloed database does not help if the tenants share a single ingress controller and a single login service in front of it. The blast radius is set by the most shared layer on the attacked tenant's path, not by the most isolated one.
Cells put a ceiling on it
A cell-based design runs the same stack several times and assigns each tenant to one cell. An attack that exhausts a cell takes down that cell's tenants and nobody else's.
With 20 cells of roughly equal size, the worst case for a single attacked tenant is about 5% of customers. That is still an outage for those customers, but it is a bounded one, and the bound is a number you chose when you sized the cells.
Shuffle sharding shrinks the overlap
Shuffle sharding assigns each tenant to a small random subset of shared workers instead of a fixed cell. Take 8 workers and give every tenant 2 of them: there are 28 possible pairs.
If an attack kills both workers serving tenant A, only the tenants assigned that exact pair lose everything, about 1 in 28. Most of the others share one worker with A at most and still have a healthy second. The arithmetic gets better quickly as the worker count grows; the cost is a routing layer that has to know each tenant's shard, which is itself shared.
Per-tenant or global rate limits: which one protects the other tenants?
Only a per-tenant limit protects the neighbours, and only if the platform can work out who the tenant is before the request becomes expensive. A global limit protects the platform and sacrifices whoever happens to be in the queue.
A global limit spreads the victim's traffic across everyone
A global limit counts all traffic together. When one tenant is flooded, that tenant's requests fill the global budget, and the limit starts rejecting requests from every tenant in proportion to their share of the traffic.
The flooded tenant is now responsible for most of the traffic, so the other tenants get only a small slice of the budget. The limit did its job for the platform and passed the outage on to the customers.
A per-tenant limit has to know the tenant first
A per-tenant limit needs a tenant ID, and where that ID becomes known decides what the limit can protect.
If the tenant is in the hostname, the edge can read it from SNI or the Host header and apply the limit before anything expensive happens. If the tenant is only in a token or an API key, the request has to be authenticated first, and authentication is often the most expensive thing the platform does per request. The general problem of limiting requests that arrive before a key exists is covered in DDoS testing for APIs; in a SaaS it means the tenant boundary is only as early as your tenant resolution.
The per-tenant limits add up to more than you have
Per-tenant limits are sized so that a normal tenant never touches them. Add them up and the total is far larger than the platform can actually serve.
A worked example with illustrative numbers: 400 tenants, each allowed 500 requests per second, on a platform that serves 40,000. The limits add up to 200,000, five times capacity. One tenant at its limit uses 1.25% of the platform. Eighty tenants at their limits use all of it.
That is fine when the hot tenants are independent. It stops being fine when one attacker controls the eighty.
The attacker can sign up
Most SaaS platforms let anyone create a tenant: a free plan, a trial, a self-serve signup. Each new tenant gets its own fresh per-tenant budget.
So the per-tenant limit is a per-signup limit, and the way around it is more signups. Test how many tenants one actor can create in an hour, what each costs you to provision (a schema, a bucket, a search index, a welcome email), and whether free-tier limits are low enough that eighty of them cannot fill the platform.
Why is the control plane the real single point of failure?
Because the data plane is often split into cells or shards while login, signup, billing, admin and custom-domain setup are still one global service. An attack on any tenant's login page lands on the login service every tenant uses.
Login is shared even when the data is not
A tenant-branded login page at acme.yourapp.example/login looks like it belongs to Acme. Behind it is the same authentication service, the same password-hashing workers and the same SSO callback endpoint every tenant uses.
Flood Acme's login and every customer's users stop being able to sign in, including customers whose data lives in a cell the attack never reached. Users already signed in may carry on until their sessions expire, which makes the outage look partial and confusing for the first hour.
Signup, billing and admin
These are the low-traffic, high-cost paths. Signup provisions resources. Billing calls a payment provider and writes to a ledger. The admin console runs heavy reports across the tenant's data.
They were sized for an ordinary day's handful of requests, they are often reachable without much authentication, and they are rarely behind the same caching and rate limits as the product itself.
Custom-domain certificates are a quota you can lose
Platforms that let customers bring their own domain usually issue a TLS certificate for each one automatically, sometimes on demand when a new hostname first appears in a TLS handshake.
If the edge will start issuance for any hostname in SNI, a flood of handshakes for random hostnames can spend your certificate authority's rate limits on names nobody owns. The visible failure comes later: a real new customer adds their domain and cannot get a certificate. Servers that support on-demand issuance usually offer a hook to check the hostname against your list of configured domains first; the test is whether that check is switched on and whether it holds under load.
Can you isolate the targeted tenant while the attack is running?
Only if you built the switch before the attack. Isolation has to be possible per tenant at the edge, in routing and in the contract, and all three are decided long before the incident.
Mitigation that applies to one hostname
The emergency controls that are easy to reach for, a site-wide challenge, a geo block, a lower global rate limit, apply to every tenant. A challenge that is acceptable for the attacked tenant's portal can break another tenant's machine-to-machine API traffic.
Check that your edge can apply a rule to one hostname or one tenant ID, and that the on-call engineer knows how to do it at 03:00. A per-tenant control that needs a deployment is not an emergency control.
Moving the tenant
The stronger move is to take the attacked tenant out of the shared pool: route their hostname to a dedicated cell or a separate edge configuration, so the attack follows them and leaves everyone else.
How fast that happens depends on how the tenant is routed. If it is a DNS change, the TTL on the tenant's record is your best case. If tenant-to-cell routing lives in a lookup table at the edge, it can be seconds. Test the move, time it, and check that the tenant's sessions and data still work in the new place.
The contract decides what you are allowed to do
The fastest way to protect 399 customers is sometimes to take the 400th offline: null-route their custom domain, or stop serving their hostname until the attack ends.
Whether you may do that is settled by your terms of service, and nobody on call should be reading them for the first time mid-incident. Find out before the incident whether your terms allow suspending a tenant to protect the service, who in the company can make that call, and who tells the customer.
What does a DDoS outage cost a SaaS company?
Mostly SLA credits and churn, and both scale with the number of customers affected, not with the size of the attack.
The SLA budget is small
A 99.9% monthly availability commitment allows about 43 minutes of downtime in a 30-day month. At 99.95% it is about 22 minutes, and at 99.99% about 4. A DDoS that takes an hour to identify and mitigate has used more than the month's budget on most tiers.
Credits multiply across tenants
The SLA is usually written per customer, with a credit, often a share of that month's fee, for each tier of shortfall. In a pooled platform, an attack on one small free-plan tenant can trigger credits for every paying customer on the platform.
Whether a DDoS counts against the SLA at all depends on the wording. Some agreements exclude attacks or events outside the provider's control; many enterprise customers negotiate those exclusions out. Read your own terms before you plan around either answer.
Aggregate availability hides the damage
A platform-wide error rate is a weighted average. If one cell of twenty is down, the platform shows 95% success, which reads as a bad hour rather than a total outage for 5% of customers, and those customers measure their own availability, not yours.
Report availability per tenant, or at least per cell, and look at the worst tenant, not the mean.
How do you test a multi-tenant platform without hurting real customers?
By attacking tenants you own and measuring tenants you did not attack. The result that matters is the service your untouched tenants received.
Attack your own test tenants
Create one or more test tenants in the production pool (or the closest staging copy, and say which in the report). Give them your own test domains, never a customer's hostname. A customer's custom domain is their DNS and their name; pointing a test at it needs their written consent, and in practice you do not need it.
Keep the test tenants on the same plan, cell and configuration as a typical customer, or the test measures an isolation the real tenants do not have. The general containment practice, ramps, ceilings and a kill switch, is in running a DDoS test without disrupting production.
Measure the tenants you did not attack
Run synthetic users against several other test tenants throughout: one in the same cell as the target, one in a different cell, one on an enterprise plan, one using SSO. Track their goodput and login success second by second.
A test where the attacked tenant degraded and the canaries stayed flat is a pass. A test where the attacked tenant held up and a canary in another cell lost its login is a finding, and usually the most important one in the report.
Keep internal cascades in their own lane
Some of what you find will be one service's slowness spreading through its callers inside your platform. That is a call-graph problem rather than a tenancy one, and it has its own method in DDoS testing for microservices. Platform-level limits behave differently again on Kubernetes and on serverless, where an account-wide concurrency pool is a noisy-neighbour problem inside your own tenancy.
A SaaS DDoS test checklist
- List which layers are shared on the attacked tenant's path: edge, TLS, ingress, workers, database, cache, queues, login, billing.
- Write down the tenancy model per layer and the expected blast radius as a fraction of customers.
- Find where the tenant ID becomes known (hostname, path, token) and confirm per-tenant limits act before the expensive work.
- Add up the per-tenant limits and compare the total with measured capacity.
- Measure how many tenants one actor can create per hour, and what each costs to provision.
- Confirm custom-domain certificate issuance only runs for hostnames you have configured.
- Create test tenants on your own domains, matched to a typical customer's plan and cell.
- Run canary tenants in the same cell, another cell, an enterprise plan and an SSO configuration.
- Practise a per-tenant emergency rule and a tenant move to an isolated cell, and time both.
- Report goodput and login success per canary tenant, and the worst tenant's numbers, not the platform average.
FAQ
What is a noisy neighbour in a DDoS context?
It is a tenant whose load degrades other tenants on shared resources. Under attack the targeted tenant becomes the noisiest neighbour on the platform without doing anything wrong, and the test is whether the other tenants notice.
Are per-tenant rate limits enough to isolate tenants?
They help, but only for resources they guard and only if the tenant is identified early. They do not protect a shared login service, and an attacker who can create many tenants gets many budgets.
Does a cell-based architecture solve multi-tenant DDoS?
It caps the data-plane blast radius at one cell. Anything still shared across cells, typically login, signup, billing, admin and the routing layer itself, keeps a platform-wide blast radius and needs testing on its own.
Should a SaaS company tell customers before a DDoS test?
Check your contracts. Testing on your own test tenants usually needs no customer notice, but some enterprise agreements require notice of any security testing in production. A customer's custom domain should never be a target without their written consent.
Do SLAs cover DDoS outages?
It depends on the wording. Some exclude attacks; many enterprise customers negotiate that out. Either way, customers judge you on their own experience, so the credit is often the smaller part of the cost.
Your attack surface is your customer list
A single-tenant service gets attacked because of what it is. A multi-tenant platform gets attacked because of what any one of its customers is, and every customer it adds brings its own set of enemies.
Nothing in the design stops that. What the design decides is how many other customers notice. That is the number to measure and the one to bring down, cell by cell and limit by limit, before someone else's attacker measures it for you.