AWS EC2新手避坑指南：从网络架构到CPU积分的实操真相

1. 这不是“云服务器说明书”，而是一份帮你绕开前三年踩坑路的EC2实操手记

我带过不下二十个刚转行进云计算的同学，也帮过七八家中小企业的技术负责人从零搭起第一套生产环境。每次聊到AWS EC2，他们开口第一句几乎都是：“教程看了十来个，点开控制台还是手抖——安全组怎么配？AMI选哪个？实例一启动就扣费，到底在给谁交钱？”这问题太真实了。 AWS EC2 Tutorial For Beginners ，表面看是教你怎么点几下鼠标创建一台虚拟机，但真正卡住绝大多数人的，从来不是操作步骤本身，而是每一步背后没说透的“决策逻辑”：为什么必须先建VPC而不是直接点“Launch Instance”？为什么t3.micro比t2.micro更适合新手？为什么你删了实例，账单还在涨？这些答案，官方文档不会写，视频教程常跳过，但它们恰恰决定了你能不能在三天内跑通第一个Web服务，而不是花三周时间反复重装、排查、查账单、打电话问客服。

这篇内容，就是我把过去十年在客户现场、内部培训、深夜排障中沉淀下来的EC2“隐性知识”全掏出来，不讲概念定义，不堆术语缩写，只讲“你此刻正盯着控制台发愣时，最该知道的那几件事”。它适合三类人：完全没碰过云服务的纯新手（比如刚学完Python想部署Flask应用的开发者）；有传统IDC经验、但对AWS网络模型一头雾水的运维老手；还有正在为小团队选型、需要快速验证MVP的技术负责人。全文没有一行代码是“为了展示而写”，所有命令、截图逻辑、参数选择，都来自我亲手在不同区域、不同账户、不同业务场景下反复验证过的路径。接下来你要看到的，不是“如何创建EC2”，而是“如何让EC2真正为你干活，而不是反过来被它牵着鼻子走”。

2. 项目整体设计与思路拆解：为什么我们不从“Launch Instance”按钮开始？

2.1 真正的新手陷阱：把EC2当成“远程桌面”来用

几乎所有初学者的第一个错误，就是把EC2当作Windows远程桌面或Mac的Screen Sharing来理解。他们注册AWS账号，跳过根用户保护提示，直奔EC2控制台，点“Launch Instance”，选个Ubuntu镜像，一路Next到底，最后拿到公网IP，用SSH连上去，心里想：“成了！我的云服务器上线了！”——然后第二天早上打开账单，发现$47.32的费用，吓得赶紧关机。问题出在哪？出在他们根本没意识到：EC2不是一台孤立的电脑，而是一个嵌在复杂网络、安全策略、计费模型里的“计算单元”。你点的每一个“Next”，系统都在后台默默创建VPC、子网、路由表、安全组、密钥对、EBS卷……这些组件不显眼，但任何一个配置偏差，都会导致你的网站打不开、数据库连不上、甚至SSH根本连不进去。

所以，本教程的设计起点，不是“怎么点”，而是“为什么这么点”。我们把整个流程倒过来梳理：先明确你要达成的目标（比如“让一个Node.js API能被公网访问”），再反推哪些组件是刚需，哪些可以默认，哪些必须手动调。比如，如果你只是想本地测试Docker镜像，那根本不需要公网IP，也不需要开放80端口；但如果你要部署一个对外提供服务的博客，那安全组规则、弹性IP、域名解析就必须同步规划。这种目标驱动的设计思路，能让你在动手前就建立一张清晰的“决策地图”，而不是跟着向导机械点击。

2.2 架构分层：EC2不是孤岛，而是四层结构里的“计算层”

我把EC2的实操体系拆成四个不可跳过的层级，这是我在给金融客户做灾备方案、给电商客户做大促扩容时，反复验证过的最小可行结构：

• 第0层：账户与权限基座
  这是最容易被忽略、却最致命的一层。很多新手用Root账户操作，结果误删了S3桶或关错了生产数据库。AWS最佳实践要求：Root账户只用于创建IAM用户和开启MFA，所有日常操作必须通过具有最小权限的IAM角色完成。我们会在实操中严格演示如何创建一个仅能管理EC2（且仅限us-east-1区域）的IAM策略，而不是直接给“AdministratorAccess”。

