AWS核心服务拆解：存储、计算、消息队列与架构选型实战

简介：这是《云计算》第三版配套课件中讲解Amazon云计算AWS的完整章节，适合云计算初学者、高校学生及需要系统了解AWS服务体系的IT从业者学习。资源包内共1个pptx演示文稿文件，大小2.85MB，内容完整覆盖第3章全部小节。目前已有454人浏览学习。课件从基础存储架构Dynamo讲起，围绕每项服务的特点、功能与应用场景，详细介绍了EC2弹性计算云、S3简单存储服务、SimpleDB与DynamoDB非关系数据库、RDS关系数据库、SQS简单队列服务以及CloudFront内容推送服务等核心模块，并进一步拓展到Elastic Beanstalk快速部署、Route 53 DNS服务、VPC虚拟私有云、Redshift数据仓库、AppStream应用流等AWS扩展服务，最后还安排了AWS应用实例和章节小结。整体结构清晰，重点突出，既能用作课堂教学PPT，也适合自学者按模块查阅，快速搭建AWS知识框架。

1. 从《云计算》PPT 到生产环境：AWS 服务拆解的正确起点

这份 PPT 是《云计算》第三版配套课件里讲 AWS 的一章，适合做内部培训底稿，也适合拿来重新梳理 AWS 的服务边界。课件从 Dynamo 讲起，一路覆盖 EC2、S3、RDS、SQS，最后用一整节列了 Elastic Beanstalk、VPC、Route 53（课件原文写的是 Router 53）、EMR、Redshift、Kinesis 这些产品。真正动手做过云上架构的人再看这份材料，会发现它没有停留在罗列服务，而是在解释几个关键设计决策：Dynamo 为什么牺牲强一致性换可用性、EC2 为什么按实例类型计费、S3 怎么支撑百亿级对象。课件把这些服务当成“云基础设施机制”的构件块来讲，构件块怎么组合、边界怎么划分，才是云架构真正要练的基本功。把这套内容拆开，对应到现代云环境里的实际选型，就是下面这几章要展开的。

2. Dynamo、EC2、S3：三大基础服务的实现逻辑与实操

2.1 Dynamo：一致性哈希与宽松仲裁的存储原型

Dynamo 不是教材里的抽象概念，它是 Amazon 电商内部使用的分布式键值存储，SOSP 2007 那篇论文把设计公开了。课件强调高可用和高性能，落到具体机制是四个关键点：一致性哈希做数据分布，向量时钟解决并发写冲突，宽松仲裁（Sloppy Quorum）保证部分节点故障时仍能读写，Hinted Handoff 把临时写不进去的数据转交给其他节点，等目标节点恢复后再补交。节点之间还会用 Merkle 树做反熵比对，让长期运行后可能出现的副本分歧逐步收敛。这套组合的核心是把“可用性优先”实现到协议层，而不是靠运维兜底。

如果只看教材，容易把 Dynamo 当成一个数据库产品。实际上 AWS 对外提供的是 DynamoDB，Dynamo 引擎支撑购物车、会话这类高并发内部场景。两者的关系可以理解为：Dynamo 是一套分布式技术范式，DynamoDB 是把它做成 SLA 明确的托管服务。选型时先要分清这一点，否则会拿对 KV 存储一致性的预期去套 Dynamo，得出错误结论。

2.2 EC2 实例选型：从实例家族看计算资源的边界条件

EC2 选型的核心是实例家族。课件写作时主流还是 m1、m3 序列，今天已经换成了通用型 t3/m7i、计算优化型 c7i、内存优化型 r7i、存储优化型 i3/i4i、GPU 实例 p4/p5 等，命名逻辑没变，只是代际在迭代。选型顺序我一般固定为：先定业务类型，再选家族，最后谈规格。一个 Redis 集群节点优先考虑 r 系列；一个 Go 写的网关服务，c 系列性价比更高；开发测试环境用 t 系列突发性能模型，能省不少钱。

EC2 只提供虚拟 CPU 和内存配额，块存储走 EBS 独立计费。压测发现性能不达标时，先看 EBS 的 IOPS 配额是否打满，而不是盲目换更大规格的实例。创建实例的常用命令如下，密钥对和安全组要提前准备好：

