你的网站或者应用跑在EC2上，用户一多就开始卡、响应慢，CPU动不动飙到百分之八九十。最怕的就是活动大促前心里没底，不知道这台机器能不能扛住。这种感觉我懂，咱们直接看怎么解决。
最直接的：原地升级实例规格
先确定你的EC2是EBS-backed（系统盘用的是EBS云硬盘，不是实例本身自带的临时存储）。绝大多数人用的都是这种。如果是，恭喜你，换个更大的机型跟换手机卡一样简单，数据全都保留。
操作就这几步：
先给EBS卷打个快照（备份一下，图个安心）。
在控制台把实例停止（Stop）。注意，停止后实例就关机了，但EBS上的数据还在。
点“操作” -> “实例设置” -> “变更实例类型”。
选个大点的型号，比如t2.micro换成t2.large，或者直接从老一代跳到新一代的m系列、c系列。
启动实例。完事。
这里有个坑：有些旧机型和新机型架构不兼容。比如你想从上一代迁到基于Graviton（AWS自研的ARM架构芯片）的实例，省30%-40%的费用，那就没法直接升级了，得走迁移流程（新起一台机器，把数据拷过去）。
比盲目升级更聪明的做法：先看数据
别凭感觉升，感觉这东西不靠谱。去CloudWatch（AWS的监控服务）里调出过去两周的CPU使用率历史记录。官方文档给出的建议是，如果过去四周的最大CPU和内存利用率低于40%，说明机器买大了，该降配省钱。反过来，如果CPU长期在70%-80%晃悠，那才是该升级的信号。
还有一种情况是磁盘IO（读写速度）或者网络带宽不够了。这些指标同样能在CloudWatch里看到。发现是存储慢，给实例加一块更高IOPS的EBS卷就行，不用动计算规格。
单台机器不够用？上负载均衡和自动扩容
一台机器的天花板是有限的，哪怕升到顶配也不行。这时候就得考虑横向扩展——多来几台一起扛。
架构是这么搭的：前面挂一个应用负载均衡器（ALB，负责把流量分发给后端多台EC2），后面接一个自动扩缩组（ASG，根据压力自动加减机器数量）。你可以设置一个伸缩策略，比如CPU平均超过60%，就自动加一台新的EC2进来分担压力，高峰期过去再缩回去。这样平时不用养一堆闲置机器，省钱，活动来了又能自动扩容。
再提一嘴省钱的事
升级配置肯定会带来账单上涨。如果你的业务是长期稳定的（比如数据库服务器），可以考虑购买Savings Plan或预留实例，相当于包年批发价，能比按需付费（On-Demand，即用即付的零散价格）便宜最多72%。如果是那种容错性很强的计算任务（比如视频转码、大数据分析），用Spot实例（竞价实例，用别人闲置算力，随时可能被回收）成本直接打一折。
另外，AWS Compute Optimizer（一个利用机器学习帮你推荐合适机型的小工具）这个服务值得一开。它会自动分析你的使用习惯，直接告诉你该升还是该降，省得你自己看监控图表看到眼花。