本指南通过Azure网络设计指南提供了一个有序阅读路径，用于将Azure连接到 Amazon Web Services（AWS）、Google Cloud 或从另一个云提供商迁移工作负载的客户。 按照编号的步骤设计Azure与现有云基础结构之间的安全监视连接。
为什么探索是第一步
跨云网络将Azure连接到一个或多个外部云环境。 可以在 AWS 或 Google Cloud 中运行工作负载，这些工作负载需要与Azure服务建立专用连接，或者可以将应用程序从另一个云迁移到Azure，同时保持与保留的应用程序的连接。 无论哪种方式，Azure网络都必须与另一端无法完全控制的基础结构集成。
此读取路径以发现而不是Azure基础结构设计开头。 首先映射现有的多云拓扑（了解运行的位置、连接方式以及云之间的流量流），然后再设计Azure端。 这种先发现后设计的方法可以避免返工：如果你在不了解 AWS 或 Google Cloud 中的网络拓扑的情况下设计 Azure 网络，就可能面临 IP 地址冲突、连通性缺口和安全盲点等风险。
您的目标体系结构使用 Azure 虚拟广域网（WAN）作为中转枢纽（相当于 Azure 中对应 AWS Transit Gateway 的服务），并通过 IPSec VPN 隧道连接到 AWS 虚拟专用网关和 Google Cloud VPN。 安全虚拟中心中的Azure 防火墙检查所有跨云和分支流量。 DNS 需要进行周密的切换规划，以确保在迁移期间跨云边界的名称解析保持正常运行。
先决条件
- 阅读Azure网络计划和设计概述，了解可用的Azure网络服务的方向。
- 完成 AWS 和 Google Cloud 环境的拓扑发现：
- AWS：在 AWS 上运行 AWS 迁移中心或工作负荷发现，以清点虚拟私有云（VPC）、传输网关和 VPN 间连接。
- Google Cloud：使用网络智能中心映射 VPC 网络、Cloud Interconnect 附件和防火墙规则。
- 记录跨云流量流：哪些应用程序在云之间通信、所需的带宽、延迟敏感度和加密要求。
- 创建所有三个云中的 IP 地址范围的清单，以识别重叠。
阅读路径
以下阶段指导你按顺序完成跨云网络设计。
阶段 1：发现
从发现开始。 在设计Azure基础结构之前了解多云布局。
1. 跨区域和多云连接
本文是你的中心设计决策点。 映射您的多云拓扑：哪些 AWS VPC 和 Google Cloud VPC 需要连接到 Azure、云之间传输哪些流量，以及哪种体系结构模式适合您的规模。 使用不同云提供商之间的服务映射（Transit Gateway 对应 虚拟 WAN、安全组对应网络安全组、VPC 对等互连对应 VNet 对等互连），用 Azure 的术语来表述您现有的设计。
2. Azure 虚拟 WAN
如果有多个 VPN、分支、区域或云边缘，建议使用虚拟 WAN传输模型。 虚拟 WAN 提供了 Azure 中与 AWS Transit Gateway 对应的能力：自动路由、集中式安全以及多分支/多区域扩展能力。 评估您的跨云环境是否有必要采用 虚拟 WAN，还是采用带 VPN 网关 的更简单中心辐射型架构就已足够。
阶段 2：基础
3. 虚拟网络和子网
将 Azure VNet 设计为已迁移或已连接工作负载的着陆区。 从 AWS VPC 和 Google Cloud VPC 的概念进行映射：VPC 子网对应为 Azure 子网，可用性区域映射到 Azure 可用性区域，路由表也遵循类似的模式。 重点关注部署到 Azure 的工作负载的子网规模规划。
4. IP 地址规划
跨所有三个云规划不重叠的地址空间。 此步骤对于跨云连接至关重要：如果Azure VNet 范围与 AWS VPN 范围或 Google Cloud VPN 范围重叠，则无法建立它们之间的 VPN 隧道。 在分配Azure地址空间之前，记录所有环境中使用的每个 CIDR 块。
将 AWS 安全组和 Google 云防火墙规则镜像为Azure网络安全组（NSG）。 将现有允许和拒绝规则转换为 NSG 格式。 使用应用程序安全组（ASG）复制 AWS 安全组引用提供的基于标记的分组。
阶段 3：连接
6. 混合连接
为加密的跨云传输设置Azure与 AWS 或 Google Cloud 之间的 IPSec VPN 隧道。 将Azure VPN 网关（或虚拟 WAN VPN 连接）连接到 AWS 虚拟专用网关和 Google 云 VPN。 根据跨云流量需求选择隧道带宽。 规划冗余隧道以避免单一故障点。
阶段 4：安全性
在迁移工作负载之前，规划好 DNS 切换策略。 AWS 或 Google Cloud 中的应用程序会解析主机名，而这些主机名在迁移后可能需要指向 Azure。 使用出站终结点配置 Azure DNS 专用解析器，以实现跨云名称解析。 请参阅本文后面的 DNS 切换清单，获取分步迁移指导。
8. Azure 防火墙
在安全的虚拟中心部署Azure 防火墙，以检查所有跨云和分支流量。 Azure与 AWS 或 Google Cloud 之间遍历的每个数据包都通过防火墙进行日志记录和策略强制实施。 使用网络规则进行跨云流量模式和威胁情报筛选，以阻止已知的恶意目标。
阶段 5：操作
9. 网络监视和可观测性
跨云资产更难进行故障排除，因为你无法控制每个连接的两端。 为连接测试、VPN 隧道诊断和数据包捕获启用Azure 网络观察程序。 根据容量要求监视隧道运行时间、云之间的延迟和吞吐量。 针对会影响跨云应用程序可用性的隧道断连设置告警。
条件文章
根据具体要求包括以下文章：
| 条件 | 文章 | 何时应包含 |
|---|---|---|
| 面向公众的应用程序 | Internet 入口 | 迁移的应用程序面向 Internet（需要直接公共访问） |
| HTTP/HTTPS 应用程序 | Web 应用程序防火墙 | 面向公众的 Web 应用程序需要第 7 层 WAF |
| 需要第 7 层分发 | 应用程序交付和性能 | 迁移后需要全局或区域流量分布 |
| 公共端点 | DDoS 保护 | 你对面向公众的服务有可用性要求 |
| 首选中心辐射型 | 中心辐射型拓扑 | 您的跨云环境规模较小，因此没有必要采用 虚拟 WAN |
| 多区域 Azure | 多区域网络 | 您的 Azure 目标覆盖跨云连接之外的多个区域 |
| VM 管理员访问权限 | 开发人员和管理员访问权限 | 需要对Azure托管的 VM 进行安全的 RDP/SSH 访问 |
| 集中式出口 | 出站互联网访问 | 集中式互联网出口策略是目标设计的一部分 |
| 大型 VNet 资产 | 集中式网络管理 | Azure 环境发展为受治理的多订阅环境 |
| PaaS 专用终结点 | PaaS 专用访问 | 目标体系结构包括带有专用终结点的 Azure PaaS 服务 |
跨云发现清单
在设计Azure网络之前，请将现有云服务映射到Azure等效项。 此映射可加速设计决策并防止不匹配的预期。
AWS 到 Azure 服务映射
| AWS 服务 | Azure 的等效 | 注释 |
|---|---|---|
| 中转网关 | Azure 虚拟 WAN | 用于多维联、多区域、多云的集中式路由中心 |
| VPC | Azure 虚拟网络 | 包含子网和路由表的隔离网络边界 |
| VPC 对等互连 | VNet 对等互连 | 两个虚拟网络之间的直接连接 |
| 安全组 | 网络安全组 (NSG) | 子网或网络接口级别的有状态流量筛选 |
| 网络 ACL | NSG （子网级别） | Azure NSG 结合了安全组和 NACL 函数 |
| 虚拟专用网关 | VPN 网关 | IPSec VPN 终止点 |
| 直接连接 | Azure ExpressRoute | 专用私有连接（不通过公共互联网） |
| Route 53 私有托管区域 | Azure 专用 DNS 区域 | 虚拟网络中的专用 DNS 名称解析 |
| 路由表 | 用户定义路由 (UDR) | 用于替代Azure系统路由或 AWS 隐式路由的自定义路由 |
| 弹性负载均衡器（ALB/NLB） | Azure 负载均衡器/应用程序网关 | L4 和 L7 负载均衡;应用程序网关提供类似于 AWS ALB 和 AWS WAF 的 WAF 功能 |
| AWS WAF | Azure Web 应用程序防火墙 | 第 7 层 HTTP/HTTPS 保护 |
| 网络防火墙 | Azure 防火墙 | 具有威胁情报的有状态网络防火墙 |
Google Cloud 到Azure服务映射
| Google Cloud 服务 | Azure 的等效 | 注释 |
|---|---|---|
| VPC 网络 | Azure 虚拟网络 | Google Cloud 中的全局资源；Azure 中的区域性资源（跨区域时使用 VNet 对等互连） |
| 云互连 | Azure ExpressRoute | 专用私有连接 |
| 云 VPN | VPN 网关 | IPSec VPN 隧道 |
| 云NAT | Azure NAT 网关 | 专用资源的出站 Internet 访问 |
| 云路由器 | Azure 路由服务器 | 与网络虚拟设备的动态 BGP 路由交换 |
| Cloud Armor | Azure Web 应用程序防火墙 | 第 7 层 DDoS 和应用程序保护 |
| 防火墙规则 | 网络安全组 | 流量过滤（Google Cloud 的规则是全局性的；Azure NSG 是按子网或按网卡设置的） |
| 云 DNS 专用区域 | Azure 专用 DNS 区域 | 网络中的专用名称解析 |
| 网络智能中心 | Azure 网络观察程序 | 网络监视、诊断和拓扑可视化 |
DNS 切换检查清单
DNS 切换是跨云迁移中风险最高的步骤。 按照此清单操作，以最大程度地减少转换期间的解决失败。
迁移前
- 调低 TTL（生存时间）值，适用于所有发生更改的 DNS 记录。 至少在切换前 48 小时将 TTL 设置为 60-300 秒。 此步骤可确保在更新记录后，缓存能迅速失效。
- 记录所有指向你正在迁移的基础设施的 DNS 记录：服务器的 A 记录、服务的 CNAME 记录、邮件服务的 MX 记录，以及用于服务发现的 SRV 记录。
- 使用 Azure VNet 中的出站终结点配置Azure DNS专用解析程序。 此解析程序在共存期间将 AWS/Google 云托管区域的查询转发到相应的上游 DNS 服务器。
- 在迁移任何工作负载之前，先测试从 Azure VNet 到 AWS/Google 云托管名称的正向和反向解析。
在迁移过程中
- 更新迁移到 Azure 的服务的 CNAME 记录。 随着各个服务的迁移，将 CNAME 记录指向 Azure Front Door、Azure 流量管理器 或 Azure 应用程序网关 终结点。
- 更新迁移的各个服务器的主机 A 记录。 将 AWS 或 Google Cloud IP 地址替换为 DNS 区域中Azure专用 IP 地址。
- 保持条件转发启用，以便你尚未迁移的区域中的名称仍通过原有云的 DNS 服务器进行解析。
迁移之后
- 验证来自所有位置的解析：本地客户端、Azure VNet 以及所有剩余的 AWS 或 Google 云工作负载都必须正确解析迁移的名称。
- 确认稳定分辨率后，将 TTL 值提升回生产级别（3,600 秒或更高）。
- 删除完全迁移到Azure DNS的区域的条件转发器。 仅保留仍位于 AWS 或 Google Cloud 中的区域的转发器。
你构建的内容
通过遵循此读取路径，你将Azure连接到现有的 AWS 或 Google Cloud 环境，其中包含加密传输、集中式防火墙检查和受监视的连接。 你的设计包括：
- 多云拓扑发现和服务映射
- 虚拟 WAN 或中心辐射型传输架构
- 到 AWS 和 Google Cloud 的 IPSec VPN 隧道
- 用于跨云流量检查的Azure 防火墙
- 使用专用解析器进行跨云名称解析的 DNS 切换
- 使用 网络观察程序 对隧道运行状况和性能进行监视
后续步骤
- 直接迁移网络路径：如果还具有直接迁移到 Azure IaaS 的本地工作负荷
- 迁移和现代化网络路径：如果Azure部署采用 PaaS 服务和容器
- 设计阶段一目了然：Azure 网络设计的通用分阶段摘要
- Azure 网络规划和设计概述：按功能浏览所有可用服务