architecting-networks

网络架构

使用 AWS、GCP 和 Azure 上经过验证的模式，设计安全、可扩展的云网络架构。本技能提供 VPC 设计、子网策略、零信任实施和混合连接的决策框架。

何时使用本技能

在以下情况下调用本技能：

• 为新的云环境设计 VPC/VNet 拓扑
• 实施网络分段和安全控制
• 规划多 VPC 或多云连接
• 建立混合云连接（本地环境到云端）
• 从扁平网络迁移到复杂架构
• 实施零信任网络原则
• 优化网络成本和性能

核心网络架构模式

模式 1：扁平（单 VPC）架构

适用场景： 小型应用、单一环境、简单的安全需求、工程师少于 10 人

特点：

• 所有资源都位于一个 VPC 中，通过子网级别进行分段
• 公有、私有和数据库子网层
• 最容易理解和管理
• 无 VPC 间路由复杂性

权衡：

• ✓ 成本最低，设置最快
• ✗ 隔离性差，难以扩展，整个 VPC 都处于爆炸半径内

模式 2：多 VPC（隔离）架构

适用场景： 多个环境（开发/预发布/生产）、严格的隔离要求、合规性强制要求分离

特点：

• 每个环境或工作负载使用单独的 VPC
• 未经明确配置时，无法直接连接
• CIDR 范围相互独立

权衡：

• ✓ 有效限制爆炸半径，安全边界清晰
• ✗ 管理开销大、基础设施重复、成本更高

模式 3：中心辐射式（Transit Gateway）架构

适用场景： 5 个以上 VPC 需要互通、需要集中式安全检查、需要混合连接、多账户设置

特点：

• 中心 Hub VPC/Transit Gateway
• Spoke VPC 连接到 Hub
• 所有 VPC 间流量都经由 Hub 路由

权衡：

• ✓ 路由简化、安全集中、易于扩展（100 个以上 VPC）
• ✗ Transit Gateway 成本（约 $0.05/小时 + $0.02/GB）、延迟增加（经过 Hub）

模式 4：全网状（VPC Peering）架构

适用场景： VPC 数量较少（少于 5 个）、低延迟至关重要、无需集中式检查

特点：

• 每个 VPC 都通过对等连接直接相连
• VPC 间直接通信

权衡：

• ✓ 延迟最低，无 Transit Gateway 成本
• ✗ 管理复杂性按 O(n²) 增长，超过约 10 个 VPC 后难以扩展

模式 5：混合（多模式）架构

适用场景： 需求多样的大型企业，需平衡成本、性能和安全性

特点：

• 大多数 VPC 使用中心辐射式架构 + 对延迟敏感的 VPC 对使用直接对等连接
• 根据工作负载需求组合使用

权衡：

• ✓ 针对特定需求进行优化
• ✗ 设计和管理更加复杂

模式选择框架

Number of VPCs?
│
├─► 1 VPC → Flat (Single VPC)
├─► 2-4 VPCs + No inter-VPC communication → Multi-VPC (Isolated)
├─► 2-5 VPCs + Low latency critical → Full Mesh (VPC Peering)
├─► 5+ VPCs + Centralized inspection → Hub-and-Spoke (Transit Gateway)
└─► 10+ VPCs + Mixed requirements → Hybrid (Multi-Pattern)

Additional Considerations:
├─► Hybrid connectivity required? → Hub-and-Spoke preferred
├─► Centralized egress/inspection? → Hub-and-Spoke with Inspection VPC
├─► Multi-account environment? → Hub-and-Spoke with AWS RAM sharing
└─► Cost optimization priority? → Flat or Multi-VPC (avoid TGW fees)

子网策略

标准三层设计

公有子网：

• 路由到 Internet Gateway
• 用于负载均衡器、堡垒主机、NAT Gateway
• CIDR：/24 至 /27（256 至 32 个 IP）

私有子网：

