阿里云FC通过VPC内网访问RDS和OSS，原来这么简单又省钱！

你是不是也遇到过这样的问题：用函数计算（Function Compute，简称FC）处理业务逻辑时，需要频繁读写数据库或上传下载文件，结果发现公网访问不仅慢还贵？尤其当你把数据存在RDS里、文件放在OSS上的时候，每次走公网都像在烧钱。别急，今天我就来给你支个招——用阿里云的VPC内网打通FC和RDS/OSS，速度飞起，成本还降下来了！

为啥要让FC走VPC内网？

先说说背景。很多人一开始用FC，图省事直接让它走公网去连RDS或者OSS。听着好像没啥问题，但实际上隐患不少。

第一是安全风险。你的RDS如果开了公网IP，等于把数据库大门敞开，谁都能试着敲两下。虽然有白名单限制，但终究不如内网隔离来得安心。

第二是网络延迟高。公网绕一圈，响应时间动不动就几十毫秒起步，尤其是高频调用的场景，卡得你想砸键盘。

第三最扎心——费用高。OSS通过公网下载流量是要计费的，哪怕你只是跑个日志分析的小任务，一个月下来流量费可能比函数本身还贵。更别说有些地区公网带宽资源紧张，还限速。

聪明人都会选择：让FC接入VPC，走内网直连RDS和OSS。这样一来，数据不走公网，安全、稳定、速度快，关键是——便宜！

那具体怎么操作呢？手把手教你配置

别被“VPC”“专有网络”这些词吓到，其实整个过程就跟搭积木差不多，一步步来就行。

第一步：确认你的RDS和OSS已经在VPC里

大多数新创建的RDS实例默认就在VPC中，这个一般没问题。你只需要登录阿里云控制台，进RDS管理页面，看实例详情里的“网络类型”是不是“专有网络”。如果是，那就OK。

OSS稍微特殊点，它本身是全局服务，不隶属于某个VPC，但它支持VPC反向访问。也就是说，只要你给FC分配了VPC环境，并且授权它通过内网Endpoint访问OSS，就能走内网链路，不走公网。

第二步：为FC配置VPC权限

打开函数计算控制台，找到你要部署的函数，进入“编辑”页面。往下拉，有个“网络配置”选项，选择“专有网络”。

然后你需要填三个关键信息：

• VPC：选你RDS所在的那个VPC
• 交换机（vSwitch）：选和RDS同可用区的交换机，这样延迟最低
• 安全组：建议新建一个专门给FC用的安全组，别跟其他服务混用

这里划重点：安全组规则一定要放行出方向的流量，允许访问RDS的3306端口（或其他你用的数据库端口），以及OSS的内网Endpoint端口（一般是80或443）。

第三步：设置OSS内网Endpoint

很多人在这一步翻车——明明VPC配好了，但OSS还是走公网。为什么？因为你代码里写的OSS地址可能是公网域名，比如https://your-bucket.oss-cn-beijing.aliyuncs.com，这当然走公网。

正确做法是改成对应地域的内网Endpoint。比如你在华北2（北京），就应该用：
https://your-bucket.oss-cn-beijing-internal.aliyuncs.com

改完之后，FC在VPC内发起请求，就会自动走阿里云内部高速网络，速度嗖嗖的，而且不产生公网流量费用。

第四步：给FC角色加权限

光有网络还不行，还得有“通行证”。FC运行时是用一个RAM角色来访问其他云产品的。你需要确保这个角色有足够权限操作RDS和OSS。

推荐直接授予系统策略：
– AliyunOSSFullAccess（如果你对OSS操作频繁）
– 或者更精细地用自定义策略，只允许读写特定Bucket
– 对于RDS，不需要额外权限，因为连接靠的是数据库账号密码，但RAM角色要能通过VPC访问网络

配置完成后，保存并发布函数版本。等几秒钟部署完成，就可以测试了。

实测效果：快了多少？省了多少？

我拿自己项目做了个对比测试。一个简单的函数，每次从OSS下载10MB文件，处理后再写回另一个目录，同时往RDS插入一条记录。

走公网的情况：平均耗时约850ms，其中OSS下载占了600ms以上，而且每万次调用产生约10GB公网流出流量，按北京地区价格算，一个月下来流量费得小几百。

切换VPC内网后：平均耗时降到210ms，OSS下载基本在150ms内完成，RDS写入也稳定在30ms左右。最关键的是——OSS这部分流量完全免费！

别说省那点钱了，用户体验提升才是大头。以前用户上传文件要等好几秒，现在几乎是秒级响应，差评都少了。

常见坑点提醒，别踩雷！

虽然整体流程不复杂，但有几个容易忽略的细节，我帮你列出来，避免你走弯路。

1. 交换机必须和RDS同可用区

虽然同一个VPC，但如果FC的交换机在杭州可用区B，RDS在可用区E，跨可用区通信会有额外延迟，严重时甚至连接失败。尽量保持在同一可用区。

2. 安全组别忘了开出口

很多人只记得给RDS设白名单，却忘了FC所在安全组的出方向规则。默认情况下，安全组是拒绝所有出站流量的。你得手动添加规则，允许目标为RDS内网IP:3306，协议TCP。

3. DNS解析问题

FC在VPC内运行时，默认使用阿里云内网DNS。但如果你用了自建DNS或特殊解析规则，可能导致OSS内网域名无法正确解析。建议保持默认设置。

4. 冷启动时延略增

接入VPC后，FC每次冷启动需要额外时间挂载弹性网卡，通常会多花1~3秒。如果你对首请求延迟敏感，可以考虑开启预留实例，或者用HTTP触发器预热。

这种架构适合谁？

不是所有场景都需要上VPC，我给你总结几个典型适用情况：

• 你的函数需要频繁访问RDS，比如做订单处理、用户行为分析
• 大量文件上传/下载场景，比如图片压缩、视频转码、日志归档
• 对数据安全性要求高，比如金融、医疗类应用
• 已经用了VPC部署其他服务，希望统一网络架构

如果你只是偶尔调用一次API，或者根本不碰数据库和OSS，那其实没必要折腾VPC，省点事也挺好。

最后送你个福利：省上加省！

看到这儿，相信你已经跃跃欲试想动手配置了。不过别急，在你开通RDS、OSS或者升级配置之前，先去领个阿里云优惠券。新用户有很多满减券，老用户也有续费折扣，哪怕省个几十块也是肉啊。

特别是你要上生产环境，资源用量上来之后，这些优惠叠加起来可能直接帮你免掉一两个月的费用。我上次就是靠券白嫖了一个月的RDS基础版，省下的钱请团队喝了奶茶，大家都夸我会过日子 😄

结语：小改动，大收益

说实话，让FC走VPC内网访问RDS和OSS，技术上真没那么复杂。但就是这样一个小小的网络调整，能带来性能提升、成本下降、安全性增强三重好处。

云计算玩到拼的不是谁会堆高端配置，而是谁能把基础架构搭得又稳又省。这种“润物细无声”的优化，才是真正体现技术功力的地方。

别再让你的函数在公网上“裸奔”了。花半小时，把VPC打通，该走内网的就走内网。你会发现，原来云服务可以这么丝滑。

赶紧行动吧！配置过程中遇到问题欢迎留言，我可以帮你一起排查。