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

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

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

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

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

Windows 实例执行 Sysprep 制作 AMI 时失败，报错 0x80073cf2。原因是 Notepad++ 8.9+ 注册的 AppX 包残留，即使卸载桌面版也无法清除。

EC2 Windows 实例启动后，系统时间比实际时间慢 8 小时。W32Time 同步时发生一次性 8 小时跳变，导致日志时间戳混乱、Kerberos 认证失败。根因是 RTC 本地时间与 UTC 混淆。

Mac mini 通过 SMB 挂载了 Windows PC（C/D/E 盘）和极空间 NAS。核心痛点是 macOS 睡眠、重启、网络断开后，SMB 挂载会自动断开且不会自动恢复，每次都要手动在 Finder 里重新连接。本文记录了一套完整的自动重连方案。

两台同 VPC 的 EC2 Windows 实例通过 SMB 访问共享失败，安全组和 NACL 都放行，Windows 防火墙也关闭，但 net use 报 1792，抓包看到 STATUS_NETLOGON_NOT_STARTED。最终根因不是 VPC 网络，而是安全软件拦截了 SMB 认证流程。

从 AWS 公有 Windows AMI 启动的 EC2 实例不能直接通过 VM Import/Export 导出为 VMDK，因为包含 AWS 授权软件。替代方案是停机后块级读取 EBS 根卷，用 qemu-img 转换，并离线启用 Windows 通用存储驱动，避免在 VMware 中蓝屏。

在一台 Windows Server 2008 EC2 实例上，CloudWatch Agent 服务状态正常，但监控指标一直无法上报到 CloudWatch。日志里反复出现 x509: certificate signed by unknown authority，最后定位到旧系统根证书和 TLS 支持不足。

EC2 Windows 实例状态检查正常、能 ping 通，但 RDP 连接不上，Stop & Start 后又恢复。遇到这种情况不要只看网络，Windows 内部资源耗尽也可能让 Winlogon 等关键进程崩溃。

在 EC2 Windows 实例上启用 BitLocker 系统盘加密是可行的，但风险比物理机更高。关键问题是 EC2 通常没有传统 TPM，系统盘加密后启动阶段需要输入密码，而普通控制台未必能提供可靠输入通道。