第二章：AWS核心计算服务——EC2实例类型、购买选项、用户数据与弹性伸缩组
好，咱们今天聊聊AWS最核心的计算服务——EC2。说实话，我见过太多人一上来就开个t2.micro跑生产，结果业务一上来直接卡死。EC2这东西，选对了是利器，选错了就是烧钱机器。
2.1 EC2实例类型：别选错了，真的会哭
AWS的实例类型，说白了就是给你一台虚拟机的“配置套餐”。它分成了几个大族系，每个族系干不同的活。我个人习惯，先看业务再选型，而不是反过来。
| 实例族系 | 典型用途 | 我的经验 |
|---|---|---|
| 通用型（T系、M系） | Web服务器、中小型数据库、开发环境 | t3/t4g适合突发负载，但别跑持续高CPU任务 |
| 计算优化型（C系） | 批处理、高性能计算、游戏服务器 | C5/C6g做视频转码，性价比极高 |
| 内存优化型（R系、X系） | 内存数据库、实时分析、缓存 | R5跑Redis，我踩过内存溢出的坑 |
| 存储优化型（I系、D系） | NoSQL数据库、数据仓库、日志处理 | I3做Elasticsearch，IOPS很稳 |
| GPU实例（P系、G系） | 机器学习训练、图形渲染、视频编码 | P3跑深度学习，记得配EFA网络 |
核心要点：实例类型决定了你的CPU、内存、网络和存储能力。选错了，要么性能不够，要么钱白花了。
我记得有一次帮客户做架构优化，他们用t2.medium跑一个实时数据分析服务。结果一到高峰期，CPU积分直接被打穿，服务响应时间从200ms飙到5秒。后来换成c5.large，问题直接解决，成本还降了30%。你想想看，这就是选型的重要性。
2.2 购买选项：省钱还是省心，你自己选
AWS给了你三种购买方式，说白了就是：按需、预留、竞价。我一般这么跟团队说：按需是打车，预留是月票，竞价是拼车。
2.2.1 按需实例
按需就是按小时或按秒付费，想开就开，想关就关。适合那些负载不稳定、或者你还没摸清业务规律的情况。嗯，这里要注意：按需虽然灵活，但长期跑下来，成本是最高的。
2.2.2 预留实例
预留实例说白了就是你跟AWS签个“包年包月”合同。你承诺用1年或3年，AWS给你打折。折扣力度有多大？我见过最高能省70%。
我的建议：如果你有稳定的基础负载，比如数据库、核心业务服务器，果断上预留实例。我曾经帮一个客户把30台按需的Web服务器换成3年预留，一年省了十几万美金。
2.2.3 竞价实例
竞价实例是AWS把闲置的计算资源拿出来拍卖。你出价，AWS决定给不给你用。价格波动很大，有时候能比按需便宜90%。但问题来了——AWS随时可能回收你的实例，给个2分钟通知。
避坑指南：我曾经在项目里用竞价实例跑批处理任务，结果半夜竞价价格飙升，实例全被回收了，任务跑了8小时全白费。后来我加了Spot Fleet和混合策略，才稳下来。
所以，竞价实例适合什么？无状态、可中断、容错性强的任务，比如大数据处理、CI/CD构建、渲染任务。千万别把数据库跑在竞价实例上，除非你想体验“数据丢失”的刺激。
2.3 用户数据：让EC2开机就干活
用户数据（User Data）是啥？说白了就是你在启动EC2时，塞给操作系统的一段脚本。它会在实例第一次启动时自动执行。我习惯用它来做初始化配置。
#!/bin/bash
# 安装Web服务器
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from User Data!</h1>" > /var/www/html/index.html你看，这段脚本干了三件事：更新系统、装Apache、启动服务。实例启动后，直接就能访问网页。我经常用用户数据来做三件事：安装软件、配置环境、注册到负载均衡。
注意：用户数据只在实例第一次启动时执行。如果你重启实例，它不会再次运行。除非你通过控制台或API重新设置。
我记得有一次，客户说他们的EC2每次重启都要手动配置环境。我说，你把初始化脚本写到用户数据里不就行了？他们一脸懵。后来改完，运维效率直接翻倍。
2.4 弹性伸缩组：让实例数量自动适配负载
弹性伸缩组（Auto Scaling Group，ASG）是AWS里我最喜欢的服务之一。它能让你的EC2实例数量根据负载自动增减。说白了，就是“负载高了自动加机器，负载低了自动减机器”。
2.4.1 ASG的核心组件
- 启动模板（Launch Template）：定义实例的配置，包括AMI、实例类型、安全组、密钥对等。
- 伸缩策略（Scaling Policy）：定义何时增加或减少实例。常见的有基于CPU、内存、网络流量的策略。
- 健康检查（Health Check）：ASG会定期检查实例的健康状态，不健康的实例会被自动替换。
- 最小/最大/期望容量：定义实例数量的上下限。
2.4.2 一个典型的ASG配置
# 启动模板配置示例
LaunchTemplate:
ImageId: ami-0abcdef1234567890
InstanceType: t3.medium
SecurityGroups:
- sg-0123456789abcdef0
UserData:
Fn::Base64: !Sub |
#!/bin/bash
echo "Instance launched by ASG" > /var/log/asg.log
# 伸缩策略：基于CPU使用率
ScalingPolicy:
TargetTrackingConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ASGAverageCPUUtilization
TargetValue: 60.0这个配置的意思是：当ASG中所有实例的平均CPU使用率超过60%时，自动增加实例；低于60%时，自动减少实例。我一般会把目标值设在50%-70%之间，留点余量应对突发流量。
我的经验：ASG一定要配合负载均衡器（ALB/NLB）使用。我曾经见过有人只用ASG，结果新加的实例没有注册到负载均衡，流量全打到了旧实例上，新实例闲着看热闹。
2.4.3 避坑指南
- 冷却时间（Cooldown）：别把冷却时间设得太短，否则ASG会频繁伸缩，造成“抖动”。我一般设300秒。
- 实例生命周期钩子：如果你需要在实例启动或终止时执行自定义操作（比如从数据库注销），记得用生命周期钩子。
- 混合实例策略：在ASG里混合使用按需和竞价实例，可以平衡成本和稳定性。我一般按需占20%，竞价占80%。
我曾经踩过的坑：有一次我把ASG的最小容量设成了0，结果半夜负载降下来，ASG把所有实例都终止了。第二天早上业务恢复，ASG重新启动实例，但数据库连接池还没预热，导致服务挂了10分钟。从那以后，我至少会保留1个实例作为“看门狗”。
2.5 总结一下
EC2的核心就这四块：实例类型选对、购买方式算清、用户数据用好、ASG配稳。你想想看，如果这四块都搞明白了，AWS的计算服务基本就吃透了。下一章咱们聊聊存储，到时候我会分享一些S3和EBS的实战经验，保证让你少走弯路。