# 创建通用型实例，根卷用 gp3，30GB 起步 aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type t3.micro \ --key-name my-keypair \ --security-group-ids sg-0123456789abcdef0 \ --subnet-id subnet-0123456789abcdef0 \ --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \ --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-node-01}]'

--image-id对应 AMI，即实例的操作系统模板；--instance-type决定 vCPU 与内存配比；--block-device-mappings指定根卷类型，gp3 是性价比最高的通用 SSD，按需扩容量比换实例便宜得多。批量创建时把 tag 打全，后续按标签做成本分摊会省很多事。

2.3 S3 对象存储：CLI 操作与一致性模型的演进

S3 是对象存储，核心抽象是存储桶（bucket）、对象（object）和前缀（prefix）。logs/2024/01/app.log这种路径只是对象键的一部分，并没有真正目录层级，这种扁平设计让 S3 能横向扩展到百亿对象，同时也决定了它不适合做随机写、追加写。课件说 S3 能自动检测故障，指的是数据和校验信息分散在多个可用区，单盘故障对外无感。

S3 的一致性模型值得单独讲。很多老资料写 S3 是“最终一致性”，但 AWS 在 2020 年 12 月已经把包括 LIST 在内的所有 S3 操作升级为强一致性。如果旧代码还在按最终一致性做“写完立刻读列表”的补偿逻辑，现在可以简化。对象版本控制、生命周期、静态网站托管、事件通知是 S3 最常用的四个附加能力，日常操作集中在下面几条命令上：

# 建桶并上传构建产物，排除 sourcemap aws s3 mb s3://my-app-assets --region ap-northeast-1 aws s3 cp ./dist s3://my-app-assets/static/ --recursive --exclude "*.map" # 增量同步日志目录，使用低频存储降低费用 aws s3 sync ./logs s3://my-app-assets/logs/ --storage-class STANDARD_IA # 查看 bucket 占用总量并删除指定对象 aws s3 ls s3://my-app-assets/static/ --human-readable --summarize aws s3 rm s3://my-app-assets/static/old-version.js

aws s3 sync按文件名和修改时间增量传输，适合构建产物发布；--storage-class STANDARD_IA把不常访问的数据降到低频存储，成本大约省一半；--human-readable --summarize在查询 bucket 总量时直接给出可读结果。需要提醒的是，cp --recursive不带--exclude时会把 sourcemap 这类调试文件也传到公网可读的桶里，发布前用aws s3 ls检查对象列表，比出事后再刷权限更省心。

3. SimpleDB、DynamoDB、RDS、SQS：数据链路的选型与排错

3.1 SimpleDB 为何被 DynamoDB 取代：从多属性索引到按量扩展

SimpleDB 是 AWS 最早的 NoSQL 服务，支持在多个属性上建索引，写起来像轻量级文档库。它的单域上限是 10GB，查询能力受固定分区限制，业务量一涨就撞墙。DynamoDB 推出后，SimpleDB 逐步退出主线，今天生产环境几乎不会再用。这个演进带来的教训很明确：无服务器数据库的扩展性取决于分片策略，分片策略一旦定死，后期修改只能做数据迁移。SimpleDB 适合课程设计和小规模验证，不适合作为业务主存储。

DynamoDB 的数据模型是分区键加可选排序键，分区键决定数据分散到哪个分区，排序键决定同一分区内如何排序。建表时就要想清楚访问模式，否则只能靠 GSI（全局二级索引）兜底。它的优势是单表扛住每秒几百万次请求，吞吐按读写容量单位计费，另有按量计费模式适合负载不确定的场景。需要注意 DynamoDB 不支持跨表 JOIN 和真正意义上的聚合查询，统计逻辑得自己维护计数表或走流式处理。

3.2 DynamoDB 的读写容量单位怎么算才不浪费

容量单位计算是新手最容易算错的地方。1 个 RCU 对应最终一致性读 4KB、强一致性读 1KB，1 个 WCU 对应 1KB 写入。一个平均 2KB 的 item，每秒 100 次强一致读就需要 200 RCU；每秒 10 次 2KB 写则需要 20 WCU。按量模式下系统自动伸缩，但突发读流量会被限流，表现为ProvisionedThroughputExceededException，处理方式要么指数退避重试，要么把读改成最终一致性。生产上比较稳的做法是先按峰值的两倍预留容量，再根据 CloudWatch 的ConsumedReadCapacityUnits指标逐步下调。

