Managed SQL Server Hosting: Security, Backups, and the Cloud Tradeoff

Most teams running SQL Server in the public cloud have not fully reasoned through the security model. The performance gap that used to drive the dedicated-versus-cloud debate has narrowed significantly. Hyperscalers have addressed noisy neighbor effects with dedicated host options, larger VM sizes that consume entire NUMA nodes, and provisioned IOPS storage. For most workloads, raw performance is no longer the deciding factor.

What hasn't been solved is everything that surrounds the database. Identity integration, network paths, backup architecture, and compliance attestation all get harder in a multi-tenant cloud, not easier. The threat model expands. The audit surface expands. And the cost of engineering equivalent isolation in public cloud often exceeds what dedicated infrastructure costs in the first place.

At Concourse Cloud, we host SQL Server on dedicated private cloud infrastructure. The customers we work with usually start with a security or compliance requirement. The performance and total cost outcomes show up afterward.

This post focuses on self-managed SQL Server running on cloud IaaS, meaning SQL Server on EC2 or Azure VMs that your team owns end to end. Fully managed PaaS services like AWS RDS for SQL Server and Azure SQL Managed Instance handle backups, patching, and HA on your behalf. Those are different tradeoffs and worth their own discussion.

The Noisy Neighbor Problem Is Mostly Solved. The Rest Is Not.

Cloud architects have spent the last several years engineering noisy neighbor effects out of SQL workloads. AWS Dedicated Hosts, Azure Dedicated Host SKUs, M-series VMs sized for SQL Enterprise, io2 Block Express, Ultra Disk: the tooling exists, and it works. If you provision the right SKUs and pay for them, you get consistent CPU and storage performance.

That is the relevant qualifier. Provisioned IOPS volumes cost several times more than standard storage. Dedicated hosts shift you from per-VM to per-host pricing, which is rarely cheaper. M-series VMs are among the most expensive compute SKUs Microsoft sells. The performance is real, and so is the bill.

The deeper issue is what surrounds SQL Server in production. SQL is rarely an island. It authenticates against Active Directory or Entra ID. It accepts connections from application servers. It pulls from upstream ETL sources, exports to reporting platforms, ships logs to a SIEM, and gets backed up by an enterprise backup product. Each of those is an integration with its own security controls.

In a public cloud IaaS environment, those integrations cross trust zones: VNet peering, private endpoints, service endpoints, hybrid connectivity back to on-prem identity. Each connection is a configuration to maintain, an audit obligation to track, and a potential blind spot in incident response. The performance gap may have closed. The integration surface has not.

Integration Security Is Where the Real Cost Hides

The shared responsibility model is honest about this. The cloud provider secures the infrastructure. You secure everything you put on it, plus every integration you build between cloud and your other environments. The provider's compliance attestations do not transfer to your workload. They are a foundation. You build your own attestation on top.

For SQL Server workloads under CMMC, HIPAA, or PCI DSS 4.0, this matters more than it sounds. Compliance is not satisfied by the cloud provider's certifications. Your scope includes every system that touches the database, every network path between them, and every identity that can authenticate. In public cloud IaaS, that means tracing audit evidence across multiple control planes: yours, the provider's, and any third-party tooling layered on top.

Dedicated managed private cloud collapses that surface. The hosting provider operates inside a single auditable boundary. Network paths are direct. Identity is consistent. Audit trails are unified. CMMC and HIPAA attestations apply to the environment your workload actually runs in.

This is the part that does not show up on a price comparison. It shows up in engineering hours, architectural review cycles, and the time spent during an audit explaining why a particular integration is configured the way it is.

SQL Server Backups: The Workload Most Teams Underestimate

For multi-terabyte databases, backup is one of the heaviest workloads SQL Server runs. Native backups read every page, compute checksums, optionally compress, and write the result somewhere durable. On a 5 TB OLTP database, a full backup can consume several CPU cores and saturate the storage subsystem for the duration of the run. The impact shows up in elevated query latency, slower reports, and complaints from users in time zones where the "off-hours" backup window is the middle of the business day.

Differential and log backups reduce the impact, but the core problem stays. Backups compete with production for CPU and I/O. The bigger the database, the more obvious the contention.

This is where Rubrik changes the picture. Concourse runs Rubrik as the backup platform across our SQL Server environments. It addresses the operational and security problems together.

