Ask a datacenter operator what keeps them up at night and you'll hear about power redundancy, cooling capacity, and uptime SLAs long before you hear about malware. That's not because cyber risk inside the datacenter is small — it's because the entire discipline of datacenter engineering grew up around physical resilience, and security got bolted on as an afterthought, usually scoped no further than the door to the cage. The gap between how rigorously DC operators engineer for a power outage and how loosely they engineer for a compromised hypervisor is the subject of this post, and it's a bigger gap than most operators would like to admit.
Why datacenter security actually matters more than the industry treats it
A single enterprise server getting compromised is bad. A shared piece of virtualized infrastructure getting compromised is bad multiplied by however many tenants, workloads, and customer environments sit on that same physical host or cluster. Datacenters are, by design, concentration points — of compute, of data, and increasingly of the virtualization and orchestration layers that many organizations now trust with everything they run. That concentration is exactly what makes them disproportionately attractive targets: compromising the right layer of a multi-tenant environment doesn't get an attacker one victim, it potentially gets them dozens or hundreds, and it gives ransomware operators outsized leverage, since taking down shared infrastructure serving many customers creates far more pressure to pay than taking down one company's file server ever could.
The physical security side of this has matured enormously — biometric access, mantraps, N+1 power and cooling, Tier III/IV certification standards. The cyber security side of the same facility, particularly at the virtualization and hypervisor layer where tenant workloads actually run, has not kept pace at anywhere near the same rigor. That mismatch is the real blind spot.
Why it's so often ignored
This isn't operator negligence so much as a structural gap that nobody quite owns. In colocation and hosting relationships, there's a persistent ambiguity about where physical security ends and where operational security begins. Tenants often assume that because the facility is SOC 2 or ISO 27001 certified, security is broadly "handled" — when in reality those certifications typically cover physical and operational controls at the facility level, not the runtime security of the virtual machines and workloads a tenant deploys inside it. DC operators, meanwhile, often treat what happens inside a customer's VM as explicitly out of scope — it's the customer's OS, the customer's patching, the customer's antivirus. The result is a gap in the shared responsibility model that both sides can point past each other to justify, and that gap sits precisely at the virtualization layer.
There's also a practical, less-discussed reason: traditional endpoint security tooling was never built for this environment, and the people running datacenter infrastructure are power, cooling, and network engineers first, not security analysts. When a security tool causes performance problems in a shared, hyper-consolidated environment — which, as covered below, traditional antivirus reliably does — the operational instinct is to scale it back or disable it rather than re-architect around it, because the team's core competency and incentive structure is uptime, not detection engineering. Security spend in this world has historically gone toward physical controls and compliance certifications that are directly marketable and auditable, not toward the comparatively invisible work of securing what's actually running on the hardware.
Why offering it can be a real profit center, not just a cost
This is where operators tend to get the framing backwards. Colocation and hosting has become a commodity business at the rack-and-power level — pricing is transparent, margins on raw space and power are compressed, and differentiation is hard to find in a spec sheet. Managed services are where the industry's actual growth and margin now sit: managed colocation, remote-hands, monitoring, and security-adjacent offerings have consistently outgrown commodity colocation, and the operators winning are the ones bundling higher-margin, sticky services on top of the base offering rather than competing purely on dollars per kilowatt.
Security fits that pattern unusually well, for two reasons specific to this problem. First, once a customer's security is embedded in the provider's managed stack rather than self-administered, switching providers becomes materially harder — that's the kind of retention lever commodity colocation doesn't have. Second, and less obvious: centrally offloaded scanning (the approach covered in detail below) doesn't just protect tenant workloads, it reduces the aggregate compute, memory, and storage I/O that security software consumes across the operator's own shared infrastructure. In other words, done right, this isn't a service the operator subsidizes out of goodwill — it's a service that can genuinely improve the operator's own platform economics while being sold as a premium, recurring line item on top of the rack. That combination — better margins and lower platform overhead at the same time — is unusual enough in infrastructure services to be worth taking seriously as a product line, not a compliance checkbox.
The technical bottleneck: why per-VM scanning breaks down at datacenter scale
To understand why this has been hard to sell as a clean managed offering until relatively recently, it helps to understand exactly why traditional antivirus performs so badly in virtualized environments — a problem the industry calls the "AV storm."
Traditional antivirus was architected for physical, isolated machines: each instance has its own dedicated hardware, its own local copy of signature databases, and its own scan schedule, and none of that competes with any other system for resources. Virtualization breaks that assumption completely. When dozens or hundreds of VMs share the same physical host, hypervisors are very good at deduplicating common elements across near-identical instances — shared memory pages, common OS files — to make consolidation efficient. Traditional antivirus doesn't participate in that deduplication. Each VM runs its own full antivirus engine, its own signature database, and its own scan process, entirely unaware that the VM next to it on the same host is running an essentially identical scan against essentially identical files. When scheduled scans or signature updates fire simultaneously across many VMs — which they tend to, since most environments are built from similar images on similar schedules — every one of those redundant engines competes for the same CPU, memory, and storage I/O at once. That's the storm: a spike in resource contention severe enough to degrade performance across the whole host, sometimes badly enough that storage has to be over-provisioned just to absorb it.
The downstream effect is exactly what you'd predict: operators and tenants alike start disabling or de-scheduling security scans to protect performance, which means the actual security posture of the environment quietly degrades in the name of keeping things running. Non-persistent virtual desktop and golden-image environments make this worse in a different way — baking a full antivirus agent into a golden image creates its own headaches around license consumption, inconsistent reporting, and clones that silently lose protection during rapid provisioning.
How centralized, offloaded scanning actually fixes the economics
Bitdefender's GravityZone Security for Virtualized Environments (SVE) is a direct answer to this specific problem, and it's worth understanding the mechanism rather than just the marketing claim, because the mechanism is what makes the cost-effectiveness argument real rather than aspirational.
Instead of a full antivirus engine running inside every VM, SVE centralizes the scanning and signature intelligence on a dedicated Security Virtual Appliance (SVA), sometimes referred to as a Security Server, deployed once per host or cluster rather than duplicated per guest. Bitdefender offers this in two architectures depending on the environment: an agentless model built on VMware's NSX Guest Introspection technology, where the SVA performs scanning of guest VMs with no security agent inside the guest at all, and a Multi-Platform model that works independently of the hypervisor — using a lightweight agent (Bitdefender Endpoint Security Tools) paired with the SVA doing the heavy lifting, which extends the same approach to AWS, Azure, Nutanix, and VMware Tanzu environments where full NSX integration isn't available.
The part that actually solves the AV storm problem is the caching architecture underneath both models. Bitdefender maintains scanning and caching at two levels: a local cache per VM, and a shared, global cache maintained at the Security Virtual Appliance and synchronized across every SVA in the environment. When a file is scanned once anywhere in the environment, that result is cached and reused rather than re-scanned from scratch on every other VM running the identical file — which, given how much OS and application file content is genuinely identical across VMs cloned from the same image, eliminates the overwhelming majority of the redundant scanning that causes storms in the first place. The system also applies intelligent scheduling and specific anti-storm logic on top of that caching, and pre-populates caches with known system files so that newly provisioned VMs don't start from zero.
Two additional design details matter for anyone actually running this at datacenter scale rather than just reading about it. First, resilience: if a VM's local agent loses connectivity to its SVA, it doesn't simply go unprotected — it searches for an alternative available SVA in the environment, and can fall back to local scanning as a last resort, so a single appliance going down doesn't create a security gap across the workloads depending on it. Second, golden image cleanliness: because the heavy scanning engine lives on the SVA rather than baked into every clone, golden image deployment avoids the license-consumption and inconsistent-protection problems that come from embedding a full agent in a template that then gets cloned dozens or hundreds of times.
What this means as a managed offering, concretely
For a datacenter or hosting operator, the pitch to a tenant isn't "buy antivirus" — it's "your workloads get continuously scanned without the performance tax you'd pay running full agents yourself, because the scanning infrastructure is already shared and amortized across the platform." That's a materially different and more defensible sales conversation than the usual security upsell, because it's true on the economics, not just the marketing: a shared SVA doing deduplicated, cached scanning across many tenant VMs genuinely costs less in aggregate compute and storage I/O than the same number of tenants each running independent, redundant full-engine agents. The operator can package this as a managed security tier priced per VM or per rack, on top of the base colocation or hosting contract, capturing margin on a service that also happens to reduce the load those tenants would otherwise be putting on the shared platform if they self-administered heavier, less efficient tooling.
The centralized model also gives the operator centralized visibility and management — through integrations like vCenter synchronization, security posture across every tenant VM on the platform becomes something the operator can actually see and report on, rather than a black box each customer manages independently. That visibility is itself sellable, particularly to enterprise tenants who need to demonstrate security controls to their own auditors and customers but don't want to run and staff that function themselves.
Where to start
None of this requires ripping out existing infrastructure. Most environments already running VMware, Nutanix, or a mixed AWS/Azure footprint can layer a Security Virtual Appliance into the existing environment and begin offloading scanning incrementally, starting with the highest-density clusters where AV storms are already causing the most visible performance pain. For a datacenter or hosting operator evaluating whether to build this into a managed offering — or an enterprise tenant trying to understand why their own virtualized environment keeps hitting scan-related performance ceilings — the architecture question and the business case turn out to be the same conversation.
Curious whether centralized virtualized scanning makes sense for your environment, or want help scoping it as a managed offering for your tenants? Talk to our enterprise team or book a free 15-minute call.