公私网分离的核心是暴露面控制：公网流量仅经ALB/Nginx/Cloudflare等七层代理且只开放80/443；应用服务器部署于私有子网，禁用IGW直连；数据库等敏感组件置于无NAT的深层子网，仅允许可信子网指定端口访问。

公网与私网规划不是配IP、开端口那么简单，而是整套生产环境稳定性和安全性的起点。真正出问题的，往往不是服务器宕了，而是网络边界模糊、访问路径混乱、权限层层叠加却没人理清——比如数据库被扫到3306端口、API网关误绑了公网IP、测试环境和生产共用一个子网导致配置污染。

公私网分离的核心逻辑：从暴露面控制入手

所有设计都围绕一个目标：让公网流量只经过它“必须经过”的节点，其余服务一律不感知互联网存在。

• 对外入口只保留ALB/Nginx/Cloudflare等七层代理，且仅开放80/443；其他端口（如22、3306、6379）在安全组层面彻底禁止公网入向
• 应用服务器全部部署在私有子网，路由表默认不指向互联网网关（IGW），仅通过NAT网关回源（如下载依赖、调用第三方API）
• 数据库、缓存、消息队列等敏感组件，放在更深层的私有子网，连NAT网关都不允许访问，只接受来自应用子网的指定端口通信

子网划分与VPC拓扑设计实操要点

一个标准生产VPC至少需要4个子网：2个公有子网（跨AZ）、2个私有子网（跨AZ）。不推荐“一个子网打天下”，否则扩缩容、故障隔离、合规审计全受影响。

• 公有子网只放ALB、跳板机、CI/CD构建节点；它们有IGW路由，但安全组严格限制来源IP（例如跳板机只允许可信办公IP段）
• 私有子网分层：前端应用子网（可访问NAT）、后端数据子网（无NAT路由，仅允许前端子网CIDR+指定端口入向）
• 地址规划留余量：建议使用/16 VPC网段（如10.10.0.0/16），每个子网按/24划分，避免后期扩容时地址不够或需重叠迁移

安全组与ACL协同使用的典型场景

安全组是实例级防火墙，ACL是子网级状态无关过滤器。两者不是替代关系，而是分层兜底。

• 安全组做精细控制：例如数据库安全组只允许来自应用子网的10.10.10.0/24 + 3306端口，拒绝所有其他来源
• ACL做兜底防御：在私有子网ACL中，显式拒绝0.0.0.0/0对3306、6379、27017等高危端口的入向请求，哪怕某台EC2误配了宽松安全组也不会被爆破
• 注意ACL是无状态的：入向规则拒绝后，出向响应包也会被拦，所以拒绝规则要配对（如拒绝入向22，也要拒绝对应出向22）

生产环境中容易踩坑的几个细节

很多架构图看着完美，一上生产就翻车，问题常出在边界模糊、路径绕行、权限冗余这三类地方。

• 不要让任何业务服务器直接绑定EIP：即便临时调试，也要走ALB或堡垒机跳转；EIP只应绑定在负载均衡器或NAT网关上
• 避免跨子网直连：比如前端子网里的服务直接调用后端子网数据库——看似能通，实则绕过ACL、难审计、无法限流，应统一走内部API网关或服务网格
• 日志与监控节点要单独规划：它们需要同时访问应用、数据库、NAT出口流量，建议放在独立管理子网，安全组按需授权，不混入业务流