• 出站流量路由到 NAT Gateway
• 用于应用服务器、容器、计算工作负载
• CIDR：/20 至 /22（4,096 至 1,024 个 IP）

数据库子网：

• 无直接互联网路由
• 用于 RDS、ElastiCache、托管数据库
• CIDR：/24 至 /26（256 至 64 个 IP）

多 AZ 分布

生产环境： 每一层至少分布在 3 个可用区 开发/测试环境： 为节省成本，可接受使用 1 至 2 个 AZ

CIDR 块规划

VPC 大小：

• /16（65,536 个 IP）— 大型生产环境
• /20（4,096 个 IP）— 中型环境
• /24（256 个 IP）— 小型/开发环境

关键规则：

• 各 VPC 的 CIDR 范围不得重叠
• 混合连接需与本地网络团队协调
• 为未来扩展预留地址空间

有关详细的子网规划，请参阅 references/subnet-strategy.md

NAT Gateway 策略

决策框架

Cost vs Resilience?
│
├─► Cost Priority (Dev/Test)
│   └─► Single NAT Gateway (~$32/month)
│       └─► Risk: Single point of failure
│
├─► Balanced (Most Production)
│   └─► One NAT Gateway per AZ (~$96/month for 3 AZs)
│       └─► Resilience: AZ failure doesn't break connectivity
│
└─► Maximum Resilience
    └─► Multiple NAT Gateways per AZ + monitoring
        └─► Critical workloads, SLA-dependent

Alternative: Centralized Egress Pattern
└─► Hub-and-Spoke: Single egress VPC with NAT
    └─► Reduces NAT Gateway count, centralized logging

不需要访问外部互联网？

• 完全跳过 NAT Gateway（节省成本）
• 使用 VPC Endpoints 访问 AWS 服务

安全控制

安全组（推荐）

特点：

• 有状态（自动允许返回流量）
• 实例级控制
• 仅允许规则（隐式拒绝）
• 可以引用其他安全组

适用场景：

• 服务间通信
• 实例级安全
• 最常见的使用场景

最佳实践：

• 使用描述性名称（app-alb-sg、app-backend-sg）
• 引用其他安全组，而不是 CIDR 块
• 规则应尽可能精简、具体

网络 ACL（可选）

特点：

• 无状态（必须同时允许请求和响应）
• 子网级控制
• 允许和拒绝规则
• 按顺序处理规则（从编号最小的开始）

适用场景：

• 明确的拒绝规则（屏蔽特定 IP）
• 合规要求（纵深防御）
• 在安全组之外增加额外防护层

最佳实践：

• 谨慎使用（管理复杂）
• 记得允许临时端口（1024-65535）
• 充分测试（无状态特性容易导致问题）

安全组架构模式请参阅 references/security-controls.md

零信任原则

核心原则

1. 从不信任，始终验证

   • 无论请求来源如何，都要对每个请求进行身份验证
   • 不基于网络位置默认信任

2. 最小权限访问

   • 仅授予必要的最低权限
   • 限时访问（按需即时授予）

3. 假定已遭入侵

   • 积极进行网络分段
   • 监控所有流量
   • 快速检测并响应

实施模式

微分段：

• 使用细粒度安全组规则隔离每个工作负载
• 仅允许特定服务之间进行服务间通信
• 缩小影响范围

基于身份的访问：

• 使用 IAM 角色而不是 IP 地址进行授权
• 使用 IAM 策略配置 VPC Endpoints
• 验证服务间身份

持续验证：

• 使用 VPC Flow Logs 分析流量
• 监控被拒绝的连接
• 对异常情况发出警报

零信任架构模式请参阅 references/zero-trust-networking.md

混合连接

VPN（虚拟专用网络）

适用场景： 开发/测试环境、备用连接、临时连接

特点：

• 通过公共互联网建立加密隧道
• 吞吐量：每条隧道约 1.25 Gbps
• 延迟：不固定（取决于互联网）
• 成本：低（约 $0.05/小时 + 数据传输费用）
• 设置：快速（无需签订合同）

