Idle Windows Server 2025 instances: reproducible high CPU due to interrupt processing; AWS driver incompatibility?

I think the generic SSM runbooks mentioned above won't help here. A high % Interrupt Time (~11%) on a clean, idle OS indicates a low-level issue with kernel timer handling or hypervisor clock synchronization in Windows Server 2025 on Nitro (t3a / AMD EPYC).

To isolate the root cause, test these specific configurations on a fresh test instance:

1. Disable Dynamic Ticks

Windows Server 2025 uses dynamic ticking to adjust timer resolution on the fly. On virtualized hardware, miscommunication between guest timer interrupts and the hypervisor frequently causes an interrupt storm. bcdedit /set disabledynamictick yes

(Requires a system reboot).

2. Verify ENA Interrupt Moderation

Check if the Amazon Elastic Network Adapter driver in WS2025 has interrupt moderation enabled by default: Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object { $_.DisplayName -like "Interrupt" }

If moderation is disabled or misconfigured, small background packets can saturate a vCPU with hardware interrupts.

3. Compare BCD Clock Settings

Run bcdedit /enum on both WS2022 and WS2025. Verify if useplatformclock or useplatformtick is enabled on the WS2025 AMI, which forces the OS to use synthetic clock sources instead of invariant TSC, causing higher overhead.

If disabling dynamic ticks drops % Interrupt Time back to WS2022 baseline levels, attach your before/after Get-Counter logs to an AWS Support case so this can be escalated to the EC2 Windows Engineering team for AMI timer calibration.

See also:

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-os.html
• https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--set

Thank you, I opened a case.

I also found out that this does NOT happen with non-burstable instance types like c7a!

WPA analysis attributes almost all ISR CPU time to ntoskrnl!HalpVpptAcknowledgeInterrupt, with the call stack dominated by:

ntoskrnl!KiIdleLoop → ntoskrnl!PoIdle → ntoskrnl!PpmIdleExecuteTransition → ntoskrnl!HalpVpptAcknowledgeInterrupt

Very little ISR time is attributed to ENA, AWSNVMe or Storport.

Based on your detailed analysis, you're experiencing high interrupt processing on Windows Server 2025 instances that doesn't occur on Windows Server 2022. The approximately 10% CPU usage from interrupt processing on idle instances is concerning, especially for burstable instances like t3a.micro that can't accumulate CPU credits when consistently above their baseline.

To troubleshoot and potentially resolve this issue:

Immediate Troubleshooting Steps:

1. Run the AWSSupport-TroubleshootWindowsPerformance runbook through AWS Systems Manager. This can automatically identify processes causing high CPU usage and may provide additional insights into the interrupt processing behavior.

2. Check for driver compatibility issues by running the AWSSupport-UpgradeWindowsAWSDrivers runbook. While your driver versions appear current, Windows Server 2025 is relatively new, and there may be compatibility improvements or updates available specifically for this OS version.

3. Monitor with CloudWatch by setting up detailed monitoring and creating alarms for CPUUtilization. Use the procstat plugin to get more granular process-level data that might reveal patterns not visible in standard metrics.

Potential Root Causes:

Given that Windows Server 2025 is a newer operating system, there may be:

• Compatibility issues between the OS kernel's interrupt handling and the current AWS drivers (ENA, NVMe)
• Changes in how Windows Server 2025 processes hardware interrupts compared to 2022
• Differences in default system services or background tasks that generate more interrupt activity

Recommended Actions:

1. Ensure all instance drivers are fully updated and compatible with Windows Server 2025
2. Consider temporarily using a larger instance type (beyond t3a.micro) to determine if the issue scales proportionally or if it's a fixed overhead
3. Review your AWS Support plan options, as this appears to be a systemic compatibility issue that may require deeper investigation by AWS engineering teams
4. Document your findings and add correspondence through the AWS Support Center at https://console.aws.amazon.com/support/ with your detailed performance counter data

Since this is reproducible across multiple deployments and availability zones, it's unlikely to be a host-specific issue and more likely represents a broader compatibility consideration with Windows Server 2025 on AWS infrastructure.
Sources
Troubleshoot high CPU usage in my EC2 Windows instances | AWS re:Post
Troubleshoot EC2 Windows Nitro instance status check failures | AWS re:Post

Thank you @Florian Turnwald for your super quick and helpful answer!

Output for (2) on Server 2025:

Empty. Output without the filter:

Name                      DisplayName                    DisplayValue                   RegistryKeyword RegistryValue
----                      -----------                    ------------                   --------------- -------------
Ethernet                  IPv4 Checksum offload          Rx & Tx Enabled                *IPChecksumO... {3}
Ethernet                  Jumbo Packet                   Disabled                       *JumboPacket    {1514}
Ethernet                  Large Send Offload V1 (IPv4)   Enabled                        *LsoV1IPv4      {1}
Ethernet                  Large Send Offload V2 (IPv4)   Enabled                        *LsoV2IPv4      {1}
Ethernet                  Large Send Offload V2 (IPv6)   Enabled                        *LsoV2IPv6      {1}
Ethernet                  Maximum Number of RSS Queues   32                             *NumRssQueues   {32}
Ethernet                  Priority and Vlan Support      Both                           *PriorityVLA... {3}
Ethernet                  Receive Buffers                1024                           *ReceiveBuffers {1024}
Ethernet                  Receive Side Scaling           Enabled                        *RSS            {1}
Ethernet                  TCP Checksum Offload (IPv4)    Rx & Tx Enabled                *TCPChecksum... {3}
Ethernet                  TCP Checksum Offload (IPv6)    Rx & Tx Enabled                *TCPChecksum... {3}
Ethernet                  Transmit Buffers               1024                           *TransmitBuf... {1024}
Ethernet                  UDP Checksum Offload (IPv4)    Rx & Tx Enabled                *UDPChecksum... {3}
Ethernet                  UDP Checksum Offload (IPv6)    Rx & Tx Enabled                *UDPChecksum... {3}
Ethernet                  LLQ Header Size Policy         Recommended                    LlqPolicy       {0}
Ethernet                  Metrics Refresh Interval       1                              MetricsRefre... {1}
Ethernet                  MAC Address                    --                             NetworkAddress  {--}
Ethernet                  VLAN ID                        0                              VlanId          {0}

Same on Server 2022.

Output for (3)

On Server 2025:

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
bootshutdowndisabled    Yes
default                 {current}
resumeobject            {06abedb4-730f-11f0-bb11-0afff7ff4a31}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {5e607f64-734b-11f0-aaf4-0affe412849f}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {06abedb4-730f-11f0-bb11-0afff7ff4a31}
nx                      OptOut
bootstatuspolicy        IgnoreAllFailures

useplatformclock or useplatformtick not mentioned!

Neither on Server 2022, although the output is slighty different:

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
bootshutdowndisabled    Yes
default                 {current}
resumeobject            {4426d739-00bc-11ec-a967-0e221fdbf186}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows Server
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {abb264d7-85c0-11ef-bb37-0afff4384355}
displaymessageoverride  Recovery
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4426d739-00bc-11ec-a967-0e221fdbf186}
nx                      OptOut
bootstatuspolicy        IgnoreAllFailures

Disable Timer Ticks

I ran the suggested command and rebooted. Unfortunately, it didn't change anything except the output of bcdedit /enum which now includes

disabledynamictick Yes

Any ideas? Should I provide you with a WPR trace (CPU profile)?