AWS 全球多 Region + IDC 互联互通架构设计与实践
前言
在全球化业务场景中，企业往往需要在多个 AWS Region 部署应用，同时保持本地 IDC 与云端的连通性。本文将详细介绍一种基于 AWS Transit Gateway 的 Hub-Spoke 架构，实现 IDC + 6个 AWS Region 的全互联方案。
业务场景
目标： 实现以下网络互联需求
- IDC： 本地数据中心通过 Direct Connect 接入
- 6个 AWS Region： 爱尔兰、英国、新加坡、东京、巴西、香港
- 互联要求： 任意两点之间可达，统一管理，成本可控
架构设计
整体拓扑
采用 Hub-Spoke 星型架构，以香港 Region 作为全球网络枢纽：
HK (Hub)
│
┌──────┬───────┼───────┬──────┐
│ │ │ │ │
IE UK SG Tokyo Brazil
IDC ──── DX ──── HK拓扑说明：
- HK (Hub)： 香港 Region 作为全球网络中心，承担所有流量的路由转发
- 5个 Spoke： 爱尔兰、英国、新加坡、东京、巴西通过 TGW Peering 连接到 Hub
- IDC 接入： 本地数据中心通过 Direct Connect 专线连接到香港枢纽
- 流量路径： 所有跨 Region 和 IDC 通信都经过香港Hub中转, 便于统一监控和审计
架构特点
1. 成本优化
- 最少连接数： Hub-Spoke 模式只需 N-1 条连接
- 统一接入： IDC 只需一条 DX 线路
- 按需扩展： 新增 Region 成本线性增长
2. 管理简化
- 集中路由： 所有路由策略在 Hub 统一管理
- 故障隔离： Spoke 故障不影响其他 Region
- 监控统一： 流量监控集中在 Hub 节点
3. 性能保障
- 地理优势： 香港作为亚太枢纽，延迟适中
- 高带宽： 每个 AZ 支持最高 100Gbps
- 高可用： 支持多 AZ 部署和冗余链路
4. 安全合规
- 网络隔离： VPC 级别的安全边界
- 访问控制： 基于路由表的精细化控制
- 审计追踪： VPC Flow Logs 全链路监控
核心组件
| 组件 | 作用 | 部署位置 |
|---|---|---|
| Hub TGW | 全局路由中心 | ap-east-1 (香港) |
| Spoke TGW | 区域网络网关 | 其他5个 Region |
| DXGW | IDC 接入网关 | ap-east-1 (香港) |
| TGW Peering | 跨 Region 连接 | 5条连接线路 |
网络规划
# CIDR 分配策略
HK (Hub): 10.0.0.0/16 # 香港枢纽
IE (Spoke): 10.1.0.0/16 # 爱尔兰
UK (Spoke): 10.2.0.0/16 # 英国
SG (Spoke): 10.3.0.0/16 # 新加坡
Tokyo (Spoke): 10.4.0.0/16 # 东京
Brazil (Spoke): 10.5.0.0/16 # 巴西
IDC: 192.168.0.0/16 # 本地数据中心规划建议:
- CIDR 规划： 预留足够地址空间，避免冲突
- 路由优化： 使用汇总路由减少路由表条目
- 冗余设计： 关键链路配置备用连接
实施步骤
第一步：部署 Transit Gateway
# 1. 创建香港 Hub TGW
aws ec2 create-transit-gateway \
--description "Global-Hub-TGW" \
--options DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable \
--region ap-east-1
# 2. 批量创建 Spoke TGW
regions=("eu-west-1" "eu-west-2" "ap-southeast-1" "ap-northeast-1" "sa-east-1")
for region in "${regions[@]}"; do
aws ec2 create-transit-gateway \
--description "Spoke-TGW-${region}" \
--region ${region}
done
第二步：配置 Direct Connect
# 创建 Direct Connect Gateway
aws directconnect create-direct-connect-gateway \
--name "Global-DX-Gateway" \
--region ap-east-1
# 关联到香港 Hub TGW
aws ec2 create-transit-gateway-direct-connect-gateway-attachment \
--transit-gateway-id <hub-tgw-id> \
--direct-connect-gateway-id <dx-gateway-id> \
--region ap-east-1
第三步：建立 TGW Peering
# 从各 Spoke 向 Hub 发起 Peering
spoke_regions=("eu-west-1" "eu-west-2" "ap-southeast-1" "ap-northeast-1" "sa-east-1")
for region in "${spoke_regions[@]}"; do
aws ec2 create-transit-gateway-peering-attachment \
--transit-gateway-id <spoke-tgw-id> \
--peer-transit-gateway-id <hub-tgw-id> \
--peer-region ap-east-1 \
--region ${region}
done
# 在香港接受 Peering 请求
aws ec2 accept-transit-gateway-peering-attachment \
--transit-gateway-attachment-id <attachment-id> \
--region ap-east-1
第四步：配置路由策略
Hub 路由表（香港）
# 配置到各 Spoke 的路由
aws ec2 create-route \
--route-table-id <hub-route-table-id> \
--destination-cidr-block 10.1.0.0/16 \
--transit-gateway-attachment-id <ie-peering-id>
# 配置 IDC 路由
aws ec2 create-route \
--route-table-id <hub-route-table-id> \
--destination-cidr-block 192.168.0.0/16 \
--transit-gateway-attachment-id <dx-attachment-id>
Spoke 路由表
# 各 Spoke 配置默认路由到 Hub
for region in "${spoke_regions[@]}"; do
aws ec2 create-route \
--route-table-id <spoke-route-table-id> \
--destination-cidr-block 0.0.0.0/0 \
--transit-gateway-attachment-id <hub-peering-id> \
--region ${region}
done
数据流向分析
跨 Region 通信
示例：Tokyo → Brazil
Tokyo VPC → Tokyo TGW → HK TGW → Brazil TGW → Brazil VPC
IDC 与云端通信
示例：IDC → Tokyo
IDC → Direct Connect → DXGW → HK TGW → Tokyo TGW → Tokyo VPC
成本效益分析
月度成本估算
| 项目 | 数量 | 单价 | 月费用 |
|---|---|---|---|
| TGW Attachment | 6个 | $36/月 | $216 |
| TGW Peering | 5条 | $30/月 | $150 |
| Direct Connect | 1Gbps | $500-2000/月 | $1000 |
| 数据传输 | 按量计费 | $0.02-0.09/GB | 变动 |
| 总计 | - | - | ~$1366/月 |
成本优势
相比 Full Mesh 架构节省：
- 减少 16个 TGW Peering 连接
- 节省约 70% 的连接费用
- 简化管理降低运维成本
技术限制与扩展性
AWS 服务限制详情
Transit Gateway 限制
| 项目 | 默认限制 | 可调整 | 说明 |
|---|---|---|---|
| 每个账户的 TGW 数量 | 5个 | ✅ | 可通过 Service Quotas 申请 |
| 每个 TGW 的总 Attachments | 5,000个 | ❌ | 包括所有类型的连接 |
| 每个 TGW 的 Peering Attachments | 50个 | ✅ | 跨 Region 连接限制 |
| 待处理的 Peering Attachments | 10个 | ✅ | 同时处理的连接请求 |
| 每个 VPC 连接的 TGW 数量 | 5个 | ❌ | VPC 侧的连接限制 |
| 每个 TGW 的路由表数量 | 20个 | ✅ | 路由策略管理 |
| 每个 TGW 的总路由数 | 10,000条 | ✅ | 所有路由表的总和 |
Direct Connect Gateway 限制
| 项目 | 默认限制 | 可调整 | 说明 |
|---|---|---|---|
| 每个 DXGW 关联的 TGW 数量 | 6个 | ❌ | 单个 DXGW 的连接上限 |
| 每个 TGW 关联的 DXGW 数量 | 20个 | ❌ | TGW 侧的 DX 连接限制 |
| 每个账户的 DXGW 数量 | 200个 | ✅ | 可联系 SA/TAM 提升 |
| 每个 DXGW 的虚拟接口数量 | 30个 | ❌ | 私有和传输接口总数 |
性能限制
| 项目 | 限制值 | 说明 |
|---|---|---|
| 每个 AZ 的 VPC Attachment 带宽 | 最高 100 Gbps | 可联系 SA/TAM 获得更高带宽 |
| 每个 AZ 的包转发率 | 最高 750万 PPS | 高性能应用的关键指标 |
| 每个 VPN 隧道带宽 | 最高 1.25 Gbps | 可通过 ECMP 聚合多隧道 |
| 每个 Connect Peer 带宽 | 最高 5 Gbps | SD-WAN 集成场景 |
实际应用建议
VPC 连接规模
- 理论最大： 接近 5,000个 VPC
- 实际建议： 1,000-3,000个 VPC
- 考虑因素： 路由数量、性能、管理复杂度
跨 Region 连接规划
- 理论最大： 50个 Region
- 本方案使用： 5个 Peering 连接
- 扩展空间： 还可增加 45个 Region
配额提升方式
- 自助申请： 通过 AWS Service Quotas Console
- 技术支持： 联系 SA (Solutions Architect) 或 TAM (Technical Account Manager)
- 不可提升： 部分硬限制需要架构调整
总结
本文介绍的 Hub-Spoke 架构方案具有以下特点：
✅ 成本可控： 相比 Full Mesh 节省 70% 连接费用
✅ 管理简单： 集中化路由和监控管理
✅ 扩展性强： 支持 50个 Region 的理论上限
✅ 性能优异： 香港枢纽提供最优延迟
✅ 高可用性： 支持冗余链路和多 AZ 部署
该方案适用于需要全球多 Region 部署的企业，特别是以亚太地区为主要市场的业务场景。通过合理的网络规划和路由设计，可以实现高效、经济、可靠的全球网络互联。
参考文档：
