Articles

Add Windows Node Groups to EKS for .NET Workloads (2026)

April 16, 2026 4 min read

Adding Windows node groups to your Amazon Elastic Kubernetes Service (EKS) cluster for .NET workloads is a straightforward process, but it unlocks a whole new dimension of deployment flexibility. The most surprising thing is that you’re not actually adding "Windows nodes" in the traditional sense; you’re adding instances that run Windows Server and are joined to your EKS control plane, allowing Kubernetes to schedule Windows containers on them.

Let’s see this in action. Imagine you have a .NET application that absolutely must run on Windows, perhaps due to legacy dependencies or specific .NET Framework requirements. You’ve already got your EKS cluster running with Linux worker nodes.

Here’s a simplified view of what happens when you add a Windows node group:

  1. EKS Control Plane: Your existing EKS cluster, managed by AWS, is already configured to understand Kubernetes objects. It doesn’t care if the underlying nodes are Linux or Windows; it just needs them to run the Kubelet and report their status.
  2. EC2 Instances (Windows): You provision EC2 instances running Windows Server. These instances will have the EKS-optimized Windows AMI.
  3. Kubelet on Windows: The Kubelet agent is installed and configured on these Windows instances. It registers these instances with the EKS control plane as Kubernetes nodes.
  4. Node Group Configuration: You define a "managed node group" in EKS, specifying that it should use Windows AMIs and target your cluster. AWS then automates the provisioning and management of these EC2 instances.
  5. Scheduling: When you deploy a .NET container that has a nodeSelector or affinity rule targeting Windows nodes (e.g., kubernetes.io/os: windows), the Kubernetes scheduler directs these pods to your newly added Windows nodes.

The Problem This Solves:

Historically, EKS clusters were Linux-only. This meant that organizations with existing Windows-based applications or those needing specific Windows features for their .NET workloads were stuck. They couldn’t fully leverage EKS for their entire application portfolio. Adding Windows node groups allows you to run a heterogeneous cluster, consolidating both Linux and Windows workloads under a single Kubernetes control plane. This simplifies management, centralizes observability, and allows for consistent application deployment pipelines across different operating systems.

How It Works Internally (The Levers You Control):

When you create a Windows managed node group, you’re essentially configuring a set of EC2 instances and how they integrate with EKS. Key parameters you’ll set include:

  • AMI Type: You’ll select EKS_WINDOWS_FULL_CONTAINER or EKS_WINDOWS_SERVERCORE_CONTAINER depending on whether you need a full Windows Server installation or the more lightweight Server Core for your containers.
  • Instance Types: Choose appropriate EC2 instance types (e.g., m5.large, c5.xlarge) that meet the CPU, memory, and networking requirements of your .NET applications.
  • Desired Size, Min Size, Max Size: These define the auto-scaling behavior of your Windows node group. EKS will automatically adjust the number of instances based on your cluster’s needs and these parameters.
  • Subnets: Specify the VPC subnets where your Windows instances should be launched. Ensure these subnets have internet access (either via NAT Gateway or VPC endpoints) for EKS communication and package downloads.
  • SSH Access: Configure SSH key pairs for direct access to your Windows nodes for debugging purposes.
  • Labels and Taints: You can apply custom Kubernetes labels to your Windows nodes (e.g., workload-type=dotnet-legacy) and taints to control which pods can be scheduled there.

Example Configuration Snippet (AWS CLI):

aws eks create-nodegroup \
    --cluster-name my-eks-cluster \
    --nodegroup-name windows-nodegroup-1 \
    --subnets subnet-0123456789abcdef0 subnet-fedcba9876543210f \
    --instance-types t3.medium \
    --scaling-config desiredSize=2,minSize=1,maxSize=3 \
    --ami-type EKS_WINDOWS_FULL_CONTAINER \
    --node-role arn:aws:iam::111122223333:role/EKSNodeRole \
    --launch-template id=lt-0abcdef1234567890,version=1 \
    --tags Environment=Production,App=DotNetApp

This command creates a managed node group named windows-nodegroup-1 for my-eks-cluster, using t3.medium instances, with auto-scaling between 1 and 3 nodes, and utilizing a full Windows container image. It also specifies the IAM role for EKS nodes and a launch template for further customization.

The most counterintuitive aspect of running Windows containers on EKS is understanding how Kubernetes networking integrates. Unlike Linux, where CNI plugins like Calico or Cilium are common, Windows nodes typically rely on the built-in win-overlay or win-bridge network drivers. The win-overlay driver uses VXLAN encapsulation to provide pod-to-pod communication across different nodes, effectively mimicking the behavior of Linux overlay networks, while win-bridge uses a virtual bridge on each node. Your choice of CNI on Windows can significantly impact network performance and complexity, and it’s crucial to select one compatible with your EKS version and desired features.

Once your Windows node group is up and running, you’ll start thinking about how to manage Windows-specific security patches and updates for your nodes.

Want structured learning?

Take the full Eks course →