ALB、Route 53、S3、CloudWatch 落地
一旦应用不再只是"一台机器一个 IP"，你就需要四个能力：域名解析、负载均衡入口、对象存储备份、云监控观测。AWS 对应的服务是 Route 53、ALB、S3、CloudWatch。
AWS 运维组件图
graph TD
A[用户请求] --> B[Route 53 DNS]
B --> C[ALB 负载均衡]
C --> D[EC2 应用]
D --> E[S3 备份存储]
D --> F[CloudWatch 日志与指标]
F --> G[告警通知 SNS]
这些服务分别替代了什么
| 运维任务 | 传统做法 | AWS 服务 | 关键优势 |
|---|---|---|---|
| DNS 解析 | 域名注册商自带 DNS | Route 53 | 低延迟、健康检查路由 |
| 负载均衡入口 | Nginx upstream | ALB | 自动 TLS 终止、按路径路由 |
| 文件备份存储 | 本机或 NAS | S3 | 99.999999999% 耐久性、版本控制 |
| 日志与指标 | journald + 自建 | CloudWatch | 统一查询、设置告警阈值 |
关键配置命令
# 将域名 NS 指向 Route 53 托管区（先在控制台创建 Hosted Zone，获取 NS 记录）
aws route53 create-hosted-zone \
--name myapp.com \
--caller-reference "$(date +%s)"
# 把备份文件上传到 S3
aws s3 cp /var/backups/myapp_$(date +%Y%m%d).tar.gz \
s3://myapp-backups/daily/
# 为 EC2 实例启用 CloudWatch Agent（收集内存、磁盘等非默认指标）
sudo apt install -y amazon-cloudwatch-agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
# 创建简单 CPU 告警（超 80% 触发 SNS 通知）
aws cloudwatch put-metric-alarm \
--alarm-name high-cpu \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=InstanceId,Value=i-xxxxxxxxxxxxxxxxx \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:myapp-alerts
常见误区
- 以为 ALB 会自动续签证书：需要配合 ACM（Certificate Manager）颁发证书，ALB 本身不管证书生命周期
- 把应用日志直接写进 S3：S3 适合存归档文件；实时日志应先写本地，再用 CloudWatch Agent 或 Fluentd 推送
- CloudWatch 默认指标足够用：EC2 默认只收集 CPU/网络/磁盘 I/O；内存和磁盘使用率需要安装 CloudWatch Agent 才有
本节执行清单
- [ ] 在 Route 53 创建 Hosted Zone，把域名 NS 改指向 AWS
- [ ] 用 ACM 申请 TLS 证书，绑定到 ALB
- [ ] 把每日备份脚本改为上传到 S3，设置 30 天生命周期自动删除
- [ ] 安装 CloudWatch Agent，确认内存和磁盘指标出现在控制台
- [ ] 为 CPU > 80% 和磁盘 > 85% 各建一条告警
下一节：Ubuntu 应用在 AWS 上的部署与排错——把 AWS 组件串成一次完整交付。