1. 从一台永远在线的虚拟电脑说起很多人第一次接触云服务器脑子里冒出来的第一个问题就是我到底买了个啥是一台放在别人机房里的物理机吗还是一台虚拟机其实这两种说法都对也都不完全对。拿亚马逊云科技的EC2来说它给你的是一台可以随时开机、随时关机、按秒计费的虚拟电脑你可以像操作自己桌上的那台机器一样装系统、配环境、跑服务、开端口唯一的区别是它不在你脚下而是在某个你根本不需要关心的数据中心里。EC2这三个字母是Elastic Compute Cloud的缩写翻译过来就是弹性计算云。弹性这两个字是整个产品的灵魂也是我这些年用下来觉得最值钱的地方。传统物理服务器你要么买一台放机房要么租一台按月付费配置定死了想升级就得停机换硬件想降配就得浪费钱。EC2不一样你今天觉得2核4G够用明天业务涨了点几下就能升到8核16G后天流量回落了再降回去计费跟着配置走不用为闲置资源买单。这篇文章我打算把EC2从里到外拆一遍包括实例类型怎么选、计费模式怎么挑、存储和网络怎么配、安全组怎么设、快照和镜像怎么用以及那些只有踩过坑才知道的细节。适合刚上手云服务的新手也适合用了一段时间但总觉得好像哪里没配对的老用户。我不打算照本宣科念文档而是按一个实际项目从零到上线的顺序把每个环节的决策逻辑讲清楚让你看完能直接照着做。2. 实例类型与规格别让选型变成选坑2.1 实例家族的命名规则到底在说什么EC2的实例类型名字看起来像乱码比如m5.large、c6g.xlarge、r5.2xlarge其实每个字母和数字都有含义。拿m5.large举例m是实例家族family代表通用型5是代次generation数字越大越新large是规格大小size决定CPU和内存的具体数量。再比如c6g.xlargec是计算优化型6是第六代g表示用的是ARM架构的处理器xlarge是规格。理解这套命名规则的好处是你看到一个新实例名字大概就能猜出它适合干什么。通用型m家族CPU和内存比例均衡适合Web服务器、中小型数据库、开发环境计算优化型c家族CPU强内存少适合批处理、视频编码、高性能计算内存优化型r家族内存大CPU相对少适合内存数据库、大数据分析、缓存服务。还有存储优化型i家族、加速计算型p和g家族等等各有各的专长。我个人的经验是新手最容易犯的错就是无脑选最便宜的或者无脑选最贵的。最便宜的那档往往是突发性能实例T系列它的CPU积分机制后面会细说用不好会导致服务卡顿。最贵的那档可能是GPU实例你跑个静态网站根本用不上。选型的核心原则是先搞清楚你的应用是CPU密集、内存密集还是IO密集然后对应选家族再根据负载量选规格。2.2 突发性能实例的CPU积分机制T系列实例是很多人的入门首选因为便宜。但它有一个非常特殊的机制叫CPU积分CPU Credits。简单说T实例有一个基准CPU性能比如t3.micro的基准是10%意思是它平时只能用到10%的CPU。当你需要更多CPU时它会消耗积分来透支性能最高可以冲到100%。积分在你CPU用得少的时候会慢慢积累用得多了就消耗。这个机制听起来很美好但坑在于如果你的应用持续高负载积分很快耗尽CPU就会被限制在基准水平服务直接变慢。我见过有人用t3.micro跑一个持续有流量的API服务白天还好到了晚上积分用完响应时间从50毫秒飙到2秒。所以T系列只适合负载波动大、平时比较闲的场景比如个人博客、测试环境、低流量后台。如果你的服务是7x24小时稳定吃CPU的老老实实选m家族或c家族。判断方法很简单在控制台看CloudWatch的CPU积分余额指标如果经常接近零说明你选错了。或者干脆用无限模式Unlimited Mode积分用完可以继续透支但月底会按超出量额外收费账单可能比你升级实例还贵。2.3 架构选择x86还是ARM最近几代实例里出现了带g后缀的型号比如m6g、c6g、r6g这些是基于ARM架构的。相比同规格的x86实例ARM实例通常便宜10%到20%性能却不相上下某些场景甚至更好。听起来很香但有一个前提你的应用得能在ARM上跑。大部分主流语言和框架都已经支持ARM了比如Python、Node.js、Java、Go、Nginx、MySQL、Redis这些都没问题。但如果你用的是某些商业软件、老旧的二进制包、或者自己编译的C扩展可能就没有ARM版本。我一般的做法是新项目优先考虑ARM省钱又省电迁移老项目时先在测试环境跑一遍确认所有依赖都有ARM版本再切。还有一个细节是ARM实例和x86实例的镜像不通用。你创建实例时选的AMI系统镜像必须匹配架构选错了启动会失败。这个在控制台里其实有提示但如果你用命令行或API创建很容易忽略。3. 计费模式按需、预留、竞价到底怎么选3.1 三种主流计费模式的适用场景EC2的计费模式主要有三种按需实例On-Demand、预留实例Reserved Instances、竞价实例Spot Instances。按需就是随用随付按秒计费最灵活也最贵。预留是你承诺用一年或三年换取大幅折扣通常能省30%到60%。竞价是你在一个动态市场上出价价高者得能省70%甚至90%但随时可能被回收。怎么选我的判断逻辑是这样的如果你的服务是长期稳定运行的比如生产环境的Web服务器、数据库用预留实例最划算反正你本来就要一直开着。如果是临时性的、可中断的任务比如批量数据处理、视频转码、CI/CD构建用竞价实例能省一大笔。如果是开发测试、短期项目、不确定要不要长期用的用按需灵活第一。这里有个容易忽略的点预留实例不是绑定某台具体机器的它绑定的是实例家族、区域、操作系统这些属性。你买了一个m5.large的预留只要在这个区域创建m5.large的实例就自动享受折扣不用管具体是哪台。而且预留还有可转换和不可转换之分可转换的贵一点但能换成其他家族或规格适合业务可能变化的场景。3.2 竞价实例的中断处理策略竞价实例最大的风险是中断。当市场价超过你的出价或者容量紧张时系统会给你两分钟警告然后回收实例。两分钟听起来很短但如果你的架构设计得当完全可以从容应对。我的做法是把竞价实例用在无状态、可重试的任务上。比如一个视频转码队列每个任务独立实例被回收了任务重新排队到另一台机器继续跑就行。关键是任务状态不能存在本地磁盘要存在外部数据库或对象存储里。另外我会混合使用按需和竞价比如一个集群里70%是竞价30%是按需保证即使竞价全被回收核心服务也不断。还有一个技巧是使用竞价队列Spot Fleet或容量优化分配策略让系统自动在多个实例池里找最便宜且稳定的容量。不要只盯着一个实例类型出价多选几个备选中断概率会低很多。3.3 隐藏成本流量、存储、快照很多人算EC2成本时只看实例本身的价格结果账单出来发现超了不少。EC2的隐藏成本主要有三块数据传输费、EBS存储费、快照费。数据传输方面入站流量通常免费出站流量按量收费而且跨区域传输比同区域贵。如果你的服务要往外发大量数据比如视频、图片这部分费用可能比实例还高。优化方法是把内容放到CDN上或者尽量让数据在同区域内流转。EBS存储是按配置容量收费的不管你用没用满。比如你挂了一块100G的gp3卷即使只用了10G也按100G收费。所以创建卷时别贪大按实际需求来不够了再扩。快照是按实际存储的数据量收费的但如果你频繁创建快照累积起来也不少。建议设置生命周期策略自动删除过期的快照。4. 存储与网络把地基打牢4.1 EBS卷类型的选择与性能对比EBS弹性块存储就是EC2的硬盘主要有几种类型gp3、gp2、io1、io2、st1、sc1。gp3是通用型SSD性价比最高基准3000 IOPS和125MB/s吞吐可以额外付费提升。gp2是老一代通用SSD性能跟容量挂钩容量越大IOPS越高但价格比gp3贵。io1和io2是高性能SSD适合对IOPS要求极高的数据库io2的耐久性更好。st1是吞吐优化型HDD适合大数据处理。sc1是冷存储HDD最便宜但性能最低。我的建议是绝大多数场景直接用gp3除非你有明确的IOPS需求。gp3的好处是性能和容量解耦你可以买一块很小的卷但配很高的IOPS这在gp2时代是做不到的。比如一个20G的gp3卷你可以额外买3000 IOPS总共6000 IOPS成本比买一块大容量gp2低得多。还有一个细节是EBS卷只能挂载到同一可用区的实例上。如果你的实例在可用区A卷在可用区B是挂不上去的。创建卷时一定要看清楚可用区。另外一块卷同一时间只能挂载到一个实例除了io1/io2的多挂载特性别想着几台机器共享一块盘。4.2 安全组与网络ACL的区别和配合安全组Security Group和网络ACLNetwork ACL都是防火墙但工作层次和方式不同。安全组作用于实例级别是有状态的你允许了入站流量出站响应自动放行。网络ACL作用于子网级别是无状态的入站和出站规则要分别配置。实际使用中安全组是主力网络ACL是补充。我一般这样配安全组按角色划分比如Web服务器的安全组允许80和443入站数据库的安全组只允许来自Web安全组的3306入站。网络ACL用默认的允许所有就行除非你有特殊的安全合规要求才去细化。安全组有一个很重要的特性你可以引用另一个安全组作为源而不是写IP地址。这样当你的Web服务器扩容或IP变化时数据库的安全组不用改。这个技巧在多环境、多层级架构里特别有用。还有一个新手常犯的错改了安全组规则后发现不生效。其实安全组规则是即时生效的但如果你是通过域名访问可能是DNS缓存的问题。另外安全组默认拒绝所有入站允许所有出站这个默认行为要记牢。4.3 弹性IP与公有IP的区别EC2实例可以有两种IP公有IP和弹性IPEIP。公有IP是自动分配的实例停止再启动后会变。弹性IP是你手动申请的可以固定绑定到实例上实例重启也不变。如果你需要一个固定的公网地址比如给客户配置白名单就必须用弹性IP。弹性IP有一个收费规则要注意绑定到运行中的实例上是免费的但如果没绑定或者绑定到停止的实例上会按小时收费。这是为了防止有人占着IP不用。所以如果你暂时不需要某个弹性IP最好释放掉别留着吃灰。另外弹性IP是区域级别的资源不能跨区域使用。你在区域A申请的EIP只能绑定到区域A的实例上。如果你在多个区域有业务每个区域都要单独申请。5. 镜像、快照与自动化让重复劳动归零5.1 AMI的制作与复用AMIAmazon Machine Image是实例的模板包含操作系统、应用、配置等。你可以从公共AMI启动实例也可以自己制作AMI。自己制作AMI的好处是新实例启动后直接就是配好的环境不用再手动装一遍。制作AMI的流程是先启动一个实例装好所有软件、配好所有参数然后从这个实例创建AMI。创建过程会重启实例可选不重启但可能不一致所以最好在业务低峰期做。AMI创建后你可以用它启动任意数量的相同实例非常适合横向扩容。我的经验是AMI要定期更新。比如每个月打一次安全补丁然后重新制作AMI。旧AMI可以保留几个版本方便回滚。另外AMI是区域级别的跨区域复制需要手动操作而且会产生传输费用。5.2 快照的增量备份机制EBS快照是卷的备份第一次是全量之后是增量。增量意味着只备份变化的数据块所以后续快照很快也很省空间。但要注意删除快照时如果后续快照依赖它系统会保留必要的数据块不会导致数据损坏。快照可以用来创建新卷也可以跨区域复制。跨区域复制对于灾备很有用比如你把生产环境的快照复制到另一个区域万一主区域出问题可以在备区域快速恢复。复制是按数据传输量收费的所以别复制太频繁。我一般会设置一个快照策略每天凌晨自动打一次快照保留最近7天每周打一次保留4周每月打一次保留12个月。这样既有细粒度的恢复点又有长期的归档。生命周期策略可以在控制台里配不用自己写脚本。5.3 启动模板与自动扩缩容启动模板Launch Template是创建实例的配方包含AMI、实例类型、安全组、密钥对等所有参数。你可以基于模板创建实例也可以让自动扩缩容组Auto Scaling Group用模板来动态增减实例。自动扩缩容的核心是策略。最简单的策略是目标追踪比如保持CPU利用率在50%系统会自动增减实例来维持这个目标。还有步进策略和简单策略适合更复杂的场景。扩缩容组还可以跨可用区部署提高可用性。这里有一个坑扩缩容组在缩减时会终止实例如果实例上有未保存的数据就丢了。所以扩缩容组里的实例必须是无状态的所有状态存在外部。另外缩减时默认是随机选实例终止你可以配置终止策略比如优先终止最旧的实例。6. 常见问题与排查技巧实录6.1 实例连不上的排查思路实例启动后连不上是最常见的问题。排查顺序我一般是这样先看实例状态是不是在运行中再看安全组有没有放行你的IP和端口然后看网络ACL有没有误拦接着看路由表有没有指向互联网网关最后看实例内部防火墙有没有开服务有没有监听。如果是SSH连不上还要检查密钥对是否正确。很多人创建实例时选错了密钥对或者用了.ppk格式但用ssh命令连。密钥对的权限也很重要Linux下私钥文件必须是600权限否则SSH会拒绝使用。还有一个隐蔽的问题是实例的公有IP变了。如果你没绑弹性IP实例停止再启动后公有IP会变你还在用旧IP连当然连不上。养成习惯需要固定IP就绑弹性IP。6.2 磁盘满了怎么办磁盘满了是另一个高频问题。EC2的根卷默认可能只有8G或20G装几个软件就满了。解决办法有两种一是扩容根卷二是挂载新卷。扩容根卷的步骤是先在控制台修改卷大小然后在实例内部扩展分区和文件系统。Linux下用growpart和resize2fsext4或xfs_growfsxfs。注意扩容只能增大不能缩小所以别一次加太多。挂载新卷的步骤是创建卷、挂载到实例、在实例内分区格式化、挂载到目录、修改fstab。fstab一定要用UUID而不是设备名因为设备名可能会变。改完fstab后先用mount -a测试确认没问题再重启否则可能开不了机。6.3 账单异常怎么查账单比预期高先别慌去Cost Explorer里按服务、按区域、按标签拆解。常见原因有忘了关的实例、闲置的弹性IP、未删除的快照、跨区域流量、竞价实例的额外费用。我建议给所有资源打标签比如项目、环境、负责人。这样账单出来能直接定位到是谁的什么资源。还可以设置预算告警超过阈值就发邮件避免月底才发现超支。还有一个技巧是用成本分配标签把共享成本按比例分摊到不同项目。比如一个NAT网关被多个项目共用可以按流量比例分摊费用这样每个项目的成本更准确。7. 我个人在实际操作中的几点体会用了这么多年EC2踩过的坑不少总结几条最值钱的经验。第一永远不要在生产环境用默认VPC的默认安全组那个安全组默认允许同组内所有流量很容易出安全问题。第二创建实例时养成打标签的习惯哪怕只打一个Name标签以后找资源会方便很多。第三定期检查闲置资源停止的实例、未绑定的弹性IP、旧的快照这些都是隐形成本。第四自动化能省则省启动模板、自动扩缩容、快照策略配一次省一辈子。第五多看看CloudWatch的指标CPU、内存、磁盘、网络异常往往在出问题之前就有征兆。最后再分享一个小技巧如果你不确定某个实例类型适不适合你的应用可以用按需实例跑一天看看CloudWatch的指标再决定要不要转预留或换类型。别一上来就买三年预留万一选错了退都退不掉。