1. 从一台“永远在线”的虚拟电脑说起很多人第一次接触云服务器脑子里冒出来的第一个问题往往特别朴素我明明有本地电脑为什么还要花钱去租一台看不见摸不着的机器这个问题我当年也问过自己后来真正把业务跑起来才明白云服务器解决的从来不是“有没有电脑”的问题而是“这台电脑能不能永远在线、随时扩容、按需付费、坏了还能自动恢复”的问题。亚马逊云科技EC2全称是弹性计算云本质上就是给你提供一台可以随时开机、随时关机、随时换配置的虚拟服务器。你可以把它理解成一台放在别人机房里的电脑你通过远程连接去操作它它不关机、不断电、不担心你家停电或者网线被拔。这篇文章我想聊的不是那种官方文档式的概念罗列而是从一个实际使用者的角度把EC2里那些真正会影响你账单、影响你业务稳定性的知识点掰开揉碎讲清楚。适合谁看如果你是刚接触云服务的新手想搞明白实例类型、计费方式、存储选项这些基础概念那这篇内容能帮你少走很多弯路如果你已经用过一段时间但总觉得账单莫名其妙偏高、或者对安全组和网络配置一知半解那这里面关于选型逻辑和避坑经验的部分应该也能给你一些参考。我会尽量用生活化的类比来解释那些听起来很唬人的术语同时把关键参数的计算过程和选择理由都摆出来让你不仅知道怎么配还知道为什么这么配。EC2的知识点其实可以分成几个层次最表层的是“怎么开一台机器”往下一层是“怎么选一台合适的机器”再往深了是“怎么让这台机器安全、稳定、省钱地跑下去”。很多人只停留在第一层结果就是要么配置选大了浪费钱要么选小了业务跑不动要么安全组开得太宽被人扫端口。我见过太多这样的案例所以这篇文章会按照从选型到配置再到运维的顺序把每个环节的核心逻辑都讲透。2. EC2实例选型的核心逻辑与参数拆解2.1 实例家族到底怎么区分EC2的实例类型多到让人眼花缭乱什么通用型、计算优化型、内存优化型、存储优化型、加速计算型光看名字就够晕的。但其实背后的逻辑特别简单不同的应用对CPU、内存、存储、网络这几个资源的消耗比例不一样所以云厂商就按照这些比例把机器分成了不同的家族。你可以把它想象成买车有人需要拉货所以买卡车有人需要飙速度所以买跑车有人只是日常代步所以买轿车。EC2的实例家族就是云端的“车型分类”。通用型实例的CPU和内存比例比较均衡适合大多数Web应用、中小型数据库、开发测试环境。计算优化型则是CPU特别强、内存相对少适合视频编码、高性能计算、游戏服务器这类吃CPU的场景。内存优化型反过来内存特别大适合内存数据库、实时大数据分析、缓存服务。存储优化型则是本地盘性能特别高适合需要大量高速读写本地数据的场景。加速计算型就是带GPU或者专用加速芯片的适合机器学习训练和推理、图形渲染。我个人的经验是新手最容易犯的错误就是“凭感觉选”。看到有个应用要跑数据库就直接选了个内存优化型结果发现数据库的瓶颈其实在磁盘IO上。或者看到要跑一个Web服务就选了个计算优化型结果发现内存不够用导致进程频繁被系统杀掉。正确的做法是先搞清楚你的应用到底在哪个资源上是瓶颈然后针对性地选家族而不是反过来。2.2 实例规格的命名规则EC2实例的规格名称看起来像一串乱码比如m5.large、c5.xlarge、r5.2xlarge这种。其实这串名字是有固定格式的第一个字母代表家族比如m是通用型、c是计算优化型、r是内存优化型后面的数字代表第几代数字越大通常越新、性价比越高点号后面的部分代表规格大小从nano、micro、small、medium、large、xlarge、2xlarge一直往上翻倍。这里有个特别容易踩的坑不同代的实例同样叫large配置可能完全不一样。比如m4.large是2核8Gm5.large也是2核8G但m5用的是更新的CPU架构网络性能也更好。所以你在选型的时候不能只看large这个后缀一定要点进去看具体的vCPU数量和内存大小。我见过有人照着旧教程配了m4.large结果发现新账号默认只能开m5以上的代次折腾了半天才搞明白。还有一个细节是同一代实例里规格越大通常网络带宽和EBS带宽也越大。这个在跑高并发服务的时候特别明显。比如你用一个large规格的实例去扛一万个并发连接可能网络带宽先被打满了CPU反而还没跑满。这时候你升级到xlarge网络带宽翻倍问题可能就解决了。所以选型的时候不能只看CPU和内存网络性能也是一个关键指标。2.3 按需、预留、竞价三种计费方式怎么选EC2的计费方式主要分三种按需实例、预留实例、竞价实例。按需就是你开一小时算一小时的钱随时开随时关最灵活但单价最高。预留就是你承诺用一年或者三年提前付一部分钱然后每小时的价格会大幅降低适合长期稳定运行的服务。竞价实例则是你出一个你愿意付的最高价如果市场价格低于你的出价你就能用但市场价格一旦超过你的出价实例就会被回收适合那些可以中断的任务比如批处理、渲染、大数据分析。我自己的做法是核心业务用预留实例因为稳定跑一年下来能省不少钱临时测试或者不确定要不要长期跑的服务用按需那些跑几个小时就能出结果的任务比如视频转码、数据跑批就用竞价实例成本能压到按需的十分之一甚至更低。但竞价实例有个必须注意的点一定要做好中断处理。你的程序要能接受随时被中断并且能在中断后从断点继续。我见过有人把数据库跑在竞价实例上结果实例被回收数据还没来得及落盘损失惨重。这里给一个简单的成本对比假设你需要一台4核16G的机器跑一年计费方式每小时单价示例一年总成本示例适用场景按需约0.8元约7000元临时测试、短期项目预留一年全预付约0.5元约4400元长期稳定业务预留三年全预付约0.35元约9200元三年核心长期业务竞价约0.2元约1750元理论可中断的批处理任务这个表里的数字只是示意实际价格会随区域和代次变化但比例关系大致如此。你可以看到预留三年折算下来每年比按需省了一半还多。所以如果你的业务确定要跑很久预留是绝对划算的。3. 存储、网络与安全组的实操配置要点3.1 EBS存储类型的选择与性能计算EC2的实例本身只有计算资源真正的数据是存在EBS上的也就是弹性块存储。EBS有好几种类型通用型SSD、预置IOPS SSD、吞吐优化HDD、冷HDD。名字听起来复杂其实核心就两个指标IOPS和吞吐量。IOPS是每秒能读写多少次吞吐量是每秒能传多少数据。数据库这种小文件频繁读写的场景看IOPS视频编辑这种大文件连续读写的场景看吞吐量。通用型SSD是默认选项适合大多数场景价格适中性能也够用。预置IOPS SSD则是你可以指定一个IOPS数值云厂商保证你能达到这个性能适合对延迟极其敏感的数据库。但这里有个坑预置IOPS是要额外花钱的而且你预置了多少不管用不用都要付这个钱。我见过有人为了保险预置了很高的IOPS结果实际根本用不到白白浪费预算。还有一个关键点是EBS的带宽和实例规格是挂钩的。小规格的实例即使你买了高性能的EBS也跑不出那个速度因为实例本身的网络和存储带宽有限。所以选型的时候要综合考虑不能只盯着EBS看。比如你用一个t3.micro的实例去挂一个预置IOPS的SSD那纯属浪费因为t3.micro的EBS带宽根本喂不饱那个盘。3.2 安全组的配置逻辑与常见误区安全组本质上就是一套虚拟防火墙规则控制哪些流量能进、哪些能出。很多人第一次配安全组的时候为了图省事直接把入站规则开成0.0.0.0/0也就是允许所有IP访问所有端口。这个操作在测试环境可能无所谓但在生产环境就是灾难。我见过有人开了22端口给所有IP结果第二天就被暴力破解了几万次虽然最后没被攻破但日志里全是登录失败的记录看着就头疼。正确的做法是最小权限原则只开放必要的端口只允许必要的来源IP。比如你的Web服务只需要80和443端口对公网开放那其他端口一律关掉。SSH端口22最好只允许你自己的办公IP或者跳板机的IP访问而不是对所有IP开放。如果实在需要临时开放用完立刻关掉。还有一个容易忽略的点是出站规则。默认情况下安全组允许所有出站流量这通常没问题但如果你有合规要求也可以限制出站只允许访问特定的外部服务。另外安全组是有状态的也就是说你允许了入站请求对应的出站响应会自动放行不需要额外配置。这个特性让安全组的配置比传统防火墙简单很多。3.3 弹性IP与网络接口的绑定关系弹性IP就是一个固定的公网IP地址你可以把它绑定到任意实例上。它的价值在于当你重启实例或者更换实例的时候IP地址不会变这样你的域名解析就不用改来改去。但这里有个计费陷阱弹性IP如果绑定了实例并且实例在运行是不收费的但如果弹性IP没有绑定实例或者绑定的实例处于停止状态那就要按小时收费。这个设计的目的是防止有人大量占用IP地址不用。我个人的建议是除非你的服务确实需要一个固定的公网入口否则不要随便申请弹性IP。很多场景下用负载均衡器或者域名解析到实例的公有DNS名称就够了不需要弹性IP。而且弹性IP的数量是有限额的默认每个区域5个需要更多得申请提额。网络接口这块每个实例至少有一个主网络接口你也可以附加多个辅助网络接口。多网卡的好处是可以把管理流量和业务流量分开或者把不同子网的流量分开。但多网卡配置起来比较复杂涉及到路由表的设置新手建议先用单网卡等有明确需求了再折腾。4. 从零开一台实例的完整实操流程4.1 启动实例前的准备工作在真正点“启动实例”按钮之前有几件事必须先想清楚。第一是区域选择你要把实例开在哪个区域。这个选择会影响延迟、价格和可用服务。一般来说离你的用户越近越好但也要考虑价格差异。有些区域因为电力成本低同样的实例价格能便宜百分之二三十。第二是VPC和子网的选择默认情况下每个区域都有一个默认VPC你可以直接用但生产环境建议自己规划网段避免和本地网络冲突。第三是密钥对。EC2用密钥对来登录而不是密码。你创建实例的时候会生成一个密钥对公钥放在云端私钥你自己下载保存。这个私钥文件只能下载一次丢了就再也拿不到了只能重新创建密钥对并重建实例。我见过有人把私钥随手放在下载文件夹里后来清理磁盘的时候删掉了结果再也连不上那台机器只能重新开一台。所以私钥文件一定要妥善保存最好放在一个加密的存储里并且做好备份。第四是安全组的规划。前面说了最小权限原则这里再补充一点最好提前把安全组建好而不是在启动实例的时候临时创建。因为临时创建的安全组往往规则比较随意后面再改容易漏掉。提前建好一个命名规范的安全组比如“web-server-sg”、“db-server-sg”后面复用起来也方便。4.2 一步步配置实例参数启动实例的界面看起来选项很多但其实核心就那几个。首先是名称和标签给实例起个有意义的名字比如“prod-web-01”后面在控制台里找起来方便。然后是镜像选择也就是操作系统。亚马逊提供了各种Linux发行版和Windows Server的镜像你也可以用自己的自定义镜像。新手建议先用亚马逊Linux或者Ubuntu社区支持好遇到问题容易搜到答案。实例类型的选择我们前面已经讲过了这里不再重复。关键是要根据你的实际负载来选不确定的话可以先选个通用型的medium或者large跑起来之后看监控数据再调整。存储这块默认是通用型SSD大小根据你的数据量来定。系统盘一般20G到30G就够了数据盘另算。注意存储是可以后续扩容的但只能往大了扩不能往小了缩所以一开始不用买太大不够了再扩。网络设置里VPC和子网选默认的就行自动分配公网IP要勾上否则你的实例没有公网地址从外面连不上。安全组选你提前建好的那个。高级选项里可以配置IAM角色、用户数据脚本等这些后面再讲第一次开实例可以先跳过。4.3 连接实例与初始化配置实例启动之后状态变成“运行中”你就可以连接了。Linux实例用SSHWindows实例用RDP。SSH连接的命令大概是这样的ssh -i /path/to/your-key.pem ec2-useryour-instance-public-ip这里有几个细节要注意。第一是权限问题私钥文件的权限必须是400也就是只有你自己能读否则SSH会拒绝使用这个密钥。第二是用户名不同的镜像默认用户名不一样亚马逊Linux是ec2-userUbuntu是ubuntuCentOS是centos用错了连不上。第三是安全组要允许你的IP访问22端口否则连接会被拒绝。连上之后第一件事是更新系统补丁第二件事是配置时区和时间同步第三件事是安装你需要的软件。这些操作看起来简单但每一步都有坑。比如更新系统的时候如果内核更新了可能需要重启才能生效时区配错了日志时间对不上排查问题的时候会很痛苦时间不同步可能会导致证书验证失败或者数据库事务异常。我个人的习惯是连上实例之后先跑一个初始化脚本把常用的工具装好把时区和时间同步配好把日志轮转配好。这个脚本可以做成用户数据在启动实例的时候自动执行省得每次手动操作。用户数据就是一段在实例首次启动时运行的脚本你可以把初始化命令写进去实例起来之后自动就跑完了。5. 日常运维中的监控、告警与成本控制5.1 CloudWatch监控指标怎么看EC2自带CloudWatch监控默认提供CPU使用率、网络流量、磁盘读写等指标。这些指标看起来简单但真正会看的人不多。比如CPU使用率很多人只看平均值觉得平均50%就没事。但实际上平均值会掩盖峰值如果CPU每隔几分钟就飙到100%虽然平均值不高但用户体验会明显卡顿。所以看监控要看最大值和百分位值比如P99也就是99%的请求都在这个值以下。网络流量指标也很关键。如果你的实例网络流量持续接近实例规格的上限那就说明网络是瓶颈需要考虑升级规格或者用负载均衡分散流量。磁盘指标里EBS的读写延迟和队列长度是重点如果队列长度持续大于1说明磁盘IO跟不上了需要考虑换更高性能的EBS或者优化应用。我自己的做法是给每个实例都配一个CloudWatch告警CPU持续5分钟超过80%就发通知网络流量持续5分钟超过规格的70%也发通知。这样在用户感知到问题之前我就能先收到预警有时间去处理。5.2 告警配置与自动恢复告警只是第一步更重要的是自动恢复。EC2支持状态检查告警如果实例的系统状态检查失败可以自动重启或者恢复实例。这个功能在实例因为底层硬件故障而挂掉的时候特别有用能自动把实例迁移到健康的宿主机上。配置起来也简单在CloudWatch里创建一个状态检查失败的告警然后关联一个恢复操作就行。但自动恢复不是万能的。如果实例是因为应用崩溃而挂掉状态检查可能还是通过的这时候就需要应用层面的健康检查。比如你可以配一个负载均衡器让它定期检查你的应用端口如果连续几次检查失败就把实例从负载均衡里摘掉然后触发一个自动扩展组来替换这个实例。这套机制搭起来之后你的服务就有了基本的自愈能力。还有一个容易被忽略的点是日志。CloudWatch可以收集实例的系统日志和应用日志但默认是不开的需要你手动配置CloudWatch代理。配好之后你可以在CloudWatch里直接搜索日志不用再SSH到实例上去翻文件。这个在排查问题的时候特别省时间尤其是实例已经挂掉连不上的时候日志还在CloudWatch里能帮你快速定位原因。5.3 成本控制的几个实用技巧EC2的成本控制是个永恒的话题。除了前面说的预留实例和竞价实例还有几个技巧很实用。第一是定时开关机如果你的服务只在工作时间用那晚上和周末就可以关掉能省一半以上的钱。用CloudWatch的事件规则或者Lambda函数可以定时执行开关机操作。第二是选择合适的区域不同区域的价格差异不小在不影响延迟的前提下选便宜的区域能省不少。第三是定期检查闲置资源。我每个月都会扫一遍账号看看有没有没绑定的弹性IP、没挂载的EBS卷、快照存了一大堆但早就不用的。这些东西单个看起来不贵但积少成多一年下来也是不小的数目。第四是用成本分配标签给每个实例打上项目、环境、负责人的标签这样月底看账单的时候能清楚地知道钱花在哪了哪个项目超支了一目了然。还有一个进阶技巧是使用Savings Plans这是一种更灵活的预留方式你承诺每小时花多少钱然后不管用什么实例类型都能享受折扣。适合那些实例类型经常变、但总体用量稳定的场景。不过这个需要你对未来的用量有比较准确的预估不然承诺多了用不完就浪费了。6. 常见问题排查与避坑经验实录6.1 连接不上实例的排查思路连接不上实例是最常见的问题排查起来其实有固定的套路。第一步先看实例状态是不是在运行中。第二步看安全组22端口有没有对你的IP开放。第三步看网络ACL子网级别的ACL有没有放行。第四步看路由表子网有没有路由到互联网网关。第五步看实例本身SSH服务有没有在跑磁盘是不是满了导致服务起不来。这五步走下来九成以上的连接问题都能定位到。我遇到最多的情况是安全组规则改了但忘了保存或者换了办公网络导致IP变了但安全组没更新。还有一种情况是实例的磁盘满了SSH服务写不了日志就挂了这时候只能通过控制台的串口连接或者重启实例来恢复。提示如果你用的是动态IP安全组里不要写具体的IP地址而是写一个IP段或者用前缀列表来管理。这样IP变了也不用改安全组。6.2 性能不达预期的常见原因性能不达预期通常有几个原因。第一是实例规格选小了CPU或者内存不够。第二是EBS的IOPS或者吞吐量不够磁盘成了瓶颈。第三是网络带宽不够尤其是跨区域传输的时候。第四是应用本身的配置问题比如数据库连接池太小、Web服务器的工作进程数不够。排查的时候先用CloudWatch看指标确定是哪个资源先到瓶颈。如果是CPU先满那就升级CPU或者优化代码。如果是磁盘IO先满那就换更高性能的EBS或者优化查询。如果是网络先满那就升级实例规格或者用CDN分流。关键是要找到真正的瓶颈而不是盲目升级所有配置。我见过一个案例有人觉得网站慢就把实例从2核升到8核结果还是慢。后来一看监控CPU从来没超过30%瓶颈在数据库查询上一条慢查询拖垮了整个页面。所以性能问题一定要用数据说话不能凭感觉。6.3 账单异常增长的排查方法账单突然涨了先别慌按步骤排查。第一步看成本管理器里的每日费用趋势确定是从哪天开始涨的。第二步按服务维度拆分看是EC2涨了还是EBS涨了还是流量费涨了。第三步按区域拆分看是哪个区域的费用增加了。第四步按标签拆分看是哪个项目的费用增加了。常见的原因有忘了关的测试实例、没绑定的弹性IP、快照越存越多、跨区域流量费、NAT网关的处理费。NAT网关这个特别隐蔽它是按处理的数据量收费的如果你的实例通过NAT网关访问外网流量大的话费用会很高。这时候可以考虑用VPC端点来访问特定服务绕过NAT网关能省不少钱。还有一个坑是EBS快照的存储费。快照是增量存储的但如果你频繁创建快照又不清理积少成多也是一笔开销。建议设一个生命周期策略自动删除超过一定天数的快照。问题现象可能原因排查方法解决方案连接超时安全组未放行检查入站规则添加对应端口规则连接被拒SSH服务未启动控制台查看系统日志重启实例或修复磁盘CPU持续高实例规格不足CloudWatch看CPU指标升级规格或优化代码磁盘IO高EBS性能不足看EBS队列长度换更高性能EBS账单突增闲置资源或流量费成本管理器按维度拆分清理闲置、优化架构6.4 几个我踩过的坑第一个坑是可用区选择。创建实例的时候如果你选了某个可用区后面想换到另一个可用区是不能直接改的只能重新创建实例。所以一开始就要规划好把实例分散在不同的可用区这样单个可用区出问题的时候服务还能继续跑。第二个坑是实例的停止和终止的区别。停止实例只是关机EBS数据还在下次可以再开机。终止实例则是彻底删除EBS数据默认也会被删除除非你设置了不删除。我有一次手滑点了终止结果那台机器上的数据全没了幸好有快照备份不然就惨了。所以生产环境的实例一定要设置终止保护防止误操作。第三个坑是密钥对的丢失。前面说过了私钥只能下载一次丢了就没了。我的做法是把私钥放在一个加密的密码管理器里同时离线备份一份。另外不要多个实例共用同一个密钥对万一泄露了影响面太大。每个环境用不同的密钥对定期轮换。第四个坑是安全组的默认规则。新建安全组的时候默认是拒绝所有入站、允许所有出站。这个默认值其实挺合理的但很多人没注意以为新建的安全组就是全开的结果配了半天发现连不上其实是入站规则没加。所以新建安全组之后第一件事就是加入站规则。7. 关于EC2学习路径的一点个人建议EC2的知识点其实远不止上面这些还有自动扩展、负载均衡、容器集成、混合云连接等等。但我觉得学习路径应该是由浅入深的先把单台实例开起来、连上去、跑起来然后再去折腾高可用和自动化。很多人一上来就想搞一套完整的架构结果基础没打牢遇到问题不知道从哪查起。我自己的学习方法是每学一个知识点就动手开一台实例去验证。比如学了安全组就故意配错规则看看连接会报什么错。学了EBS就故意把磁盘写满看看系统会有什么反应。这种“故意制造故障”的学习方式比只看文档印象深得多而且真正遇到问题的时候你会有一种“这个我见过”的从容。另外EC2的官方文档其实写得很好但很多人不看遇到问题就到处搜。我的建议是先把官方文档里关于实例类型、存储、网络、安全组这几个核心章节通读一遍不用记住所有细节但要知道有哪些东西遇到问题知道去哪查。然后再结合实践去深入。最后说一个我个人的习惯每次开实例之前先想清楚这台实例的用途、预期生命周期、成本预算、安全要求。把这四个问题回答清楚了配置起来就不会乱。用完及时清理该关的关该删的删保持账号干净。这个习惯看起来简单但能帮你省下不少钱和不少麻烦。