Application-consistent backups with zero production impact. The mechanism is the Rubrik and Pure Storage integration. Rubrik coordinates a brief VSS quiesce on SQL Server, instructs Pure Storage to take a snapshot, and releases SQL Server. Pure snapshots are metadata operations with no array performance cost and no read or write traffic on the production volumes. From that point forward, the entire backup runs against the Pure snapshot: changed block analysis, deduplication, compression, encryption, and transmission to immutable storage. The SQL Server is not involved. For multi-terabyte databases that previously ran native backups for hours, this gives the production server hours of CPU and I/O back every backup cycle. The "backup window" stops being something your DBAs and users have to plan around.

Native SQL Server awareness. Rubrik treats SQL Server as a first-class workload. It performs transaction log backups for point-in-time recovery, understands Always On Availability Groups, and supports live mounts. Live mount instantiates a backup as a running SQL database in seconds, which is useful for recovery testing, extracting a single table, or staging a development copy without performing a full restore. That capability is one of the more underused features in modern backup platforms.

Immutable, air-gapped storage. This is the security half. Rubrik writes backups to immutable storage with retention locks that cannot be overridden, even by an administrator with full credentials. The threat model is explicit: a domain admin compromise should not be able to delete or alter your backups. Immutability is enforced at the storage layer, not the application layer. That distinction matters when you are modeling ransomware or insider threat scenarios.

Reporting that holds up to an audit. Built-in reporting covers backup completion, retention, and recovery testing. For environments under CMMC, HIPAA, or PCI, this is the difference between having a backup system and having a backup system you can prove works.

The pattern in public cloud IaaS varies. Most teams stack native SQL backups to object storage with VM-level snapshots from the cloud provider, then layer a third-party backup product on top. Each layer adds cost, configuration, and operational burden. Immutability guarantees vary by SKU. Recovery testing rarely runs automatically. The result functions, but it is rarely well integrated.

You discover the quality of a backup posture during an incident. The teams that have not pressure-tested theirs ahead of time tend to learn it the most expensive way available.

Performance: The Outcome Customers Did Not Expect

When customers move SQL Server workloads from public cloud IaaS to dedicated infrastructure for security or compliance reasons, the performance improvement tends to be the part they did not plan for.

Storage latency on Pure Storage all-flash arrays runs consistently under one millisecond. There are no burst credits, no throttling thresholds, and no provisioned IOPS premium to pay for consistent performance. NVMe communicates directly with the CPU over PCIe, which removes the protocol overhead that limits SATA arrays under sustained load. StorageReview's SQL Server benchmarks comparing NVMe and SATA show average query latency of 2ms on NVMe versus 16ms on SATA under equivalent transaction loads. That is a useful proxy for the storage architecture difference.

Compute is straightforward. Our environments run on Dell PowerEdge servers with AMD EPYC processors. We offer four compute tiers matched to different SQL Server demands:

• Tier 1 (4.4 GHz): Among the fastest CPU clock speeds commercially available. Up to 6 TB RAM. Built for the most demanding transaction-heavy Enterprise workloads.
• Tier 2 (3.7 GHz): Premium tier for high-throughput SQL Enterprise environments with heavy concurrent query loads.
• Tier 3 (3.5 GHz): Standard tier for most SQL Server Enterprise production environments.
• Tier 4 (3.0 GHz): Base tier for non-SQL or lower-intensity workloads. Still runs roughly 25% faster on average than comparable public cloud VM offerings.

RAM ranges from 208 GB to 768 GB depending on configuration. SQL Server Enterprise licensing is included at every tier.

Performance monitoring runs continuously through SQL Sentry, the industry standard for SQL Server observability. Real-time query tracking, wait time analysis, resource usage, and bottleneck detection. All specific to SQL Server rather than generic infrastructure telemetry. For a deeper look at how this feeds day-to-day optimization, see our guide to SQL Server performance tuning.

SQL Server Licensing: The Hyperthreading Tax

Performance and security drive the conversation. Licensing usually closes the case.

SQL Server Enterprise core licensing is expensive on its own. Cloud VMs make it more expensive than most teams expect, because most VM types expose logical vCPUs rather than physical cores. A VM with 8 vCPUs typically runs on 4 physical cores with hyperthreading enabled. SQL Server licenses every vCPU, so you pay for 8 core licenses where 4 physical cores actually exist.

Microsoft's core-based licensing guidance confirms that virtual cores map to hardware threads, and every virtual core assigned to a SQL Server instance requires a license. Hyperscale vCPUs are also typically weaker than equivalent physical cores, which means you need more of them to hit comparable throughput, and you license each one. The cost compounds fast.