建表和写入可以直接用 CLI 验证：

# 创建订单事件表：order_id 为分区键，event_time 为排序键 aws dynamodb create-table \ --table-name order_events \ --attribute-definitions AttributeName=order_id,AttributeType=S AttributeName=event_time,AttributeType=S \ --key-schema AttributeName=order_id,KeyType=HASH AttributeName=event_time,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST # 写入一条订单事件，并返回消耗的容量单位 aws dynamodb put-item \ --table-name order_events \ --item '{"order_id":{"S":"20240101-0001"},"event_time":{"S":"2024-01-01T10:00:00Z"},"status":{"S":"PAID"}}' \ --return-consumed-capacity TOTAL

HASH键即分区键，RANGE键即排序键，两者共同构成唯一主键。PAY_PER_REQUEST是按量计费，适合开发阶段；流量稳定后切到预置模式通常更省。--return-consumed-capacity TOTAL可以精确看到一次操作消耗多少容量单位，做成本评估时这个数值比预算报表更直接。

3.3 RDS 与 SQS：关系库高可用和消息可见性超时的误区

RDS 解决的是关系库上云问题，内核仍然是 MySQL、PostgreSQL、SQL Server 等引擎，只是把主备切换、快照、补丁升级变成托管能力。课件里列出了 Oracle，实际上 Aurora 出现后，RDS 里跑自研引擎的比例越来越高。使用 RDS 最容易混淆的是多可用区部署和只读副本：多可用区是主备同步，备库不提供读流量；只读副本是独立实例，分担读压力但不能自动切换。同时需要高可用和读写分离时，两者要一起配，不是只建一个副本。

创建实例的关键参数如下，存储自动扩容和备份保留期直接决定后续运维成本：

# 创建 PostgreSQL 实例，开启多可用区和存储自动扩容 aws rds create-db-instance \ --db-instance-identifier my-app-db \ --db-instance-class db.t3.medium \ --engine postgres \ --allocated-storage 100 \ --max-allocated-storage 500 \ --backup-retention-period 7 \ --multi-az \ --db-subnet-group-name my-db-subnet-group

--multi-az开启自动主备切换，故障时请求会被切到新主库；--max-allocated-storage是存储自动扩展上限，不设置会在磁盘满时直接报错。SQS 的可见性超时是另一个高频误区。消息被消费者取走后不会立刻删除，而是在VisibilityTimeout内对其他消费者不可见；处理成功要显式 delete，失败则让消息超时后重回队列。超时太短，慢消费者处理到一半消息被另一个消费者拿走，造成重复消费；太长，消费者宕机后消息要等很久才能再次被处理。经验值是设成平均处理时长的 6 倍，再配一个死信队列接住反复失败的消息。

四个服务的选型可以收成一张对照表：

4. 自动化编排与网络边界：Beanstalk、CloudFormation、VPC、Route 53 及周边服务

4.1 快速部署的两种路径：Elastic Beanstalk 与 CloudFormation

Elastic Beanstalk 解决的是“从代码到可用服务”的距离问题。课件写作时只支持 Java，现在 PHP、Python、Node.js、Go、Docker 都能部署。它隐藏了实例创建、负载均衡、健康检查、自动缩放这些细节，提交代码后环境会自动拉起。它默认给应用创建一个弹性伸缩组加负载均衡器，实例挂了自动替换，适合标准 Web 应用，不适合自定义网络拓扑或需要精细控制调度器的场景。

CloudFormation 则更进一层，把基础设施本身写成模板，纳入版本控制。它和 Beanstalk 不是替代关系，而是互补：Beanstalk 管应用层，CloudFormation 管整套环境。下面这个模板创建了一个最小可用的 EC2 实例和安全组，NameTag参数在创建堆栈时动态传入。

