亚马逊云国际站 亚马逊云国内节点大盘点

说到“亚马逊云国内节点”，不少朋友第一反应是：哦，AWS在咱国内也有机房了？点开控制台就能选“北京区域”、“上海区域”——那不就是国产云？

打住。先喝口茶，把这杯“认知偏差”咽下去。

AWS在中国大陆，压根儿没有独立建IDC，也没有自持牌照。它玩的是一套“借壳上市+分身术”组合拳：一个身子，两套马甲；一套面向北上广深，一套专供宁沪杭苏。别急，咱们慢慢拆解这个比《甄嬛传》还讲究的“云上宫斗局”。

第一幕：不是“AWS中国”，是“AWS中国合作版”

2013年，AWS牵手光环新网，在北京启用首个中国区域（cn-north-1）。2016年，再联西云数据，在宁夏落地第二个区域（cn-northwest-1）。注意关键词：“合作运营”，不是AWS直营。这意味着——

• 牌照是光环新网（增值电信业务许可证、IDC牌照）和西云数据（同样持牌）的；
• 亚马逊云国际站 账单开票方是这两家中国公司，不是Amazon.com, Inc.；
• 数据主权、安全审计、等保备案，全由合作方担责，AWS只提供技术底座和品牌授权。

换句话说：你登录的是aws.amazon.com.cn，但背后跑着的，是装了AWS操作系统、穿了AWS制服、但户口本上写着“北京朝阳区”或“宁夏中卫市”的两个本地化实体。

第二幕：四大物理节点，其实是“两大区域+两个边缘延伸”

常有人刷到“AWS上海节点”“AWS南京节点”，兴奋截图发群：“快看！AWS终于进长三角了！”——其实，这是典型的信息错位。

目前AWS在中国合法可用的只有两个区域（Region）：

• cn-north-1：由光环新网运营，物理数据中心位于北京亦庄（主中心）+上海松江（灾备/扩展可用区）。注意：上海松江不是独立区域，而是cn-north-1的AZ（可用区），叫cn-north-1a/b/c/d…其中d就是松江。它不支持单独购买，不能跨区域迁移，也不能和宁夏区域互通内网。
• cn-northwest-1：由西云数据运营，主数据中心在宁夏中卫（国家级算力枢纽），另设南京江北新区作为补充可用区（即cn-northwest-1a/b，b为南京）。这里要划重点：南京不是新区域，是宁夏区域的“异地兄弟间”，类似“银川总部+南京办事处”。

所以，“四大节点”本质是：2个区域 × 各含2个地理分散的可用区 = 4个物理位置。但网络层面，它们严格按区域隔离——北京&上海属一个VPC生态，宁夏&南京属另一个，彼此之间走公网（哪怕只隔1000公里），延迟35ms起步，丢包率看运营商心情。

第三幕：服务不是“照单全收”，而是“菜单式阉割”

别以为控制台里看着和国际站一样，就真能all-in。现实是：每个合作区域，都有一份定制版服务清单。

比如——

• AI全家桶？SageMaker在cn-north-1有，但在cn-northwest-1至今缺席；
• Serverless扛把子Lambda？两个区域都有，但内存上限卡在10GB（国际站是10GB起步，最高可配10GB）；
• EKS（K8s托管服务）？宁夏区域直到2023年底才上线，北京区域则早两年就跑着客户生产环境；
• 最扎心的是：Aurora数据库，两个区域都支持，但不支持Aurora Serverless v2——想弹性扩缩？得自己写脚本轮询指标+调API，半夜三点被告警call醒是常态。

更隐蔽的坑在于API兼容性。某电商客户曾用Terraform写了一套国际站基础设施代码，直接apply到cn-north-1——结果90%资源创建失败。原因？国内版EC2 AMI ID格式带中文前缀，IAM策略语法少一个字段校验，就连S3的Endpoint域名后缀都从.s3.amazonaws.com变成了.s3.cn-north-1.amazonaws.com.cn……表面是云，底层全是方言。

第四幕：选区域？别看地图，看你的“合规身份证”

很多技术负责人拍板：“用户多在上海，那就选上海节点！”——然后法务部一个电话打过来：“等等，你合同里写的‘数据存储于北京市’，现在往松江放，算不算违约？”

真实选型逻辑，得倒推三步：

1. 等保/密评要求：若系统需三级等保，必须明确备案地域。北京亦庄机房已通过等保三级+密评二级，宁夏中卫也过等保三级，但松江和南京只是“延伸可用区”，备案主体仍是北京/宁夏，不能单独出具属地证明；
2. 客户合同约束：金融客户常写死“数据不得出京”，那即便松江物理距离近，法律意义上仍属“出京”，只能选亦庄主AZ；
3. 灾备真实性：宣称“两地三中心”？查清楚：北京亦庄+松江是同城双活（光纤直连），但若把亦庄和宁夏当异地灾备——不好意思，中间隔着骨干网，RPO可能分钟级，RTO要看你备份策略是否跨区域同步。

第五幕：一线运维的真实吐槽合集

最后，送上三位不同行业客户的血泪总结（已脱敏）：

• 在线教育公司：初期全量上cn-north-1，半年后因视频转码并发暴涨，想切Lambda函数到宁夏区域分流——结果发现宁夏没SageMaker，FFmpeg容器镜像拉不到，最终加购GPU实例硬扛，月增成本17万；
• 医疗SAAS厂商：为满足卫健委“患者数据不出省”，把数据库放宁夏，应用放北京，靠DMS做实时同步。结果某次骨干网抖动，DMS延迟飙升至47分钟，导致门诊挂号号段重复发放，当天退款单爆了200+；
• 游戏出海公司：用北京区域部署国内服，国际站部署海外服，想用Global Accelerator做加速。一查文档才发现：GA不支持中国区域！最后改用CloudFront+自建Anycast，CDN回源延迟反而比原来高8ms。

结语：云没有祖国，但合规有户籍

AWS在中国的双轨制，不是技术缺陷，而是本土化生存的智慧妥协。它既保留了AWS的技术基因，又严守监管红线。对用户而言，与其纠结“哪个节点更快”，不如先问清三个问题：

1. 我的数据，法律上必须落在哪里？
2. 我的核心服务，在这两个区域里，到底有没有？
3. 我的运维团队，能不能接受“同一份代码，两套调试方式”？

记住：最好的云，不是参数表里最亮的那个，而是让你半夜接到告警时，不用翻墙查英文文档、不用猜API报错含义、更不用对着法务函发呆的那个。

毕竟，云的本质不是炫技，是让业务稳稳落地——哪怕落地的姿势，有点像太极推手：借力、卸力、四两拨千斤。