Noisy Neighbor

A noisy neighbor is a tenant or workload whose resource use degrades the performance of others sharing the same infrastructure. Microsoft’s architecture guidance defines the problem from the victim’s side: it occurs when one tenant’s performance is degraded because of the activities of another tenant.

It is the standing cost of multi-tenancy. Sharing resources is what makes shared platforms cheaper, and the same guidance notes that sharing a resource carries a noisy-neighbor risk that cannot be completely avoided — only reduced and contained.

How it happens

There are two shapes, and the second is easy to overlook.

• One heavy tenant. A single tenant uses a disproportionate share — a month-end batch, a runaway query, a traffic spike — and others’ requests slow down or fail.
• Many modest tenants at once. Each uses a small share, but their peaks coincide and together they exceed capacity. No single tenant is misbehaving, which makes this version harder to attribute.

The contended resource is not always CPU. On a data platform, one large scan can evict the cache that dashboards depend on and hold workers that interactive queries are waiting for. Memory, disk I/O, network bandwidth, connection pools, and even a shared control plane can all be the point of contention. The Kubernetes documentation, for instance, lists noisy neighbors in the control plane as a concern alongside those on worker nodes.

Most noisy neighbors are accidental. The tenant causing the problem usually does not know it, which is why Microsoft’s guidance recommends treating the issue as a resource governance problem rather than a behavioral one.

How to detect it

The symptom from the victim’s side is inconsistency: the same request that succeeds quickly at other times becomes slow or fails, apparently at random. Recording a performance baseline is what makes that visible.

From the platform’s side, the useful signals are per tenant, not overall. A spike in total resource use says something is heavy; failures or slowdowns for a tenant that is not using much at the time point to a neighbor. That requires tracking consumption and latency by tenant identifier — the same per-tenant metering that cost attribution needs. Averages across all tenants tend to hide the problem, because one tenant’s bad morning is diluted by everyone else’s normal one; a per-tenant percentile of response latency shows it.

How to reduce it

Each control covers only the resource it governs. The Kubernetes documentation notes that resource quotas keep one tenant from exceeding its allocated share but do not protect against every kind of sharing, such as network traffic, and that when requests are set lower than limits some impact across workloads remains possible. A design that caps CPU and memory can still suffer a noisy neighbor on bandwidth or storage throughput.

Whatever limits are enforced, tell tenants about them. A throttled request that the client expects can be retried with exponential backoff; one that arrives as a surprise looks like an outage, and clients that retry immediately turn a cap into an amplifier. The broader techniques are covered in workload isolation and load shedding, and how competing workloads share one data platform is worked through in Enterprise Scale: One Platform, Workloads That Disagree.

References: Azure Architecture Center, Noisy Neighbor antipattern; Kubernetes Documentation, Multi-tenancy.