AWSTemplateFormatVersion: "2010-09-09" Parameters: NameTag: Type: String Default: web-node Resources: WebSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow HTTP access SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 0.0.0.0/0 WebInstance: Type: AWS::EC2::Instance Properties: InstanceType: t3.micro ImageId: ami-0abcdef1234567890 SecurityGroupIds: - !Ref WebSecurityGroup Tags: - Key: Name Value: !Ref NameTag

!Ref是模板内部引用，把安全组资源 ID 注入实例配置，避免硬编码。这类模板的价值在于可评审、可回滚，删除堆栈时关联资源按声明顺序清理，不会留僵尸资源。实际项目中我习惯把网络、数据库、应用拆成三个堆栈分阶段创建，避免一个模板里几百个资源出错后无从查起。

4.2 VPC 与 Route 53：虚拟网络与 DNS 的联动

课件里的虚拟私有云 VPC 今天已经是 AWS 网络的基本盘。VPC 用 CIDR 划出一段私有网段，再切分子网，通过路由表决定流量走向。创建 VPC 后必须显式创建 Internet Gateway 并加入路由表，子网里的实例才能访问外网。很多新人建实例后发现不通外网，第一反应是查安全组，实际上先查路由表效率更高，NAT 网关或 IGW 缺少路由是最常见的问题。

教材里的 Router 53 正式服务名是 Route 53，取自 DNS 端口号 53。它不只是域名解析，还承担健康检查和故障转移。REST API 允许创建托管区域，在区里维护 A、AAAA、CNAME、TXT、MX 记录。VPC 和 Route 53 联动时，私网 DNS 解析最容易出错：VPC 默认自带 DNS 解析，但自定义域名要创建 Resolver 规则或直接把记录指向 RDS 内网地址。新增记录用 CLI 批量操作：

# UPSERT 表示记录不存在则创建，存在则覆盖，适合重复执行 aws route53 change-resource-record-sets \ --hosted-zone-id Z0123456789ABCDEF \ --change-batch '{ "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "db.internal.example.com", "Type": "CNAME", "TTL": 300, "ResourceRecords": [{"Value": "my-app-db.c9abc123.us-east-1.rds.amazonaws.com"}] } } ] }'

UPSERT动作保证部署脚本可以重复执行而不报错。TTL 设 300 秒是折中：调试期改记录能较快生效，线上稳定后可降到 60 或提高到 600。配合健康检查可以把 DNS 指向健康后端，但前提是应用能区分存活探针和就绪探针，否则流量打到还没加载完配置的实例上，用户看到的就是 502。

周边服务里还有一批和网络、消息、数据相关的产品，按定位可以分成几类：

4.3 大数据与分析服务：EMR、Redshift、Kinesis、AppStream 的分工

EMR 是跑在 EC2 和 S3 之上的 Hadoop 生态服务平台，Spark、Hive、Presto 都可以直接用。课件说的“上传数据到 S3，启动集群，下载结果”流程没变，变的是集群编排方式。EMR 集群分为长期集群和临时集群，临时集群跑完即销毁，只在运行期付费。主节点和从节点分属不同安全组的设计沿用至今。需要特别强调的是，EMR 的存储层在 S3，计算层在临时 EC2，数据不落本地盘，删集群不会删数据，这和 Redshift 正好相反。

Redshift 是列式存储的数据仓库，数据按列压缩存放，适合大范围聚合查询，不适合单行高频写入。它由领导节点和计算节点组成，查询分发到计算节点并行执行。把 Redshift 当数据库用并不合适，更合理的姿势是从 RDS 或 S3 批量导入，支撑 BI 报表。Kinesis 做实时流接入，日志、点击流先进入 Kinesis Data Streams，再由 Lambda 或 Kinesis Data Analytics 做窗口计算，结果落到 S3 或 Redshift。AppStream 的应用流形态对应 AppStream 2.0，适合给远程用户提供渲染类应用，但成本普遍高于普通 EC2，用户量不大时往往不划算。

4.4 通知、邮件与电商时代的组件：SNS、SES、DevPay、FPS 与人工众包

