AWS实战指南：从核心服务选型到CLI部署与事件驱动架构

简介：这是一份《云计算》第三版配套课件《Amazon云计算AWS介绍》PPT，面向高校师生、云计算初学者及方案架构师，系统梳理AWS核心服务与典型应用场景。资源共1个pptx，容量2.85MB，内容覆盖基础存储架构Dynamo、弹性计算云EC2、对象存储S3、非关系数据库SimpleDB与DynamoDB、关系数据库RDS、消息队列SQS、内容推送CloudFront等，并对Elastic Beanstalk、Router 53、VPC及其他AWS扩展服务展开介绍。已有454人下载学习，适合作为课堂讲授、课前预习或方案入门参考。课件以40页结构化篇幅呈现，章节清晰，每项服务均配有特点与功能分析，便于快速建立AWS全局认知，可作为备考或方案选型前的速查资料。

1. 为什么一张 PPT 讲不清 AWS：你需要的不是服务列表，是决策框架

很多团队接触 AWS 的方式，是从同事手里接过来一份名为“Amazon云计算AWS介绍.pptx”的分享材料。那份 PPT 通常画满了图标：EC2、S3、RDS、Lambda、VPC，每一页都在讲“这是什么”，但真正上手时你发现，最难的不是记住这些缩写，而是在一套云基础设施机制里选型：同一份业务，到底该把状态放在 EC2 的 EBS 上，还是放进 S3 再让 Lambda 去消费？为什么别人能用一套 CloudFormation 模板拉起全部环境，而你还在控制台里一个个点按钮？

这篇文章不复制 PPT 的目录结构。我会按一线工程师交付 AWS 方案的顺序来讲：先建立服务地图与选型逻辑，再用 CLI 跑通一台 EC2 的最小闭环，接着做一次 S3 与 Lambda 的事件驱动集成，最后把账单、权限和最常见的故障排查手段收进同一个章节。目标是让你读完以后，能不看控制台，用自己的终端把一条典型业务链路搭起来，并且知道每个参数写下去之后会发生什么。

2. AWS 核心服务地图：计算、存储、网络先分清边界，再谈“云覆盖度”

2.1 三大类服务是云基础设施机制的基本构件块

云基础设施机制是云环境的基础构件块，这句话听起来抽象，落到 AWS 上其实就是三类东西：计算资源、存储资源、网络资源。所有上层服务——数据库、消息队列、数据分析——都跑在这三者之上，只是用不同的方式封装了它们。理解 AWS 的第一步，不是背服务列表，而是给每个服务贴上“计算 / 存储 / 网络”的标签，并且知道它解决了什么问题。

2.1.1 计算：EC2、Lambda 与 ECS 的边界在“状态”和“时长”

EC2 是最经典的云服务器，它的核心特征是：有状态、可登录、时长不限。你可以在上面装任何东西，内核参数、文件系统、监控代理，全部由你控制。代价是你要负责补丁、容量、可用区分布。Lambda 是反过来的极端：无状态、短时运行、不需要登录，你只提供代码和触发条件，剩下的并发、伸缩、补丁都由 AWS 处理。ECS/Fargate 则处于中间，它给你一个容器运行环境，不给你完整虚拟机。

选型的一个实用判断标准是：如果你的进程需要常驻、需要监听端口、需要持久化本地磁盘，优先 EC2；如果是事件驱动的短任务，比如图片缩略、消息转发、定时清理，优先 Lambda；如果已经有 Docker 镜像，想要 K8s 但又不想维护控制平面，用 EKS 或 Fargate。这条边界在很多真实项目里会被打破：有人用 Lambda 跑一个 15 分钟的长任务，最后因为超时被迫改回 EC2；也有人用 EC2 只跑一个 cron 脚本，结果每月为闲置付费。

2.1.2 存储：EBS、S3、EFS 的差异在访问方式和一致性

