SQL Server on AWS: A Practical BYOL Decision Guide

I've had this conversation quite a few times now. Not very frequent, but reasonable times that I thought I would blog about it.

Most of the times the discussion is with someone running dozens of SQL Server Enterprise instances on AWS, where the licensing cost is quietly eating 40-60% of their EC2 spend. Something that needs proper attention.

The question they always ask is some version of: "Should we be doing BYOL?"

And the honest answer, the one that actually serves them, is: it depends on five things you probably haven't measured yet.

I'm going to walk through the full decision here. The actual version, with the caveats that change everything.

First, the thing nobody tells you upfront

Microsoft SQL Server Enterprise Edition costs roughly 4x more than Standard per core. When you're on AWS and using License Included AMIs, that cost is baked into your EC2 hourly rate, so it looks like compute spend rather than licensing spend. Finance and engineering both see a single line item, and nobody's really interrogating what's inside it.

That's the first problem. The second problem is that most of the SQL Enterprise instances I see in the wild don't actually need Enterprise. They're on Enterprise because that was the safe default when the server was provisioned, and nobody went back to check.

AWS Compute Optimizer now has a feature specifically for this. It deploys a lightweight service on your EC2 instance and checks whether any Enterprise-exclusive features are actually running, things like Always On Availability Groups, Resource Governor, buffer pools over 128 GB, and read replicas. If none of those are active, it flags the instance as "license over-provisioned" and recommends downgrading to Standard.

I'd run that audit before touching anything else. Edition downgrade is a bigger win per instance than BYOL optimization, and it requires no infrastructure change, just a SQL Server reinstall with a Standard license.

With that out of the way, here's the BYOL decision.

The one thing that changes if you have active Software Assurance

Most BYOL guidance starts with Dedicated Hosts. That framing makes sense for Windows Server because Windows genuinely has no other path and requires dedicated infrastructure. But SQL Server with active Software Assurance (SA) is a different animal entirely.

Active SA gives you License Mobility, which means you can BYOL your SQL Server licenses on standard shared EC2 tenancy with no Dedicated Host, no host packing exercise, and no fixed infrastructure commitment. You just bring your licenses, deploy on regular EC2, pay zero SQL licensing to AWS, and submit a License Mobility Verification Form to Microsoft within 10 days of going live.

That 10-day form is not optional. Missing it is an audit risk. But it's a Word document and not a big deal once you know it exists.

The point is: if you have active SA, the question "should we do BYOL?" is really two separate questions. Should we do License Mobility on shared tenancy? Or should we go further and move to Dedicated Hosts for physical-core licensing efficiency? Those are different decisions with different economics, different complexity, and different risk profiles, and they deserve separate answers.

Before the decision tree: check your HA setup first

If any of your SQL servers are running in Always On Availability Groups or Failover Cluster Instances, which for most production fleets is almost certain, you may be paying for standby SQL licenses you don't need to pay for at all.

With active Software Assurance, Microsoft's passive failover benefit lets you run one passive standby instance per active server without licensing the SQL Server portion on the standby. The standby still incurs compute and Windows costs, but the SQL piece, which is the expensive part, is free as long as the passive node is truly passive and not serving read traffic.

If your secondaries are serving reporting workloads, they're not passive and they need to be licensed. This is worth verifying specifically, because it's a common assumption that gets expensive when Microsoft audits it.

For License Included deployments, AWS now has the EC2 High Availability for SQL Server feature that automates this. It uses Systems Manager to detect which node is active and which is passive, and waives the SQL LI fee on the passive node automatically. That's up to 40% HA cost reduction with no architecture change, just an IAM policy and SSM Agent. Minimum requirements are SQL Server 2017 or newer and Windows Server 2019 or newer.

Settle the HA question first. That saving exists regardless of which licensing path you choose next.

The decision tree

Here's how I'd walk a prospect through it. Five gates, each with a real answer that points somewhere different.

Gate 1: Does SQL BYOL actually beat License Included after SA costs?

This is the gate most people skip. They see the licensing cost on an LI instance, subtract it, and declare victory. What they forget is that Software Assurance renewal runs 20 to 25% of original license purchase value every year. That's real money. On a large SQL Enterprise estate, SA renewal can run $5,000 to $10,000 a month. If your SA renewal cost is high relative to your fleet size, License Included might actually be cheaper.

You need your actual SA renewal figure from your Microsoft EA, not an estimate, before this calculation is meaningful. Without it, you're comparing against a made-up number.

If BYOL doesn't beat LI after SA costs: License Included. Done. Don't complicate it.

Gate 2: Can you fill a Dedicated Host?

If BYOL does beat LI, the next question is whether Dedicated Hosts are worth the complexity. The economics of a Dedicated Host are fixed costs and you pay per host whether it's running 2 instances or 12. Packing density is everything.

For SQL Enterprise specifically, you need roughly 8 or more instances on the same host family to justify the host overhead. Below that, License Mobility on shared tenancy gives you the SQL BYOL benefit without the fixed infrastructure cost and without the density constraint.

If you can't fill a host: License Mobility on shared tenancy. Simpler, more flexible, still eliminates the SQL LI component.

Gate 3: Are these workloads stable and running 24/7?

Dedicated Hosts are not for variable workloads. The host charges the same whether your instances are running flat-out or sitting idle during off-peak hours. If any of these servers have pronounced peaks and troughs, like batch processing, end-of-month loads, or seasonal patterns, a fixed-cost host works against you.

Shared tenancy scales with usage. A host doesn't.

