亚马逊云32核账号 AWS 基础设施自动化最佳实践：从手动运维到持续交付操作指南

用户搜索这个主题，通常不是想知道“什么是自动化”，而是已经遇到现实问题：测试环境和生产环境不一致、EC2 实例参数靠人工记录、安全组改错后服务中断、数据库变更没有版本管理、发布时需要多人登录控制台逐项点击、回滚只能靠临时补救。真正需要解决的是：如何把 AWS 上已有资源逐步纳入代码管理，如何建立可重复创建的服务器和数据库配置，如何让发布动作从人工执行变成可审计、可回滚的持续交付流程。

下面的内容按“先能落地，再逐步规范”的顺序展开，适合已经在 AWS 上运行业务，但希望从手动运维迁移到自动化交付的团队。

一、先判断你的问题出在哪个环节

在开始改造前，先判断当前瓶颈属于哪一类，否则容易一上来就建流水线，结果根本问题没解决。

如果你现在还依赖人工在控制台创建实例，建议先完成“资源模板化”；如果你已经有模板，但仍靠人工发布，重点转向“持续交付流水线”；如果两者都有但故障多，优先做“权限、回滚、监控和变更审计”。

二、准备工作：在 AWS 上做自动化前必须先定好的内容

亚马逊云32核账号 1. 账号与权限准备

不要直接用 root 账号做模板创建和流水线部署。至少准备以下角色：

• 基础设施部署角色：允许创建 CloudFormation Stack、EC2、RDS、VPC、IAM Instance Profile。
• 应用发布角色：只负责部署应用，不直接改底层网络和数据库实例。
• 只读审计角色：给运维、开发、审计查看资源变更和流水线执行记录。

如果使用 IAM Role，建议把生产环境和测试环境分账号管理，通过跨账号角色执行部署。这样即使测试流水线配置错误，也不会直接修改生产资源。

2. 所需资源清单

3. 前置条件

开始之前先完成这几个基础动作，否则后面会频繁返工：

• 统一命名规范，例如 dev-web-01、prod-rds-app、shared-vpc-apne1。
• 确定地域和可用区，不要让测试在 us-east-1、生产在 ap-southeast-1，却期望延迟和镜像行为完全一致。
• 规划 VPC 网段、子网、NAT、路由表，避免后续 RDS 或 EKS 无法接入。
• 为所有资源加标签：Environment、Owner、Project、CostCenter。
• 决定 Linux 或 Windows 服务器基线镜像，并固化初始化脚本。

三、第一步：先把服务器、网络和数据库改成代码创建

从控制台手工点选资源迁移到模板，是最关键的一步。没有这个基础，持续交付只会把混乱流程自动化。

步骤1：梳理现有资源并拆分模板

在控制台中先盘点已有资源：VPC、子网、Internet Gateway、NAT、EC2、EBS、RDS、安全组、负载均衡、Route 53 记录。不要把所有资源写进一个超大模板，建议按下面结构拆分：

这样拆分后，修改数据库参数时不会误影响网络层资源。

步骤2：创建基础网络模板

在 CloudFormation 控制台点击“Create stack”，上传 network.yaml。填写参数时，建议至少暴露这些变量：

• VpcCidr：例如 10.20.0.0/16
• PublicSubnetA：例如 10.20.1.0/24
• PrivateSubnetA：例如 10.20.11.0/24
• AvailabilityZoneA：如 ap-southeast-1a
• EnableNatGateway：true 或 false

注意事项：

• 如果业务需要 RDS 放在私网，至少准备两个不同可用区的私有子网。
• 面向网站应用时，EC2 建议放私网，通过 ALB 暴露公网流量。
• 跨境业务优先把地域选在主要用户附近，再通过 CloudFront 或 Route 53 做流量优化，不要直接把所有服务放离用户很远的地域。

步骤3：创建 EC2 并固化初始化

