EC2生产实例从t2.medium升级到t2.large后SSH连接失败问题咨询

• 网卡驱动兼容性问题：同属t2实例族的不同规格，也可能触发老旧操作系统镜像的适配缺陷。如果生产实例使用的自定义AMI内置的ENA（弹性网卡适配器）驱动版本过低，或内核补丁未兼容高规格实例的硬件参数，切换到t2.large后网卡会初始化失败，网络栈无法正常启动，导致sshd服务依赖的端口未监听，返回ssh: connect to host ****.compute.amazonaws.com port 22: Connection refused报错。即使预发环境配置逻辑和生产一致，也可能存在实际内核版本、驱动补丁的微小差异导致预发测试未复现问题。
• sshd服务绑定规则限制：如果生产环境配置了sshd仅绑定固定网卡名称、固定私有IP地址，切换实例规格会触发EC2底层重新枚举网卡，可能出现网卡名称变更（如从eth0变为eth1）、临时私有IP变动的情况，导致sshd启动时无法匹配到绑定的地址，服务启动失败。切回t2.medium后网卡配置恢复到原有状态，sshd即可正常启动。
• cloud-init配置冲突：若生产实例的cloud-init规则配置了实例规格校验逻辑，仅在匹配t2.medium等特定规格时才会初始化正确的网络、sshd、防火墙规则，切换到t2.large后cloud-init执行异常，会覆盖原有合法配置，导致22端口未对外开放。
• 动态访问控制规则限制：部分企业会配置基于实例标签、实例规格的动态安全组、网络ACL规则，当实例规格变更为t2.large后，会匹配到拒绝22端口访问的规则，切回t2.medium后重新命中放行规则，SSH访问恢复正常。
• 启动资源抢占导致sshd超时：生产实例的实际负载、磁盘数据量远高于预发环境，切换规格后首次启动时，可能触发磁盘fsck校验、大量业务进程启动抢占资源，导致sshd服务启动超时被系统终止，访问时22端口尚未进入监听状态。
• 自定义防火墙规则拦截：如果生产实例内置的iptables、ufw规则配置了基于硬件参数的放行逻辑（如仅内存小于6G时开放22端口），切换到t2.large后内存从4G升级到8G，会匹配到拒绝规则，22端口被防火墙拦截。

内容的提问来源于stack exchange，提问作者Vladyslav Zavalykhatko