SNS 是发布订阅消息服务，主题（Topic）是核心抽象，生产者把消息发到主题，订阅方可以是 HTTP 端点、邮件、SQS、Lambda。它和 SQS 的区别是推送模型与拉取模型的不同：SNS 主动推，SQS 消费者主动拉。两者经常组合使用，一个 SNS 主题挂多个 SQS 队列实现扇出。SES 是邮件发送服务，需要先验证域名或邮箱，配置 SPF 和 DKIM 记录，否则发信容易被判垃圾邮件。生产上常见的坑是退信率过高导致 SES 暂停发信，监控 bounce 和 complaint 率比监控发送量更重要。

DevPay、FPS 和 Simple Pay 这批服务有很强的电商时代痕迹。DevPay 允许开发者发布付费 AMI 和 S3 产品，AWS 负责计费和结算；FPS 是支付服务；Simple Pay 是简化支付按钮。它们在课程内容里有价值，因为揭示了 AWS 早期的商业模式：AWS 不只是卖计算资源，还尝试做软件分发和支付平台。今天的 AWS Marketplace 承接了类似角色，只是形态成熟得多。教材列表里最模糊的“Amazon 执行网络服务”，后来这类服务大多被并入更大的产品线，现在的产品目录里很少单独看到它的名字。土耳其机器人则是众包人力的 API，用 API 调用“人”完成任务，本质是把内容审核、数据标注这类机器不擅长的操作变成可编程接口，和 EMR 形成一个有趣对照：有的任务适合机器，有的任务只能交给人类。

5. S3 生命周期治理与 CloudFront 缓存失效：一个能直接落地的组合技巧

5.1 S3 生命周期规则：把存储成本压在三个月内

日志、备份这类数据的特点是访问频率随时间快速下降，但 S3 默认按标准存储计费，放着不管一年成本很难看。生命周期规则可以按前缀自动转移存储类，比如 30 天转低频、60 天转归档、90 天过期删除。下面这段配置同时清理未完成的分段上传，避免大文件上传中断后残留碎片一直占容量。

# 对 raw-logs 前缀应用生命周期：30天转低频，60天转归档，90天删除 aws s3api put-bucket-lifecycle-configuration \ --bucket my-app-assets \ --lifecycle-configuration '{ "Rules": [ { "Id": "log-archive", "Status": "Enabled", "Filter": {"Prefix": "raw-logs/"}, "Transitions": [ {"Days": 30, "StorageClass": "STANDARD_IA"}, {"Days": 60, "StorageClass": "GLACIER_INSTANT_RETRIEVAL"} ], "Expiration": {"Days": 90}, "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7} } ] }'

注意过期删除的 90 天从对象创建时间算起，转移和过期放在同一条规则里时时间点要合理。生命周期规则只对新对象生效，存量对象提交后通常在 24 到 48 小时内处理完毕。如果团队有人手动把归档存储类对象复制回标准存储，成本会回升，这类操作建议用 IAM 策略限制。

5.2 CloudFront 缓存失效：改源站不等于改 CDN

CloudFront 把静态资源缓存在边缘节点，TTL 内用户请求不会回源。线上最典型的故障是 S3 文件已更新，但用户看到的还是旧版本，因为边缘节点还缓存着旧对象且 TTL 未到。针对部分路径做失效处理可以立即回源：

# 按路径失效缓存，/* 是全量失效，/static/js/* 只清理 JS aws cloudfront create-invalidation \ --distribution-id E1A2B3C4D5E6F7 \ --paths "/static/js/*"

--paths接受路径列表，/*全量失效代价最大，按目录范围失效能降低成本。创建失效请求后需要等待几分钟让边缘节点同步。更省钱的替代方案是版本化发布：构建产物带上内容哈希，文件名变了自然绕过缓存，旧文件交给生命周期规则过期删除。只有全局路径配置、域名切换这类场景，create-invalidation才是首选。

5.3 用 curl 验证缓存命中，而不是盯浏览器

验证资源是否真的命中缓存，用 curl 看响应头最直接：

curl -I https://dxxxxxxxxxxx.cloudfront.net/static/app.js

重点看x-cache: Hit from cloudfront和age头。x-cache返回 Miss 表示回源拉取了对象，返回 Hit 表示边缘节点已有缓存；age表示对象已在边缘缓存了多久，结合 TTL 可以推断下次回源时间。把这两个字段加进发布脚本的断言里，比在浏览器里手动刷新可靠得多，尤其适合有多级缓存层的架构做排障。

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