Shared-Tenant PaaS Reliability Risks in Production

Shared-tenant PaaS platforms run every customer's workload on the same pool of compute, storage, and networking, managed by one provider. That pooling is exactly what makes the model cheap and fast to onboard onto. It's also what creates the reliability and security exposure this piece is about, and none of it is a bug the provider forgot to fix. The global PaaS market hit roughly $176 billion in 2024, according to IBM figures cited by Embroker, which means the assumptions baked into shared tenancy aren't a niche concern. They're load-bearing for a huge chunk of production software running today.

Multi-tenancy, in plain terms, means multiple customers sharing the same runtime, the same physical machines, the same network fabric. It's a genuinely good deal on cost: better resource use, faster time to first deploy, economies of scale the provider passes down (some of them, anyway). But the same sharing that makes it efficient is what makes it fragile in three specific ways: noisy-neighbor contention, synchronized vulnerability windows, and platform-wide blast radius. Teams that understand these mechanisms ahead of time make different infrastructure decisions than teams that meet them for the first time in an incident channel at 2 a.m.

How resource contention between tenants degrades performance and availability

Noisy neighbor is the plain name for it: one tenant's workload eats more CPU, memory, network I/O, or disk bandwidth than its share, and every other tenant sitting on the same hardware feels it as latency and dropped throughput. This isn't a misconfiguration on anyone's part. It's what happens by design when resource limits are enforced loosely, or when burst capacity gets pooled across a whole batch of tenants instead of reserved per customer.

The trigger is usually mundane. A batch job kicks off at the wrong hour. A traffic spike hits another customer's app. Somebody's memory leak finally catches up with them during a high-utilization window on the platform. None of that has anything to do with your code, and none of it shows up anywhere you can see.

That's the real problem: the provider sees aggregate utilization across the whole fleet. The tenant sees only their own symptoms, slow response times, timeouts, health checks failing for no visible reason, with zero access to the cross-tenant context that would explain any of it. Many organizations can't effectively track lateral movement between tenant boundaries, and the same blind spot applies to performance degradation as it does to security. You're diagnosing in the dark either way.

In a microservice setup, this gets worse fast. One dependency slows down because of neighbor contention, and that triggers retries, which builds queues, which cascades into failures across services that had nothing to do with the original slowdown. And the fix isn't in your hands. Remediation means opening a support ticket and waiting on the provider's timeline, not pushing an infrastructure change yourself. Plenty of teams burn hours chasing this as an application bug, a slow query, a network issue in their own stack, before anyone considers that the real cause is sitting one rack over.

The 2021 Azure ChaosDB case and what cross-tenant exposure looks like at scale

In 2021, security researchers found a vulnerability in Microsoft Azure Cosmos DB, later named ChaosDB, that let them exploit the Jupyter Notebook feature to reach into other customers' databases. Thousands of organizations were potentially exposed. The mechanism is worth sitting with: a feature Microsoft built, not something any tenant configured wrong, opened a path across tenant boundaries that the provider itself hadn't anticipated.

Compare that to the 2021 Accellion FTA breach. Dozens of organizations running the same legacy file transfer software, including Kroger and Shell, had sensitive data exposed through a single point of entry. One vulnerability, many victims, because they all sat on the same software.

Both cases show what blast radius actually means in practice. A vulnerability at the platform layer isn't a single-tenant incident that happens to also affect others. It's simultaneously an incident for every tenant on that infrastructure, all at once, with no stagger. IBM's 2024 data breach report puts the average cost of these breaches at $4.5 million, a number that reflects just how much the scope multiplies when the failure sits in shared infrastructure instead of one company's stack.

None of this is an argument that Microsoft or Accellion were careless. It's an argument that under the shared model, a tenant's exposure surface includes every feature the provider ships and every other tenant on the platform, not just the code that tenant wrote. Tenants in the ChaosDB window had no advance warning, no control over the feature that caused it, and no way to opt out while it was live. Tenants had no control over the feature that caused it and no way to opt out while it was live.

Side-channel attacks that cross tenant boundaries without ever touching application code

Side-channel attacks don't need a misconfiguration or a logical access flaw at all. They exploit information leaking through shared physical resources: CPU caches, branch predictors, memory buses. The kind of hardware plumbing no application developer ever thinks about, until it becomes the attack surface.

Research presented at ASPLOS 2024 demonstrated a practical cross-tenant cache attack against public clouds that recovered 81% of the secret bits from an ECDSA key belonging to a victim container running on Google Cloud Run. The researchers noted that other major cloud providers are likely equally vulnerable. This isn't a flaw specific to one provider's implementation. It's a property of sharing physical hardware between tenants, full stop.