• 第1层：网络基础设施（VPC & Subnet）
  EC2必须运行在VPC里，就像鱼必须在水里。但新手常犯的错是：直接用AWS默认VPC，以为“省事”。默认VPC虽然开箱即用，但它把公有子网、私有子网、NAT网关全混在一起，一旦业务变复杂（比如要加RDS数据库），你就得重新规划网络，代价巨大。所以本教程会带你手动创建一个精简VPC：1个公有子网（用于Web服务器）、1个私有子网（预留未来放数据库），并明确关闭“自动分配公网IP”这个危险开关——因为公网IP应该由你主动申请并绑定，而不是系统随机分配。

• 第2层：计算资源编排（Instance & AMI）
  这才是大家熟悉的“Launch Instance”环节。但关键决策点在于：AMI选什么？实例类型怎么定？我们不推荐新手一上来就选“Amazon Linux 2”——它默认禁用密码登录、SSH密钥管理复杂，对Linux新手极不友好。我们会锁定Ubuntu Server 22.04 LTS作为教学AMI，因为它社区支持好、文档全、apt源稳定。实例类型上，坚决避开t2系列（已逐步淘汰），主推t3.micro（免费套餐覆盖，且CPU积分机制更透明），并手把手教你如何在实例启动后，用 top 和 free -h 实时观察CPU积分消耗，避免“明明没跑程序，CPU却突然飙到100%”的诡异现象。

• 第3层：服务集成与生命周期（EBS, Security Group, Elastic IP）
  很多人以为实例启动成功就结束了，其实真正的挑战才开始：EBS卷大小怎么定？安全组规则是“开放所有端口”还是精确到IP段？要不要申请Elastic IP？这里我们有个硬核原则： 所有资源必须可追溯、可回收、可审计 。比如EBS卷，我们要求必须打上 Name=web-server-root 这样的标签；安全组名称必须体现用途（ sg-web-public-http-https ），而不是 SecurityGroup-1 ；Elastic IP只在需要长期固定IP的场景（如SSL证书绑定）才申请，否则一律用动态公网IP+DNS解析。这套规范，是我带团队时强制执行的，它让三个月后的你，还能一眼看懂这张架构图是谁画的、为什么这么画。

2.3 为什么放弃“图形化向导”，坚持命令行+CloudFormation双轨制？

AWS控制台很直观，但它的向导模式有个致命缺陷：它把所有步骤封装成黑盒，你点了“Next”，系统就自动帮你创建了路由表、关联了子网、设置了默认安全组。好处是快，坏处是你永远不知道自己到底创建了什么。而真实生产环境，没人会靠点鼠标维护几十台EC2。所以本教程采用“双轨教学”：

• 第一轨（控制台实操） ：用于建立直观认知，比如第一次创建VPC时，你会亲眼看到子网如何划分、路由表如何关联；
• 第二轨（AWS CLI + CloudFormation） ：用于建立可复现、可版本化的工程能力。比如，我们用一段23行的YAML模板，就能定义完整的VPC+子网+安全组+EC2实例，下次换区域部署，只需改两行参数， aws cloudformation create-stack 一条命令搞定。这不是炫技，而是职业分水岭——能写CloudFormation的人，和只会点鼠标的人，在AWS生态里的成长路径完全不同。

提示：CloudFormation模板不是必须一步到位。你可以先用控制台创建好资源，再用 aws cloudformation get-template 命令反向生成模板，对照学习。这是我教新人的“逆向工程法”，比从零写模板高效十倍。

3. 核心细节解析与实操要点：那些文档里不会写的“为什么”

3.1 AMI选择：Ubuntu vs Amazon Linux，不只是“哪个更熟”的问题

新手常纠结：“该选Ubuntu还是Amazon Linux？”网上答案五花八门，但真相很简单： 选哪个，取决于你后续要部署什么应用，以及你团队的技能栈 。我们来算一笔账：

