2. AWS全球基础设施与区域边界规划

在AWS上设计企业网络与安全边界,第一步不是画VPC,而是先理解AWS全球基础设施的层级结构。因为Region、AZ、Edge Location、Local Zone、Wavelength这些概念决定了你的资源能部署在哪里、流量从哪里进入、延迟能压到多低、合规边界如何划定。很多架构问题表面上是路由或安全组配置错误,根源其实是基础设施层级选错了。

一、基础设施层级:从全球到边缘

AWS全球基础设施可以按“覆盖范围从大到小、离用户从远到近”来理解。最上层是Region(区域),每个Region是一个独立的地理区域,拥有独立的电力和网络,Region之间默认不互通,必须显式建立跨区域连接。Region内部由多个AZ(可用区)组成,AZ是同一区域内物理隔离的数据中心集群,彼此之间通过低延迟、高带宽的私有光纤互联。AZ是可用性设计的基本单元:把工作负载分布到多个AZ,才能在一个AZ故障时继续服务。

再往外是Edge Location(边缘站点),它是CloudFront、Route 53、Global Accelerator、AWS Shield等服务的接入点,数量远多于Region,主要解决“用户到AWS第一跳”的延迟问题。它不运行你的EC2或RDS,但决定了静态内容缓存、DNS解析和DDoS清洗在哪里发生。

更靠近终端用户的是两类延伸设施:Local Zone是Region的延伸,把计算、存储、数据库等核心服务放到离大城市更近的位置,适合对本地延迟敏感但又需要与Region内VPC低延迟互联的场景;Wavelength则把计算嵌入5G运营商网络内部,流量不必先绕出运营商网络再到Region,适合超低延迟的移动边缘应用,如车联网、AR/VR、实时游戏。

AWS全球基础设施层级与边界关系 Region(区域)— 独立地理边界 AZ-a 独立供电 独立冷却 低延迟互联 AZ-b 独立供电 独立冷却 低延迟互联 AZ-c 独立供电 独立冷却 低延迟互联 VPC 跨AZ部署:子网分布在多个AZ,实现高可用 安全边界:安全组 / NACL / 路由表 / 网关端点 Region间默认隔离,需显式建立对等连接或Transit Gateway Edge Location(边缘站点) CloudFront 缓存 / Route 53 解析 Global Accelerator 接入 / Shield 清洗 不运行用户EC2/RDS,只做接入与加速 Local Zone(本地扩展区) Region的延伸,靠近大城市 运行EC2/EBS/ELB等核心服务 与父Region VPC低延迟互联 Wavelength(5G边缘) 计算嵌入5G运营商网络内部 流量不绕出运营商网络 超低延迟:车联网/AR/实时游戏 企业多区域边界设计要点 • 数据驻留:合规要求决定Region选择,数据不跨边界 • 延迟优化:用户就近接入Edge,计算靠近用户用Local Zone/Wavelength • 容灾架构:跨Region复制 + 跨AZ高可用,RTO/RPO决定复制策略 • 网络互联:Transit Gateway / VPC Peering / Direct Connect 统一编排 Region AZ Edge Local Zone

二、Region与AZ的边界含义

Region是合规边界和故障域边界。企业选择Region时,首先要回答三个问题:数据是否允许离开该国家或地区?用户主要分布在哪里?灾难恢复目标是什么?例如,一家面向中国用户的企业,如果合规要求数据不出境,就不能把主Region放在新加坡;如果要求RTO小于15分钟,通常需要跨Region的热备或温备,而不是仅靠单Region多AZ。

AZ是高可用边界。一个Region通常有3个或更多AZ,但并非所有Region都有相同数量。设计时不要把“多AZ”简单理解为“多子网”,而应确保关键组件在每个AZ都有独立实例:应用服务器、数据库副本、NAT网关、负载均衡节点。以典型三层Web应用为例,可以在AZ-a和AZ-b各部署一台应用服务器,RDS使用多AZ部署,ELB跨AZ分发流量。这样单个AZ故障时,服务仍可用,只是容量下降。

三、Edge Location、Local Zone与Wavelength的定位差异

这三者容易混淆,但定位完全不同。Edge Location解决的是“用户到AWS入口”的问题,它不承载你的业务计算,只做缓存、DNS、加速和防护。Local Zone解决的是“计算离用户太远”的问题,它承载EC2、EBS、ELB等,但仍然是Region的一部分,受Region的VPC和IAM管理。Wavelength解决的是“移动网络内部超低延迟”的问题,它把计算放进5G基站侧,适合对延迟极度敏感且用户集中在移动网络中的场景。

选择时可以用一个简单判断:如果只是静态内容加速或DDoS防护,用Edge Location;如果业务需要本地计算但又要与Region内数据库低延迟通信,用Local Zone;如果业务运行在5G网络内且要求端到端延迟低于20ms,考虑Wavelength。

四、企业多区域边界设计示例

假设一家企业需要同时服务华东和华南用户,合规要求数据不出中国,且要求RTO不超过30分钟。一个合理的边界设计如下:主Region选择宁夏或北京,承载核心数据库和主应用;在华南用户密集城市启用Local Zone,部署无状态应用层,通过Transit Gateway与主Region VPC互联;静态资源和API入口使用CloudFront Edge Location加速;跨Region容灾可以选择另一个合规Region作为温备,通过S3跨区域复制和RDS跨区域只读副本实现数据同步。

网络边界上,需要明确:Region之间通过Transit Gateway或VPC Peering互联,但安全组和NACL必须逐层收紧;Edge Location到源站的回源流量应限制为CloudFront的IP段;Local Zone与父Region之间的流量走AWS骨干网,不经过公网;Wavelength与Region之间的流量通过运营商网络和AWS骨干网衔接。

规划检查清单:
  • 合规:数据是否允许离开所选Region?是否有数据驻留要求?
  • 延迟:用户到Edge的延迟是否可接受?计算是否需要Local Zone或Wavelength?
  • 可用性:关键组件是否跨至少2个AZ部署?跨Region容灾的RTO/RPO是否明确?
  • 网络:Region间互联方式是否确定?安全边界是否逐层收紧?
  • 成本:跨Region流量、Local Zone溢价、Wavelength费用是否纳入预算?

基础设施层级选错,后续的网络和安全配置往往事倍功半。先确定Region和AZ的边界,再决定是否需要Edge、Local Zone或Wavelength,最后才进入VPC、子网、路由和安全组的具体设计。这个顺序不能颠倒。