Thank you this articles sponsor!

Introduction

Licensing Microsoft SQL Server is hard enough on prem. In the cloud, it’s even trickier. Instance sizes can change by the hour, high availability introduces extra nodes to license, and the way Microsoft counts cores and mobility rights isn’t always intuitive. Add in multiple deployment models on AWS, each with different licensing rules, and it’s easy to overpay or drift out of compliance.

Microsoft’s licensing terms have also evolved, especially since changes introduced in and after October 2019 that affect how customers can bring licenses to “Listed Providers” such as AWS. The net result: whether you can reuse existing SQL Server licenses in AWS depends on details like Software Assurance, License Mobility eligibility, edition, and when your licenses were acquired.

This article demystifies your options on AWS including Amazon RDS for SQL Server vs. running SQL on Amazon EC2, License Included vs. Bring Your Own License (BYOL), and highlights the biggest cost drivers and savings levers. You’ll get practical guidance on when each path makes sense, how to stay compliant, and where customers most often leave money on the table.

Understanding SQL Server Licensing Basics

SQL Server licensing in AWS primarily follows two models. The per core model requires you to license every core that runs SQL Server, sold in two core packs, with a minimum of four core licenses per virtual machine or operating system environment. This model does not require client access licenses and is well suited for internet facing or hard to count user populations. It is required for Enterprise edition and is the most common approach in cloud and virtualized environments. The Server and CAL model requires one Server license per virtual machine or operating system environment plus a client access license for every user or device that connects. CALs must be the same or a newer version than the SQL Server instance they access, and external users typically need either individual CALs or an External Connector. In shared public cloud this model is often impractical, so most customers default to per core licensing, but you should confirm current Microsoft Product Terms before planning to use Server and CAL in AWS.

Edition choice influences both features and licensing options. Enterprise edition delivers advanced high availability, disaster recovery, performance, and security capabilities and is licensed only per core. With Software Assurance and when licensing physical cores on dedicated hosts, Enterprise can unlock broader virtualization rights. Standard edition offers a core feature set for most line of business applications and can be licensed either per core or with Server and CAL. Developer edition is functionally equivalent to Enterprise but is free for non production development and testing and cannot be used for production. Express edition is also free, with resource and database size limits, and is not intended for heavy production use.

There are several important rules to understand before moving to AWS. When licensing virtual machines you must license all virtual CPUs assigned to the SQL Server virtual machine, with a four core minimum per virtual machine. SQL Server does not use a core factor multiplier, so you count virtual CPUs as cores. Bringing your own license into shared cloud infrastructure usually requires active Software Assurance through License Mobility rights. Microsoft policy changes that took effect after October 2019 affect what you can bring to providers like AWS and may depend on when your licenses were purchased, whether you have Software Assurance, and the tenancy type, so always verify the current terms.

If you choose the Server and CAL model in the cloud, remember that CALs are still required and that multiplexing through connection pooling or middleware does not reduce CAL requirements. High availability and disaster recovery topologies can change license counts. With Software Assurance, one truly passive failover replica for each licensed primary may not require additional SQL Server licenses, but details vary by configuration and features, so validate your architecture against the current rules. The ninety day license reassignment rule can complicate frequent resizing or moving of workloads. License Mobility under Software Assurance offers more flexibility, but you should confirm the current reassignment rights. Software Assurance also provides upgrade rights, while downgrade rights allow you to deploy older versions for application compatibility needs. Finally, remember that Windows Server licensing is separate from SQL Server licensing. Bring your own license for Windows on shared tenancy has its own restrictions, so plan operating system licensing separately from SQL Server.

AWS Deployment Options for SQL Server

Amazon RDS for SQL Server offers a managed service with license included pricing. AWS supplies the SQL Server licenses as part of the hourly or per second rate, and handles routine operations such as automated backups, patching, monitoring, and Multi AZ high availability. This model reduces administrative overhead and simplifies compliance because you are not tracking individual SQL licenses. It works well for most line of business workloads that can run within the managed constraints and that benefit from predictable pay per use pricing.

RDS does come with functional limitations that matter for some architectures. You do not get operating system level access and the sysadmin role is restricted, which affects certain server level configurations and third party agents. Features such as SQL Server Reporting Services and SQL Server Analysis Services are not supported, and Integration Services support is limited compared to self managed deployments. HA on RDS for SQL Server is delivered through managed technologies under the covers rather than through a customer managed Windows Server Failover Cluster, which simplifies operations but reduces fine grained control.