创建 compute.yaml 时，不要只定义实例规格，还要把启动后的初始化动作写进去。Linux 可以通过 UserData 安装 Nginx、JDK、CloudWatch Agent；Windows 可以在 UserData 中启用 WinRM、安装 IIS 或配置 RDP 策略。

常用参数建议：

Linux 远程连接时，优先用 SSM Session Manager 替代直接开放 22 端口。如果必须开 SSH，安全组只放行固定办公 IP。Windows 则同理，3389 不要对全网开放。

步骤4：创建 RDS 并同步参数组

数据库不要在控制台手工创建。RDS 至少要把以下内容放进模板：

• 亚马逊云32核账号 实例类型，如 db.t3.medium
• 存储类型与容量，如 gp3 100GB
• 是否多可用区
• 自动备份保留天数
• 参数组和选项组
• 数据库子网组
• 安全组入站规则，仅允许应用服务器安全组访问

MySQL 连接问题很多并不是数据库本身异常，而是以下几项配置遗漏：

• RDS 安全组未放行应用服务器所在安全组
• 数据库用户只允许 localhost 登录
• 参数组修改后未重启实例生效
• 应用侧连接池过大，超过 max_connections

四、第二步：把发布流程改成持续交付，而不是继续人工上线

当基础设施已经能通过模板创建后，下一步是让应用发布自动执行。一个可用的最小闭环是：代码提交 → 模板校验 → 构建 → 测试 → 部署到测试环境 → 人工审批 → 部署到生产环境。

步骤1：创建代码仓库结构

建议一个仓库至少包含以下目录：

这样基础设施、应用和环境参数可以一起走版本控制，避免“代码更新了，但生产参数忘记改”的问题。

步骤2：配置 CodePipeline

在 AWS 控制台进入 CodePipeline，点击“Create pipeline”。

关键设置建议如下：

• Source：选择 CodeCommit 或 GitHub。
• Build：接入 CodeBuild，执行单元测试、模板语法校验、镜像构建。
• Deploy-Test：部署到测试环境，可以调用 CloudFormation 更新 Stack，或用 CodeDeploy 发布到 EC2。
• Approval：生产前人工审批，审批信息里写明变更资源、影响范围、回滚版本。
• Deploy-Prod：只读取生产参数文件，禁止直接复用测试环境变量。

常见错误是把测试和生产用同一个参数文件，结果生产数据库地址被误改。正确做法是不同环境使用独立参数集，并在流水线中显式区分。

步骤3：为 EC2 配置自动部署

如果应用运行在 EC2，可使用 CodeDeploy。创建 Deployment Group 时：

• 通过标签选择服务器，例如 Environment=prod、Role=web。
• 部署策略优先用一次一台或分批更新，避免所有实例同时中断。
• 应用包存放在 S3，版本号与 Git Commit 关联。

部署前后建议执行两个脚本：

• BeforeInstall：备份当前配置文件、停止旧进程。
• AfterInstall 或 ValidateService：检查 80/443 端口、应用健康接口、数据库连通性。

如果验证失败，立即终止部署并回滚到上一版本包。

五、第三步：数据库变更、备份与回滚要一起设计

很多团队只把应用接入流水线，数据库仍靠 DBA 手动执行 SQL，这会导致持续交付在数据库层面中断。

1. 数据库变更如何接入流程

做法不是让流水线自动执行所有 SQL，而是把数据库脚本纳入版本管理，并区分三类变更：

MySQL 连接失败排查时，先看错误信息，再对照以下顺序：

• 能否从 EC2 telnet 到 3306 或使用 nc 测试端口
• RDS 安全组是否允许来源安全组
• 用户名和 host 权限是否正确
• 是否启用了 SSL 连接但客户端未配置
• 连接数是否耗尽

2. 备份与恢复不要只依赖自动快照

亚马逊云32核账号 RDS 自动备份可以解决实例级恢复，但不等于满足业务回滚需求。建议至少保留：

• RDS 自动备份：用于时间点恢复
• 手动快照：用于重大版本发布前保留
• 亚马逊云32核账号 逻辑备份：用于单表恢复、跨环境迁移

