AWS CloudFormation可扩展EC2架构问题及Fn::GetAtt错误排查

一、模板错误修复 #

你遇到的Fn::GetAtt references undefined resource ELBSecurityGroup错误，核心原因是资源名称不匹配：
你定义的ELB安全组名称是ELBSecGrp，但在LoadBal资源的SecurityGroups字段里错误引用了不存在的ELBSecurityGroup。

关键修正点： #

1. 修正ELB安全组引用
   将LoadBal中的：

   SecurityGroups:
     - !GetAtt ELBSecurityGroup.GroupId
   

   改为：

   SecurityGroups:
     - !GetAtt ELBSecGrp.GroupId
   

   或直接用!Ref ELBSecGrp（CloudFormation支持直接引用安全组ID）。

2. 其他隐藏错误修正

   • SubRoute1中引用了未定义的PublicSubnet1，应改为!Ref Subnet1；
   • AGate中InternetGatewayId引用了未定义的InternetGateway，应改为!Ref IGateway；
   • EC2SecGrp的SecurityGroupIngress格式错误，SourceSecurityGroupId需作为规则字段嵌入，正确写法：

     SecurityGroupIngress:
       - IpProtocol: tcp
         FromPort: 80
         ToPort: 80
         SourceSecurityGroupId: !Ref ELBSecGrp # 允许ELB访问EC2的80端口
       - IpProtocol: tcp
         FromPort: 22
         ToPort: 22
         CidrIp: 10.0.0.333/24
     

   • S3BuckPol中SecurityGroupIds和KeyName是无效属性，直接删除；
   • MyRDS中的KeyName属性无效（RDS不需要密钥对），删除该字段；
   • 若要将EC2部署到Subnet2，将EC2的SubnetId改为!Ref Subnet2。

二、架构设计合理性分析 #

1. EC2部署在Subnet2的合理性 #

Subnet2是公网子网（MapPublicIpOnLaunch: true），若EC2需直接暴露公网，该设计可行，但不符合生产级可扩展架构的最佳实践：

• 推荐将EC2放在私有子网（如Subnet1），仅让ELB在公网子网接收流量，EC2通过NAT网关访问外网（用于更新、拉取资源），可大幅降低攻击面。
• 测试场景可临时将EC2放在公网子网，生产环境建议私有子网+堡垒机的SSH访问模式。

2. ELB是否需要关联所有子网 #

对于internet-facing的ELB，必须关联多可用区的公网子网以实现高可用：

• 若Subnet1是私有子网，不能关联到ELB（ELB需要公网IP接收外部流量）；
• 若Subnet1和Subnet2属于不同可用区的公网子网，建议全部关联，这样单个可用区故障时，ELB可自动切换到正常可用区，保证服务连续性；
• ELB必须绑定应用监听器（如你定义的ALBListen），这部分设计是正确的。

3. EC2安全组与RDS、S3关联的合理性 #

• RDS关联EC2安全组：合理，但建议优化权限粒度：
  创建独立的RDS安全组，仅允许EC2安全组访问RDS的3306端口（MySQL默认端口），而非直接将EC2安全组赋值给RDS，后续调整权限更灵活。
• S3与EC2安全组关联：不合理，S3是全局服务，安全组是VPC层面的网络控制，两者无直接关联。正确做法是：
  给EC2实例附加IAM角色，授予该角色访问S3桶的权限，优先用IAM角色实现实例级S3访问控制，桶策略适合跨账号或公开访问场景。

4. 是否需要为每个子网/EC2分别关联安全组 #

不需要：

• 安全组是状态化防火墙规则，可复用，多个EC2实例只要规则需求一致，即可共享同一个安全组；
• 子网无需关联安全组，安全组直接绑定到EC2、RDS等资源，子网的网络控制通过路由表和NACL实现。

内容的提问来源于stack exchange，提问作者Data Science Analytics Manager