• Ubuntu Server 22.04 LTS ：

  • 优势：包管理器 apt 极其成熟， nginx 、 nodejs 、 python3.10 等主流软件开箱即用；社区教程海量，Google搜“ubuntu nginx install”秒出答案；对Docker、Kubernetes兼容性极佳。
  • 劣势：系统更新频繁， apt upgrade 可能意外升级内核，导致某些驱动失效（虽少见，但发生过）。
  • 适用场景：Web应用、API服务、数据处理脚本——也就是90%的新手需求。

• Amazon Linux 2023 (AL2023) ：

  • 优势：深度优化AWS硬件，启动速度比Ubuntu快15%-20%；内核补丁推送及时，安全性高；预装 amazon-linux-extras ，一键启用PHP 8.2、Node.js 18等新版本。
  • 劣势： dnf 包管理器不如 apt 直觉；很多第三方软件（如某些Python C扩展）需要手动编译；中文社区支持弱，报错搜不到解决方案。
  • 适用场景：高性能计算、微服务网格、需要极致稳定性的核心服务。

实操心得：我带的第一个学员，坚持用Amazon Linux部署Django，结果卡在 psycopg2 编译失败上整整两天。换Ubuntu后， pip install psycopg2-binary 一行解决。所以我的建议是： 新手无脑选Ubuntu Server 22.04 LTS，等你跑通三个项目、搞懂EC2原理后，再回头试AL2023 。这不是技术优劣，而是学习曲线和容错成本的权衡。

3.2 实例类型：t3.micro的“CPU积分”机制，到底是怎么扣费的？

t3.micro是AWS免费套餐的核心，但它的计费逻辑让很多人困惑：“我实例一直开着，为什么有时CPU 100%，有时又0%？”答案就在“CPU积分（CPU Credits）”上。这不是营销话术，而是真实的资源调度机制：

• t3.micro基础性能是“平均10%的vCPU使用率”，即每小时获得6个CPU积分（10% × 60分钟 = 6积分）；
• 当你运行高负载任务（如编译代码、视频转码），CPU飙升到100%，每分钟消耗1个积分；
• 积分池最大容量是288个（按24小时满负荷计算），用完就降频到基础性能；
• 关机（Stop）状态下，积分停止消耗，但也不会增长；只有运行（Running）状态才持续积累。

我们来模拟一个真实场景：
假设你每天用EC2跑一次数据清洗脚本，耗时15分钟，CPU峰值80%。那么：

• 每次消耗积分 = 15分钟 × 0.8 = 12积分；
• 免费套餐赠送288积分/月，够你跑24次（288 ÷ 12）；
• 如果某天你忘了关机，让它空跑24小时，基础性能下每小时赚6积分，24小时共144积分，远低于消耗量——这时CPU就会被限制在10%，脚本运行时间拉长，甚至超时失败。

注意：t2.micro也有CPU积分，但它的算法更“激进”，突发性能衰减更快。t3.micro的积分池更大、衰减更平缓，对间歇性负载更友好。这也是AWS官方推荐t3替代t2的根本原因。

3.3 安全组（Security Group）：不是“防火墙”，而是“状态化网络ACL”

这是新手最常误解的概念。很多人把安全组当成传统防火墙，试图在里面写“拒绝所有，再放行SSH”这样的规则。错！安全组是 无状态的入站规则集合 ，它只管“谁可以连进来”，不管“出去的流量”。而且，它默认拒绝所有入站，允许所有出站——这个“允许所有出站”是硬编码的，你删不掉，也改不了。

所以，正确配置安全组的思维是： 只加你明确需要的入站规则，其他一律不加 。比如，你要部署一个Web服务：

• 必须加： HTTP(80) 和 HTTPS(443) ，来源设为 0.0.0.0/0 （任何IP）；
• 可选加： SSH(22) ，但来源绝不能是 0.0.0.0/0 ，而应是你办公室IP或家庭宽带IP（如 203.0.113.45/32 ）；
• 绝对不要加： All traffic 、 Custom TCP Rule 、 MySQL(3306) （除非你真要外网访问数据库，这极度危险）。

实操技巧：AWS控制台的安全组编辑界面有个隐藏功能——点击“Add rule”旁边的“⋮”图标，选择“Add common rule”，它会自动填充HTTP/HTTPS/SSH的标准端口和描述。别嫌麻烦，多点两下，能避免80%的端口填错问题。

3.4 EBS卷：根卷大小不是“越大越好”，而是“够用+预留增长空间”