亚马逊云32核账号 如果是 Redis，重点不是“如何备份”本身，而是先确认持久化策略、参数组和故障切换方式。很多连接失败问题来自安全组没放行 6379，或者客户端误连只读节点。

六、不同业务场景下的配置建议

如果当前还是单台 ECS 风格的服务器思路迁移到 AWS，建议不要一步做得过重。先把单机应用模板化，再逐步加负载均衡、自动扩缩容、蓝绿部署。

七、实施时最容易卡住的故障与处理方法

1. Stack 创建失败

先看 CloudFormation Events，不要只看“Create failed”结果。常见原因包括：

• IAM Role 权限不够，无法创建实例配置文件
• 子网可用 IP 不足
• 安全组引用了错误的 VPC
• RDS 子网组不满足多可用区要求

2. EC2 创建成功但 SSH 连接不上

依次检查：

• 实例是否绑定公网 IP，或是否通过堡垒机/VPN 进入私网
• 安全组是否放行 22 端口且来源 IP 正确
• 操作系统防火墙是否拦截
• 密钥对是否匹配
• 亚马逊云32核账号 是否应改用 SSM Session Manager

3. Windows RDP 无法连接

先确认 3389 安全组规则，再查看系统初始化是否完成。如果通过模板创建后立刻取密码，可能实例尚未完成启动。建议等待状态检查通过后再连接。

4. 发布成功但网站打不开

亚马逊云32核账号 这类问题通常发生在应用层，而不是流水线本身。重点检查：

• ALB Target Group 健康检查路径是否正确
• Nginx 或 IIS 是否监听预期端口
• 安全组是否只放行 ALB 到 EC2 的入站流量
• DNS 是否已解析到正确的负载均衡地址
• SSL 证书是否绑定到 HTTPS 监听器

5. 数据库迁移后性能下降

优先对比迁移前后以下指标：CPU、FreeableMemory、ReadIOPS、WriteLatency、DatabaseConnections。很多时候问题出在实例规格过小、参数组未同步、索引缺失或应用连接池配置变化。

八、上线后还需要做的优化，不然自动化只是“能用”

1. 安全优化

• 禁用长期静态密钥，流水线优先用 IAM Role。
• Secrets 放入 Secrets Manager，不写在 buildspec 或 UserData 明文中。
• 服务器登录尽量走 SSM，减少暴露 SSH 和 RDP。
• 安全组按来源安全组授权，不按大网段长期开放。

2. 性能优化

• EC2 系统盘和高频数据盘使用 gp3，并按吞吐量需求单独调优。
• RDS 在高并发场景下先检查连接池和慢查询，不要只靠升配。
• 亚马逊云32核账号 跨地域访问明显变慢时，先做延迟测试，再决定是否拆分区域部署。
• 应用发布后必须有健康检查和基础压测，至少覆盖登录、首页、数据库读写。

3. 成本优化

• 测试环境通过计划任务在夜间停止非必须 EC2。
• 旧版本快照和无挂载 EBS 定期清理。
• 日志保留周期分级设置，避免 CloudWatch 成本持续增长。
• 对稳定负载使用 Savings Plans 或预留实例。

4. 稳定性优化

• 每次发布前自动创建快照或保留手动恢复点。
• 生产发布采用分批部署，避免一次替换全部实例。
• 亚马逊云32核账号 数据库参数调整前先在测试环境回放典型流量。
• 定期演练系统重装、实例替换、RDS 恢复和 DNS 切换。

真正可持续的 AWS 基础设施自动化，不是把控制台点击动作换成脚本，而是让网络、服务器、数据库、权限、发布、备份和回滚成为同一条可重复执行的链路。对大多数团队来说，最优路径不是一次性重构全部，而是先把最容易出错的资源创建和发布流程固化，再逐步补齐数据库变更、审批、监控和成本治理。这样才能从“手动运维”真正走到“持续交付”。