AWS把S3访问藏了2条路径，选错每月白烧几千块

2023年Q3，AWS S3存储了超过350万亿个对象。但有个冷知识：90%的工程师不知道访问这350万亿对象时，AWS其实给了两条完全不同的"暗道"——选错那条，账单能差出一个程序员的月薪。

这不是配置错误，是设计选择。而大多数人在设计阶段就埋了雷。

Gateway Endpoint：AWS的"免费高速公路"

想象你住在一个封闭式小区，S3是小区外的超市。Gateway Endpoint就像物业偷偷修了一条地下通道，直接从你家单元门通到超市后门——不经过地面，不收费，也不占小区停车位。

技术实现上，它不创建弹性网络接口（ENI），不消耗子网IP地址，只在你的路由表里加一条前缀列表（Prefix List）。所有发往S3的流量被自动重定向到这条内部路径。

成本？零。没有小时费，没有数据处理费。AWS把这个当基础设施福利送。

但有个致命限制：这条地下通道只通小区内部。你的笔记本电脑连了VPN想进小区再用这条道？不行。隔壁小区的朋友想借道？也不行。它锁死在单个VPC的边界内。

这解释了为什么很多混合云架构的团队会踩坑——他们在本地数据中心放了台服务器，想通过VPN访问S3，发现Gateway Endpoint根本不可见。就像你站在小区外，地下通道的入口对你不存在。

Interface Endpoint：付费买一张"万能门禁卡"

Interface Endpoint走的是另一条逻辑。它在你的子网里创建一个真实的ENI，分配私有IP，像一台虚拟服务器坐在那里。所有S3流量先打到这个IP，再被转发。

这带来两个直接后果：

第一，计费开始运转。每小时每个可用区收费，每GB数据处理再收一层。一个跨3个可用区的中等规模架构，月费轻松过百美元。

第二，网络边界消失。因为这个ENI有真实的私有IP，它可以通过Direct Connect或Site-to-Site VPN被外部网络访问。本地机房、其他VPC、甚至其他AWS账号，都能把它当作S3的本地代理。

原文作者Pangoro24在第一篇里用Interface Endpoint搞定了SSM访问。那个场景需要跨网络边界的灵活性，Interface是正确选择。但如果你的EC2和S3 bucket已经在同一个VPC里，这笔开销就是纯浪费。

关键区分点：Gateway是"VPC内部优化"，Interface是"网络边界穿透"。需求错配，钱就白烧。

实战决策树：3个问题省掉90%的无效支出

原文作者在GitHub更新了Demo仓库，把两种配置都放了进去。但配置之前，建议先回答这三个问题：

流量是否100%源自本VPC内的EC2、Lambda或其他计算资源？是→Gateway。否→继续问。

是否需要从本地数据中心、其他VPC或跨账号环境访问S3？是→Interface。否→继续问。

是否使用了需要Interface Endpoint的特定S3功能（如S3 Object Lambda）？是→Interface。否→回到第一题，确认你没漏掉什么。

一个常见误区：很多人以为Interface Endpoint"更现代"或"更安全"，于是无脑选它。实际上两者在传输加密、IAM策略支持上完全一致。AWS没有 deprecate Gateway的计划，免费选项不会被淘汰。

另一个隐蔽成本：Interface Endpoint按可用区计费。如果你的EC2在us-east-1a，S3 bucket默认跨区，但Endpoint只在1a部署，流量会被强制留在1a，可能绕远路。多可用区冗余部署，费用直接翻倍。

一个被忽视的混合场景

有些架构同时需要两者。比如主应用在VPC-A用Gateway Endpoint免费访问S3，但审计系统部署在VPC-B，需要跨VPC访问同一个bucket。这时候VPC-A保持Gateway，VPC-B部署Interface，比强制统一成Interface省下一半成本。

AWS文档不会主动告诉你这种组合策略。他们的示例架构通常假设单一网络拓扑。

原文的Demo仓库地址藏在第一段链接里，包含Terraform配置和流量抓包验证。作者Pangoro24是拉美区的解决方案架构师，这套内容最初用西班牙语写成，被翻译成英文后在Dev.to获得2.3k赞——说明这个痛点足够普世。