凌晨两点收到报警，网站挂了。手忙脚乱打开控制台，一堆指标和日志扑面而来，完全不知道该看哪个。这种时刻最需要的是按顺序来，跳过冗余信息，直接找根因。

服务器卡顿或没响应

别急着重启。先去EC2控制台看实例状态检查（Status Checks）。如果系统状态（System Status）或者实例状态（Instance Status）显示异常，说明底层硬件或操作系统出了状况，这时候重启可能会自动迁移到健康硬件，值得一试。

如果状态都正常，但应用还是跑不动，去CloudWatch看三个核心指标：CPU利用率、EBS磁盘读写IOPS（每秒读写次数）、内存使用率。CPU长时间超过80%说明算力不够；磁盘读写指标持续跑满，说明EBS卷的IOPS规格买低了；内存如果没监控，用会话管理器（Session Manager，浏览器直接开命令行）登进去跑free -h看一眼，满了就得考虑升配或排查内存泄露。这三个指标至少能锁定额70%的性能问题。

还有一种情况：CPU、磁盘、内存都正常，但接口响应奇慢。这时候大概率是外部依赖阻塞——应用在等某个下游服务返回，比如第三方API或者数据库查询。这时候得看应用日志，找出那个卡住的调用。

网络不通

外网连不上服务器，先确认实例有公网IP。如果是动态公网IP，每次停止再启动就变了，你得去控制台确认当前分配的地址对不对。如果依赖固定地址，绑一个弹性IP（Elastic IP，固定不变的公网地址）最省心。

公网IP没问题还是连不上？九成九是安全组（Security Group，实例的门禁系统）把端口挡了。去入站规则里看22（SSH）、80（HTTP）、443（HTTPS）这些端口是否允许了你的来源IP。如果不确定当前IP，百度搜“IP”就能看到。出站规则默认全放，除非你改过。

如果安全组配好了还不通，往下看网络ACL（子网级别的防火墙）。这个比安全组更底层，很多默认VPC没问题，但如果你在自定义VPC里改过规则，记得确认入站和出站都允许了临时端口（1024-65535），否则TCP握手会卡死。

最后查路由表。确认子网关联的路由表里有一条指向互联网网关（Internet Gateway）的0.0.0.0/0路由。缺了这条，实例压根出不去。

数据库超时

连RDS超时，先看安全组。RDS也有自己的安全组，得允许你的应用服务器或办公IP访问对应的数据库端口（MySQL 3306、PostgreSQL 5432等）。如果RDS没开公共访问，只能从同VPC内的资源去连。

安全组没问题，去RDS控制台看连接数（DatabaseConnections）和CPU利用率。连接数满了，要么是连接池配置太大，要么是有慢查询把连接占着不放。CPU飙高，十有八九是慢查询闹的，开启Performance Insights（性能洞察工具）能把那条拖垮数据库的SQL抓出来。

另外查一下RDS的存储空间。存储满了会导致数据库进入只读状态，写操作全部失败。平时设置好自动扩容，别等满了才处理。

如果以上都正常，可能是网络链路抖动。RDS多可用区部署能提供自动故障转移，主库挂了备库秒级顶上。单可用区的RDS出故障就只能等AWS修复，恢复时间完全不可控。

总结一下：按链路分层排查

服务器卡顿，先看状态检查，再盯CPU、磁盘、内存三指标；网络不通，从公网IP、安全组、网络ACL、路由表一路查下去；数据库超时，安全组先行，再看连接数、CPU、存储空间。这套流程走下来，大部分紧急故障都能定位到关键节点。