SQL Server Patching on AWS vs On-Premises: Why the Tools Don't Transfer

When companies move SQL Server workloads to AWS EC2, they usually bring their patching process with them. WSUS, SCCM, or a homegrown PowerShell script that's worked for years. A few weeks in, they discover the process doesn't translate. Patches miss instances. Schedules drift. Audit logs disappear. The same team that had a handle on their on-premises SQL Server fleet is suddenly behind.

This isn't a skills problem — it's an architecture problem. AWS EC2 is meaningfully different from on-premises infrastructure in ways that break the assumptions behind most enterprise patching tools. Understanding those differences is the first step to building a process that actually works in the cloud.

What on-premises tooling assumes

WSUS and SCCM were designed for a world where servers live in your data center, join your Active Directory domain, and stay there. They make specific assumptions: agents installed on every managed machine, reliable network connectivity to a central management server, persistent machine identities that don't change, and a relatively static inventory that someone manages manually.

Those assumptions made sense when they were designed. On-premises infrastructure is mostly stable. Servers are named, racked, and stay put. Your SCCM client has been running on that server for three years without issue.

AWS EC2 violates almost all of these assumptions — not because AWS is poorly designed, but because it was built for a different operational model.

Where the assumptions break

Domain membership is optional and often absent

On-premises SQL Server environments are nearly always Active Directory-joined. WSUS and SCCM depend on this — group policy, SCCM client enrollment, and software distribution all flow through AD.

On AWS, many EC2 instances are never domain-joined. They authenticate via IAM instance profiles, and access to other AWS services goes through role-based policies rather than Kerberos. If your patching process requires AD membership, a significant portion of your EC2 fleet simply won't be in scope.

Inventory is dynamic and often incomplete

On-premises inventory management is mostly a solved problem. Servers get added to SCCM when they're provisioned, and they stay there until they're decommissioned. The inventory is relatively accurate because the environment is relatively static.

EC2 environments are not static. Instances get launched by developers running infrastructure-as-code templates. Auto-scaling groups spin up new instances automatically. Disaster recovery instances get promoted. None of these show up in your patch management inventory unless someone explicitly adds them — and in practice, nobody does.

The result is a fleet where your patching tool manages the instances you remember to tell it about, and everything else accumulates drift.

WSUS and SCCM handle the OS, not SQL Server

This is the most important gap, and the one that surprises teams most often. WSUS and SCCM are designed to deliver Windows Updates — OS patches, security rollups, .NET updates. They are not designed for application-level patching of SQL Server.

SQL Server cumulative updates are distributed as standalone installers, not as Windows Update packages. They require the SQL Server installer engine, service restarts, and post-install validation. WSUS has no concept of these. You can use SCCM's software distribution features to deploy SQL Server CUs, but this requires custom packaging, maintenance window configuration, and manual catalog management — none of which SCCM provides out of the box for SQL Server.

Most teams discover this when they run a WSUS compliance report and see green across the board for their SQL Server hosts, while the SQL Server builds themselves are six CUs behind.

Network reach is not guaranteed

WSUS clients need to reach the WSUS server. SCCM clients need to reach the management point and distribution points. In on-premises environments, this is a given — everything is on the same corporate network.

In AWS, it's not. EC2 instances in private subnets may have no path to your on-premises WSUS server unless you've configured VPN, Direct Connect, or Transit Gateway routing. Even with those in place, firewall rules, security groups, and routing tables can block the connection silently.

Teams often don't notice this until they check WSUS and find that half their EC2 instances haven't reported in for 30 days.

What AWS provides instead

AWS Systems Manager is the native answer to remote management on EC2. The SSM Agent runs on most modern Windows AMIs by default, communicates outbound over HTTPS (no inbound ports required), and doesn't need domain membership or VPN to work. For OS-level patching, SSM Patch Manager fills the WSUS role reasonably well.

But SSM Patch Manager has the same blind spot as WSUS: it manages Windows Server patches, not SQL Server application patches. It will keep your Windows Server current while your SQL Server builds fall behind.

For SQL Server CU patching on EC2, the gap is real and AWS has no native, managed solution for it. The options are building your own automation (Lambda + SSM Run Command + EventBridge + a CU catalog you maintain manually) or using a purpose-built tool.

What a cloud-native SQL Server patching process needs

Rather than trying to make on-premises tools work in AWS, the more reliable approach is to design around AWS primitives from the start:

SSM Run Command instead of SCCM software distribution — no agent to install beyond what's already on modern Windows AMIs, no inbound firewall rules, works across accounts and regions.

Dynamic discovery instead of static inventory — automatically find SQL Server instances by querying SSM inventory or EC2 tags, so new instances don't fall through the cracks.

A managed CU catalog instead of manual tracking — something that knows the current recommended build for SQL 2016, 2017, 2019, 2022, and 2025 and can compare that against what's running on each instance.

IAM-based access control instead of AD-based — cross-account IAM roles eliminate the need for domain membership, VPN tunnels to on-prem, and SCCM infrastructure.

Structured audit logging instead of SCCM reports — every patch action logged with instance ID, build before, build after, result, and timestamp, available for compliance queries without digging through SCCM databases.

The transition

Most teams don't rip out WSUS or SCCM for their EC2 fleet on day one. They continue using it for OS patches while acknowledging the SQL Server gap and building something to fill it. That's a reasonable intermediate state as long as the gap is acknowledged and tracked.

The risk is treating the familiar tool as complete coverage when it isn't. If your patch compliance report comes from WSUS and WSUS doesn't see SQL Server CUs, you have a compliance gap that doesn't show up in your reporting — which is the worst kind of gap to have going into an audit.

PatchPilot was built specifically for this gap: SQL Server CU patching on AWS EC2, using SSM for all remote execution, with discovery, compliance tracking, scheduling, and audit logging designed for cloud environments rather than adapted from on-premises tooling.

Try it free for two weeks — setup takes about 20 minutes and doesn't touch your existing Windows patching process.