On June 2, 2026, AWS removed a tax that had been baked into Amazon RDS for SQL Server since the service launched. Customers with their own SQL Server licenses can now run them on the fully managed RDS without paying for the license a second time. The mechanism is called Bring Your Own Media (BYOM); the savings are real (roughly 40 to 60 percent on the licensing portion for typical Standard and Enterprise workloads); the prerequisite is mandatory and non-trivial (active Software Assurance plus a manual ISO upload to S3); and Azure Hybrid Benefit still has one structural advantage that BYOM does not replicate. The same launch leaves Google Cloud as the only major cloud where the managed-PaaS BYOL path does not exist at all. This article walks through the mechanics, the savings math on a concrete instance, the parts of the bill BYOM does not touch, where Google Cloud now sits in the multi-cloud landscape, and where the migration from EC2 self-managed or License Included RDS makes sense for which workloads.
The change matters because the pre-BYOM situation was a long-running forced choice. Customers with on-premises SQL Server licenses and active Software Assurance could bring those licenses to AWS only on self-managed Amazon EC2, where Microsoft's License Mobility program had always been honored. The moment a customer wanted the managed RDS service (no patching, no backups to wire up, no high-availability replicas to operate), they had to abandon their license and pay for it a second time through the License Included pricing model. Azure SQL Managed Instance, by contrast, has supported the equivalent BYOL path through Azure Hybrid Benefit since 2019. That asymmetry produced years of "AWS or Azure" decisions where the licensing math was the load-bearing argument. BYOM closes the asymmetry on the managed-PaaS line item.
What changed in mechanical detail
The AWS Database Blog post by Srikanth Katakam and Colleen Betik, published June 2, 2026, describes BYOM as a custom engine version that AWS creates from a customer-supplied RTM installation media. The customer uploads the SQL Server ISO to an S3 bucket, hands AWS a pointer to it, and RDS spins up a managed instance running that media without charging the SQL Server license fee. AWS still charges for the underlying infrastructure (compute, storage, I/O, data transfer), the Windows OS license, and any RDS features the customer enables on top.
Three things distinguish BYOM from a vanilla BYOL. First, the customer supplies the media. Most BYOL flows take a customer license attestation and run the software off the platform's own media; BYOM is explicit that the platform consumes the customer's RTM ISO directly. Second, the prerequisite chain is heavier than a typical BYOL. Customer must hold an active SQL Server license (Standard or Enterprise) with active Software Assurance, submit a License Mobility Verification Form to Microsoft, and clear that verification before BYOM will accept the media. Third, the supported editions are deliberately narrowed. License Included supports Enterprise, Standard, Web, and Express. BYOM supports Enterprise, Standard, and Developer (Developer for non-production only). Web Edition is BYOM-excluded by design; customers running Web Edition on RDS stay on License Included.
The four asks RDS makes of a BYOM customer are, in order: active SA on the license, completed License Mobility verification, an English-language core-based RTM ISO in S3, and ongoing compliance monitoring through AWS License Manager. AWS does not block operations when license limits are exceeded; the BYOM model assumes the customer is the compliance owner. If RDS does terminate a BYOM instance for licensing reasons, restoration from the snapshot creates a new instance running under the License Included model, which produces an immediate cost shift back to the License Included rate. The compliance burden is not technical, it is administrative.
Multi-AZ deployments have no additional licensing requirement under BYOM, which is consistent with the License Included behavior. The AWS documentation states explicitly: "There are no additional licensing requirements for Multi-AZ deployments." This matters because a meaningful share of production SQL Server workloads run Multi-AZ for high availability, and license-doubling at the standby was a real concern in some prior BYOL programs on other platforms.
The four BYOM prerequisites in practical terms
The Software Assurance prerequisite is the gate that filters who BYOM is for. SA is the optional Microsoft program that adds upgrade rights, technical support, and (relevantly) License Mobility to a perpetual or subscription SQL Server license. Customers who bought SQL Server on Open License or Open Value without SA do not qualify. Customers with a Microsoft Enterprise Agreement that includes SA do. CSP subscription customers gained License Mobility on April 1, 2026 (more on that below), so they qualify under the subscription path even though they do not technically hold SA in the classical sense.
The License Mobility Verification Form is a Microsoft document submitted via the Volume Licensing Service Center or through the customer's Microsoft account team. The form attests that the licenses being moved are eligible (active SA, eligible edition, eligible volume) and triggers the License Mobility benefit on the back end. Customers who have not done this paperwork before should expect a multi-day turnaround, particularly if the license inventory is messy or split across multiple agreements.
The RTM ISO upload to S3 has specific requirements. The ISO must be English language and must be the core-based licensing variant (not the CAL-based variant). The download itself comes from the customer's Visual Studio subscription, the Microsoft 365 admin center, or the Volume Licensing Service Center. First-time setup of the custom engine version takes around 20 minutes from upload to availability. Once the custom engine version exists, future RDS instances using the same media spin up at normal RDS provisioning speed.
The ongoing compliance monitoring is the part most teams forget about. AWS does not enforce license limits at runtime, which is by design (the customer is the licensee, not AWS). Customers are expected to use AWS License Manager to track vCore-to-license consumption, particularly across multi-account organizations where SQL Server instances can proliferate without central visibility. The same skill set required to track License Mobility on EC2 self-managed BYOL applies; BYOM does not introduce a new compliance burden, it inherits the existing one.
The pre-BYOM situation: BYOL or managed, pick one
The pre-BYOM choice was operational, not just financial. Customers with on-premises SQL Server and active SA could deploy on AWS in two ways. Self-managed EC2 honored their existing license via License Mobility, but the customer owned the operational stack end-to-end: Windows OS patching, SQL Server patching, backup configuration, high-availability topology setup, monitoring, failover testing. The license bill was sane; the engineering bill was not.
Amazon RDS for SQL Server offered the managed alternative. Patching is on a customer-selected maintenance window. Backups are automatic with point-in-time recovery. Multi-AZ deployments handle high availability through SQL Server Database Mirroring, Always On Availability Groups, or block-level replication for Web Edition. Monitoring integrates with CloudWatch out of the box. The operational bill collapses; the license bill doubles, because the customer pays for the existing on-premises SA and the AWS License Included rate at the same time.
The forced choice ("operational efficiency or license efficiency, not both") drove customer behavior in three directions. Customers with strong DBA teams and tolerance for the operational lift stayed on self-managed EC2 with BYOL. Customers with weaker DBA teams and budget flexibility went to RDS with License Included and absorbed the double-payment. Customers with both constraints (small DBA team and tight budget) often chose Azure SQL Managed Instance, where Azure Hybrid Benefit had been honoring the same License Mobility right since 2019 on the managed PaaS tier.
BYOM removes the forced choice. The customer can have the managed RDS operational profile and reuse their existing licensed entitlement. The double-payment goes away. The decision criterion shifts from "operational vs license efficiency" to "what is the right RDS instance shape for this workload" because the licensing efficiency is no longer platform-dependent.
The savings math on a concrete instance
The headline savings range published in industry analysis is 40 to 60 percent on the licensing portion of the RDS line item for typical Standard and Enterprise workloads. To make that range concrete, take a db.r6i.2xlarge in us-east-1 on-demand. This is a memory-optimized RDS instance with 8 vCPUs and 64 GB of RAM, which is a common shape for a mid-sized production SQL Server workload.
Under License Included with SQL Server Standard Edition, the published rate sits at roughly 3.25 dollars per hour on-demand, which lands at roughly 2,370 dollars per month for the instance plus license (excluding storage, I/O, and data transfer). The compute and Windows OS portion of that figure is roughly 1.10 dollars per hour, derived from the equivalent db.r6i.2xlarge running PostgreSQL on RDS (which has no SQL Server license premium) plus a small Windows OS adder. The SQL Server Standard license premium under License Included is therefore roughly 2.15 dollars per hour or roughly 1,570 dollars per month.
Under BYOM on the same instance, AWS charges only the compute and Windows OS portion, which lands at roughly 1.10 dollars per hour or roughly 800 dollars per month. The customer continues to pay Microsoft for their existing SA on the SQL Server license, which is a sunk cost in the comparison (the customer was already paying SA whether they used LI or BYOM). The net savings on the AWS bill is roughly 1,640 dollars per month per instance, or roughly 19,700 dollars per year per instance. The percentage savings on the RDS line item is roughly 65 percent on this specific instance shape.
The savings get larger as the instance gets larger, because the SQL Server license premium scales linearly with vCount count under License Included, while the BYOM Windows OS adder stays roughly flat. The savings get even larger on Enterprise Edition, because the Enterprise per-core license premium is roughly four times the Standard premium, so the absolute dollar savings on a BYOM-vs-LI comparison for the same instance running Enterprise is roughly four times what the Standard math shows.
The savings get smaller (and can flip negative) for very small instances and for Web Edition. On a db.t3.medium (2 vCPUs) the absolute dollar savings is too small to justify the BYOM setup overhead for a one-instance deployment. On Web Edition there is no BYOM path at all. The savings calculation is workload-by-workload, not blanket.
For the reference floor, Microsoft's official Azure Hybrid Benefit page (the equivalent benefit on Azure SQL Database and Azure SQL Managed Instance) cites "up to 30 percent or more" savings against pay-as-you-go pricing. AWS does not publish an equivalent official percentage for BYOM. The industry analysis range of 40 to 60 percent reported by independent pricing aggregators sits above Microsoft's official Azure benchmark, which suggests AWS's License Included markup on SQL Server was somewhat richer than the Azure equivalent (consistent with the historical narrative that SQL-Server-on-AWS was deliberately priced as a tax on customers who chose AWS over Azure).
Where Azure Hybrid Benefit still wins
BYOM does not produce full pricing parity between AWS RDS for SQL Server and Azure SQL Managed Instance. Azure Hybrid Benefit retains one asymmetric advantage that has no AWS equivalent: the SQL Server Enterprise to Azure SQL MI General Purpose vCore multiplier.
Microsoft's documentation on Azure Hybrid Benefit states the rule directly: "SQL Server Enterprise Edition core customers with SA" can use "One core on-premises equals four vCores in General Purpose SKU." This is a 4-to-1 multiplier in the General Purpose tier of Azure SQL Managed Instance, designed for highly virtualized SQL Enterprise workloads where the customer's on-premises licensing footprint represented physical cores that mapped to many virtualized SQL instances. There is no equivalent multiplier in AWS BYOM; AWS counts vCores one-for-one against the SQL Server license.
For SQL Standard the multiplier is one-for-one on both platforms (one Standard core on-premises maps to one vCore on either Azure SQL MI General Purpose or AWS RDS BYOM). The asymmetric advantage is Enterprise-specific.
Practitioners deciding between RDS BYOM and Azure SQL Managed Instance for a highly virtualized SQL Enterprise workload should run the vCore-multiplier math on the specific shape they plan to deploy. A workload that maps to 32 vCores on a managed PaaS would consume 32 Enterprise cores under AWS BYOM but only 8 Enterprise cores under Azure SQL MI General Purpose. At Microsoft Enterprise list prices for Enterprise per-core licensing, that gap is substantial.
The honest framing is that AWS closed the most visible gap with Azure (managed BYOL on the PaaS tier), but Azure retains a structural advantage on the specific subset of highly virtualized SQL Enterprise workloads. For the broader population of SQL workloads (Standard Edition, one-to-four vCore mappings on either platform), the platforms are now comparable on the licensing line.
The parallel CSP change on April 1, 2026
A complementary licensing change took effect on April 1, 2026 that broadens the population eligible for BYOM. Microsoft extended License Mobility to SQL Server subscription licenses purchased through the Cloud Solution Provider (CSP) program. Before April 1, CSP-purchased SQL Server licenses were limited to on-premises or Azure deployment; License Mobility was a benefit reserved for Volume Licensing with active Software Assurance. After April 1, CSP subscribers can bring SQL Server subscription licenses to AWS, Google Cloud, or other Authorized Mobility Partners.
The CSP change matters because the CSP channel is heavily used by small and mid-sized businesses that do not have direct Enterprise Agreements with Microsoft. SMB customers who buy through a CSP partner (typically a regional Microsoft partner that handles licensing, billing, and basic support) now have the same License Mobility right that previously required an Enterprise Agreement. Combined with the AWS BYOM launch on June 2, those same SMB customers can now bring their SQL Server entitlements to AWS RDS without paying a second time.
One caveat the CSP change does not fix: perpetual SQL Server licenses purchased through CSP cannot have Software Assurance added after the fact, and without SA those licenses are not License Mobility eligible. The CSP change applies specifically to subscription SQL Server licenses, which include the equivalent of SA built into the subscription model. Customers with perpetual CSP licenses and no SA remain locked to on-prem or Azure.
The combined effect of the two changes (Microsoft CSP extension on April 1 plus AWS BYOM launch on June 2) is that the License Mobility right is more uniformly available across customer segments and across clouds than at any prior point. Customers who were structurally locked out of BYOL on AWS RDS by their licensing channel now have a path.
Where this leaves Google Cloud
Google Cloud is the only major cloud where you still cannot bring your SQL Server license to the managed PaaS service as of mid-2026. Cloud SQL for SQL Server, Google Cloud's managed SQL database service, is License Included only. There is no BYOM equivalent and no Azure-Hybrid-Benefit equivalent on the managed side. Customers running SQL Server on Cloud SQL pay roughly 0.13 dollars per vCPU-hour for the Standard edition license premium and roughly 0.47 dollars per vCPU-hour for Enterprise, on top of the underlying compute and storage. Microsoft's core-based licensing rules apply on the Google Cloud side as well: 4-core minimum per instance, and instances under 4 vCPUs are charged for SQL Server at 4 times the per-vCPU license rate to satisfy that minimum. Committed Use Discounts do not reduce the license premium portion.
BYOL for SQL Server on Google Cloud is available, but only on Compute Engine (the IaaS layer) through Microsoft License Mobility. This is the same path AWS had for years before the June 2 BYOM launch: a customer with active Software Assurance brings their license to a self-managed SQL Server instance on Compute Engine and owns the operational stack end-to-end. The Microsoft April 1, 2026 CSP licensing change extended this License Mobility right to CSP subscription licenses bound for Google Cloud, but the destination is still Compute Engine, not Cloud SQL.
The practical effect of the AWS BYOM launch is to leave Google Cloud as the structural outlier among the three hyperscalers on managed-PaaS SQL Server licensing. Before June 2 the gap was two-versus-one, with Azure offering managed BYOL via Azure Hybrid Benefit while both AWS and Google Cloud forced License Included on their managed services. After June 2 the gap is one-versus-two, with AWS and Azure both offering managed BYOL paths and Google Cloud holding the only License Included-only position. For multi-cloud customers comparing managed SQL Server options today, the operational-versus-license trade-off that AWS just resolved still applies on Google Cloud. Cloud SQL or BYOL on Compute Engine. Not both.
For Google Cloud customers running SQL Server on Cloud SQL today, the practical takeaway is awareness rather than action: no equivalent of BYOM has been announced for Cloud SQL, and the savings opportunity that AWS RDS and Azure SQL Managed Instance customers now have on managed PaaS is not available on Google Cloud's managed surface. The competitive question for Google Cloud product as the gap widens is whether the License Included-only stance on Cloud SQL for SQL Server is sustainable in mid-market accounts where SQL Server license cost is a material line item on the bill.
When migrating from self-managed EC2 to RDS BYOM makes sense
The migration calculus for customers running SQL Server self-managed on EC2 with BYOL is workload-specific. The trade-off is operational simplification (RDS handles patching, backups, Multi-AZ failover) against feature constraint (RDS supports a subset of SQL Server features) and against the specific RDS BYOM setup overhead (RTM ISO upload, custom engine version creation, License Mobility verification).
Migration is straightforwardly worthwhile for workloads where the SQL Server feature surface is well within RDS's supported set, the operational lift on EC2 has consumed meaningful DBA time, and the workload is large enough to amortize the one-time BYOM setup over a multi-month or multi-year run. A 32-vCore SQL Standard production database with active SA, three replicas, and a regular patch cadence that has historically eaten DBA hours fits the profile. The BYOM setup is a one-week project; the operational savings recur monthly.
Migration is worth scrutinizing for workloads with cross-database transactions to non-RDS SQL Server instances, FILESTREAM dependencies, Service Broker external activation patterns, or replication topologies where the BYOM RDS instance would need to be the publisher (RDS hosts SQL Server as a subscriber but has limited publisher capabilities). The mitigation in each case is to verify the specific feature against the current RDS for SQL Server feature support matrix before committing to the migration.
Migration is worth declining for workloads where the regulatory or compliance posture requires explicit change-window control over patches, where the customer's existing SQL Server tooling (third-party HA replication, audit collectors, security agents) is not certified against RDS, or where the workload runs SQL Server Web Edition (BYOM does not support Web, so the only RDS path is License Included, which removes the savings rationale for the migration).
When BYOM is NOT the right call
BYOM is not the right call when the customer does not have active Software Assurance. The prerequisite is hard, not soft. Customers without SA continue on License Included or stay self-managed on EC2 without BYOL. The path to BYOM eligibility in that case is to add SA at the next license renewal cycle, which has its own cost-benefit calculation independent of the AWS migration question.
BYOM is not the right call for ephemeral or dev-test workloads where SQL Server Express is functionally sufficient. Express is free, requires no license entitlement at all, and runs on License Included on RDS at the lowest pricing tier. The BYOM Developer Edition path is sometimes proposed for dev-test, but Express on License Included is usually cheaper after accounting for the BYOM setup overhead and the Developer Edition's non-production constraint.
BYOM is not the right call for Web Edition workloads. AWS does not offer a BYOM path for Web Edition; the only RDS path is License Included. Customers running Web Edition who want license efficiency should evaluate either staying on EC2 self-managed (if the operational profile allows) or migrating to Standard Edition on RDS BYOM (if the workload requirements allow).
BYOM is not the right call when the License Included markup is small enough that the BYOM setup overhead is not amortizable. Very small instances (db.t3.small or db.t3.medium with light workloads) have a small absolute SQL Server license premium under LI, and the one-time BYOM setup costs (License Mobility verification, RTM ISO procurement and upload, custom engine version creation) typically erase the savings on a single small instance over a one-year horizon. The threshold below which BYOM stops being economically rational depends on the customer's labor rate for the setup work, but a useful rule of thumb is that a workload below roughly 4 vCores of SQL Standard or 2 vCores of SQL Enterprise is in the gray zone.
Where to Start
If your AWS bill includes SQL Server line items today, the first step is to make those line items visible at the right granularity. The standard FOCUS-normalized billing approach surfaces every License Included instance, every BYOM instance, and the corresponding compute, storage, and data transfer adjacent line items across all your AWS accounts in a single view. The cross-account dimension matters because SQL Server workloads often proliferate across project accounts, dev accounts, and acquired-company accounts in ways that are invisible in any single account's bill.
Once the line items are visible, the workload-by-workload migration calculus described above can be applied with real numbers. The Cost Scout agent surfaces anomalies and waste patterns on the FOCUS layer today. License-aware optimization (a recommendation pattern that surfaces specific BYOM migration opportunities for License Included instances where the customer's underlying SQL Server entitlement supports it) is on the Brain Agents AI post-beta roadmap as a Savings Advisor recommendation category. The Weekly Briefing agent surfaces the cost shift in the week-over-week summary once a migration happens, which makes the finance-team reconciliation cleaner.
For multi-cloud customers comparing AWS RDS BYOM against Azure SQL Managed Instance with Azure Hybrid Benefit, FOCUS-normalized billing data makes the like-for-like comparison possible without manually reconciling the two providers' billing exports.
The change AWS shipped on June 2 was a long time coming. The structural gap between AWS and Azure on managed SQL Server BYOL is closed for the population that has SA today. The savings are real, the prerequisites are manageable, and the one remaining Azure advantage on highly virtualized SQL Enterprise is now small enough that the choice between platforms can finally be made on the merits of the platform rather than on the load-bearing weight of a single licensing line item.