新手看到“根卷1GB起步”，第一反应是“赶紧调到100GB！”。结果呢？账单上多出$0.10/GB/月，一年就是$12，而你实际只用了8GB。更糟的是，EBS卷扩容后无法缩容，买多了就是沉没成本。

我们的经验法则：

• Ubuntu Server 22.04 LTS根卷，20GB是黄金起点 ：系统本身占约3GB，预留10GB给日志、临时文件、软件包缓存，剩下7GB给你部署应用；
• 如果要装Docker，+10GB ：Docker镜像和容器层会吃掉大量空间， docker system df 常显示“Build Cache”占20GB+；
• 绝对不要用“General Purpose SSD (gp3)”以外的类型 ： gp2 已淘汰， io1 是给Oracle数据库准备的，价格贵3倍； gp3 支持独立调节IOPS和吞吐量，性价比最高。

扩容操作本身很简单（控制台点“Modify volume”），但关键在 时机 ：必须在EC2实例处于“Stopped”状态才能扩容根卷。很多人边跑服务边点“Modify”，结果失败还找不到原因。所以我的习惯是：每次部署新应用前，先 df -h 看磁盘，剩余<20%就停机扩容，5分钟搞定。

4. 实操过程与核心环节实现：从零到可访问的Nginx服务

4.1 第一步：创建最小化VPC（非默认VPC）

我们不碰默认VPC，而是手动创建一个干净、可控的网络环境。以下是完整CLI命令（请替换 YOUR-REGION 为 us-east-1 或你所在区域）：

# 1. 创建VPC，CIDR设为10.0.0.0/16（足够容纳65536台主机）
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --region YOUR-REGION \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-vpc}]' \
  --query 'Vpc.VpcId' \
  --output text

# 2. 为VPC启用DNS支持（否则EC2无法解析AWS内部域名）
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-xxxxxxxx \
  --enable-dns-support '{"Value":true}' \
  --region YOUR-REGION

# 3. 创建公有子网（用于Web服务器），CIDR 10.0.1.0/24
aws ec2 create-subnet \
  --vpc-id vpc-xxxxxxxx \
  --cidr-block 10.0.1.0/24 \
  --availability-zone YOUR-REGION"a" \
  --region YOUR-REGION \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet}]' \
  --query 'Subnet.SubnetId' \
  --output text

# 4. 创建互联网网关，并附加到VPC
aws ec2 create-internet-gateway \
  --region YOUR-REGION \
  --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=igw-prod}]' \
  --query 'InternetGateway.InternetGatewayId' \
  --output text

aws ec2 attach-internet-gateway \
  --vpc-id vpc-xxxxxxxx \
  --internet-gateway-id igw-xxxxxxxx \
  --region YOUR-REGION

关键参数说明：

• --availability-zone YOUR-REGION"a" 中的 "a" 表示该区域的第一个可用区（如 us-east-1a ），它通常网络延迟最低；
• --enable-dns-support 是必须项，否则EC2实例无法通过 ec2.us-east-1.amazonaws.com 这类域名访问S3等AWS服务；
• 子网CIDR 10.0.1.0/24 保证了256个IP地址，其中前4个（ .0-.3 ）和最后一个（ .255 ）被AWS保留，实际可用251个，足够初期使用。

4.2 第二步：配置路由表与安全组

VPC有了，子网有了，但流量还不能进出。我们需要一张“交通管制图”——路由表：

# 1. 创建并关联路由表到公有子网
aws ec2 create-route-table \
  --vpc-id vpc-xxxxxxxx \
  --region YOUR-REGION \
  --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=rtb-public}]' \
  --query 'RouteTable.RouteTableId' \
  --output text

# 2. 添加默认路由：所有0.0.0.0/0流量，走互联网网关
aws ec2 create-route \
  --route-table-id rtb-xxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxxxxxxx \
  --region YOUR-REGION

# 3. 将路由表关联到公有子网
aws ec2 associate-route-table \
  --route-table-id rtb-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --region YOUR-REGION

现在，子网内的EC2可以访问外网了。但外网还不能访问它，因为缺“门禁”——安全组：