Fixes exist. Cache partitioning, disabling simultaneous multithreading, writing cryptographic code with constant-time execution so timing itself doesn't leak anything. But these have to be applied at the provider level, or the tenant has to design around them, and most tenants have no idea whether either is happening. A tenant getting hit by a side-channel attack sees nothing unusual: no errors, no odd traffic, no anomaly in the metrics dashboard. The leak happens a layer below anything the tenant's observability tools can even reach.

This isn't new territory, either. Meltdown and Spectre showed the same class of attack years earlier, pulling data across tenant boundaries through CPU cache timing and speculative execution. What ASPLOS 2024 shows is that the problem never got solved. It evolved. Cryptographic secrets, session tokens, credentials sitting in memory inside a shared-environment container are not guaranteed private, even when every logical isolation control is working exactly as designed.

Synchronized vulnerability windows and why platform-wide updates remove the stagger that limits blast radius

On-premises setups, or single-tenant environments, let an organization control exactly when an update goes out. That staggering matters more than it sounds like it should: if a new version ships a zero-day, only the tenants who've taken that update are exposed. Everyone else is running the older, unaffected version, whether by policy or just by not getting around to it yet.

Shared PaaS removes that stagger entirely. The provider pushes updates on its own schedule, to everyone, at once. If that update introduces a vulnerability, every tenant is exposed in the same instant. There's no protected population still running the safe version, because there's no such thing as an unpatched holdout on a platform where you don't control patch timing.

The inverse holds too. When a vulnerability gets disclosed before a patch is ready, every tenant sits in that window simultaneously, which means attackers can go after the entire customer base at once instead of picking off whoever happened to update first. Josys names this as its own distinct category of multi-tenant risk, separate from misconfiguration or straightforward data leakage.

This bites hardest for teams under SOC 2, HIPAA, or PCI-DSS, all of which expect demonstrable control over data isolation and change management. On a shared PaaS, that control belongs to the provider, not the tenant. The shared responsibility model draws a clean line on paper (provider secures infrastructure, tenant secures the application) but patch timing falls into the gap between those two boxes, a place where the tenant can't act and often doesn't even get told an update happened. When an auditor asks who authorized a given patch and when, the honest answer on a lot of shared platforms is: the provider did it, and notice came after the fact, if it came at all.

Where the 2024 outage trend is pointing: risk shifting from hyperscalers toward PaaS intermediaries

Outages traced to digital service providers rose in 2024, while outages traced to the big cloud and internet giants fell, per industry reporting on outage trends. That split isn't a coincidence. Hyperscalers have poured money into distributed resiliency at the raw infrastructure layer for years, and it shows.

So the base layer, AWS, GCP, Azure, keeps getting more reliable at the hardware and network level. But that reliability doesn't automatically pass through to whatever sits on top of it. The gap is opening up one layer higher, at the PaaS intermediary sitting between the hyperscaler and the application.

That's exactly where shared-tenant PaaS platforms live. They inherit the hyperscaler's improving uptime at the VM and network level, sure, but then stack their own multi-tenant failure modes on top of it: routing bugs, scheduler errors, control plane outages that hit every tenant on the platform regardless of how healthy the underlying cloud is. A team running on a shared PaaS built on top of a highly reliable hyperscaler can end up seeing more downtime than a team running directly on that same hyperscaler, because the PaaS layer adds its own blast radius on top of infrastructure that was already fine.

And when something breaks at that layer, tenants just see their app go down. They can't tell whether it's an infrastructure failure, a scheduler bug, a noisy-neighbor cascade, or something more serious, because sorting that out requires the provider's cooperation and, usually, the provider's internal telemetry.

What teams typically cannot see or control on a shared-tenant platform

Every tenant gets a clear view of their own metrics, logs, and traces. That's where the visibility ends. Co-tenant activity, scheduler decisions, shared resource utilization, cross-tenant network traffic: none of it is visible from the tenant side, by design.

Many organizations simply cannot track lateral movement attempts across tenant boundaries. They're blind to an entire class of attack that the multi-tenant model itself makes possible.

Change control works the same way. Providers push updates, config changes, and infrastructure modifications on their own timeline, and tenants find out after the fact, if notification happens at all. Capacity planning is just as opaque: there's no way to know how many other tenants share the same physical hardware, what their usage patterns look like, or whether a large new tenant just got dropped onto the same rack last week.

