简介：《AWS共有云架构介绍.pptx》是一份面向云架构师、运维工程师及解决方案人员的公有云架构科普型演示文稿，围绕AWS全球基础设施展开，涵盖亚马逊传统发布流程向云化演进、全球13个Region布局、可用区高可用设计、VPC网络互联以及丰富合规认证等核心内容，帮助读者快速建立对AWS整体架构和设计理念的系统认知。资源包共1个pptx演示文件，整体大小约10.82MB，单文件结构便于按页浏览和讲解演示。目前已有131人学习下载，适合正在筹备云解决方案、参与架构选型或是准备AWS相关技术分享的人员参考使用。通过该PPT，读者可以获知AWS如何以区域和可用区支撑低延迟、高覆盖的全球业务，了解其面向企业市场及政府合规的诸多认证清单，并能从跨AZ高可用MySQL等实例中借鉴云上容灾与业务连续性设计思路。内容信息密度高、页数较丰富，适合用于内部培训、课程讲义或方案介绍的起点材料。
1. 一份 AWS 共有云架构介绍，到底在介绍什么
很多人第一次拿到这份《AWS共有云架构介绍.pptx》时，以为是看概念图、背服务名。实际翻完才发现，它真正在讲的是三件事：怎么把业务拆成云上的模块、每个模块该用哪个 AWS 服务、这些服务之间如何用网络和安全规则串起来。对刚接触 AWS 的团队来说，这份材料最大的价值不是让你记住 EC2 和 S3 的名字，而是帮你建立「先画架构图，再谈预算」的思考习惯。我见过太多项目跳过架构设计直接开控制台，结果一个月后账单翻倍、故障恢复时间以小时计。这篇文章就顺着这份 PPT 的脉络，把共有云架构从选型到落地、再到排障的关键步骤拆开讲清楚，适合正在规划上云方案、或者想把现有架构从单机改成分布式的人。
2. 先搞清楚共有云的骨架：区域、可用区与 VPC 网络规划
2.1 为什么说区域的选型决定了你后面几年的延迟和账单
AWS 共有云的地基不是某台服务器，而是「区域（Region）+ 可用区（AZ）+ 边缘节点」这套层级结构。区域是一个地理范围，每个区域内有多个相互独立的可用区，可用区之间通过低延迟网络相连。你在控制台看到的每一个服务，最终都落在某个区域的某个可用区里。选区域这件事，很多人以为只是选个离公司近的地方，实际上它牵扯到四个维度的权衡。
第一个维度是延迟。业务用户在国内，你选了美东区域，那么每次请求都要跨太平洋，网络往返延迟在 200 毫秒以上，这对 API 接口或者 Web 应用来说几乎是不可接受的。第二个维度是合规，如果你的业务涉及个人隐私数据或行业监管要求，数据不能出境，那区域选择就没有商量余地。第三个维度是成本，不同区域的定价有差异，有些区域因为电力、带宽成本低，同样配置的实例可能便宜 10% 到 20%。第四个维度是服务可用性，AWS 的新服务和新规格往往先在部分区域上线，比如某些新的 GPU 实例类型只在三个区域提供，你需要的算力规格在目标区域没有，那这个区域再好也得放弃。
我一般会在架构图的第一页直接画一张表，列出候选区域的延迟测试数据、服务清单覆盖情况和预算单价，三列并排比较。这个习惯可以避免后面做容灾设计时发现跨区域数据同步方案根本不可行。区域选定了，接下来才是 VPC 网络设计。
2.2 用 CIDR 规划 VPC 子网：一个能直接抄的地址分配方案
VPC（虚拟私有云）是你在 AWS 上划出的一块逻辑隔离网络空间。常见做法是每个环境（生产、测试、开发）各建一个 VPC，VPC 内的 IP 地址段用 CIDR 表示法规划。很多人第一步就栽在 CIDR 取值上——随手填了一个172.32.0.0/16，等业务增长后才发现可用 IP 不够，整个 VPC 推倒重建。
以生产环境为例，我常用的分配方案是 VPC 取10.88.0.0/16，这样最多可容纳 65536 个 IP。第一层按可用区拆，10.88.1.0/24和10.88.2.0/24分给两个可用区；第二层按用途拆，每个可用区内再切出公有子网和私有子网。公有子网放负载均衡器和 NAT 网关，私有子网放应用服务器和数据库。这里有一个参数值得特别注意——子网掩码不要小于/24，也就是每个子网至少 256 个 IP，否则以后扩容器实例、加中间件节点时会因为 IP 不够面临重新划分子网的风险。
创建 VPC 时如果你用命令行操作，流程是三步：创建 VPC、创建子网、关联路由表。下面这段命令是创建 VPC 和子网的最小步骤。
aws ec2 create-vpc \ --cidr-block 10.88.0.0/16 \ --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-vpc}]' aws ec2 create-subnet \ --vpc-id vpc-0abc123456789def0 \ --cidr-block 10.88.1.0/24 \ --availability-zone ap-southeast-1a \ --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=prod-subnet-pub-1a}]'第一段命令创建 VPC，--cidr-block是地址段，--tag-specifications里的 Name 标签用于在控制台标识它。第二段命令创建子网，--vpc-id填上一步返回的 VPC ID，--availability-zone指定可用区，这一步决定了你的资源物理上落在哪里。命令执行完后，建议立刻去控制台看一眼「子网」页面，确认每个子网的「自动分配公有 IP」选项是否关闭。这个选项默认是关闭的，如果手动开启了，EC2 实例启动时会自动获得公网 IP，很容易绕过安全组约束，属于非常常见的配置疏漏。
2.3 路由表与 Internet Gateway：让流量按你的意图走
VPC 建好了，子网也划好了，但此时所有子网都是「与世隔绝」的，因为还没有配置路由。路由表的作用是告诉网络流量往哪个方向走。每个子网都必须关联一张路由表，最常见的是「公有子网走 Internet Gateway，私有子网走 NAT Gateway」这套组合。
创建 Internet Gateway 的步骤比较固定：先创建网关，再把它附加到 VPC，然后往公有子网的路由表里加一条0.0.0.0/0的目标路由。这里有一个坑：如果把0.0.0.0/0这条默认路由配到了私有子网的路由表里，那私有子网里的 EC2 就直接暴露在公网下了，数据库被扫到就是几分钟的事。
私有子网的出网访问一般走 NAT Gateway，它部署在公有子网中，为私有子网内的实例提供出站访问能力，同时不允许外部主动连接进来。需要注意的是，NAT Gateway 是按运行时间计费的，即使没有流量也会产生费用，而且它存在单点故障风险——如果一个 NAT Gateway 挂在一个可用区里，这个可用区断了，对应子网的出网也就断了。所以生产环境至少要在两个可用区各放一个 NAT Gateway，并把路由表拆开。
到这里，网络骨架已经成型，可以开始往里面放计算和存储资源了。
3. 从 PPT 到生产：计算、存储与数据库的选型落地
3.1 计算资源怎么选：EC2、容器还是 Serverless
PPT 里通常会画一个大大的 EC2 图标，旁边标注着 Auto Scaling，但实际落地时第一步不是选实例类型，而是先决定「用虚拟机、容器还是函数」。这个决定往往被忽略，导致后面重写部署脚本。
判断依据可以简单粗暴地按三点来。如果你的业务是对延迟极其敏感的 Java 应用、或者需要挂载块存储做大数据处理，EC2 是首选，因为它给你完整的操作系统控制权。如果你的团队已经在用 Docker 做镜像交付，而且不想管 Kubernetes 的控制面，那 AWS ECS（Elastic Container Service）比自建 K8s 省心得多。如果你处理的是事件型任务，比如上传图片后生成缩略图、定时抓取数据，Lambda 最合适，因为它在无请求时不产生费用。
选 EC2 时，实例类型的命名规则是有规律的，需要说明一下：第一个字母代表实例族，比如c是计算优化型，r是内存优化型，m是通用型，g是 GPU 实例。数字代表代际和规格大小，c7i.xlarge里的7是第七代，xlarge表示 4 核 8GB 起。新手最常见的翻车点是拿t2.micro（免费套餐实例）跑生产数据库，结果 CPU 积分耗尽后实例性能急剧下降。t系列是可突增实例，适合开发测试环境，生产环境一定要选固定性能的实例，比如m7i或r7i。
实际创建 EC2 实例时，有几个参数经常被忽略。用户数据（User Data）脚本可以在实例首次启动时自动执行，很多团队用它来初始化环境，但脚本里如果写入了 Access Key，密钥就泄露在实例上了，所以一定要改用 IAM 角色。另外，终止保护（Termination Protection）默认是关闭的，如果误操作终止了实例，数据盘会一并删除，这个开关建议对生产实例全部打开。
3.2 存储选型：S3 与 EBS 的分工，以及存储类怎么切
AWS 存储体系里最常用的两个服务是 S3（对象存储）和 EBS（块存储）。S3 存放的是「文件」，适合图片、日志、备份、静态网站资源；EBS 是挂载在 EC2 上的「硬盘」，适合数据库文件、应用数据。这个分工在 PPT 里可能只是一句话，但实际影响很大。
S3 的一个关键技术点是存储类（Storage Class）。默认的 S3 标准存储类适合频繁访问的数据，但如果你的数据是日志归档，90 天前的基本没人查，那么放着不动就是浪费钱。常见做法是配置生命周期规则：30 天后转 S3 标准低频访问，90 天后转 Glacier 冷归档。注意转存储类不是实时的，而是按天批量执行，所以容量预估时要留出缓冲。S3 的存储成本与访问量呈反向关系，低频访问类存储单价更低但取回要付费用，所以数据被大量读取的稳定业务，用标准存储类反而更划算。
EBS 这边最容易踩的坑是快照策略缺失。数据库所在的根卷如果每天有数据变更，却只在手动操作时打快照，一旦实例损坏，最多只能恢复到上次快照的时间点。生产环境的 EBS 快照建议至少每天一次，并且快照本身要设置保留周期，比如只保留最近 7 天的，避免快照费用越积越高。这块的配置可以通过 AWS Backup 服务统一管理，也可以直接用命令行调aws backup start-backup-job，核心是把策略固化下来。
3.3 数据库选型：什么时候该上 RDS，什么时候必须自建
数据库是架构里最「牵一发动全身」的部分。PPT 里一般会画 RDS 的图标，但真正做技术决策时，你需要先回答三个问题：数据模型是关系型的还是文档型的？读写比例是多少？能不能容忍分钟级的自动故障切换时间？
如果你的业务是订单系统、财务系统这种强事务场景，直接用 RDS 托管 MySQL 或 PostgreSQL 是稳妥的。RDS 的价值在于它替你做了三件事：自动备份、自动补丁、多可用区自动故障切换。多可用区部署这个参数一定要在生产库上开启，它会在另一个可用区同步创建一个备实例，主实例故障时自动切换，RPO 接近零。开启多可用区后，数据库的写入延迟会略有上升，但对绝大多数业务来说，这点延迟换来的是不用半夜爬起来手工切换数据库，值得。
如果是海量时序数据、或者数据模型频繁变化，RDS 就不太合适了。时序数据可以考虑 DynamoDB 或者自建 InfluxDB，文档型数据用 DynamoDB 也可以。这里给一个比较激进的建议：新项目如果数据量预期三个月内超过 50GB，且没有强事务需求，优先考虑 DynamoDB 而不是 RDS。DynamoDB 的按量付费模式在业务刚起步时成本很低，等业务大了再优化读写容量，比一开始就买个高配 RDS 便宜得多。
数据库选型确定后，接下来的问题就是架构怎么做到高可用——这是整份 PPT 最核心的部分。
4. 从单机到多可用区：高可用架构的搭建顺序与关键参数
4.1 先画故障域：你的应用挂了，谁来自动接管
高可用架构不是「多买几台机器」这么简单。它的本质是把你架构里的每一个单点找出来，然后给每个单点做冗余。在一个典型的 Web 三层架构里，单点通常出现在这四个位置：应用服务器、负载均衡器、数据库、网络出口。PPT 里那张复杂的架构图，拆开看其实就是这四个位置上的冗余策略。
应用服务器的冗余是最容易做的，用 Auto Scaling Group 就可以实现。它的核心参数有三个：最小实例数、最大实例数、期望实例数。常见的配置是最小 2、最大 10、期望 2，这样即使一台实例被系统回收，另一台也能扛住流量，同时扩缩容策略会在 CPU 超过 70% 时自动增加实例。
负载均衡器的冗余主要靠跨可用区部署。Application Load Balancer 本身就是区域级服务，AWS 会把它自动部署在多个可用区，所以你只需要保证注册到它后端的 EC2 实例分布在至少两个可用区即可。这里有个参数叫「跨可用区负载均衡」，开启后流量会在所有可用区的实例间均匀分配，建议保持开启，否则可能出现某个可用区的实例压力很大、另一个可用区的实例在空转。
数据库的冗余就是前文提到的 RDS 多可用区。在 PPT 架构图里，这三层冗余画完之后，还需要加一个故障演练的环节，否则你根本不知道配置到底有没有生效。
4.2 用命令行搭建一套最小高可用架构：从启动模板到伸缩策略
下面这套命令是我在测试环境里经常用来验证高可用配置的完整链路，你可以直接照着跑一遍，看整个架构是怎么串起来的。
首先创建启动模板，它定义了新实例启动时用的镜像、实例类型、安全组等配置。
aws ec2 create-launch-template \ --launch-template-name prod-app-template \ --launch-template-data '{ "ImageId": "ami-0abcdef1234567890", "InstanceType": "m7i.large", "SecurityGroupIds": ["sg-0abc123456789def0"], "IamInstanceProfile": {"Name": "app-ec2-role"}, "UserData": "IyEvYmluL2Jhc2gKc3lzdGVtY3RsIHN0YXJ0IG5naW54" }'启动模板里的UserData是 base64 编码的脚本，上面这段解码后是启动 nginx 的一段 shell 命令。这样实例启动后就会自动部署 Web 服务，不需要人工登录。IamInstanceProfile指定了实例的 IAM 角色，后续代码里调用 S3 或 DynamoDB 时不需要在服务器上保存密钥，这个习惯能避免很多安全告警。
接着创建 Auto Scaling Group，并把启动模板关联进去。
aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name prod-app-asg \ --launch-template LaunchTemplateName=prod-app-template,Version='$Default' \ --min-size 2 --max-size 10 --desired-capacity 2 \ --vpc-zone-identifier "subnet-0abc123456789def1,subnet-0abc123456789def2" \ --health-check-type ELB \ --target-group-arns "arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/prod-app-tg/abc123"--min-size 2和--max-size 10定义了实例数量的边界，--health-check-type ELB表示以负载均衡的健康检查结果作为实例健康状态依据，比单纯依赖 EC2 状态检查更准确。--vpc-zone-identifier里传了两个不同可用区的子网 ID，这样伸缩组会自动把实例分散到两个可用区。
然后配置伸缩策略，当 CPU 平均利用率超过阈值时扩容。
aws autoscaling put-scaling-policy \ --auto-scaling-group-name prod-app-asg \ --policy-name cpu-target-tracking \ --policy-type TargetTrackingScaling \ --target-tracking-configuration '{ "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" }, "TargetValue": 70.0 }'这段命令的核心是TargetValue: 70.0，表示让伸缩组把平均 CPU 维持在 70% 左右——高了加机器，低了减机器。这里要留意的是，缩容是保守的，默认要等实例状态稳定一段时间后才会触发，不会出现流量一波动就疯狂重启实例的情况。整套配置跑通后，你可以手动把一台实例终止掉，观察伸缩组在几分钟内自动拉起新实例。
4.3 健康检查与告警：高可用不等于「挂了能拉起来」，还要「挂了能知道」
架构能自愈还不够，你必须能在故障发生时第一时间感知。云上监控的标准配置是 CloudWatch 告警，它的核心是「指标 + 阈值 + 通知」。常用的一组告警包括：CPU 利用率超过 85% 持续 5 分钟、ALB 的 5xx 错误率超过 1% 持续 2 分钟、RDS 的磁盘空间低于 20% 持续 10 分钟。
用命令行创建一条告警比较直观。以下命令创建了针对 ALB 5xx 错误的告警，触发时往 SNS 主题发送通知。
aws cloudwatch put-metric-alarm \ --alarm-name prod-alb-5xx-alarm \ --alarm-actions "arn:aws:sns:ap-southeast-1:123456789012:prod-ops" \ --metric-name HTTPCode_ELB_5XX_Count \ --namespace AWS/ApplicationELB \ --statistic Sum \ --period 60 \ --evaluation-periods 2 \ --threshold 10 \ --comparison-operator GreaterThanThreshold \ --dimensions Name=LoadBalancer,Value=app/prod-alb/abc123--period 60表示以 60 秒为周期采集数据，--evaluation-periods 2表示连续两个周期都超过阈值才触发，这样可以过滤掉瞬时抖动。--comparison-operator GreaterThanThreshold是触发条件。告警触发后会通过 SNS 往团队群发消息，这里建议在 SNS 里配置多个订阅终端，比如钉钉机器人或邮件，别只配一个人，否则这个人休假时告警就没人处理了。
5. 云上架构常见的五个坑：现象、原因与补救办法
5.1 子网里实例突然连不上外网，安全组规则却一切正常
这是一个非常典型的问题：EC2 实例配置没问题、安全组入站规则也放行了 80 端口，但公网就是访问不了。排查到最后才发现，是子网关联的路由表里压根没有加 Internet Gateway 那条默认路由。很多人创建 VPC 后直接建实例，忘了检查「路由表」页面。解决方法是编辑该子网关联的路由表，增加一条目标为0.0.0.0/0、目标指向 Internet Gateway 的条目。如果实例在私有子网里，则检查是否有 NAT Gateway 以及路由表是否指向它。
5.2 数据库备份「开了」，但恢复时发现备份是空的
RDS 的自动备份默认保留 7 天，这个大多数人知道。但有一个细节经常被忽略：自动备份的第一个快照要等实例创建后一段时间才会生成，而且如果实例状态是「暂停」或刚启动不久，备份可能还没跑完。常见翻车现场是：周一创建数据库，周五删了数据想恢复，发现最早的备份点是周三，周一的数据全丢了。原因在于自动备份窗口默认是随机的，而且备份窗口内如果实例负载很高，备份会被跳过。解决方法是手动修改备份窗口，把它设置在业务低峰期，并且创建实例后立刻手动触发一次快照，把基线数据先兜住。
5.3 IAM 权限越给越大，最后开了「*」号管理员权限
为了省事，不少团队直接给应用服务器挂了一个AdministratorAccess的 IAM 角色，应用代码里用这个角色调用 AWS API。这样做的后果是：一旦代码被注入攻击，攻击者就能通过这个角色创建新的管理员用户、删除所有数据。这是云上安全事故的头号原因。正确做法是按最小权限原则设计 IAM 策略，比如只需要访问 S3 某个桶的某个前缀，就只授予s3:GetObject和s3:PutObject权限，资源 ARN 精确到桶名。权限建模时有 AWS 自带的策略生成器可以辅助，先把权限收紧，再逐步放宽，不要一开始就放开。
5.4 自动扩缩容配置了，但流量高峰时新实例迟迟不启动
Auto Scaling 的扩容策略触发了，但新实例从启动到提供服务需要时间，如果镜像太大、启动脚本里安装依赖太多，可能 5 分钟才能就绪。这中间流量已经打满了原来的机器。解决方向有三个：一是用自定义 AMI，把应用和依赖预先打包进镜像，启动时间可以从 5 分钟降到 90 秒；二是启用 Elastic Load Balancing 的慢启动模式，让新实例渐进地接收流量，避免刚启动就被压垮；三是把伸缩组的「扩缩容冷却时间」调小一些，但注意冷却时间太短可能导致频繁波动，一般建议 120 秒。
5.5 S3 桶被公开读，敏感数据泄露了才发现
S3 桶的权限有两种控制方式：桶策略和块公共访问设置。很多人往桶里传了一个文件后，为了分享链接，直接勾选了「公共读取」，然后整个桶的策略就被污染了。AWS 有「块公共访问」功能，可以在账户级别强制禁止所有公共读写，建议对所有生产环境账户开启。如果业务确实需要公开分享某些文件，单独建一个专门的公开桶，和内部数据桶分开管理，不要把内部桶设置成公开读取。
6. 把这份 PPT 变成你自己的架构蓝图：成本预估与演进路径
最后聊一个 PPT 里很少写清楚、但所有人都会关心的问题——这套架构到底要花多少钱，以及从第一步开始怎么演进。成本估算的核心思路是先算「最小可用架构」的钱，再算「增长后的钱」。所谓最小可用架构，就是我前面描述的那套：两个可用区各放一台应用实例、一台 RDS 多可用区数据库、一个 ALB、一个 NAT Gateway、若干 S3 存储。你可以把每项服务的按需单价列出来按月累加，得到一个基础成本数字。这个数字通常会让第一次上云的人吓一跳，因为你看到的不是某台服务器的价格，而是包括网络、存储、备份在内的完整账单。
成本优化有一个北极星指标：闲置资源的比例。每月账单出来后，先看 EC2 的利用率报告，低于 10% 的实例直接停掉；再看 EBS 快照总量，超过 1TB 的检查一下保留策略；然后看 NAT Gateway，如果出网流量一个月不到 1GB，考虑是不是可以直接去掉。云上省钱不是靠选择最便宜的套餐，而是靠「按需创建、及时释放」这个习惯。
架构演进的路径我通常会画成三步走。第一步：单区域双可用区，所有服务用托管产品，这套方案能保证业务稳定运行 3 到 5 年。第二步：当数据库压力成为瓶颈，引入只读副本或缓存层，把读流量从主库分走。第三步：业务规模进一步扩大后，考虑多区域部署或单元化架构。这三步不是割裂的，每一步都要回到最初的 VPC 规划、服务选型和成本模型里去核对。
我个人吃过最大的亏是没有在第一步就把 VPC 的 IP 段留够余量，到了第二步想加容器集群时发现地址不够，只能重新规划网络，业务中断了整整一个周末。所以我的习惯是：架构图不急着画最终版，先按上面的思路把最小可用架构跑起来，让团队在真实环境里操作一个月，记下哪些配置经常改、哪些服务实际很闲，再决定是否往下一步演进。毕竟架构这种事，按下葫芦浮起瓢的情况太多了，唯有按真实数据迭代才靠谱。希望这些经过验证的路径和参数，能让你在画完 PPT 之后真正建出一套扛得住业务的 AWS 共有云架构。
本文还有配套的精品资源，点击获取