Direct Connect / ExpressRoute / Cloud Interconnect

适用场景： 生产工作负载、大量数据传输、实时应用

特点：

• 专用网络连接（绕过公共互联网）
• 吞吐量：最高 100 Gbps
• 延迟：低且稳定
• 成本：较高（端口费用 + 数据传输费用）
• 设置：较慢（需要签订合同并协调）

Transit Gateway + Direct Connect

适用场景： 多个 VPC 需要连接本地环境

优势：

• 通过单个 Direct Connect 连接 → Transit Gateway → 多个 VPC
• 成本高效且可扩展
• 集中管理混合连接

混合连接模式和示例请参阅 references/hybrid-connectivity.md

多云网络

各云服务提供商的统一概念

概念	AWS	GCP	Azure
虚拟网络	VPC	VPC	Virtual Network（VNet）
子网	子网（限定于 AZ）	子网（区域级）	子网
NAT	NAT Gateway	Cloud NAT	NAT Gateway
对等连接	VPC Peering	VPC Peering	VNet Peering
中心辐射式	Transit Gateway	Cloud Router	Virtual WAN
私有端点	PrivateLink	Private Service Connect	Private Link
混合 VPN	VPN	Cloud VPN	VPN Gateway
混合专用连接	Direct Connect	Cloud Interconnect	ExpressRoute

特定云服务提供商的最佳实践

AWS：

• 生产环境采用多可用区作为基线
• VPC 数量达到 5 个及以上时，优先使用 Transit Gateway
• 使用 VPC Endpoints 以避免 NAT 费用

GCP：

• 使用自定义模式 VPC（而非自动模式）
• 从单个 VPC 开始，多项目场景使用 Shared VPC
• 在子网级别授予网络用户角色

Azure：

• 将 Hub-and-Spoke 网络拓扑作为标准
• 使用少量大型 VNet，而不是大量小型 VNet
• 为 Azure 服务使用专用终结点

有关多云实现，请参阅 references/multi-cloud-networking.md

网络可观测性

VPC Flow Logs

为以下用途启用 Flow Logs：

• 流量分析和故障排查
• 安全监控（检测未授权访问）
• 按网络路径分摊成本
• 满足合规要求

配置：

• 流量类型：ALL（捕获已接受和已拒绝的流量）
• 聚合间隔：1-10 分钟
• 目标位置：CloudWatch Logs 或 S3

监控模式

监控：

• 被拒绝的连接（安全异常）
• 流量量激增
• 跨 VPC 通信模式
• NAT Gateway 使用情况

针对以下情况发出警报：

• 被拒绝的连接激增
• 异常流量模式
• 高额数据传输费用
• 网络错误

有关可观测性模式和流日志分析，请参阅 references/network-observability.md

成本优化

常见成本因素

1. NAT Gateway： $0.045/小时 + $0.045/GB 处理的数据
2. Transit Gateway： $0.05/小时/连接 + $0.02/GB
3. 数据传输： 出站费用因目标位置而异
4. VPN/Direct Connect： 端口费用 + 数据传输费用

优化策略

降低 NAT Gateway 成本：

• 对 AWS 服务（S3、DynamoDB）使用 VPC Endpoints
• 采用集中式出站流量 VPC 模式
• 开发/测试环境使用单个 NAT Gateway（接受可用性风险）

降低数据传输成本：

• 将流量限制在同一区域内
• 使用 VPC Endpoints，而非公共互联网
• 对大流量传输使用私有连接

避免 Transit Gateway 成本：

• VPC 数量较少（< 5）时使用 VPC Peering
• 对延迟敏感的连接对使用直接对等连接

有关详细的成本优化策略，请参阅 references/cost-optimization.md

实施工作流

步骤 1：分析需求

• 需要多少个 VPC/环境？
• 是否需要混合连接？
• 延迟要求是什么？
• 有哪些安全/合规要求？
• 预算限制是什么？

