简介《Amazon Web Services in Action》第三版2023年英文版是一本聚焦AWS核心服务与架构设计的实战型指南适合云计算运维工程师、解决方案架构师、DevOps从业者以及正在备考AWS认证的读者。全书从基础到进阶系统展开前几章讲解EC2、Lambda、VPC、安全组等计算与网络组件后续深入IAM、CloudFormation、CLI/SDK、部署管道等自动化运维主题书中配有大量架构图、对比表格和可直接运行的练习代码并针对成本、安全、扩展性等给出实用取舍建议帮助读者直观理解每个服务的适用场景与组合用法。压缩包内为1个完整的PDF文档大小35.27MB内置目录与书签可快速跳转章节英文原版表述准确第三版重点纳入了近几年的服务演进与最佳实践适合有一定云基础并希望系统提升AWS应用能力的学习者。目前已有73人学习/下载可用于日常查阅、项目方案设计参考及面试前系统复习。1. Amazon Web Services in Action 3rd Edition这本书解决什么问题手里攒着一台云主机却不知道下一步该干什么、看官方文档翻到眼酸还是不敢在生产环境点“创建”——这是大多数 AWS 入门者真实的状态。Amazon Web Services in Action 3rd Edition2023 英文版就是冲着这个缺口来的不跟你铺开讲几百个服务而是把一台应用从代码到上线必须用到的 EC2、VPC、S3、IAM、Lambda、数据库、监控串成一条完整链路每个环节都给你一份能照着敲的命令或配置。它不是 API 手册也不用你先把网络基础补完再读只要你写过 Web 应用、知道 Linux 基本操作就能顺着书里的实验一步步把东西跑起来。适合三类人正打算考 AWS 认证但缺实操的人、被公司要求“上云”却没系统做过架构的开发者、以及在学校里只学过 Docker 没摸过真云的学生。2. 从书到云先用这套最小骨架理解 AWS 的计算、存储与网络这本书开篇不急着让你创建资源而是先花一章把 AWS 的底层逻辑讲清楚区域Region、可用区Availability Zone、边缘节点、共享责任模型、以及账户里那些默认就存在的“隐型资源”。这一段很多人翻得飞快结果后面一边跟着做一边卡壳。这里把书里隐含的最小组件拆开讲透你会发现后面所有实验都是这几个东西在排列组合。2.1 Region 与 AZ所有实验的第一步是“选哪儿”第一次用 AWS 的人最容易忽略 Region 的意义总以为选个离自己近的就完事。实际上 Region 影响的不只是延迟还影响价格、可用服务列表、合规要求、甚至同一个服务在不同 Region 的控制台界面都不一样。书里后续每个实验都会在命令里出现--region参数你如果没理解它就会犯“资源建在东京却在美国区查不到”的低级错误。实际操作时我的习惯是先用 IAM 用户而不是根用户登录然后在 CLI 里把 Region 固定写进配置。因为在控制台上点来点去时Region 通常显示在右上角切换成本低到几乎无感危险就在于这个“无感”——你在一个区建了一堆资源换了个区发现啥也没有账单倒是照常出。Availability Zone 是 Region 内部的物理隔离单元一个 Region 至少有三个。书里教你的高可用实验本质就是“把两个 EC2 放到不同 AZ前面挂一个负载均衡器”。理解到这一步就够了初学阶段不用深究 AZ 之间的内网带宽和延迟细节那是后续调优的事。2.2 VPC一张最小网络拓扑画明白后面才不会飘很多初学者在 VPC 上翻车是因为他们把 VPC 理解成了“虚拟防火墙”或者“一个 IP 网段”其实 VPC 是你整个云上资源的容器。书里搭建环境时永远默认你有一个 VPC、几个子网、一张路由表、一个 Internet Gateway这四个东西缺一个EC2 就“上不了网”。我把书里的思路压缩成一张最小拓扑一个 VPC比如10.0.0.0/16一个公有子网10.0.1.0/24路由表指向 Internet Gateway一个私有子网10.0.2.0/24路由表只有本地路由。Web 服务器放公有子网数据库放私有子网。就这么简单但它能解释后面 80% 的网络问题。动手验证时用命令创建比控制台更直观# 创建 VPCCIDR 设为 10.0.0.0/16 aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query Vpc.VpcId # 创建子网并绑定到 VPC注意 --availability-zone 要选同一 Region 下的具体 AZ aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a # 创建 Internet Gateway 并挂到 VPC aws ec2 create-internet-gateway aws ec2 attach-internet-gateway --vpc-id vpc-xxxx --internet-gateway-id igw-xxxx # 创建路由表并把 0.0.0.0/0 指到 Internet Gateway aws ec2 create-route-table --vpc-id vpc-xxxx aws ec2 create-route --route-table-id rtb-xxxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxxx这段命令的查询参数Vpc.VpcId是 CLI 的标准输出过滤写法--query后面跟的是 JMESPath 表达式这样不会把整个 JSON 糊在屏幕上。--availability-zone必须写全名比如us-east-1a只写us-east-1会报错。而0.0.0.0/0是默认路由含义是“所有出方向流量走这里”书里在这里会特意提醒你这个路由只解决“能出去”能不能“进来”还要看安全组。2.3 IAM权限设计决定你后面是顺畅还是处处被拒绝IAM 是整本书里“最不性感但最容易卡人”的一章。AWS 的默认策略是“显式拒绝一切”你建了 EC2 实例但没给它的 IAM role 配上 S3 权限那代码里访问 S3 一定报AccessDenied——这不是网络问题不是代码 bug是 IAM 在拦你。书里的建议是用角色而不是长期密钥最小授权能读就不给写能单资源就不给通配符。我自己的踩坑经历是为了省事给 EC2 绑了一个AdministratorAccess结果某天一个脚本误删了生产桶。书里专门强调的“最小权限原则”不是合规要求是在保护你自己。跟着做时至少要学会三件事创建 IAM 用户并只给编程访问权限、创建 IAM role 并挂到 EC2 上、用aws sts get-caller-identity验证当前身份。# 给 EC2 挂一个只读 S3 的角色 aws iam create-role --role-name ec2-s3-readonly --assume-role-policy-document file://trust-policy.json aws iam attach-role-policy --role-name ec2-s3-readonly --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccesstrust-policy.json里写的是 EC2 服务的信任关系声明格式可以提前准备成文件内容核心是Service: ec2.amazonaws.com表示这个角色只让 EC2 来“借用”。挂好角色后实例里访问 S3 就不再需要aws configure填密钥CLI 自动从实例元数据去换临时凭证。这一步体验一旦打通你会明显感觉到“身份和权限”跟“资源本身”是两套独立系统整个 AWS 的心智模型就正过来了。3. 照书动手在 AWS 上做一遍最小可复现的部署流程读这本书最值得做的事就是把它前面几章的实验串成一个完整的发布流程从配置 CLI到起一台 EC2到把代码放上 S3再到用 CloudFormation 把整个环境一键重建。这一步走通你对云的理解会发生质变因为你不再是从控制台点按钮而是开始用代码管理基础设施了。3.1 从零配置 AWS CLI一个下午搞定本机环境书里的命令全部基于 AWS CLI所以在读第二章时就得先把 CLI 装好。没有一个好用的本机环境后面所有实验都会卡在“命令没反应”这种尴尬位置。我用的是awscli2.x 版本pip install awscli这种装法在系统 Python 环境里容易依赖冲突推荐下载官方捆绑安装包或者用venv隔离一下。配置时最靠谱的做法是同时设置默认 Region 和输出格式并指定一个 profile避免和公司账号混淆# 一键配置会交互式要求输入 Access Key ID 和 Secret Access Key aws configure --profile personal # 验证身份是否可用 aws sts get-caller-identity --profile personalget-caller-identity是验证 AWS 环境有没有配对的黄金命令它能显示你当前用的账号 ID 和用户名所有“明明配了却连不上”的怀疑用这条命令一测便知。值得一提的坑是如果你之前在环境变量里设过AWS_PROFILE那么 CLI 会优先走环境变量--profile参数反而会被忽略。遇到权限莫名其妙对不上时先env | grep AWS看看有没有残留变量。3.2 起一台 EC2从 AMI 选择到用户数据脚本书里第一次 EC2 实验往往是“用命令启动一个 Web 服务器”这里最有价值的是“用户数据User Data”这个机制你在创建实例时塞一段 shell 脚本实例第一次启动时自动执行这样就不用手动 SSH 进去敲命令了。它编排思想的最小雏形也是后面建集群的基础。我习惯把建设步骤写全包括创建密钥对、记录实例 ID、等待状态变为 running、然后通过公网 IP 访问# 创建密钥对权限设置为 400SSH 时要用 aws ec2 create-key-pair --key-name book-key --query KeyMaterial --output text book-key.pem chmod 400 book-key.pem # 获取最新 Amazon Linux 2023 的 AMI ID这是依赖 Region 的 aws ec2 describe-images --owners amazon --filters Namename,Valuesal2023-ami-2023.* --query sort_by(Images, CreationDate)[-1].ImageId # 启动实例UserData 里写一段安装 httpd 并启动服务的脚本 aws ec2 run-instances \ --image-id ami-xxxx \ --instance-type t3.micro \ --key-name book-key \ --security-group-ids sg-xxxx \ --subnet-id subnet-xxxx \ --user-data file://user-data.sh \ --associate-public-ip-address--user-data file://user-data.sh的file://前缀是 CLI 读取本地文件的固定写法。user-data.sh内容可以很简单#!/bin/bash yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd echo h1Hello from $(hostname -f)/h1 /var/www/html/index.html这段脚本在 EC2 首次启动时由 cloud-init 执行。$(hostname -f)会把实例的主机名写进页面这样当你浏览器看到不同主机名时就能确认负载均衡确实在多台机器间分发请求这是书里后面“滚动部署”实验的基础。注意脚本没有set -e时某一行失败不会中断后续命令排查时要看/var/log/cloud-init-output.log。3.3 用 S3 托管静态资源理解 Bucket 策略和 ACL 的区别EC2 把应用跑起来后书里下一个动作是把静态资源挪到 S3。S3 上手极易因为它就是“存对象”的桶但权限模型比想象中啰嗦。最容易混的两个概念Bucket Policy 管“谁能访问这个桶”ACL 管“这个对象归谁”。从 2023 年 4 月起AWS 对新开的桶默认禁用 ACL哪怕你在控制台勾选了“公开读”也必须在 Bucket Policy 里显式声明。一条最常见的公开读策略我直接拿来做静态站{ Version: 2012-10-17, Statement: [ { Sid: PublicReadForGetObject, Effect: Allow, Principal: *, Action: s3:GetObject, Resource: arn:aws:s3:::example-book-bucket/* } ] }Principal: *表示所有人Resource后面必须带/*否则策略管不到桶里的对象。这里最容易犯的错是把桶 ARN 写成arn:aws:s3:::example-book-bucket不带通配符结果网页访问出现 403。S3 还有个容易忽略的点对象列表不公开时即使对象本身可读浏览器直接访问根路径也看不到目录列表所以做静态站一定要把首页命名为index.html并通过 Static Website Hosting 的端点访问。3.4 用 CloudFormation 把上面所有资源写进一个模板书前面所有实验都是手工命令到这一章则上了一个台阶把 VPC、子网、EC2、S3 全写进一个 CloudFormation 模板一条命令把整个环境建出来。这种“基础设施即代码”的体验对新手极其震撼——今天建好明天删掉后天再一键秒建环境完全一致。最简模板骨架如下只保留核心资源Resources: WebServer: Type: AWS::EC2::Instance Properties: ImageId: ami-xxxx InstanceType: t3.micro SecurityGroups: - !Ref WebServerSecurityGroup UserData: Fn::Base64: !Sub | #!/bin/bash yum install -y httpd systemctl start httpd WebServerSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Enable HTTP access SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 0.0.0.0/0!Ref是 YAML 简写表示引用模板里另一个逻辑资源的 IDFn::Base64是因为 UserData 必须经过 Base64 编码CloudFormation 提供这个函数帮你自动完成。SecurityGroupIngress里的0.0.0.0/0代表全世界都能访问 80 端口——书里再三提醒这是学习环境不是一个稳妥的生产配置生产环境应该把来源限制为你的办公网段或 CloudFront 的 IP 段。部署命令就一条aws cloudformation deploy --template-file template.yaml --stack-name book-demo --capabilities CAPABILITY_NAMED_IAM后面那个参数是因为模板里如果创建了 IAM 角色必须显式确认你是知情操作。4. 书里没写透的参数几个日常高频服务的选型笔记第三版新增和改写的部分集中在容器ECS/Fargate、无服务器Lambda、以及成本控制。这一章不是给你把整本书的目录复述一遍而是把我认为“书里有涉及但讲得克制”的高频参数展开当成自己的复盘笔记。读到这一章你可以一边对照书一边实践哪些参数必须调哪些参数用默认就够。4.1 EC2 实例类型选型t3.micro 能撑到什么时候书里的实验案例大量使用 t3.micro 和 t2.micro因为它们免费额度友好、性能对实验足够。但真实场景里第一个要决策的就是“选什么实例类型”选错要么浪费钱要么应用卡到没法用。我的经验是先按“场景”归类Web 入口用通用型t3、m7i内存型应用Redis、Elasticsearch用 r 系列计算密集视频转码、批处理用 c 系列。t3 系列有个特性值得专门测一下它是 Burstable 实例意味着平时性能基线较低但能通过积分CPU Credits短时间爆上去。开发环境拿它跑没问题生产环境一旦持续高 CPU积分耗尽就会强制限速表现为应用“突然变慢”。书里在讨论成本优化时提过这点但没展开讲积分的查看方法我一般用这条命令看aws cloudwatch get-metric-statistics \ --namespace AWS/EC2 \ --metric-name CPUCreditBalance \ --dimensions NameInstanceId,Valuei-xxxx \ --start-time $(date -u -d -1 day %Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u %Y-%m-%dT%H:%M:%SZ) \ --period 3600 --statistics MinimumCPUCreditBalance降到 0 表示积分耗尽这是 t3 实例被“限速”的铁证。--period 3600表示按一小时一个数据点聚合时间格式必须是 UTC 的 ISO 8601$(date ...)是 shell 里拼昨天时间的常用写法。如果你预算充足又不想半夜起来看监控直接选 m7i 这类固定性能实例省心。4.2 Lambda 的 timeout 和 memory两个参数决定你的成本结构书对 Lambda 的介绍一定会提到无服务器架构但它不会替你踩过性能跟成本之间的坑。Lambda 计价按“内存 × 运行时间”计算所以同样一个函数内存设 128MB 跑 3 秒和设 1024MB 跑 0.8 秒后者的总成本可能反而更低因为时间大幅缩短而单位价格只线性增长。一个常见策略是把 memory 从 128MB 一路往上调并做压测找到“时间下降不再明显”的拐点。书里没有明说但我们测试时经常遇到的另一个问题是 timeout默认 3 秒调用外部 API 稍微慢一点就超时。根据函数逻辑调整是必要的但也不要无脑设成 15 分钟因为 Lambda 同步调用会让 API Gateway 跟着一起等待用户体验会灾难性地差。通常我会设 10 到 30 秒作为起步值这足够覆盖大多外部依赖响应。# 更新 Lambda 函数的内存和超时时间 aws lambda update-function-configuration \ --function-name book-processor \ --memory-size 512 \ --timeout 30--memory-size和--timeout的修改是即时生效的不需要重新上传代码。但注意内存从 128MB 改到 512MB 时Lambda 的 CPU 算力也会相应提高因为 AWS 按比例分配 vCPU所以不是“多付费但没好处”是付费提速再省时。调试时留意 CloudWatch Logs 里的Report行里面有Duration和Billed Duration两项能帮你判断瓶颈是在代码还是内存配置。4.3 数据库选型什么时候用 RDS什么时候“没必要用数据库”第三版花了不小篇幅讲托管数据库 RDS一个重要结论是别在自己 EC2 上装 MySQL 自欺欺人。RDS 替你扛了补丁、备份、故障切换虽然价格贵一截但省下的运维时间远大于差价。不过书里也提醒你如果你的应用只是存几十条配置S3 或 DynamoDB 可能更合适杀鸡不用牛刀。RDS 创建时最容易忽略的参数是backup-retention-period和multi-az。测试环境设 0 或 1 天即可但生产环境备份至少 7 天Multi-AZ 开启后费用直接翻倍。我通常建生产数据库时用这样一条命令aws rds create-db-instance \ --db-instance-identifier book-db \ --engine mysql \ --allocated-storage 100 \ --db-instance-class db.t3.medium \ --master-username admin \ --master-user-password $(openssl rand -base64 16) \ --backup-retention-period 7 \ --multi-az \ --storage-encrypted--storage-encrypted默认是 false 的这个参数不能省因为现在很多合规审计都要求存储加密。openssl rand -base64 16生成密码是防止你图省事用弱密码这个方法生成的密码没有符号符合 RDS 的默认密码策略。比较坑的一点RDS 创建耗时可能长达十几分钟命令一直挂在前台很占终端可以加--no-cli-pager并切到另一个终端做别的事或者用aws rds describe-db-instances --db-instance-identifier book-db --query DBInstances[0].DBInstanceStatus轮询状态。4.4 成本控制的两个命令预算告警和资源清理第三版新增了不少关于成本管理的内容毕竟 2023 年大家都在捂紧钱包。书里给你推荐的场景是 Cost Explorer 控制台但作为工程师我更喜欢用命令行动做事。创建预算告警是让 AWS 在超过阈值时自动发邮件这比你每月看到账单再怀疑人生有用得多。aws budgets create-budget \ --account-id 123456789012 \ --budget file://budget.json \ --notifications-with-subscribers file://notifications.jsonbudget.json里定义预算金额、时间周期比如按月、预算类型COST或USAGEnotifications.json里定义触发条件比如实际消费达到预算的 80%和通知渠道SNS 或邮件。这个命令是少数必须带账号 ID 的场景值得先aws sts get-caller-identity查一遍账号号别复制网上的模板导致预算建到别人账号里。另外日常清理我把“列出所有 EC2”和“列出所有 S3 桶”写成了两个 alias在周末收工前跑一遍防止实验资源留在那儿夜里持续计费。5. 跟着 3rd Edition 操练时最常见的 5 个坑读这本书的典型状态实验做到一半前一条命令明明成功了可后一条就是连不上。这里挑五条我见过的高频翻车现场都是现象、原因、解决三段式你对照自己的终端输出基本能找到答案。5.1 密钥对权限过松导致 SSH 拒绝连接现象ssh -i book-key.pem ec2-userpublic-ip直接报Permissions 0644 for book-key.pem are too open。第一次做实验的人几乎都会遇到因为从 AWS CLI 导出密钥后默认权限是 644。原因OpenSSH 出于安全考虑拒绝使用任何“其他用户可读”的私钥文件。查了一下书里其实在早期的版本提过chmod 400但第三版这里写得比较低调很容易看漏。解决chmod 400 book-key.pem。另外有个隐藏点如果你把密钥下载到了 Windows用 WSL 时需要确认文件系统不是 drvfs 挂载否则chmod不生效得把密钥复制到 ext4 分区里再改权限。5.2 安全组没放行 ICMPping 不通但 Web 能开现象浏览器能打开 EC2 上的网页但ping公网 IP 一直请求超时。新手这时会怀疑“网络是不是坏了”甚至重装系统白白浪费时间。原因安全组是按“允许”规则工作的默认拒绝所有入站流量。你创建安全组时只放行了 80 端口HTTP没有放行 ICMPping协议的数据包根本进不来但 TCP 80 是通的。解决在安全组入站规则里加上--protocol icmp --cidr 0.0.0.0/0或者直接用 CLI 添加aws ec2 authorize-security-group-ingress \ --group-id sg-xxxx \ --protocol icmp \ --cidr 0.0.0.0/0严格讲生产环境放行 ICMP 是没有必要的反而会让别人更轻易发现你的主机。所以建议实验环境加一下即可生产环境专门留一台跳板机做排障就够了。5.3 IAM 角色挂载顺序错乱导致 EC2 “有角色但没权限”现象给一个已经 running 的 EC2 修改了 IAM role命令执行成功实例元数据里也能看到角色名但实例里访问 S3 依旧报Unable to locate credentials。原因EC2 的实例元数据服务会对角色凭证做缓存更换角色后旧凭证不一定会立刻失效同时如果新角色本身没有附加任何策略临时凭证即使拿到手也没有任何权限。这俩问题叠加现象非常迷惑。解决先确认角色是否真的是目标角色再确认策略有没有挂对aws iam list-attached-role-policies --role-name my-role如果策略确实挂上了在实例内可以强制刷新凭证重启实例或者登录后执行sudo systemctl restart ecs之类这取决于你装了什么 agent。更稳的办法是别在 running 实例上改角色直接在启动时就指定好 role。书里有一个强调过但容易被忽略的点EC2 的 IAM role 一旦挂上工作进程里就不能用aws configure去写静态密钥否则会覆盖掉角色凭证。5.4 CloudFormation 模板更新失败回滚后资源一片狼藉现象aws cloudformation deploy更新模板时报UPDATE_ROLLBACK_FAILED堆栈状态卡住删除也删不掉一堆资源悬在那账单照跑。原因更新过程中某个资源创建成功但后续步骤失败CloudFormation 尝试回滚时那个新资源又依赖一个已被修改的旧资源回滚无法完成于是卡死。新手看到这个报错基本是懵的因为这不在书里的正常流程中。解决先继续完成回滚而不是强行删除堆栈。可以进入控制台 CloudFormation 页面对堆栈选择“继续回滚”等状态恢复为UPDATE_ROLLBACK_COMPLETE后再处理问题。如果回滚都卡住就需要手动删除那个“卡住的新资源”再回去继续回滚。更关键的是预防改模板时尽量“新增资源不动旧资源属性”先 add 再改避免一步做太多变更。5.5 S3 桶里文件“删不掉”或“上传报 403”现象管理员账号上传文件到 S3 没问题某天换成 IAM 用户操作却报AccessDenied检查用户权限也确实给了AmazonS3FullAccess。原因AmazonS3FullAccess只管 S3 的服务权限但如果你给用户设了“拒绝”级别的桶策略或者桶策略里允许条件冲突IAM 的 Allow 会被显式 Deny 压住。另一个高频原因是 KMS 加密如果桶里对象用的是客户管理型 KMS key你还必须给用户加kms:Decrypt权限否则读对象时照样 403。解决aws s3api get-bucket-policy --bucket book-demo-bucket先看桶策略里是否存在 Deny 规则。如果没有再去检查对象是否启用了 SSE-KMS给用户补上 KMS 权限。这俩都属于“表面权限看着够实际链路断了一截”的类型排查时先别怀疑人生按 S3 访问排查表从上往下捋。6. 把书读成能力验证实验结果的两个长期习惯读这本书最容易产生的错觉是“跟着命令敲完就是会了”。命令能跑通只是第一步真正拉开差距的是“验证”这件事。一个常见做法是把每次实验的“输入、输出、预期结果”记成一张简表然后刻意做破坏性验证——比如关掉 EC2 再启动看看数据还在不在把安全组入站规则删了看看应用是不是立刻失败。这比重复敲十遍创建命令有用得多。最后一个值得长期保持的习惯每次看完一章就用 CloudFormation 把整章的环境重建一遍。第一次照着书敲命令的时候你是在“理解”第二次用它重建的时候你是在“设计”——哪个参数是必须的、哪个可以删掉、哪两个资源之间有隐式依赖全都会浮出水面。这个过程中你动手的时间变短了思考的时间变长了其实才是真正开始用 AWS 的起点。至于进阶方向我自己的路线是这本书读完后紧接着补三块——第一是 VPC 内的安全组和网络 ACL 组合怎么设计第二是成本优化里的 EC2 预留实例和 Spot 实例怎么混用第三是容器化应用上 ECS Fargate 的最小配置。这三块是书讲了但不一定展开的延伸题也是面试和实际工作中被问得最多的地方。把这本书读透不需要你背命令需要你接受“云上的一切都可以用代码重来”这个前提。我至今保留的习惯是每个周日用一个一次性账号把某个方案从零建一遍、再从零删光账单几乎为零但对服务的熟悉程度比任何时候刷文档都高。希望帮到你。本文还有配套的精品资源点击获取