简介《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 上划出的一块逻辑隔离网络空间。常见做法是每个环境生产、测试、开发各建一个 VPCVPC 内的 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 ResourceTypevpc,Tags[{KeyName,Valueprod-vpc}] aws ec2 create-subnet \ --vpc-id vpc-0abc123456789def0 \ --cidr-block 10.88.1.0/24 \ --availability-zone ap-southeast-1a \ --tag-specifications ResourceTypesubnet,Tags[{KeyName,Valueprod-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、容器还是 ServerlessPPT 里通常会画一个大大的 EC2 图标旁边标注着 Auto Scaling但实际落地时第一步不是选实例类型而是先决定「用虚拟机、容器还是函数」。这个决定往往被忽略导致后面重写部署脚本。判断依据可以简单粗暴地按三点来。如果你的业务是对延迟极其敏感的 Java 应用、或者需要挂载块存储做大数据处理EC2 是首选因为它给你完整的操作系统控制权。如果你的团队已经在用 Docker 做镜像交付而且不想管 Kubernetes 的控制面那 AWS ECSElastic 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 LaunchTemplateNameprod-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 NameLoadBalancer,Valueapp/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 共有云架构。本文还有配套的精品资源点击获取
简介《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 上划出的一块逻辑隔离网络空间。常见做法是每个环境生产、测试、开发各建一个 VPCVPC 内的 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 ResourceTypevpc,Tags[{KeyName,Valueprod-vpc}] aws ec2 create-subnet \ --vpc-id vpc-0abc123456789def0 \ --cidr-block 10.88.1.0/24 \ --availability-zone ap-southeast-1a \ --tag-specifications ResourceTypesubnet,Tags[{KeyName,Valueprod-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、容器还是 ServerlessPPT 里通常会画一个大大的 EC2 图标旁边标注着 Auto Scaling但实际落地时第一步不是选实例类型而是先决定「用虚拟机、容器还是函数」。这个决定往往被忽略导致后面重写部署脚本。判断依据可以简单粗暴地按三点来。如果你的业务是对延迟极其敏感的 Java 应用、或者需要挂载块存储做大数据处理EC2 是首选因为它给你完整的操作系统控制权。如果你的团队已经在用 Docker 做镜像交付而且不想管 Kubernetes 的控制面那 AWS ECSElastic 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 LaunchTemplateNameprod-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 NameLoadBalancer,Valueapp/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 共有云架构。本文还有配套的精品资源点击获取
