如何配置AWS VPC入站规则，仅允许ALB及指定IP访问Fargate容器服务

核心逻辑：服务级的精细化访问控制优先交给Security Group实现，Network ACL仅作为子网层面的兜底拦截，之前操作阻断ALB连接的核心原因是错将NACL作为精细化管控的首选，没有理清两类控制机制的差异。

为什么之前修改NACL会阻断ALB正常连接 #

• Network ACL是子网级的无状态访问控制，规则会覆盖子网内所有资源的进出流量，没有和具体弹性网卡/安全组的关联校验能力。
• 当你直接在NACL上添加指定IP的放行规则、删除原有的同子网流量放行规则时，ALB发往Fargate任务的子网内私有IP流量会被默认的拒绝规则拦截，自然会中断正常连接。
• 加上NACL的无状态特性，即便只配置了入站放行，没有匹配的出站响应规则，同样会出现连接失败的问题，极不适合做服务的细粒度访问管控。

具体落地配置步骤 #

• 拆分独立的安全组，不要将ALB和Fargate任务绑定在同一个安全组上，从根源上避免配置混乱
  • 为ALB单独创建安全组：入站规则仅放行公开访问所需的80/443端口流量，来源根据ALB的公网属性配置（公网ALB可放行0.0.0.0/0，内网ALB可按需限制来源），出站规则保持默认全放行即可，保证ALB具备向后端转发流量的能力
  • 为所有Fargate服务任务单独创建安全组：删除默认的0.0.0.0/0全放行入站规则，仅添加两条入站规则：
    1. 放行来源为ALB所属安全组、目标端口为你服务实际监听的业务端口的流量 —— 该规则可允许ALB正常将请求转发到Fargate任务，依托安全组的状态匹配机制，不需要额外配置出站规则即可自动放行响应流量
    2. 放行来源为预先指定的IP地址列表、目标端口为对应业务端口的流量 —— 该规则可实现指定IP绕过ALB直接访问服务的需求
• 子网层NACL仅做兜底配置：
  • 保证入站规则中，在默认拒绝规则之前，先放行ALB与Fargate任务所在子网的私有IP段的对应业务端口流量
  • 放行指定直连IP段的对应业务端口入站流量
  • 同步在出站规则中放行对应业务端口的响应流量（因NACL为无状态机制，需显式配置），保证请求的回包可以正常发出

常见避坑提醒 #

• 不要让ALB和Fargate任务共用同一个安全组，共用场景下很容易因规则误配，直接将后端服务的端口暴露到公网
• 直连指定IP的流量是直接访问Fargate任务的，不需要经过ALB的安全组校验，不需要在ALB的安全组中添加这类IP的放行规则
• 调整规则后可通过VPC Reachability Analyzer校验流量路径，确认ALB到Fargate任务、指定IP到Fargate任务的路径是连通的

内容的提问来源于stack exchange，提问作者Jan Buchar