EC2 T3实例通过Auto Scaling扩容后，公网IP是否与初始实例一致？

核心问题解答 #

扩容生成的新EC2实例不会与初始实例使用相同的公网IP。每台EC2实例启动后会被分配独立的公网IP（默认随机生成），Auto Scaling Group（ASG）自动创建的实例也遵循这个规则，无法共享同一公网IP。

关键问题与解决方案 #

直接用实例公网IP对外服务的话，扩容后多个IP无法统一流量入口，用户无法通过单一地址访问所有实例来分流高峰流量，必须搭配以下方案解决：

1. 部署Application Load Balancer（ALB）作为统一入口
   • 创建ALB，它会提供一个固定的访问域名（也可配置静态弹性IP），作为用户访问的唯一入口。
   • 将ASG内的所有EC2实例注册到ALB的目标组，ALB会自动将流量均匀分发给健康的后端实例，实现负载均衡。
2. 调整WordPress部署架构
   • 将WordPress的站点URL修改为ALB的域名（或你的自定义域名，需将域名解析指向ALB），禁止使用单个实例的IP。
   • 替换EC2本地数据库为AWS RDS（关系型数据库服务），确保多台实例共享同一数据库，避免内容不一致。
   • 将WordPress的静态资源（图片、CSS、JS等）迁移至S3存储桶，搭配CloudFront CDN加速，减轻EC2实例负载并提升全球访问速度。
3. 优化ASG与实例配置
   • 通过启动模板确保所有实例的配置完全一致：包括Ubuntu系统版本、WordPress安装包、插件、环境变量等，避免实例间差异引发问题。
   • 配置基于指标的自动扩容策略，比如CPU使用率超过70%时自动新增实例，低于30%时缩减，无需手动调整。
   • 为实例绑定IAM角色，授予访问RDS、S3等服务的权限，避免在WordPress配置中硬编码凭证，提升安全性。
4. 弹性IP的正确用法
   • 不要给每个EC2实例分配弹性IP，而是将弹性IP绑定到ALB上，这样用户始终通过固定IP访问，后端实例的IP变化不会影响服务可用性。

额外注意事项 #

• 配置ALB和ASG的健康检查规则，ASG会自动替换不健康的实例，ALB也会停止向异常实例转发流量，保障服务稳定性。
• 确保EC2实例所在的安全组允许ALB的流量进入（通常开放80/443端口），同时允许实例访问RDS、S3等依赖服务的端口。

内容的提问来源于stack exchange，提问作者delta protocol