VPC 安全组把我模型关在外面 3 天,补完 Kiro 后我整理的 6 条网络军规发版当天的下午三点,SageMaker 训练作业的状态已经卡在「InProgress」整整 47 分钟。我盯着 CloudWatch 日志里那行 Unable to pull ECR image: request canceled while waiting for connection 反复出现,心里一沉。模型代码、特征工程脚本、超参调优配置全都通过了前几轮测试,唯独网络这一步把我彻底挡在了门外。事后回想,如果我早一点吃透AWS 基础知识里关于 VPC 和安全组的那几个核心概念,就不至于让整个团队等了我三天。后来真正帮我止血的,是亚马逊云科技一个叫Kiro的机器学习基础课程--它用一整章把机器学习项目的网络隔离、私有子网部署、VPC endpoint 和安全组规则拆成了能直接落地的模块。如果你也正准备把模型往生产环境推,这份用教训换来的清单希望能帮你少踩一点坑。发版当天:训练作业卡死在 ECR 拉取上我们的场景并不复杂:用 SageMaker 训练一个协同过滤推荐模型,读写数据都在 S3,容器镜像存储在 ECR。为了数据安全,我先建了一个自定义 VPC,把训练任务挂到私有子网里,心想「网络隔离总没错」。结果作业提交后直接超时。我第一反应是安全组规则没放通,于是临时加了一条0.0.0.0/0入站规则--训练任务确实动了,但成本监控半小时后开始报警:NAT 网关的流量费用涨了将近 4 倍。更要命的是,训练任务每到数据读取阶段就变得极其缓慢,一个 20GB 的特征数据居然读了 3 小时才完成。当时我以为只要网络「通」就行,其实根本不知道机器学习管道对网络延迟和数据出向流量的敏感程度。这个时刻我才意识到,自己在网络配置上的知识完全是碎片化的。用一句话概括当时的窘境:安全组能放行,但模型依旧「关在外面」。踩坑:全开安全组让账单多出 260 美元排查的第一步是看 VPC 流日志。我发现大量到s3.amazonaws.com的请求都走了公网出口,因为私有子网的路由表指向了一个 NAT 网关。之前为了省事,我既没配 VPC endpoint for S3,也没限制安全组的出向规则。这直接导致两个问题: - 训练任务拉取容器镜像时,NAT 网关的吞吐瓶颈把启动时间拖长了近 8 倍; - 数据预处理阶段从 S3 读取 Parquet 文件时,每小时的网络出向费用比预期高出了约 17 美元,三天累计多烧了 260 美元左右的 NAT 处理费。临时把安全组全开是我犯的第二个错误。虽然入站规则0.0.0.0/0让训练任务跑了起来,但 ECR 的拉取请求依旧走公网,速度没有任何改善。更危险的是,这条规则使训练实例完全暴露在互联网上,一旦被扫描到,整个机器学习管道的中间数据都可能面临风险。# 当时我错误使用的安全组规则,入站全开(绝对不可取) aws ec2 authorize-security-group-ingress \ --group-id sg-0a1b2c3d \ --protocol all \ --port 0-65535 \ --cidr 0.0.0.0/0在 Kiro 里把网络概念从头补了一遍安全组全开的事故被同事在例会上点名之后,我开始认真找系统化的学习资料。一个做 MLOps 的朋友推荐我去看机器学习基础的在线课程,说是亚马逊云科技自己的学习路径,代号就是Kiro。Kiro 这门课把我之前东拼西凑的网络知识重新捋成了一根线。它从AWS 基础知识讲起,专门有一节分析机器学习工作负载的网络需求:哪些流量应该走内网、哪些必须出公网、安全组和网络 ACL 的分工、VPC endpoint 如何把 S3 和 ECR 的请求锁定在 AWS 骨干网上。学完Kiro那一章后我才搞清楚,之前 NAT 网关的「天价」账单根本不是偶然,而是因为我完全没区分数据平面和控制平面的流量路径。我还顺便补了特征工程和数据预处理在生产环境下的网络依赖。原来在做大规模特征提取时,如果 Spark 节点要通过 NAT 访问 S3,不仅慢还会产生大量跨 AZ 流量。Kiro 的实践模块里直接给了一套 VPC endpoint 私有子网的配置模板,我照着改完后,训练任务的启动时间从 47 分钟降到了 9 分钟。用 VPC endpoint 替代 NAT 网关:成本与延迟对比决定对网络动刀之前,我先把两种方案的预期差距拉了出来。下面是根据我们的训练规模和 AWS 定价计算器得出的对比(基于 us-east-1 区域,每月训练 12 次,单次数据量约 20GB):指标走 NAT 网关(之前)走 VPC endpoint(优化后)S3 数据传输延迟(P99)约 120ms约 8msECR 镜像拉取耗时平均 14 分钟平均 2 分钟单月网络出向费用约 310 美元约 28 美元训练实例暴露面因 0.0.0.0/0 全开仅允许 VPC 内部通信学完Kiro之后我才明白,机器学习基础课程里反复强调的那个原则--「所有 ML 辅助资源都应走私有链路」--在实际账单上能带来这么大的差异。# 用 Terraform 创建 VPC endpoint for S3 的最小化配置片段 resource aws_vpc_endpoint s3 { vpc_id aws_vpc.ml_vpc.id service_name com.amazonaws.us-east-1.s3 route_table_ids [aws_route_table.private_subnet_rt.id] policy jsonencode({ Version 2012-10-17, Statement [{ Effect Allow, Action s3:GetObject, Resource arn:aws:s3:::my-ml-data-bucket/*, Principal * }] }) }同样,ECR 的镜像拉取也切到了 VPC endpoint,两个接口端点(ecr.api和ecr.dkr)配好之后,训练任务再也没出现过 request canceled while waiting for connection。安全组从「全开」收敛到「最小权限」:一条规则差点让容器无法启动切换到私有链路后,我开始按AWS 基础知识里推荐的最小权限原则收紧安全组。这个过程又踩了一个坑:我只放了 SageMaker 训练实例到 VPC endpoint 的出向规则,却忘了 ECR 的拉取还需要访问 S3 存储桶来下载镜像层。当时看到日志里出现 layer download failed: dial tcp: i/o timeout,我还以为是 VPC endpoint 没配好。排查了两个小时后,才想起Kiro课程演示案例里专门贴了一张安全组依赖关系图--ECR 拉取镜像时,除了ecr.dkr端点,还要允许到 S3 的出向流量来拉取镜像层。多等了两小时的原因,就是少了一条到 S3 endpoint 的出向规则。这次教训让我直接把「安全组依赖关系」写进了团队 Wiki 的第一页。Kiro里那张图我截屏存了,每次新开项目都翻出来核对一遍。最终收敛后的安全组规则长这样:入站只允许来自 VPC CIDR 的 443 端口(SageMaker 控制面通信),出站精确到 VPC endpoint 对应的前缀列表和 443 端口。# 训练实例的安全组出向规则(最小权限) SecurityGroupEgress: - IpProtocol: tcp FromPort: 443 ToPort: 443 PrefixList: pl-xxxxxxx # S3 VPC endpoint 前缀列表 Description: Allow to S3 endpoint - IpProtocol: tcp FromPort: 443 ToPort: 443 PrefixList: pl-yyyyyyy # ECR VPC endpoint 前缀列表 Description: Allow to ECR endpoint私有子网 SageMaker 私有部署:把训练和端点都锁在 VPC 里网络层止血之后,我把关注点转到了模型上线。之前因为网络问题,端点一直部署在 SageMaker 的公共网络中。现在有了对机器学习管道安全隔离的理解,我决定把推理端点也迁移到 VPC 内部的私有子网。在 SageMaker 控制台上创建模型时,指定 VPC 配置的 JSON 片段如下:VpcConfig: { SecurityGroupIds: [sg-07a8b9c3], Subnets: [subnet-06d1e5f7, subnet-08f2c3a4] }加上之前配置的 VPC endpoint for S3,推理端点读取模型 artifact 的耗时从公网模式下的 35 秒降到了 4 秒以内。而且由于全部流量走内网,端点响应时间的抖动也明显变小--从 P99 的 220ms 压缩到了 78ms。如果你也准备把模型上生产,机器学习基础里的私有部署章节值得反复看。Kiro在那个模块里不仅讲了如何配 VPC endpoint,还教了怎么用 AWS PrivateLink 把 SageMaker 推理端点暴露给同 VPC 内的应用,同时避免公网暴露。军规清单:6 条机器学习网络配置止血规则踩了三天的坑,补完Kiro,我把这段经历压缩成了 6 条团队必须遵守的网络规则。这些规则现在贴在我们内部文档的《机器学习项目上线检查表》第一页:训练实例禁止绑定入站0.0.0.0/0规则;入站仅允许来自 VPC CIDR 的 SageMaker 控制面端口(443)。所有数据平面流量(S3、ECR、CloudWatch Logs)必须走 VPC endpoint,禁止经 NAT 网关绕行公网。ECR 拉取镜像需要同时放通ecr.api、ecr.dkr和 S3 三个 endpoint,漏一个都会导致 layer download 超时。私有子网的路由表中,到 S3 和 ECR 的路由必须指向对应的 VPC endpoint,别让流量跑错出口。每开一个训练作业前,先在 VPC 流日志里 grep 目标资源域名,确认没有走公网 IP 后才放量训练。把Kiro里的 VPC 实验复现一遍--跟着动手配一次,比看十遍文档都有用。如果你还没学过机器学习基础,点进去看看它的网络模块,哪怕只刷那一节也能让你少付一次「天价」NAT 账单。这六条规则背后,每一项都是真金白银买来的教训。而最后一条,是我补完Kiro后最大的感受:在机器学习项目里,特征存储的延迟、数据漂移的监控、混淆矩阵的解读固然重要,但如果你连训练实例的网络都通不了,这些高阶优化根本无从谈起。如果你也正卡在类似的网络问题上,或者准备把AWS 机器学习工作负载推上线,建议先花一个下午把Kiro里网络那一章走完。它不会让你成为网络专家,但绝对能帮你避开我这三天里踩过的每一颗雷。