存储选型比计算更容易出错。EBS 是块存储，挂载在 EC2 上，表现成一个虚拟磁盘，支持随机读写，适合数据库、文件系统。S3 是对象存储，通过 HTTP API 访问，支持海量数据，存储成本低，但它的读写模型是“整个对象”，不适合做数据库的数据文件直接放上面随机读写。EFS 是共享文件存储，多个 EC2 可以同时挂载同一个文件系统，适合做内容管理、共享目录。

很多人犯的错误是拿 S3 当硬盘用，直接在代码里 open(“s3://bucket/file”) 然后按行读，结果每次访问都有几百毫秒延迟，还产生大量 API 调用费。正确姿势是：需要低延迟随机读写的场景，本地盘或 EBS；需要跨机器共享、不关心最终一致性的静态文件，S3；需要 NFS 风格共享且延迟敏感，EFS。S3 的最终一致性已经改善，但“覆盖写后立刻读”仍然不保证新版本，这个点放在后面的实战里会再验证。

2.1.3 网络：VPC、子网、安全组决定谁能碰到你的资源

网络层是 AWS 里最容易产生安全风险的地方。VPC 是你的私有网络空间，子网划分可用区，安全组相当于实例级别的防火墙。要点是：安全组默认拒绝所有入站，你需要显式放行端口；出站默认全放通；安全组是有状态的，回程流量自动允许。哪张 PPT 都没讲清楚的暗坑是，ECS 任务和 RDS 连接失败，绝大多数时候不是密码错了，而是安全组规则没放行，或者子网路由表指向了错误的 NAT 网关。

2.2 AWS 服务选型速查表

2.3 先做最小闭环：租户隔离靠 IAM，别靠“建多个账号”

云覆盖度计算这个概念在架构评估里经常出现，说的是你的业务在云上覆盖了哪些能力模块。但比覆盖度更重要的，是账号和权限的隔离。常见做法是：用 AWS Organizations 建多个账号（开发、测试、生产），每个账号内部再用 IAM 角色和策略控制访问。你不应该让团队成员共享一组根用户的 Access Key，也不要为了省事把所有资源放进同一个默认 VPC 里。权限边界用 IAM 策略声明，而不是靠谁记得住密码。

3. 用 AWS CLI 在本地跑通 EC2 最小命令链

3.1 安装与认证：CLI 不是控制台的平替，而是可脚本化的大门

AWS CLI 是操作 AWS 的最后一条捷径。控制台适合探索，但你要做自动化、重复操作、批处理，CLI 是唯一可持续的方式。安装流程很简单，在 macOS 上用brew install awscli，在 Linux 上用官方脚本，Windows 走 MSI 包。装完后最重要的命令不是ec2 describe-instances，而是先确认身份：

aws sts get-caller-identity

这条命令返回你的账号 ID、ARN 和用户类型。如果这里报错，后面所有命令都没有意义。常见错误是本地环境变量里同时存在AWS_ACCESS_KEY_ID和AWS_PROFILE，CLI 默认优先使用前者的优先级，行为可能和你预期不符。

3.1.1 配置命名 Profile，避免把生产 Key 暴露在全局

我一般会为每个环境单独建 profile：

aws configure --profile dev

执行后会交互式要求输入 Access Key ID、Secret Access Key、Region 和输出格式。这里有个细节：region建议固定写成ap-northeast-1或us-east-1，不要用cn-north-1等你没有权限的区域，否则后续创建资源会报UnauthorizedOperation。输出格式建议用json，方便后面配合jq解析。

3.2 创建最小 EC2 实例：十行命令完成从 Key Pair 到 SSH 登录

这里给出一条可以直接执行的链路。前提是你已经有一个默认 VPC，或者自己创建了 VPC。为了演示简洁，我用--query提取输出，减少手工查控制台的时间。

# 1. 创建 Key Pair aws ec2 create-key-pair --key-name dev-key --query 'KeyMaterial' --output text > dev-key.pem chmod 400 dev-key.pem # 2. 查询最新的 Amazon Linux 2023 AMI ID aws ec2 describe-images \ --owners amazon \ --filters "Name=name,Values=al2023-ami-2023.*-x86_64" "Name=state,Values=available" \ --query 'sort_by(Images, &CreationDate)[:-1].ImageId' \ --output text # 3. 获取默认 VPC 与子网 aws ec2 describe-vpcs --filters "Name=isDefault,Values=true" --query 'Vpcs[0].VpcId' --output text aws ec2 describe-subnets --filters "Name=vpc-id,Values=<VPC_ID>" --max-items 1 --query 'Subnets[0].SubnetId' --output text # 4. 创建安全组并放行 22 端口 aws ec2 create-security-group --group-name dev-sg --description "dev sg" --vpc-id <VPC_ID> --query 'GroupId' --output text aws ec2 authorize-security-group-ingress \ --group-id <SG_ID> \ --protocol tcp --port 22 --cidr 203.0.113.0/32 # 5. 运行实例 aws ec2 run-instances \ --image-id <AMI_ID> \ --instance-type t3.micro \ --key-name dev-key \ --security-group-ids <SG_ID> \ --subnet-id <SUBNET_ID> \ --associate-public-ip-address \ --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=dev-demo}]' \ --query 'Instances[0].InstanceId' \ --output text

3.2.1 每个参数背后的选择逻辑

命令本身不难，难在参数理解。--owners amazon限定只找官方 AMI，避免误用第三方镜像。sort_by(Images, &CreationDate)[:-1]取最新镜像，是 CLI 里常用的 JMESPath 技巧。--filters的Name=state,Values=available排除了 deprecated 的镜像。

安全组只放行了一个 IP，也就是你当前的办公 IP，不要写成0.0.0.0/0。--associate-public-ip-address依赖子网的MapPublicIpOnLaunch属性，如果你在非默认子网里没开这个选项，实例不会拿到公网 IP。t3.micro是免费套餐常用规格，但如果你的账号是老账号且没有免费额度，它会按小时计费，跑完 demo 记得终止实例。

3.3 SSH 登录时最容易忽略的坑：时区、默认用户名和本地端口

启动实例后拿到公网 IP，直接用ssh -i dev-key.pem ec2-user@<IP>登录。注意两点：一是 Amazon Linux 的默认用户是ec2-user，Ubuntu 是ubuntu，用错用户名会报Permission denied；二是dev-key.pem的权限必须是400，否则 SSH 会拒绝识别。如果登录超时，优先查安全组放行的 CIDR 是否是当前网络出口 IP——用 curl 访问https://checkip.amazonaws.com可以查到，不要凭记忆填一个地址。

4. S3 与 Lambda 事件驱动：从对象上传到日志处理的完整链路

4.1 为什么事件驱动是 S3 最实用的进阶用法

S3 不止是个网盘。它的真正价值在于和 Lambda 结合成事件驱动架构：当对象被创建、删除、或者通过 S3 生命周期规则转入低频访问层时，可以触发一个 Lambda 函数。典型场景是日志处理：应用把日志写成 JSON 文件丢进 S3，Lambda 被触发后解析文件、过滤敏感字段、写入另一个存储桶供分析。整个过程无需常驻服务器，S3 和 Lambda 按调用次数计费，空闲时成本几乎为零。

但事件驱动有个隐含的“云基础设施机制”约束：S3 事件通知和 Lambda 是同一区域的服务，跨区域触发需要额外配置。另外，S3 与 Lambda 之间的触发是异步的，延迟通常在毫秒到秒级，不适合需要同步响应的场景。

4.2 用 Python 写一个实时文件解析 Lambda

下面这个例子：桶input-bucket放入一个 CSV 文件，Lambda 读取它，把内容转成 JSON 写入output-bucket。先创建 Lambda 函数需要的 IAM 角色和策略，再部署代码，最后配置 S3 事件通知。

import boto3 import csv import json import os s3 = boto3.client('s3') def lambda_handler(event, context): # 从 S3 事件中提取桶名和对象键 bucket = event['Records'][0]['s3']['bucket']['name'] key = event['Records'][0]['s3']['object']['key'] # 防止递归触发：输出对象的键名带 processed/ 前缀 if key.startswith('processed/'): print(f"skip already processed: {key}") return # 读取源对象 resp = s3.get_object(Bucket=bucket, Key=key) body = resp['Body'].read().decode('utf-8') # CSV → list[dict] rows = list(csv.DictReader(body.splitlines())) print(f"parsed {len(rows)} records from {key}") # 写入输出桶 output_bucket = os.environ['OUTPUT_BUCKET'] out_key = 'processed/' + key.split('/')[-1] + '.json' s3.put_object( Bucket=output_bucket, Key=out_key, Body=json.dumps(rows, indent=2), ContentType='application/json' ) return {'status': 'ok', 'records': len(rows)}

4.2.1 代码逻辑与关键参数

event里嵌套了多层字典，需要逐层取Records[0].s3。key可能是带路径的文件名，所以输出键名用processed/前缀拼上文件名，这样写回同一个桶也不会再次触发同一个函数——因为 Lambda 只监听了不带processed/前缀的事件。这里有个容易漏掉的点：S3 对象名是 UTF-8 编码的，但 AWS CLI 的--key传中文名时可能被本地 shell 转义，建议在代码里统一key = event['Records'][0]['s3']['object']['key']，不要用硬编码字符串解析。

环境变量OUTPUT_BUCKET在 Lambda 控制台或者 CloudFormation 里配置，代码里用os.environ读取，避免把桶名写死在代码里便于复用。

4.3 配置 S3 事件通知的两种方式

方式一，控制台在 S3 桶的属性页添加事件通知。方式二，用 CLI 配合 JSON 配置更灵活：

aws s3api put-bucket-notification-configuration \ --bucket input-bucket \ --notification-configuration file://notification.json

notification.json内容如下：

{ "LambdaFunctionConfigurations": [ { "Id": "csv-to-json-processor", "LambdaFunctionArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:csv-to-json", "Events": ["s3:ObjectCreated:*"], "Filter": { "Key": { "FilterRules": [ {"Name": "suffix", "Value": ".csv"} ] } } } ] }

LambdaFunctionArn里的账号 ID 和区域必须和你的函数真实信息一致。设置完成后，上传一个测试文件触发：

aws s3 cp test.csv s3://input-bucket/ aws logs tail /aws/lambda/csv-to-json --follow

4.3.1 观察 CloudWatch Logs 输出

aws logs tail是查看 Lambda 实时日志最快的方式。如果没有输出，先检查是否有网络访问问题——Lambda 默认在 VPC 外，不需要 NAT；但如果函数挂在 VPC 内网，就必须有 NAT 网关或者 VPC 端点才能访问 S3。这个坑在混合架构里特别常见：函数加了--vpc-config后，s3.get_object执行超时，因为 Lambda 没有出网路径。解决办法是给 Lambda 所在的子网配置 NAT 网关，或者使用 S3 VPC 端点。

5. 权限、账单与排错：一套可复用的 AWS 运维检查清单

5.1 IAM 策略最小化的三种写法

IAM 策略是 AWS 权限体系的唯一真相。常见的错误是给开发者AdministratorAccess，导致一删一改就影响生产。最小化权限不必从零写 JSON，可以用 AWS 托管的策略组合，比如AmazonS3ReadOnlyAccess加AmazonEC2ReadOnlyAccess。但更精细的可以这样写：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::prod-logs", "arn:aws:s3:::prod-logs/*" ] } ] }

注意ListBucket作用在桶 ARN 上，GetObject作用在对象 ARN 上。如果你把GetObject写成桶 ARN，权限会不生效，CLI 报AccessDenied但控制台看不到问题。

5.2 账单异常排查：从 Cost Explorer 到资源标签

账单问题最容易失控的是“忘了关资源”。EC2 跑了一个月、EBS 卷删了实例但没删卷、弹性 IP 绑在已终止的实例上，这些都会产生费用。排查顺序按以下命令走：

# 列出所有区域的所有实例 aws ec2 describe-instances --region ap-northeast-1 \ --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name}' \ --output table # 查看所有未挂载的 EBS 卷 aws ec2 describe-volumes --filters "Name=status,Values=available" \ --query 'Volumes[].VoluumeId' --output text # 列出所有弹性 IP aws ec2 describe-addresses --query 'Addresses[].AllocationId' --output text

5.2.1 用 Cost Explorer 按标签聚合

如果资源太多，靠describe-*命令排查效率低。建议从第一天就给资源打标签：Env=production、Owner=data-eng。然后在 Cost Explorer 里按标签分组，观察哪个 Owner 的账单占比异常。AWS 的账单数据最终一致，延迟约 24 小时，所以不要因刚看到昨天的数据就焦虑。真正要警惕的是“跨区域资源”的账单：比如你在东京区域建了 EC2，却误在弗吉尼亚创建了 S3 桶，下载流量费会显示在另一个区域。

5.3 三招快速定位 AWS 故障

第一招：确认是否是你账号的问题。如果服务控制台整体异常，可以查看 AWS 服务健康仪表盘，但注意区分“区域故障”和“你的安全组错误”。历史上 AWS 曾发生区域级别的服务故障，影响大量客户，这种时候你只需要等官方恢复公告，不必反复重启自己的实例。

第二招：用aws sts get-caller-identity验证身份，用aws ec2 describe-instance-status查看实例状态。如果实例显示running但 SSH 连不上，按这个顺序查：安全组入站规则、网络 ACL、路由表、操作系统防火墙。网络 ACL 是子网级别的，安全组是实例级别的，两者都放行才通。用aws ec2 describe-network-acls查看关联的子网。

第三招：对于 Lambda 超时问题，用 X-Ray 追踪或aws logs tail看日志里是否出现Task timed out after 3.00 seconds。默认超时是 3 秒，很多需要在函数里调用外部 API 的场景会撞上这个上限，把超时改成 30 秒前先确认你的函数确实能在 30 秒内跑完。改超时只是一个保护窗口，不是优化方案。

5.4 一个值得长期保留的阿里云与 AWS 对照检查习惯

如果你同时使用过国内云平台和 AWS，会发现两者的服务命名和操作习惯差别很大。AWS 的命令行风格更接近aws ec2 describe-* + --query的统一范式，而国内平台一些工具更依赖控制台。我习惯在做跨云迁移时，先为两边各列一张服务映射表，并把 IAM 策略与 RAM 策略的差异单独标注。AWS 的 IAM 是全局的，但策略里填 ARN 时要写清楚区域和账号 ID，否则策略跨区域复用会报格式错误。

5.5 最后一件小事：清理演示资源

跑完 EC2 demo 和 Lambda 触发链路后，不要直接关掉电脑。下面这组命令帮你删除本次创建的资源，避免产生隔夜账单：

# 终止 EC2 实例 aws ec2 terminate-instances --instance-ids <INSTANCE_ID> # 删除安全组（如果还关联着实例会失败） aws ec2 delete-security-group --group-id <SG_ID> --region ap-northeast-1 # 删除 S3 桶（先清空对象） aws s3 rm s3://input-bucket --recursive aws s3 rb s3://input-bucket --force

terminate-instances后实例状态变成terminated，但 EBS 卷默认会保留，如果不需要请到卷列表里单独释放。删除 S3 桶前建议先看桶里有什么，--force会直接清空，对于生产桶不要执行这个命令。清理完成后，用aws ce get-cost-and-usage --time-period Start=2026-01-01,End=2026-01-31 --granularity MONTHLY确认当月账单没有异常上涨。如果还想再验证一遍权限配置，重新跑一次aws sts get-caller-identity，确认当前身份已经不再拥有刚才的密钥——这比盯着控制台放心得多。

本文还有配套的精品资源，点击获取