Running SQL Server on Amazon EC2 gives you full control of the operating system, storage layout, and SQL Server configuration. You can choose license included Amazon Machine Images where the cost of SQL Server is baked into the instance price, or you can bring your own licenses when you are eligible. This path allows you to use the full SQL Server feature set including Reporting Services, Analysis Services, and Integration Services, install custom extensions and agents, tune the OS, and design your own high availability approach with Windows Server Failover Clustering and Always On Availability Groups across Availability Zones or Regions.

EC2 is the better choice when you need features that RDS does not support, when you require low level control for performance tuning or security tooling, when you need a specific patch cadence, or when you want to consolidate many databases on large instances with custom storage designs. It is also the right fit when you plan to use existing SQL Server licenses under eligible Bring Your Own License terms, or when you need advanced Enterprise edition features that are easier to manage with full server access.

RDS is generally the right starting point when you want a managed experience with minimal operational burden and a straightforward license included model. Choose it for standard workloads that fit within its feature set and for teams that prefer to offload backups, patching, and failover orchestration to AWS. Choose EC2 when control, feature completeness, and architectural flexibility outweigh the convenience of a managed service, or when licensing strategy and economics favor a Bring Your Own License approach.

Bring Your Own License in AWS

Bring Your Own License for SQL Server on AWS is centered on Amazon EC2. Amazon RDS for SQL Server is a license included service and does not accept customer supplied SQL Server licenses. If you want to reuse existing SQL Server entitlements, your path is to run SQL Server on EC2 and apply the correct Microsoft rights to that environment.

Eligibility for Bring Your Own License on shared EC2 infrastructure generally requires SQL Server licenses with active Software Assurance under Microsoft License Mobility. License Mobility grants the right to deploy eligible application server products like SQL Server on shared cloud infrastructure operated by third party providers such as AWS. Without Software Assurance, most customers cannot place SQL Server licenses on shared EC2. In that case you would typically use license included EC2 images or consider EC2 Dedicated Hosts if your licenses and agreements allow it. Licenses purchased after October 2019 are subject to updated Microsoft outsourcing terms that restrict deployment on listed providers without Software Assurance. Some entitlements acquired before that date may retain legacy rights on dedicated hardware, but the details depend on your specific agreements, so you should validate your situation with your licensing partner. Also note that OEM licenses and many retail licenses without Software Assurance do not include License Mobility and are usually not eligible for shared cloud use.

License Mobility through Software Assurance has both process and technical requirements. You must assign the correct number of SQL Server core licenses to the virtual machine and observe the minimum of four core licenses per virtual machine. If you use the Server and CAL model, you still need CALs for every user or device that connects, and multiplexing through connection pools or middleware does not remove that requirement. Microsoft expects customers to submit a License Mobility verification form naming AWS as the authorized provider shortly after deployment, and you should keep proof of entitlement and Software Assurance current for audit purposes. The ninety day license reassignment rule still applies, so frequent instance resizing or moving workloads between instances can have compliance implications unless you plan carefully.

If you do not meet the conditions for License Mobility on shared infrastructure, EC2 Dedicated Hosts provide an alternative because they give you visibility and control at the physical host level. With Dedicated Hosts you can assign your own SQL Server core licenses to the physical cores of a host and then run multiple virtual machines on that host. When you license all physical cores of a host with Enterprise edition and maintain active Software Assurance, you gain the broad virtualization rights that allow you to run any number of SQL Server virtual machines on that licensed host. With Standard edition you can either license each virtual machine by its assigned vCPUs or license all physical cores, but there is no unlimited virtualization grant. Dedicated Hosts also help you align to Microsoft requirements for host level affinity and provide integration with AWS License Manager to track license consumption.

It is important to distinguish Dedicated Hosts from Dedicated Instances. Dedicated Instances run on single tenant hardware but do not expose host level details that Microsoft requires for physical core licensing and unlimited virtualization rights. If your goal is to use host based licensing to consolidate many SQL Server virtual machines

Cost Considerations

The first cost decision in AWS is whether to use license included options or to bring your own licenses on EC2. With license included, the SQL Server entitlement is bundled into the instance price and you pay only while the instance is running, which simplifies budgeting and avoids upfront purchases. Bring your own license on EC2 can be more economical when you already own core licenses with active Software Assurance and plan to run steady state workloads, because you pay AWS only for infrastructure while continuing to use entitlements you already have. The trade off is that you assume responsibility for compliance, license tracking, and the mobility requirements that come with Software Assurance.