If the workloads are variable: License Mobility on shared tenancy.

Gate 4: Can you commit to 1 to 3 years?

On-demand Dedicated Host pricing is expensive. Reserved Dedicated Hosts cut that cost by 50 to 70% depending on term. Without a reservation, the host premium over shared tenancy is large enough to seriously narrow your BYOL advantage.

If no commitment is possible: License Included on-demand or License Mobility on shared tenancy. Don't take a Dedicated Host at on-demand rates unless you have a specific short-term reason.

Gate 5: Is average CPU utilization below 50%?

If you pass all four gates above, there's one more lever worth checking before finalizing your host architecture. AWS's Optimize CPU feature lets you disable hyperthreading on an instance, cutting the visible vCPU count in half. Since SQL Server licenses per vCPU, or per physical core on Dedicated Hosts, cutting visible cores cuts your license count directly.

On a Dedicated Host, an R5 or x2iezn host with hyperthreading disabled presents physical cores only, so 48 physical cores instead of 96 vCPUs. You license 48 cores. You can still run the same instances on that host, they just see fewer cores. If your workloads are memory or IO-bound and under-utilizing CPU, this compounds your savings further.

If CPU utilization is consistently above 70 to 80%, don't use Optimize CPU because you'll actually need those cores. But if it's below 50%, this is worth running.

Pass all five gates: Dedicated Host BYOL with Optimize CPU. That's the maximum savings path, typically 50 to 60% below full License Included pricing when you include the reserved host discount and physical core licensing.

The cost model: three scenarios side by side

I always run these three scenarios for any prospect before recommending a path, not with generic numbers but with their actual instance sizes, their actual region, and their actual SA renewal figure.

Use the calculator below to model these three scenarios for your own fleet.

Scenario A: License Included (baseline)

Monthly cost per instance = Compute + Windows LI + SQL Enterprise LI

SQL Enterprise LI is billed per vCPU with a minimum of 4 cores. For a 16-vCPU instance in us-east-1, SQL Enterprise LI alone runs roughly $1,400 to $1,800 per instance per month. For 60 instances, that's $84,000 to $108,000 a month just in SQL licensing.

Scenario B: License Mobility on shared tenancy

Monthly cost per instance = Compute + Windows LI + (SA cost / 12 / instance count)

You eliminate the SQL LI component but add back your SA monthly allocation. If your annual SA renewal is $600,000 across 60 instances, that's $10,000 a month or roughly $833 per instance. Net saving versus Scenario A: roughly $600 to $900 per instance per month on a 16-vCPU machine. Across 60 instances, that's potentially $36,000 to $54,000 a month. Real, but lower than the gross number suggests.

Scenario C: Dedicated Host BYOL with physical-core licensing

Monthly cost per host = Host charge / instances packed + SA allocation

The physical-core licensing advantage: on an x2iezn Dedicated Host with 24 physical cores and 48 vCPUs, you license 24 cores, not 96 vCPUs. You cover all SQL instances on that host with those 24 core licenses. The host charge itself, on a 3-year reservation, runs roughly $5,500 to $8,000 a month depending on family and region. If you pack 8 to 12 instances on that host, the per-instance infrastructure charge is modest.

The combined saving versus Scenario A: 50 to 60% in well-run deployments. But this requires the density, the stability, and the commitment, all three, to actually land there.

The things I wish more people said out loud

Software Assurance renewal costs belong in the model. Every time. Not as a footnote.

The 65% savings headlines you see from AWS come from best-case scenarios: full host utilization, 3-year reservation, Optimize CPU enabled, physical-core licensing, compared against on-demand LI pricing. Real-world savings for a well-run deployment are 40 to 55%. Still compelling, but model it honestly.

The passive node benefit is probably the fastest win for any large SQL Server fleet running HA. It doesn't require a new licensing path and it doesn't require architecture changes. It just requires knowing it exists and verifying your standby nodes are actually passive.

Edition downgrade audit should happen before BYOL analysis. Not instead of it, before. There's no point optimizing the licensing path on an instance that shouldn't be on Enterprise in the first place.

And finally: get the actual SA renewal number from the Microsoft EA. Not 20% of a rough license estimate. The real number, from the document. Every savings calculation changes when you put the real number in.

What to do right now

If you're running SQL Server Enterprise on AWS in production, here's the sequence I'd follow.

Enable AWS Compute Optimizer with CloudWatch Application Insights, give it 24 hours, then look at the License Recommendations tab to find out which instances actually need Enterprise.

Pull your annual SA renewal figure from your Microsoft EA.

Check how many of your instances are in HA pairs and whether the standbys are truly passive. If they're on SQL Server 2017 or newer and Windows Server 2019 or newer, enable the EC2 High Availability for SQL Server feature on your License Included deployments.

With those three inputs, run the cost model across all three scenarios for your actual fleet. Use the AWS Pricing Calculator for the compute and host numbers. It supports Dedicated Host BYOL estimation natively since 2023.

Then make the decision.

The right path for your fleet is probably not all Dedicated Hosts or all License Mobility or all License Included. It's almost certainly a hybrid, and the hybrid that makes sense for you comes from the actual numbers, not from a vendor's headline savings figure.

At CloudYali, we track SQL Server licensing costs as a first-class signal across cloud spend, because it's one of the few places where the wrong decision quietly compounds month after month without triggering any obvious alert. If you're unsure where your SQL licensing cost sits relative to what it should be, that's exactly the kind of visibility we're built to give you.