AWS 不提供 Graviton 架构的 Windows AMI，但这不代表 Graviton 跑不了 Windows。本文记录如何用开源项目 bin456789/reinstall 的一键 DD 脚本，把一台运行 Amazon Linux 2023 的 t4g 实例原地重装成 Windows 11 Pro ARM64。

原本想做一个更懂 IT 中文和中英混说的轻量 ASR。三阶段训练跑完后，中文指标明显变好，英文技术演讲却大量截断甚至空输出。继续增加 epoch 前，我先评估每个 checkpoint，再尝试基座与微调权重插值。

最终在当前 1,700 条测试集上，50/50 插值将总体 CER 从基座 13.36% 降到 11.62%，中文和英文都低于基座。它是当前候选模型，尚未通过独立 IT 热词验收，不能称为最终发布模型。

给运行中的 EC2 实例附加包含 AmazonSSMManagedInstanceCore 的 Instance Profile 后，实例有时不会马上出现在 Systems Manager 中。等几分钟、重启 Agent，甚至等待接近半小时后又会自行恢复。

这通常不是 IAM 策略写错，而是控制面传播、Agent 凭证生命周期和失败退避共同造成的结果。理解这几层延迟后，就能避免反复解绑角色、重装 Agent 或修改网络。

标准 Windows Server AMI 启动在 g4dn 或 g5 后，设备管理器可能只显示 Microsoft 基本显示适配器，nvidia-smi 也不可用。安装驱动后，Windows 版 CloudWatch Agent 又不能像 Linux 那样直接启用 nvidia_gpu 接收器。

本文把两部分串成一条完整部署链：从 AWS 公共 S3 桶安装 GRID 驱动，再由 PowerShell 调用 nvidia-smi，批量推送自定义 CloudWatch 指标。

ENA 问题经常被简化成“升级驱动并重启”，但真正遇到丢包、发送失败或热替换后网卡消失时，需要同时理解 PCI 设备生命周期和 Linux Tx 数据路径。

本文把两个相关主题合在一起：如何安全升级 ENA 驱动，以及 linearize_failed、dma_mapping_err 等计数器究竟对应哪一步失败。

旧 Windows Server 域控制器从早期 EC2 虚拟化栈迁移到 Nitro 平台时，通常要处理 PV、ENA 和 NVMe 驱动。普通成员服务器驱动失败可以换卷救援，但域控制器还涉及 AD DS、SYSVOL、FSMO、DSRM 和 System State，不能只把它当成一次设备驱动安装。

下面是一套面向双域控的变更流程。命令中的主机名、卷和区域均为示例，执行前必须结合 Windows 版本、实例代际和 AWS 当前驱动包验证。

EBS 卷仅支持单向扩容，不允许直接缩容。对于非 Windows 系统所在的数据卷，可以直接创建一个新的小容量 EBS 卷挂载到实例后进行文件级别的复制（如 robocopy）。而对于 Windows 系统所在的根卷，或者数据卷中存在持续读写的文件（例如 SQL Server 的数据库），就需要关机后进行冷处理。

本文使用 Windows Server 2012 R2，原始根卷和数据卷各 100GB gp3，目标缩容到各 50GB gp3。

在开始操作前请务必对实例创建 AMI 进行备份，并在测试环境中启动实例进行测试，再应用到生产环境。复制根卷需要停止实例，建议在业务低谷期进行。停止实例会导致实例存储数据丢失以及自动分配的公网 IP（非 EIP）丢失。

在 EC2 Graviton 实例上跑 Windows 11 ARM 后，最实际的问题就是：x86/x64 的运维工具还能不能用？本文在 t4g.large（Graviton2）上对 Sysinternals Suite 全套工具做了兼容性测试，对比了 ARM64 原生与 x64 模拟的性能差异。

Graviton 实例跑 Windows 11 ARM 用的是 AWS ENA ARM64 驱动，而这个驱动目前只有一个版本（2.2.1）。它能跑满 t4g.large 的网络突发上限吗？本文用 iperf3 做了完整吞吐测试。

Graviton 上 DD 安装的 Windows 11 ARM 用的是微软 inbox StorNVMe.sys，而不是 AWS 官方 AWSNVMe.sys。这个 inbox 驱动会不会成为 IO 瓶颈？本文用 diskspd 做了完整的 IOPS 和吞吐测试，把瓶颈锁定在实例侧。