Instance size and scaling choices directly drive SQL cost. In license included models the hourly rate generally grows with vCPU count and memory. In bring your own license scenarios you must cover every visible vCPU with core licenses, subject to the four core minimum per virtual machine. Oversizing doubles costs faster than expected, so right sizing is critical. Profile CPU, memory, and storage throughput, choose instance families that match your workload, and scale out only when you can fully utilize additional cores. When consolidating multiple databases, test whether you are actually improving core utilization or simply moving idle capacity onto a larger and more expensive server.

Savings Plans and Reserved Instances can materially reduce costs for both RDS and EC2 when you have steady usage. For RDS, Reserved Instances are applied at the database instance level. For EC2, Savings Plans or Reserved Instances discount your compute spend for covered instance families and regions. Treatment of embedded software charges can vary by service and purchasing option, so review the current pricing details to understand how discounts apply to your chosen deployment. For Dedicated Hosts, Host Reservations can reduce hourly host charges, which is useful when you plan to stack many SQL virtual machines on a licensed host.

Several practical tips help optimize cost without violating licensing rules. Prefer Standard edition where its feature set is sufficient and reserve Enterprise edition for workloads that truly need its capabilities. Right size cores aggressively and consider instance families with stronger per core performance so you can meet service level objectives with fewer cores. Match storage to workload needs by using gp3 with tuned throughput and IOPS or provisioned IOPS only where required, and avoid overprovisioning high cost storage tiers. Shut down non production systems outside business hours, and use Developer edition for development and test where permitted. For high availability, take advantage of the passive replica benefit with Software Assurance when the secondary is truly passive, and document that configuration for audits. Use AWS License Manager to track assignments and renewal dates, submit License Mobility verification on time, observe the ninety day license reassignment rule, and keep evidence of entitlement current.

Best Practices

Begin every migration or deployment by validating the current Microsoft Product Terms and any program specific guidance for AWS. Licensing rules change and your eligibility to bring licenses or to use specific benefits such as passive failover rights depends on the exact terms you hold at the time of deployment. Keep an authoritative record of your entitlements, Software Assurance status, version rights, and proof of purchase so that you can respond quickly to audits.

Establish strong license governance in AWS. Use AWS License Manager, AWS Config, and Systems Manager Inventory to track where SQL Server is installed, how many vCPUs are assigned, and which instances are covered by bring your own license. Tag resources with fields such as license model, edition, Software Assurance status, and mobility form submitted to make reporting reliable. Submit License Mobility verification promptly when required and observe the ninety day license reassignment rule. Align change management so that resizing, rehosting, or failover events do not accidentally create unlicensed states.

Design architecture with licensing in mind. Consolidate databases thoughtfully to improve core utilization, but verify that consolidation does not create contention or push you into Enterprise edition unnecessarily. Prefer Standard edition when its features meet your needs and reserve Enterprise edition for workloads that require advanced capabilities. Choose instance families with strong per core performance so you can meet service level objectives with fewer cores, and right size regularly based on actual metrics rather than peak assumptions.

Plan high availability and disaster recovery carefully. If you rely on the passive replica benefit with Software Assurance, ensure that the secondary remains truly passive with no production read workloads and document that configuration. On RDS, understand how Multi AZ is licensed within the service. On EC2, document which nodes are licensed, how failover will occur, and how you will remain compliant during planned and unplanned events. Test failovers to confirm that automated actions do not violate your licensing plan.

Keep patching and lifecycle management front and center. Apply cumulative updates and security fixes on a regular cadence, and use supported versions to avoid compliance and support gaps. Use Developer edition for development and test where allowed, and shut down non production systems outside business hours to control compute and license included spend. Review deployments periodically to retire unused instances, right size over time, and confirm that edition choices still match workload requirements.

If you use Dedicated Hosts for host based licensing, maintain host affinity and placement controls so that virtual machines do not spill onto unlicensed hardware. Track physical core counts, keep Software Assurance current, and reconcile host utilization so that you get the expected consolidation benefit. Automate guardrails with infrastructure as code to prevent launching the wrong images or tenancy type for your chosen license model, and maintain separate golden images for license included and bring your own license builds to simplify compliance.

Common Pitfalls to Avoid

A frequent mistake is assuming existing SQL Server licenses can move into AWS without restriction. In most cases you need active Software Assurance and License Mobility rights to deploy SQL Server on shared EC2 infrastructure. Policy changes introduced after October 2019 further limit what you can bring to listed providers such as AWS, and many OEM or retail licenses without Software Assurance are not eligible. Always confirm eligibility before planning a bring your own license strategy.

