What characteristics of two services should make you decide NOT to consolidate them onto the same compute unit, even though doing so would improve utilization and lower cost?

## The domain of validity Compute resource consolidation is a cost/utilization optimization, and like any optimization it has a domain of validity outside of which it stops being a good trade. The decision to NOT consolidate two workloads onto the same compute unit comes down to whether the risk introduced by sharing a fault, security, and performance domain is acceptable given what each workload actually needs — and there are several recurring categories where the answer is no: - **Security and compliance isolation** - **Mismatched scaling and lifecycle needs** - **Strict, uncorrelated SLA requirements combined with shared-fault-domain risk** - **Correlated peak timing** ## Security and compliance isolation The first and often hardest category is security and compliance isolation. Workloads that fall under different compliance scopes — say, a service that processes payment card data under PCI-DSS versus an unrelated internal reporting tool — should generally not share a compute unit, because doing so widens the audit boundary: - If a shared host, container runtime, or hypervisor is in scope for one workload's compliance regime, everything co-located on it can be pulled into that regime's audit surface. - Any vulnerability in the shared kernel or container runtime becomes a potential path for lateral movement between workloads that were never supposed to trust each other. This is a case where consolidation's own scope note applies directly: consolidation's shared-kernel, shared-fault-domain model is fundamentally incompatible with hard isolation guarantees, which is exactly why compliance-sensitive or multi-tenant isolation needs are handled by a different approach entirely (dedicated, isolated stacks per tenant/scope). ## Mismatched scaling and lifecycle The second category is mismatched scaling and lifecycle needs. If one workload autoscales aggressively in response to bursty traffic — spinning up and tearing down rapidly — and another has a stable, predictable footprint, co-locating them forces an uncomfortable choice: - either the stable workload's capacity gets treated as elastic too (risking eviction or resource starvation during the bursty neighbor's spike), - or the whole unit has to be sized for the bursty workload's peak even during its idle periods, which reintroduces the low-utilization problem consolidation was meant to fix. Workloads with fundamentally different deployment cadences — one that redeploys multiple times a day versus one updated quarterly — also create friction when consolidated, since a redeploy or rolling restart of the frequently-changing workload's host can incidentally disrupt the stable one's availability. ## Strict SLAs and a shared fault domain The third category is strict, uncorrelated SLA requirements combined with shared-fault-domain risk. A latency-sensitive, revenue-critical API and a best-effort nightly batch job are a textbook bad pairing even though the batch job might have plenty of idle CPU to offer during the day: - the batch job's occasional resource-hungry burst is exactly the kind of noisy-neighbor event the critical service can't tolerate; - and if the host itself fails or needs to be drained, the critical service goes down for a reason entirely unrelated to its own code or traffic. The cost asymmetry matters here too — the operational and reputational cost of an SLA breach on the critical service is usually far larger than the infrastructure savings from consolidating it, so the math doesn't favor sharing even before considering the technical risk. ## Correlated peak timing The fourth, more subtle category is correlated peak timing. Two workloads that are individually well-behaved but whose demand spikes happen at the same time — both driven by the same upstream event, like a shared batch trigger or the same regional business-hours pattern — don't actually deliver the utilization benefit consolidation promises, because their combined peak still approaches or exceeds the shared unit's capacity at the moment it matters most. In this case consolidating doesn't even buy the cost benefit cleanly; it just moves the contention problem from 'two mostly-idle machines' to 'one machine that's briefly overloaded twice a day,' with the same blast-radius downside as any other bad pairing. ## Consolidate within a boundary In each of these cases, the alternative isn't necessarily 'no consolidation at all' — it's consolidating within a boundary that respects the constraint: - A payments-scoped set of services can still be consolidated among themselves, just not with unrelated services. - A fleet of similarly-elastic services can be consolidated together while being kept separate from stable, latency-critical ones. The judgment call a senior engineer needs to make is recognizing which axis (security scope, scaling profile, SLA class, or timing correlation) is the binding constraint for a given pair of workloads, and treating that as a hard boundary for placement decisions even when the raw utilization math looks attractive. A concrete real-world version of this reasoning shows up in Kubernetes node pools segmented by workload class — a 'critical' node pool with taints/tolerations reserved for latency-sensitive services and a separate 'batch' node pool for elastic, best-effort jobs — which is exactly a policy encoding of 'consolidate within each class, never across them.'