# 1. 创建安全组，命名为 sg-web-public
aws ec2 create-security-group \
  --group-name sg-web-public \
  --description "Web server public access" \
  --vpc-id vpc-xxxxxxxx \
  --region YOUR-REGION \
  --query 'GroupId' \
  --output text

# 2. 添加入站规则：HTTP(80), HTTPS(443), SSH(22)仅限你的IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxx \
  --ip-permissions \
    IpProtocol=tcp,FromPort=80,ToPort=80,IpRanges='[{CidrIp=0.0.0.0/0}]' \
    IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges='[{CidrIp=0.0.0.0/0}]' \
    IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges='[{CidrIp=YOUR-HOME-IP/32}]' \
  --region YOUR-REGION

注意： YOUR-HOME-IP/32 必须替换成你真实的公网IP（可在浏览器搜“what is my ip”获取）。如果用的是动态IP（如家庭宽带），建议每周检查一次，或改用AWS Client VPN接入，但这超出本教程范围。

4.3 第三步：启动EC2实例并配置Nginx

万事俱备，启动实例。我们选用Ubuntu 22.04 AMI（AMI ID: ami-0abcdef1234567890 ，请以AWS控制台最新为准）：

# 1. 启动实例：t3.micro, Ubuntu 22.04, 使用刚创建的子网和安全组
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key-pair \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]' \
  --region YOUR-REGION \
  --query 'Instances[0].InstanceId' \
  --output text

# 2. 查看实例状态（等待"running"）
aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --region YOUR-REGION \
  --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress]' \
  --output table

当状态变为 running ，你将得到一个公网IP（如 34.228.123.45 ）。现在SSH连接：

# 假设密钥文件为 my-key-pair.pem，权限必须是600
chmod 600 my-key-pair.pem
ssh -i "my-key-pair.pem" ubuntu@34.228.123.45

登录后，一键安装Nginx并启动：

# 更新系统
sudo apt update && sudo apt upgrade -y

# 安装Nginx
sudo apt install nginx -y

# 启动并设置开机自启
sudo systemctl start nginx
sudo systemctl enable nginx

# 验证Nginx是否监听80端口
sudo ss -tuln | grep :80
# 应输出：tcp LISTEN 0 4096 *:80 *:*

此时，打开浏览器访问 http://34.228.123.45 ，你应该看到Nginx默认欢迎页。恭喜，你的第一个EC2服务已上线！

实操验证：如果页面打不开，请立即执行三步排查：

1. ping 34.228.123.45 —— 检查网络连通性；
2. telnet 34.228.123.45 80 —— 检查端口是否开放（若失败，99%是安全组没配对）；
3. curl -v http://localhost —— 检查Nginx是否真在运行（若失败，说明服务没起来）。

4.4 第四步：用CloudFormation实现一键部署（可选但强烈推荐）

上面的CLI命令虽然精准，但每次都要复制粘贴、替换ID，效率低。CloudFormation能把它变成一个可复用的模板。以下是一个精简版 ec2-webserver.yaml （23行）：

AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  KeyName:
    Type: AWS::EC2::KeyPair::KeyName
    Description: Name of an existing EC2 KeyPair to enable SSH access
  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small]
    Description: Web server instance type
Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags: [{Key: Name, Value: !Sub "${AWS::StackName}-vpc"}]
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      Tags: [{Key: Name, Value: !Sub "${AWS::StackName}-public-subnet"}]
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags: [{Key: Name, Value: !Sub "${AWS::StackName}-igw"}]
  # ...（路由表、安全组、EC2实例资源定义，此处省略，实际模板中需完整）
Outputs:
  WebServerURL:
    Description: URL of the deployed web server
    Value: !Sub "http://${WebServer.PublicIp}"

部署只需一条命令：

aws cloudformation create-stack \
  --stack-name my-web-server \
  --template-body file://ec2-webserver.yaml \
  --parameters ParameterKey=KeyName,ParameterValue=my-key-pair \
  --capabilities CAPABILITY_IAM \
  --region YOUR-REGION

为什么值得投入时间学CloudFormation？
因为它把“人肉操作”变成了“代码”。下次你想在 ap-northeast-1 （东京）部署同样环境，只需改 --region 参数，不用重新点一遍控制台。更重要的是，你可以把模板提交到Git，写上注释：“2024-06-15：修复安全组SSH规则未限定IP的漏洞”，团队协作、审计、回滚，全部变得简单。这是我见过最快从“EC2新手”蜕变为“云平台工程师”的路径。