步骤 2：选择模式

使用上面的模式选择框架进行选择：

• 扁平、多 VPC、Hub-Spoke、网状或混合模式

步骤 3：设计子网

• 计算 CIDR 网段（确保互不重叠）
• 规划多可用区分布
• 确定公有/私有/数据库层级

步骤 4：配置安全性

• 设计安全组架构
• 规划微分段
• 如有需要，配置 Network ACL

步骤 5：使用 IaC 实施

使用 infrastructure-as-code 技能，通过 Terraform/Pulumi 实施

步骤 6：启用可观测性

• 配置 VPC Flow Logs
• 设置监控和警报
• 跟踪成本

快速参考

VPC 模式选择

需求	推荐模式
单个环境	扁平（单个 VPC）
多个隔离环境	多 VPC（隔离）
2-5 个 VPC，低延迟	全网状（Peering）
5 个及以上 VPC，集中式安全	Hub-and-Spoke（TGW）
混合连接	Hub-and-Spoke（TGW）
成本优化	扁平或多 VPC

NAT Gateway 配置

场景	配置	月度成本（3 个可用区）
开发/测试	单个 NAT	~$32
生产环境	每个可用区一个 NAT	~$96
集中式出站流量	Hub VPC NAT	~$32-96

混合连接

需求	解决方案	吞吐量	延迟
开发/测试	VPN	~1.25 Gbps	不定
生产环境	Direct Connect	最高 100 Gbps	低且稳定
备份	VPN（作为 DX 的备份）	~1.25 Gbps	不定

参考文档

详细指南：

• references/vpc-design-patterns.md - 包含图表的全面模式说明
• references/subnet-strategy.md - CIDR 规划、IPAM、多可用区最佳实践
• references/zero-trust-networking.md - 微分段、IAM 集成、持续验证
• references/hybrid-connectivity.md - VPN、Direct Connect、Transit Gateway 模式
• references/multi-cloud-networking.md - AWS、GCP、Azure 实现
• references/security-controls.md - 安全组、NACL、防火墙模式
• references/private-networking.md - VPC Endpoints、PrivateLink、Private Service Connect
• references/multi-region-networking.md - 跨区域对等连接、全球负载均衡
• references/network-observability.md - 流日志、监控、故障排查
• references/cost-optimization.md - 减少出口流量、NAT 策略

代码示例：

• examples/aws/ - AWS VPC 模式（扁平、中心辐射、对等连接、VPN、Direct Connect）
• examples/gcp/ - GCP VPC 模式（自定义 VPC、共享 VPC、Cloud Interconnect）
• examples/azure/ - Azure VNet 模式（中心辐射、对等连接、ExpressRoute）
• examples/multi-cloud/ - 跨云连接示例

实用脚本：

• scripts/cidr-calculator.py - 计算 CIDR 块并规划 IP 地址
• scripts/cost-estimator.sh - 估算网络基础设施成本
• scripts/validate-sg-rules.py - 验证安全组规则配置
• scripts/flow-log-analyzer.py - 分析 VPC 流日志中的安全和成本信息

与其他技能集成

使用 infrastructure-as-code 技能来：

• 使用 Terraform/Pulumi 实现网络架构
• 对网络配置进行版本控制
• 自动化网络预配

使用 kubernetes-operations 技能来：

• 在 VPC 设计基础上配置 Kubernetes 网络（CNI）
• 实现 Pod 网络和服务网格

使用 security-hardening 技能来：

• 实现防火墙规则和 WAF 配置
• 配置网络级 DDoS 防护
• 设置入侵检测系统

使用 observability 技能来：

• 实现全面的网络监控
• 设置跨网络边界的分布式追踪
• 配置性能仪表板

使用 disaster-recovery 技能来：

• 设计多区域故障转移网络
• 实现跨区域备份连接
• 规划网络恢复流程