The licensing argument, and its fine print
AWS says a SQL Server host on Windows carries two license layers: the Windows Server OS license and the SQL Server license. Its answer is to run SQL Server on Linux container hosts. That removes the Windows Server license and lets you license only the virtual cores given to each container.
The post's worked example is a 16-core host running one container with 4 virtual cores. Per-core licensing of an individual virtual OSE is available only with subscription licenses or active Software Assurance, and it requires licenses equal to the virtual cores, with a four-license minimum per virtual OSE. A container counts as a virtual OSE, and the cores available to it count as virtual cores. In that example, you license 4 cores instead of 16. That is a 75% cut in the number of core licenses for that one workload.
That is not a 75% cut in your SQL Server bill. AWS itself says actual savings depend on existing agreements, core counts and SA status.
Where the math can mislead
- SA or subscription gate. Individual virtual OSE per-core licensing is available only with subscription rights or active SA. Without one of those, the 4-for-16 example does not apply.
- The four-core floor. Many small containers can erase the benefit. One licensing-vendor example describes a worker VM with eight virtual cores running six two-core Standard containers. Licensed one by one, that needs 24 core licenses, because each container carries the four-core minimum. That is a third-party illustration, not Microsoft's wording. It still shows why density matters.
- Hyper-threading. Microsoft's product terms say that if a virtual core maps to more than one hardware thread, you need a license for each thread. For containers, the cores available to the container are treated as hardware threads, so check your host configuration.
- The 40–60% combined figure. This is AWS's own estimate. The post says it rests on "typical enterprise deployment patterns." It publishes no cost model, no EC2, EBS or EKS pricing and no customer case study. Treat it as a hypothesis to test against your own invoices.
- Linux does not make licensing disappear. Microsoft's Learn documentation says SQL Server is licensed the same on Linux and Windows. You still pay for SQL Server, plus EKS, EC2, EBS, networking and the skills to run Kubernetes.
High-density alternatives
AWS also points to two other licensing paths, and Microsoft's product terms back both up:
- Enterprise Core with SA. License the physical cores and run an unlimited number of containers on that server.
- Standard or Enterprise Core with SA by virtual OSE. License the virtual cores of a VM, then run any number of containers inside it. Under this benefit, a container is not considered a separate virtual OSE.
These rights differ from the single-container model. You can't mix assumptions between them.
What AWS actually deploys
The pattern is a Helm chart that installs a single SQL Server pod on EKS worker nodes.
| Component | Role in the design |
|---|---|
| StatefulSet | Stable pod identity and ordered startup |
| Three PVCs on EBS gp3 | Separate volumes for data, log and backup paths |
| StorageClass | Encryption on, Retain reclaim policy, WaitForFirstConsumer binding |
| Secrets Manager + Secrets Store CSI + IRSA | The SA password is mounted as a file, with scoped IAM access |
| AWS Load Balancer Controller | Provisions a Network Load Balancer on TCP 1433 |
| NetworkPolicy | Allows ingress only from namespaces labeled access-mssql=true |
| PodDisruptionBudget | Limits voluntary disruptions |
| ConfigMap (mssql.conf) | Runtime settings |
The sample mssql.conf enables SQL Agent and caps memory at 3072 MB. It forces encryption, restricts TLS to 1.2, turns off customer feedback and sets trace flags 3226 and 8002. These are examples, not universal recommendations. Validate memory sizing, trace flags and certificate handling for your own workload.
Walkthrough outline
- Launch an Amazon Linux 2023 EC2 workstation and install the AWS CLI, kubectl, eksctl and Helm v3.
- Configure AWS credentials, or use an instance profile.
- Clone the solution repository. The post's clone command shows only a placeholder, so you need to find the real repo address.
- Edit cluster.yaml. The example uses us-east-1, two managed nodes (r7i.4xlarge and r6i.4xlarge) and the cluster name sqleksclu. Create it with eksctl.
- Attach AmazonEBSCSIDriverPolicy to the node group role.
- Run aws-setup.sh. It associates OIDC, installs the EBS CSI and Secrets Store CSI drivers, creates the secret and a scoped policy, sets up the mssql namespace with the mssql-sa service account, and installs the Load Balancer Controller.
- Install the chart with 4 CPU requested and limited. Use storage.create=true on the first deployment only.
- Verify with kubectl get pods, describe, logs and get svc. Then connect with sqlcmd from inside the pod or through the NLB endpoint.
Gaps to close before production
Single pod is not high availability. The example deploys one pod, mssql-mssql-0. The post shows no failover, backup restore or disaster recovery. A PodDisruptionBudget and persistent volumes are not database HA, and they are not a backup strategy. Microsoft's container documentation also warns that backups must be stored outside the container.
CU level matters for resource limits. Microsoft says SQL Server honors cgroup v2 constraints starting with SQL Server 2025 and SQL Server 2022 CU20. Earlier versions could hit out-of-memory errors on Kubernetes because container memory limits were not enforced. AWS names SQL Server 2022 but no CU, so check your image tag.
CPU limits and scheduling. Microsoft notes that with cgroup v2, the error log may still report the host's total CPU count. To align schedulers and parallelism with the quota, it recommends setting processor affinity and enabling trace flag 8002. The AWS config already includes 8002, but the affinity step is separate.
Platform support. Microsoft lists SQL Server 2022 containers as supported on Kubernetes. It also says container images are supported only on Linux hosts with Intel or AMD x86-64 CPUs. Emulation environments such as QEMU are not tested or supported. Graviton-based nodes are therefore a bad fit.
Network claims need testing. The post says pods stay in private subnets, with access through PrivateLink or VPN. Verify NetworkPolicy enforcement and actual reachability in your cluster.
Cleanup can leave charges. The Retain policy means deleting the Helm release, namespace and cluster can leave EBS volumes behind. Delete them manually once you no longer need the data.
Bottom line
This is a solid reference architecture for teams that already hold SA or subscription licenses and want to consolidate SQL Server onto Kubernetes. It is AWS's design, not a Microsoft endorsement. The headline savings are not independently demonstrated. Before you migrate, do three things:
- Model your actual licensing position, including SA status, thread mapping and the four-core floor per container.
- Confirm your SQL Server CU level.
- Plan real HA and restore testing.
If the numbers hold, the Windows license removal and right-sized cores are real levers. If they don't, you have swapped a license bill for a Kubernetes learning curve.