半夜收到服务器报警，网站打不开了。或者一觉醒来发现RDS连不上，更恐怖的是看到AWS账单上多出来一个“天文数字”。这些场景我太熟了。别慌，咱们按套路来，一个一个拆。

服务器打不开？先别重启

最典型的情况是晚上连不上、白天正常，或者公网IP突然就访问不了。

先别急着点那个“重启”按钮，那解决不了根本问题。去EC2控制台看一眼“实例状态检查”，如果系统状态或实例状态不是“通过”（OK），那说明底层硬件或系统本身可能出了状况，这时候重启可能管用。

如果状态都正常，但你就是连不上，九成九是网络门禁（安全组）改了。去安全组（Security Group，相当于AWS给服务器配的“门禁系统”）里检查入站规则，看你需要的端口（比如SSH的22，HTTP的80）是不是被不小心删了或者限制了来源IP。

另外，如果你的实例用的是自动分配的IP而不是弹性IP（Elastic IP，固定不变的公网地址），停掉再启动后IP就变了。你还在连旧IP，当然找不到。

要是以上都查不出问题，教你个绝招：用会话管理器（Session Manager）连进去。这玩意儿不走传统端口，只要实例有SSM代理，就能通过浏览器直接开个命令行进去。进去了就能看日志、查服务状态，找到问题根源。

数据库连不上？大多数是“门禁”没开

数据库连不上的核心原因，十有八九是安全组没开端口。比如MySQL默认3306端口，如果你在RDS（关系型数据库服务）上把端口封死了，外面怎么连都白搭。

如果你是本地电脑想连RDS，记得检查RDS实例的“公共可访问性”（Public Accessibility）是不是设成了“是”。如果它藏在私有子网里，那你得先跳板机（Bastion）中转一下，直连是不行的。

还有就是要确认一下连接地址。很多同学会把数据库终结点（Endpoint）和IP地址搞混。在RDS控制台抄对那个长的像域名的终结点，不要用IP去连，公共IP一变你就掉线了。

如果这些都没问题，但数据库性能突然掉链子、CPU飙高，可以看看CloudWatch里的数据库连接数和IOPS（磁盘读写次数）指标。万一真的有慢查询拖垮了数据库，可以用Performance Insights这类工具抓到那条搞事情的SQL。

账单异常？别被吓到

时不时就有客户截图给我看，账单预估几百万美元。这种消息我见的不少，甚至AWS自己都闹过这种乌龙——2026年7月，因为计费系统配置变更，有用户看到17亿甚至数万亿美元的预估账单，后来证实全是错误数据。

遇到这种情况，第一件事：去成本管理控制台（Cost Explorer）里看一眼实际已产生费用，绝大多数情况下那笔巨款只是“预估”错误，不反映真实用量。

通常导致异常费用飙升的原因有这几种：开了多余的快照备份、RDS实例类型被人悄悄升配了、产生大量跨区域数据传输，或者是有个废弃的EC2一直在跑，你以为关了，其实EBS（硬盘）还在收费。

如果你发现服务没在用，但费用还在涨，马上去检查是不是还有残留的存储卷没删干净。把不必要的资源销毁，然后开个Support工单申请退款，只要不是恶意使用，AWS一般都会给你冲抵的。

平时记得把预算告警（Budget Alert）打开，给自己设个阈值。别等账单出来了才去追悔莫及。