亚马逊云国际版 AWS亚马逊云混合云部署实践

你有没有经历过这样的深夜：服务器告警红成一片，老板微信弹出一句“客户说页面打不开”，而你的监控平台显示——一半服务在IDC机房，一半在AWS上，中间那条VPN隧道，正以每秒0.3%的概率丢包。

别急着删掉这段话。这真不是段子，而是我们给某家华东制造企业做混合云迁移时，第三周凌晨2:17的真实截图。

一、先说人话：什么叫“混合云”？

不是“本地放点，云上放点”就叫混合云。那是拼盘，不是混搭。

真正的混合云，是让应用像坐地铁换乘一样自然：A模块跑在IDC物理机上（因为要直连PLC设备），B模块跑在AWS EC2上（因需弹性扩缩容处理IoT数据洪峰），C模块干脆上了EKS集群（前端微服务），三者共用同一套用户体系、同一套日志管道、同一套告警规则——且运维同学不用开三个控制台、记三套命令、背三套权限模型。

换句话说：混合云不是技术堆叠，是体验缝合。

二、我们怎么缝的？（以某车企供应链系统为例）

业务背景：原有ERP+MES系统全在本地IDC，但新上线的供应商协同平台需要支持百万级并发接入，且要对接AWS上的SageMaker做预测性库存分析。老板一句话：“既要稳，又要快，还不许停机。”

目标架构：IDC为“主干”，AWS为“加速带”。核心交易库、主数据、审计日志留在IDC；API网关、实时计算层、AI推理服务、前端静态资源全部上云；关键链路双活，非关键链路灰度切流。

1. 网络打通：别迷信Direct Connect，先搞定BGP

我们一开始也买了Direct Connect，花了两万块月租费，结果发现——IDC出口路由器不支持BGP路由反射。AWS端配好了，IDC侧死活学不会10.100.0.0/16这条路由。

最后方案：降级用Site-to-Site VPN + bgpd（FRRouting）。在IDC边缘防火墙后加了一台Ubuntu 22.04小服务器，装FRR，手动注入静态路由+宣告BGP前缀。关键配置就三行：

router bgp 65001
 neighbor 169.254.10.2 remote-as 64512
 network 10.20.0.0/16

注意：AWS端Customer Gateway的BGP ASN必须是私有AS号（64512–65534），否则会拒收。这个坑，我们填了两天，文档里藏在第17页脚注里。

2. 身份统一：AD ≠ IAM，但能握手成功

IDC用Windows AD，AWS用IAM。想让AD账号直接登录AWS Console？别做梦。但可以做到：AD用户单点登录AWS控制台 + CLI自动换凭据 + EKS集群RBAC映射到AD组。

核心工具链：AD FS（3.0以上）+ AWS IAM Identity Center（原SSO）+ aws-adfs CLI插件。

实操要点：AD FS必须启用SAML 2.0 + 启用urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport认证上下文；AWS侧在Identity Center里绑定AD FS元数据URL后，务必手动在每个账户里为AD安全组添加Permission Set——不是全局生效，是账户粒度！我们漏配了一个开发账户，导致DevOps同学怒删了三次IAM角色。

3. 应用调度：K8s跨云不是梦，但得自己焊桥

EKS集群在AWS，IDC里跑了Rancher管理的K3s集群。怎么让一个Deployment既能调度到EC2节点，也能落到IDC的ARM服务器上？

答案：不搞跨集群调度，改用服务网格+流量染色。我们在Istio Ingress Gateway前加了一层自研的“智能路由网关”，根据Header中的X-Region-Preference: aws|idc，把请求打到对应集群的Service入口。IDC集群通过NodePort暴露服务，AWS集群走ALB+Target Group。延迟高了3ms，但稳定性提升87%——毕竟，K8s跨云调度失败时，Pod状态是Pending，而我们的网关返回的是503 Service Unavailable，运维同学一眼就懂。

4. 灾备策略：别信“自动故障转移”，先测断电

我们写了300行Python脚本模拟IDC断电：关闭IDC所有节点 → 触发CloudWatch告警 → Lambda调用Route53 API切换DNS权重 → 发钉钉通知 → 自动拉起AWS侧备用实例组。

结果第一次演练：DNS TTL设成了300秒，切换花了5分23秒；第二次：Lambda超时设成15秒，没等Route53响应就退出了；第三次才跑通——但发现IDC恢复后，没写回切逻辑，导致一周后才发现测试环境流量全卡在AWS上，账单暴涨3倍。

亚马逊云国际版 教训：灾备不是“能切”，是“能切、能回、能验、能睡得着觉”。

三、那些没写进PPT的血泪细节

• NTP漂移：IDC服务器用内网NTP，AWS用169.254.169.123，时间差超100ms时，Kerberos认证直接跪。解决方案：IDC侧同步公网NTP（如time1.aliyun.com），AWS侧强制systemd-timesyncd每30秒校准；
• MTU地狱：IDC MTU=1500，AWS VPC默认1500，但VPN隧道实际有效MTU=1436。大文件上传卡在98%？八成是TCP分片被丢。统一改成1400，世界清净；
• 日志黑洞：Fluent Bit从IDC采集日志推到CloudWatch Logs，但中文日志乱码。不是编码问题，是Fluent Bit容器镜像里缺glibc-langpack-zh包。加一行RUN apk add --no-cache glibc-langpack-zh，重启采集器，搞定；
• 成本幻觉：以为“只用EKS Worker Node，不用EC2就省钱”，结果EKS控制平面每月$72，比3台t3.xlarge还贵。后来切到EKS Anywhere+IDC裸金属，控制面归自己管，年省$1100。

四、最后送你一张“混合云避坑速查表”

（打印贴工位，亲测有效）

• 网络层：先抓包再配BGP，tcpdump -i any port 179看邻居建没建起来；
• 身份层：AD FS日志级别调到Verbose，否则SAML错误只显示“Authentication failed”；
• 存储层：S3 Cross-Region Replication别开版本控制，否则IDC同步工具会疯狂拉取Delete Marker；
• 监控层：CloudWatch Agent和Zabbix别装在同一台IDC服务器上，CPU争抢会导致指标毛刺；
• 心理层：每周五下午3点，手动执行一次aws ec2 describe-instances --filters "Name=tag:Env,Values=prod"，确认没被谁误删了生产实例——这是信仰，不是操作。

混合云没有银弹，只有铜锤。一锤一锤，把IDC的厚重感，和AWS的轻盈感，砸进同一个运维SOP里。

当你某天发现，新来的实习生问：“咱们的数据库到底在哪儿？”而你脱口而出：“它在哪儿不重要，重要的是——你查它的SQL，永远返回一样的结果，不管它今晚住IDC还是AWS。”

那一刻，混合云，才算真正混熟了。