AWS账号批发 AWS 三层架构实战教程：从 0 搭建安全、稳定、可扩展的云端应用

很多用户搜索“AWS 三层架构实战”，并不是想看三层架构是什么，而是想尽快把业务跑起来，并且避免上线后出现公网暴露过多、数据库被误访问、负载均衡转发异常、实例扩容后应用不可用、RDS 连接失败等问题。真正影响决策的，往往不是是否采用三层架构，而是：应该怎么分子网、哪些资源必须放私网、如何控制访问路径、预算要多少、后续扩容是否会重做架构。

下面这篇教程按真实部署流程展开，默认场景为一个典型 Web 应用：用户通过 HTTPS 访问网站，请求先到负载均衡，再进入应用服务器，最后访问 MySQL 数据库。所有步骤都围绕“能落地、可排错、便于后续扩容”来写。

一、用户在部署 AWS 三层架构时最关心的决策点

如果你正在评估是否按三层架构在 AWS 上部署应用，通常最关心的是以下几件事：

• 公网访问应该只暴露负载均衡，还是 EC2 也要有公网 IP。
• 应用层和数据库层是否必须放在私有子网。
• 两台应用服务器是否要跨可用区部署，成本是否明显增加。
• RDS 该选单可用区还是 Multi-AZ，什么场景值得开。
• 如果后续访问量上涨，扩容是加实例还是升级数据库规格。
• 出现 502、504、数据库连接超时后，从哪里开始排查。

先给出适合大多数生产环境的结论：

二、开始操作前的准备工作

1. 账号与权限要求

建议使用具备以下权限的 IAM 用户或角色，而不是根账号直接操作：

• AmazonVPCFullAccess
• AmazonEC2FullAccess
• ElasticLoadBalancingFullAccess
• AutoScalingFullAccess
• AWS账号批发 AmazonRDSFullAccess
• IAMReadOnlyAccess
• AmazonSSMManagedInstanceCore（如需 SSM 管理实例）

如果是企业账号，建议提前确认 Service Control Policy 是否限制了 NAT Gateway、RDS 或证书服务的创建。

2. 建议提前准备的资源

AWS账号批发 3. 建议的网段规划

不要在创建时随意填 CIDR，后期扩展会很麻烦。一个常见可用方案如下：

三、步骤一：先把网络打好，避免后面反复返工

1. 创建 VPC 与子网

进入 AWS Console，打开 VPC 控制台，点击“Create VPC”。

建议填写：

创建完成后继续创建 6 个子网，分别放到 2 个可用区。子网名称建议明确标记用途，例如：

• pub-a / pub-b
• app-a / app-b
• db-a / db-b

注意：只有公有子网需要自动分配公网 IP；应用子网和数据库子网不要开启该选项。

2. 配置互联网出口与路由

接着创建 Internet Gateway，并挂载到当前 VPC。然后创建一个公有路由表，添加默认路由：

把 pub-a 和 pub-b 这两个子网关联到公有路由表。

之后创建 NAT Gateway。实际操作中，很多人为了省钱只建一个 NAT Gateway，这样没问题，但要明确：如果该可用区故障，私网实例出网会受影响。生产环境可按可用区各建一个，测试环境可以先只建一个。

创建 NAT 后，再分别创建应用层私有路由表和数据库层私有路由表，默认路由指向 NAT Gateway。这样私网资源可以访问外部仓库、补丁源或第三方 API，但不会被公网直接访问。

3. 先把安全组规划好，不要后补

建议按层拆分安全组，而不是所有实例共用一个安全组。

很多部署失败都不是应用本身的问题，而是安全组写成了“允许 3306 来自公司公网 IP”，结果 Auto Scaling 扩容出的应用实例无法连接数据库。正确做法是：数据库安全组来源写应用安全组 ID。

四、步骤二：部署 Web/应用层，配置 ALB 与 Auto Scaling

1. 创建启动模板

进入 EC2 控制台，点击“Launch Templates”创建模板。这里决定后续扩容出来的机器是否一致。

用户数据脚本可以提前写入，用于自动部署 Nginx 和应用。例如：

<pre>#!/bin/bash yum update -y yum install -y nginx systemctl enable nginx systemctl start nginx echo 'ok' > /usr/share/nginx/html/health</pre>

这里至少要准备一个健康检查路径，如 /health，后面 ALB 会用到。

2. 创建目标组和应用负载均衡器

进入 EC2 控制台的 Target Groups，点击“Create target group”。

建议配置：

接着创建 Application Load Balancer：

• Scheme 选择 Internet-facing
• 子网选择两个公有子网
• 安全组选择 alb-sg
• 监听器先配置 80，后续再加 443
• 默认转发到刚创建的目标组

一个常见错误是：ALB 创建在公有子网，但应用实例也放在公有子网并绑定公网 IP。这样虽然能用，但三层隔离基本失效。建议应用实例全部留在私有子网。

3. 创建 Auto Scaling Group

进入 Auto Scaling Groups，点击“Create Auto Scaling group”。

关键设置如下：

扩缩容策略可先用目标跟踪：

• 平均 CPU 维持在 50%
• 实例预热时间 120-180 秒

如果应用启动较慢，不要把健康检查宽限期设得太短，否则实例刚启动就被判失败，然后反复替换。

五、步骤三：创建 RDS 数据库并限制访问范围

AWS账号批发 1. 创建数据库子网组