On dedicated infrastructure, SQL Server Enterprise licenses against physical core counts. The hyperthread multiplier disappears. For organizations moving SQL Server Enterprise workloads from cloud VMs to dedicated private cloud, licensing costs typically come down to 15 to 40% on this factor alone.

Cloud IaaS vs. Dedicated Private Cloud: The Comparison

Total Cost of Ownership

Three things drive the cost difference for steady-state SQL Server Enterprise workloads.

1. Hardware ownership. We own our infrastructure outright, so there is no hyperscaler markup baked into the price.
2. SQL Server licensing on physical cores. No hyperthread multiplier. Licensing is included.
3. Fixed monthly billing. No data egress charges, no tiered storage fees, no per-IOPS pricing, no per-restore fees on the backup side.

IDC research on VMware Cloud Foundation deployments found 34% lower infrastructure costs and 42% lower operating expenses over three years compared to equivalent public cloud footprints. For SQL Server workloads specifically, the savings tend to land higher. Licensing optimization on physical cores stacks on top of the infrastructure difference, and a bundled backup platform stacks on top of that.

The pattern is most pronounced for 24/7 steady-state workloads. ERP systems, financial applications, healthcare data platforms. Cloud pricing is optimized for variable demand. Steady-state load is the scenario where flat monthly pricing pulls ahead consistently.

When Each Option Fits

Public cloud IaaS is the right call for genuinely elastic workloads. Development and test environments, applications with highly variable demand, scenarios where native cloud tooling provides specific advantages worth the isolation tradeoff.

Dedicated managed private cloud makes more sense for SQL Server workloads that are:

• Subject to compliance frameworks where single-tenant isolation simplifies attestation (CMMC, SOC 2 Type II, HIPAA/HITECH, PCI DSS 4.0)
• Integrated with multiple upstream and downstream systems where every cross-boundary connection is an audit obligation
• Multi-terabyte, where backup operational impact is a real production concern
• Running 24/7 at consistent load
• Sensitive to query latency variability
• Running SQL Server Enterprise, where physical core licensing produces meaningful savings

For a deeper look at the security and data isolation implications, see our comparison of private vs. public cloud security.

Frequently Asked Questions

What does a managed SQL Server hosting provider actually manage? A managed provider handles the underlying infrastructure: server hardware, patching, backups, network configuration, monitoring, and performance tuning. You keep control over your databases and applications. Scope varies by provider. Confirm whether SQL Server licensing, the backup platform, security tooling, and disaster recovery are included or billed separately.

How does dedicated SQL hosting handle backups? At Concourse, SQL Server backups run through Rubrik integrated with Pure Storage. Rubrik triggers a Pure Storage snapshot through a brief VSS coordination point, then runs the entire backup against the snapshot rather than the live database. The SQL Server itself does no backup work, which means zero CPU or I/O impact on the production server during a backup. For multi-terabyte databases, this returns hours of production capacity that native backup operations would otherwise consume. Backups are application-consistent, support point-in-time recovery via transaction log backups, and are written to immutable, air-gapped storage that resists ransomware tampering.

Does dedicated SQL Server hosting include SQL Server licensing? At Concourse, SQL Server Enterprise licensing is included, billed on physical core counts. This avoids the hyperthreaded vCPU licensing trap that inflates SQL Server costs on most cloud VM types.

Is dedicated private cloud SQL hosting more expensive than public cloud IaaS? For steady-state, 24/7 SQL Server Enterprise workloads, dedicated private cloud typically produces lower total bills. Fixed monthly pricing, physical core licensing, and the absence of egress, storage, and per-IOPS surcharges eliminate the variable costs that inflate cloud spend. A bundled backup platform further closes the gap.

How do I migrate my SQL Server workload to a dedicated private cloud? Migration starts with a discovery process to inventory current workloads, dependencies, and performance requirements. From there, a migration plan is built with defined timelines and rollback procedures. Our cloud migration services cover the full process from planning through cutover, with a dedicated Technical Account Manager managing the environment once you are live.

Ready to Run the Numbers on Your Environment?

Talk to the Concourse team for a technical assessment. If you are running SQL Server on public cloud IaaS and dealing with integration complexity, compliance attestation overhead, backup operational pain, or bills that consistently exceed forecast, dedicated private cloud is worth the conversation.