把Tomcat应用搬上AWS：一个工程师的完整踩坑记录

周三下午三点，一位后端工程师盯着屏幕上的报错发呆。他的Tomcat应用已经在本地跑了五年，现在老板要求两周内上云。没有Kubernetes经验，没有运维团队，只有AWS账号和一个Deadline。

这不是个例。大量企业仍在维护 legacy 的Java Web应用，而ECS Fargate（弹性容器服务无服务器模式）成了最现实的迁移路径——不用管服务器，按实际运行时间付费，失败的任务自动重启。但路径清晰不代表路好走，session丢失、数据库连接池爆炸、安全组配错导致服务不可达，每个坑都足够消耗一个周末。

本文基于一个完整的生产级迁移案例，拆解从架构设计到最终上线的关键步骤。目标读者很明确：正在或即将把Tomcat应用迁往AWS的开发者，以及对ECS Fargate尚不熟悉的基础设施工程师。

最终架构长这样：互联网流量经ALB（应用负载均衡器）进入，分发到Fargate容器；session数据外置到ElastiCache（Redis），业务数据落盘RDS（PostgreSQL）。容器本身无状态，随时可以被替换而不影响用户体验。

第一步：安全组，最小权限原则

安全组是AWS的虚拟防火墙，规则配错等于大门敞开。四个组件各需独立安全组：

• ALB安全组：仅开放80/443端口，来源0.0.0.0/0（互联网）

• ECS安全组：仅开放8080端口，来源限定为ALB安全组

• Redis安全组：仅开放6379端口，来源限定为ECS安全组

• RDS安全组：仅开放5432端口，来源限定为ECS安全组

关键代码片段：创建ECS安全组并授权ALB入站

aws ec2 create-security-group \

--group-name sg-ecs \

--description "ECS SG" \

--vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \

--group-id sg-ecs --protocol tcp --port 8080 \

--source-group sg-alb

注意source-group参数——这是安全组引用安全组的写法，比写死IP更灵活，容器扩缩容时无需改规则。

第二步：凭证管理，拒绝硬编码

数据库密码、Redis密码绝不进入代码仓库或任务定义文件。AWS Secrets Manager（密钥管理服务）是标准解法：

aws secretsmanager create-secret \

--name myapp/db-password \

--secret-string "your-db-password"

容器启动时通过IAM角色动态获取密钥，内存中不落盘，轮换密钥时无需重新部署。

第三步：RDS配置，多可用区是底线

生产环境的数据库必须开multi-az（多可用区部署）。单点故障时AWS自动 failover，RPO（恢复点目标）理论上为零。实例类型选db.t4g.small，Graviton2架构性价比显著高于x86同类。

关键参数：--no-publicly-accessible。RDS实例不分配公网IP，所有访问走私有子网，即使密钥泄露也无法从互联网直接连接。

第四步：Session外置，Fargate的核心前提

这是最容易被忽视的一点。传统Tomcat把session存在内存，Fargate的任务重启意味着session全丢——而Fargate的任务重启比你想象的更频繁：部署新版本、底层主机维护、内存超限被OOM killer干掉。

解决方案是ElastiCache Redis作为session store。Tomcat配置context.xml，替换默认的StandardManager为Redis-backed实现。用户感知不到容器在后台被替换，购物车、登录状态全部保留。

架构图示意：互联网 → ALB(80/443) → ECS Fargate → ElastiCache(Redis/session) + RDS(PostgreSQL/数据)

至此，基础架构就绪。下一步是容器化改造、任务定义编写、以及Auto Scaling策略——但那是另一个故事了。