进入 RDS 控制台，先创建 DB Subnet Group，把 db-a 和 db-b 两个数据库子网加进去。没有这一步，后续数据库无法正确部署到私网多子网环境。

2. 创建 MySQL 实例

点击“Create database”，选择 Standard create。

数据库用户名建议不要用 root、admin 这类默认值。创建后先记下 endpoint，不要把数据库 IP 写死到应用配置里，后续故障切换可能会变更底层 IP。

3. 初始化权限与连接测试

从应用服务器测试数据库连接：

<pre>mysql -h your-db-endpoint.rds.amazonaws.com -u appuser -p</pre>

如果连不上，优先检查这 4 项：

• AWS账号批发 RDS 是否在 available 状态。
• db-sg 是否允许来自 app-sg 的 3306。
• AWS账号批发 应用实例是否真的挂载了 app-sg。
• AWS账号批发 网络 ACL 是否误拦截了 3306 或临时端口。

AWS账号批发 建议创建最小权限账号，而不是让应用直接用高权限用户：

AWS账号批发 <pre>CREATE USER 'appuser'@'%' IDENTIFIED BY 'StrongPassword'; GRANT SELECT,INSERT,UPDATE,DELETE,EXECUTE ON appdb.* TO 'appuser'@'%'; FLUSH PRIVILEGES;</pre>

六、步骤四：配置 HTTPS、DNS、日志与备份

1. 给 ALB 绑定 HTTPS

进入 ACM 申请证书，验证域名后，在 ALB 监听器中新增 443。操作路径为：EC2 控制台 > Load Balancers > 选择 ALB > Listeners and rules。

配置时：

• Protocol 选择 HTTPS
• 证书选择 ACM 已签发证书
• 默认动作转发到应用目标组

然后把 80 端口设置为重定向到 443，避免用户继续访问明文 HTTP。

2. 域名解析

在 Route 53 或第三方 DNS 平台中，把业务域名用 CNAME 或 Alias 解析到 ALB 域名。不要解析到 EC2 实例 IP，否则后续扩容、替换实例后会失效。

3. 日志与备份

至少启用以下日志：

备份方面，RDS 自动备份建议至少保留 7 天，业务关键库可保留 14-35 天。EC2 若存有上传文件，建议把文件迁移到 S3，不要依赖单机磁盘。

七、不同场景下的配置建议

八、上线后最容易遇到的故障与处理方法

1. ALB 返回 502 Bad Gateway

优先检查应用实例是否真正监听了目标组端口。例如目标组设的是 80，但应用只监听 8080。其次检查健康检查路径是否返回 200，而不是 301、403 或 500。

2. 浏览器访问超时，但实例状态正常

重点看 ALB 安全组和子网是否正确。很多情况是 ALB 在公有子网，但公有子网路由表没有指向 Internet Gateway；或者 443 没有放通。

3. 数据库连接失败

最常见原因不是账号密码错，而是安全组引用错误。确认 db-sg 的来源是 app-sg，不是某个固定私网 IP。Auto Scaling 场景下，固定 IP 策略基本不可维护。

4. 扩容后新实例一直 Unhealthy

通常是用户数据脚本执行慢、应用依赖未安装完成、健康检查宽限时间过短，或者新实例没有权限读取配置文件、Secrets Manager 参数。可以登录实例查看：

<pre>systemctl status nginx journalctl -xe curl -I http://localhost/health</pre>

5. 应用能访问首页，但上传或登录失败

这通常意味着应用实例是无状态设计不完整。会话数据、上传文件、缓存如果保存在本地磁盘，流量切到另一台实例就会出现异常。解决方法通常是：

• Session 存 Redis
• 上传文件存 S3
• 多实例共享配置放 Parameter Store 或 Secrets Manager

九、优化建议：从安全、性能、成本、稳定性四个方向处理

1. 安全优化

• 应用实例不要分配公网 IP。
• 优先用 SSM Session Manager 代替开放 22 端口。
• 数据库不开放公网访问。
• HTTPS 强制跳转，证书集中在 ACM 管理。
• 敏感配置不要写死在用户数据脚本里，改用 Secrets Manager。

2. 性能优化

• ALB 健康检查路径尽量轻量，不要访问数据库。
• RDS 存储使用 gp3，按实际 IOPS 调整。
• 静态资源交给 CloudFront 或 S3，减少应用层带宽压力。
• 应用层启用连接池，避免每次请求新建数据库连接。

3. 成本优化

• 测试环境可先单 NAT Gateway，但生产环境再考虑双 NAT。
• 应用实例先从 t3.small/t3.medium 起步，通过 CloudWatch 观察再升级。
• RDS 存储不要一次性开过大，但自动扩容建议开启。
• 非生产环境设置自动关停策略，减少闲置实例费用。

4. 稳定性优化

• 应用最少部署 2 台，跨 2 个可用区。
• RDS 生产建议开启 Multi-AZ。
• 对 CPU、内存、HTTP 5xx、Target Unhealthy Host Count 设置告警。
• 关键版本发布前先在新目标组做灰度，再切换流量。

如果你的目标是“先上线，再逐步扩展”，最稳妥的落地路径是：先完成 VPC 分层、ALB 私网应用层、RDS 私网数据库这三件核心事，再补 HTTPS、日志、监控和自动扩容。这样即使业务后续需要加 Redis、队列、读副本或 CDN，也不需要推翻现有网络结构。