Incident response inherits all of this. When an outage or security event traces back to a cross-tenant cause, the most important step in any playbook, understanding what actually happened at the platform layer, is a step the tenant can't take. That information belongs to the provider. Josys also flags misconfiguration as a compounding factor here: overly permissive access controls, inconsistent role definitions between tenants, permission inheritance that doesn't work the way anyone assumed, all of it often invisible until an incident drags it into the light. Add it up and teams on shared-tenant PaaS don't fully own their incident response, their audit trail, or their security perimeter. Chunks of each are permanently sitting with someone else.

How the risks compound when compliance requirements enter the picture

SOC 2, HIPAA, and PCI-DSS all expect demonstrable control over data isolation, change management, access controls, and incident response. On a shared-tenant platform, each of those is partially or entirely delegated to the provider, which puts the tenant in the odd position of being accountable for controls it doesn't operate.

Data isolation is the sharpest version of this. Shared databases and storage with thin logical separation can create real data leakage risk, making it genuinely hard to prove to an auditor that one customer's data is unreachable from another's account, even when nothing has actually gone wrong. Auditors also want records: what changed, when, who signed off. For platform-level changes on a shared PaaS, the honest answer is usually that the provider made the call and authorized it internally, not the tenant.

HIPAA compliance for PHI on a shared platform needs a Business Associate Agreement plus real confidence that the provider's isolation controls hold up. That confidence is hard to build when co-tenant activity is invisible by default. GDPR raises a similar issue around data sovereignty: proving data never crossed a jurisdictional line means trusting the provider's own account of its routing and storage decisions, since the tenant can't verify it independently.

The money at stake isn't small. GDPR fines can run into the tens of millions of euros, per figures cited by Embroker, a number big enough to erase whatever the shared PaaS saved in operating costs to begin with. The shared responsibility model leaves a real gap here: providers secure infrastructure, tenants secure applications, but auditors want evidence spanning both layers, and the tenant physically cannot produce evidence for a layer it doesn't control.

What running infrastructure in your own cloud account changes about each of these risks

Running dedicated compute in your own VPC removes noisy-neighbor contention outright. Your workloads compete with each other, if they compete at all, but no outside tenant's batch job or traffic spike can touch your latency. Porter, a bring-your-own-cloud PaaS, takes this approach by deploying into a team's own AWS, GCP, or Azure account rather than pooling tenants on shared infrastructure. Resource contention becomes something your own team manages, not something inflicted from outside.

Blast radius scoping changes just as directly. A platform-level failure in your own account affects your environment and nothing else. You're no longer part of a shared failure domain that happens to include a few thousand other companies' workloads.

Patch timing comes back under your control too. You decide when updates land, you can stagger rollouts, test in staging before production, and produce a real audit trail naming exactly who approved each change and when. That single shift closes most of the compliance gap around change management evidence.

The side-channel problem mostly disappears with dedicated hardware, since the ASPLOS 2024 research specifically describes attacks that require co-location on shared physical resources. Take away the shared hardware and that attack surface goes with it. Observability comes back too: VPC flow logs, native audit trails like CloudTrail, GCP Audit Logs, or Azure Activity Log, and full infrastructure metrics all sit in your own account, which means root cause analysis no longer depends on a provider's support queue.

None of this erases risk entirely, and it shouldn't be sold that way. Application code is still your code. IAM misconfigurations are still your misconfigurations. Dependency vulnerabilities don't go away because the infrastructure model changed. What changes is the removal of the structural risks that come specifically from sharing tenancy with strangers, the noisy neighbors, the synchronized patch windows, the blast radius that used to include everyone else on the platform.

The questions engineering teams should ask before committing to a shared-tenant platform

Start with data isolation, and push past a yes-or-no answer. Can the provider actually demonstrate, not just assert, that co-tenants can't reach your data? Is there schema-level isolation, row-level security, physical separation, and what evidence could they hand an auditor if asked tomorrow?

On observability, ask what visibility exists into platform-layer events at all. Can you pull logs of changes the provider makes to shared infrastructure underneath you? Is there any mechanism to detect that a co-tenant's anomaly, not your own code, is behind a performance hit you're seeing?

On update control, find out who decides when platform updates hit your environment, and on what notice. Ask how a zero-day disclosed before a patch existed would actually play out for your account, and how long that exposure window has historically run. Ask, too, what the incident response process looks like when the root cause sits at the platform layer rather than in your application, because that's the scenario where a shared-tenant platform's limits show up fastest, and it's better to know the answer before it shows up in a postmortem instead of a sales call.