简介这是《云计算》第三版配套课件中讲解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 对外提供的是 DynamoDBDynamo 引擎支撑购物车、会话这类高并发内部场景。两者的关系可以理解为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 系列突发性能模型能省不少钱。实例族适用负载备注通用型 t3/t4g/m7i中小型 Web、开发测试、微服务突发性能模型适合不持续高负载场景计算优化型 c7i批处理、音视频转码、高并发 APICPU 主频和核数优先内存优化型 r7i缓存、内存数据库、实时分析单实例内存可达 TB 级存储优化型 i3/i4i高随机 IO、NoSQL 数据节点本地 NVMe注意数据不持久GPU 实例 p4/p5模型训练、推理、图形渲染结合竞价实例能显著降本EC2 只提供虚拟 CPU 和内存配额块存储走 EBS 独立计费。压测发现性能不达标时先看 EBS 的 IOPS 配额是否打满而不是盲目换更大规格的实例。创建实例的常用命令如下密钥对和安全组要提前准备好# 创建通用型实例根卷用 gp330GB 起步 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 ResourceTypeinstance,Tags[{KeyName,Valueweb-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.jsaws 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、强一致性读 1KB1 个 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 AttributeNameorder_id,AttributeTypeS AttributeNameevent_time,AttributeTypeS \ --key-schema AttributeNameorder_id,KeyTypeHASH AttributeNameevent_time,KeyTypeRANGE \ --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 TOTALHASH键即分区键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 倍再配一个死信队列接住反复失败的消息。四个服务的选型可以收成一张对照表服务数据形态典型用途选型提醒SimpleDB多属性索引 KV课程设计、原型单域 10GB 上限不适合生产DynamoDB分区键/排序键订单事件、用户档案先定访问模式再建 GSIRDS关系表交易系统、CMS多 AZ 不等于读扩展SQS消息队列异步任务、削峰填谷VisibilityTimeout 按 6 倍处理时长设置4. 自动化编排与网络边界Beanstalk、CloudFormation、VPC、Route 53 及周边服务4.1 快速部署的两种路径Elastic Beanstalk 与 CloudFormationElastic 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。周边服务里还有一批和网络、消息、数据相关的产品按定位可以分成几类服务分类一句话定位Elastic Beanstalk应用部署把代码变成生产环境CloudFormation基础设施即代码用模板管理整套资源VPC / Route 53网络与 DNS划定网络边界并解析域名EMR / Redshift大数据离线计算与数据仓库Kinesis / AppStream流处理与桌面实时数据接入和远程应用SNS / SES消息与邮件推送通知和事务邮件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 缓存失效改源站不等于改 CDNCloudFront 把静态资源缓存在边缘节点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 可以推断下次回源时间。把这两个字段加进发布脚本的断言里比在浏览器里手动刷新可靠得多尤其适合有多级缓存层的架构做排障。本文还有配套的精品资源点击获取