5. 常见问题与排查技巧实录：那些凌晨三点让我抓狂的真实案例

5.1 问题速查表：5分钟定位90%的连接失败

实操心得：我曾经为一个客户排查“SSH连不上”问题，花了4小时。最后发现是客户把密钥对名称写错了（ my-key vs my-key-pair ），而AWS控制台错误提示是模糊的“Invalid key pair”。从此我养成了一个习惯：每次创建密钥对，都在本地用 ls -la ~/.ssh/ 确认文件名完全一致，再复制到 ssh -i 命令中。一个字符的差异，就是4小时的代价。

5.2 “实例启动失败”的三大元凶与根治法

EC2启动失败（Instance Status Check Failed）是高频痛点，根源往往不在EC2本身，而在底层依赖：

• 元凶1：EBS卷I/O性能不足
  现象：实例启动后立刻进入 stopped 状态，系统日志（System Log）显示 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) 。
  原因：根卷太小（<8GB），Ubuntu启动时需要解压initramfs，空间不足导致内核崩溃。
  根治法：创建实例时，根卷至少设20GB；若已创建，停机后修改卷大小，再启动。

• 元凶2：安全组规则冲突
  现象：实例状态为 running ，但无法SSH，也无法访问Web服务， system log 显示正常启动。
  原因：安全组同时绑定了两个规则集，其中一个禁止了所有入站。
  根治法：在EC2控制台，选中实例 → “Security”标签页 → 点击安全组名称 → 检查“Inbound rules”是否有多余规则。删除所有非必需规则，只留HTTP/HTTPS/SSH（按需）。

• 元凶3：AMI损坏或区域不匹配
  现象：实例卡在 initializing 状态超过10分钟， system log 为空白。
  原因：你选的AMI在当前区域不可用（如在 us-west-2 用了只存在于 us-east-1 的自定义AMI）。
  根治法：在AMI选择页，右上角切换区域，确认AMI状态为“Available”；或直接选用AWS官方AMI（如 ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-* ）。

5.3 账单失控预警：如何一眼识破“幽灵实例”

最可怕的不是费用高，而是你根本不知道钱花在哪。我帮一个创业公司做账单审计，发现他们每月多付$217，只因一个被遗忘的 t2.micro 实例——它被标记为 test-db ，但没人记得它，也没人关机。

识别“幽灵实例”的三招：

1. 用Cost Explorer按“Service”筛选 ：进入AWS Cost Explorer → 选择“EC2-Other”服务 → 查看明细。 EC2-Other 包含EBS、快照、弹性IP等费用，如果这里金额异常高，说明有资源没清理。

2. 用Resource Groups Tag Editor批量扫描 ：进入Tag Editor → 选择所有区域 → 资源类型选 EC2:Instance → 搜索 Name 标签为空的实例。所有没命名的实例，都是高危对象。

3. 写个5行脚本，每天邮件提醒 ：

   #!/bin/bash
   aws ec2 describe-instances \
     --filters "Name=instance-state-name,Values=running" \
     --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,LaunchTime,Tags[?Key==`Name`].Value|[0]]' \
     --output table > /tmp/ec2-running.txt
   mail -s "EC2 Running Instances Report" admin@yourcompany.com < /tmp/ec2-running.txt
   

   把它加入crontab，每天早上8点发送。你会发现，很多“运行中”的实例，名字是 i-0a1b2c3d4e5f67890 ——这就是典型的幽灵实例。

我的个人体会是：AWS的免费套餐像一把双刃剑。它降低了入门门槛，但也掩盖了资源管理的严肃性。真正成熟的云用户，不是“会创建EC2”，而是“能随时说出每一台EC2的Owner、Purpose、TTL（生存时间）”。我在团队推行一个简单制度：所有EC2必须打上三个标签—— Owner （邮箱）、 Project （项目名）、 TTL （如 2024-12-31 ）。超过TTL自动告警，再超7天自动关机。这套机制运行两年，账单浪费下降了63%。技术可以学，但工程意识，得靠制度来培养。