Another common pitfall is confusing Dedicated Instances with Dedicated Hosts. Dedicated Instances provide single tenant hardware but do not expose the host level control Microsoft requires for physical core licensing and unlimited virtualization rights. If your goal is to license physical cores and run many virtual machines on a single host, you need Dedicated Hosts, active Software Assurance, and you must license all physical cores on that host. Skipping any of these conditions can invalidate your consolidation math and your compliance posture.

High availability and disaster recovery architectures often lead to accidental noncompliance. The passive replica benefit under Software Assurance applies only when the secondary is truly passive and not serving production reads or other active workloads. Running reports, ad hoc queries, or backups that impose production activity can require additional licenses. Always document which nodes are licensed, how failover occurs, and how you will maintain compliance during both planned and unplanned events. On RDS, understand how the service prices Multi AZ and what is included so you do not double count or assume free capacity that is not actually free.

Miscounting cores and ignoring minimums creates avoidable cost or risk. Every virtual machine has a four core minimum for SQL Server licensing, and in bring your own license scenarios you must cover every visible vCPU. Frequent resizing or host moves can also run into the ninety day license reassignment rule, so plan scale events carefully. Failing to submit License Mobility verification or to keep entitlement documentation current is another easy way to fail an audit.

Choosing Enterprise edition by default can inflate costs dramatically. Many workloads run well on Standard edition when architected properly, and paying for Enterprise features that you do not use is one of the fastest ways to overspend. Evaluate the specific capabilities your application truly needs before committing to an edition.

Assuming RDS will support every SQL Server feature is another source of surprises. RDS for SQL Server restricts server level access and does not support components such as Reporting Services or Analysis Services, and Integration Services support is limited. If you need those capabilities or deep operating system control, run SQL Server on EC2 instead of forcing an ill fitting managed service.

Server and CAL licensing can cause compliance gaps when teams believe that connection pooling or middleware reduces the number of required CALs. Multiplexing does not remove CAL requirements, and external users generally need their own CALs or an appropriate external connector. If you choose Server and CAL, track users and access patterns with the same rigor you would apply on premises.

Finally, treating Windows Server and SQL Server as a single entitlement leads to planning errors. Operating system licensing is separate, and bring your own license for Windows in shared tenancy has its own rules and limits. Combine that with weak tagging, poor inventory, and inconsistent change control, and you have a recipe for license drift and unplanned cost. Establish governance early so you can prove compliance and keep spend under control.

Conclusion

Licensing SQL Server on AWS comes down to choosing the right mix of service, tenancy, and entitlement model for each workload. Amazon RDS for SQL Server simplifies operations with license included pricing and managed backups, patching, and high availability, but it limits certain features and server level control. Running SQL Server on Amazon EC2 gives you full control and full feature support, with the option to use license included images or bring your own licenses when you are eligible. Dedicated Hosts add another path for customers who want to license physical cores and consolidate many virtual machines on the same host. Each option carries different responsibilities for compliance, flexibility, and cost.

Across all models, the biggest cost and compliance drivers are edition choice, core counts, instance sizing, high availability and disaster recovery design, and whether you have Software Assurance with License Mobility. Savings Plans, Reserved Instances, and right sizing can materially reduce spend, but they do not replace the need to align with Microsoft licensing rules. Policy changes since October 2019 affect what you can bring to listed providers such as AWS, so you should validate the current Product Terms before you migrate or buy.

The safest path is to treat licensing as an ongoing discipline rather than a one time checklist. Inventory your workloads, map each to the most appropriate deployment option, document how licenses are assigned, and monitor usage with tooling such as AWS License Manager. Keep Software Assurance status, mobility verification, and entitlement records current, and review architectures regularly to confirm that edition choices, failover patterns, and instance sizes still make sense. Work closely with both AWS and Microsoft licensing experts or a trusted licensing partner to model scenarios, confirm eligibility, and avoid expensive surprises. With careful planning and steady governance you can run SQL Server in AWS confidently, control costs, and remain compliant as your environment evolves.

Thank you again to our sponsor: SQL Tailor Consulting!

SQL Tailor Consulting brings 25 years of SQL Server expertise to help organizations transform database challenges into competitive advantages. Rather than waiting for 2 AM emergencies, they take a proactive approach to monitoring, optimizing, and strengthening SQL environments before issues impact your operations. Whether you need comprehensive remote DBA coverage, performance tuning, cloud migrations, or emergency response, SQL Tailor adapts their services to match your specific situation. From startups scaling rapidly to enterprises managing complex, mission critical systems. Book a free consultation today to discuss your specific environment and challenges. Use code 𝗟𝗟𝗔𝗠𝗕𝗗𝗨𝗛 when booking for 10% off!