阿里云oss免费额度

很多人开 OSS 是为了放图片、日志或给模型做数据集，看到「有免费额度」就直接开跑，结果月底账单出来发现流量和内网外网完全不是一回事。这篇不背数字，只帮你把免费额度管哪几件事、超出后按什么单位收、在哪一页核对当期价格理清楚，顺便给一套自查顺序，避免把「存储便宜」当成「用起来便宜」。

很多人开 OSS 是为了放图片、日志，或者给模型训练做数据集，看到「有免费额度」就直接开跑，结果账单出来才发现流量和内网外网完全不是一回事。这篇不背数字，只帮你理清免费额度管哪几件事、哪些操作不在里面、超出后按什么单位收，以及去哪一页核对当期口径。

先说结论：免费额度不是一张通用券，而是按存储、请求、流量几条线分开给的。任何一条单独跑超，都会单独产生费用，不会因为你其他项没用满就互相抵扣。所以「存储便宜」不等于「用起来便宜」，先想清楚用途再开通，比事后补救省事得多。

免费额度到底管哪几件事

免费额度一般拆成几条独立的线，每条有自己的计量单位和上限。你可以把它想成几张不同面额的券，各花各的，不通用。判断自己的用法会不会踩到某条线，比记住具体数字更重要。

免费额度覆盖的是基础的对象存储动作，很多「顺手用了」的功能其实走的是另一套计费单位。下面这几类是实际使用中最容易漏算的，提前知道能少踩坑。

操作类型	是否跟着存储额度免	需要留意的点
公网下行流量	基本不免	把 OSS 当图床直接给前端页面调用，量会涨得很快
归档、低频存储	不免额外费用	有最短存放期和解冻费用，提前删除或临时取回都可能另算
图片处理、样式转换	走另一套计费	别默认它跟着存储额度一起免，处理次数单独计
批量任务、数据迁移	按任务量计	跑一次大任务可能顶你一个月的存储用量

判断自己会不会中招，有个简单办法：回想你的数据「最后是怎么被用出去的」。如果只是备份存着，风险主要在存储时长；如果是给公网用户看，风险几乎一定在流量；如果有转换或处理，就要额外算一套。

如果你的 bucket 只对内网服务开放、从不对公网暴露，那么流量这一项基本可以忽略，重点就转移到存储容量和请求次数上。反过来，如果你的用法是公开图床或前端静态资源，流量就是首要矛盾，存储反倒不是重点。

超出的部分不会「一刀切」换成一个高价，而是各条线独立叠加：存储按容量乘时长、流量按实际外发量、请求按次数分档。三者相加，不是取其中最大值。所以估算时要把三笔账分开算，再合起来看总量。

先估月度量把「每天多少张图、多少 GB、多少次调用」先折算成一个月总量，别用单日峰值当平均值。
分开算三笔账存储、流量、请求各算一份，再相加。任何一笔算漏，估算都会偏乐观。
去站内核对单价当期单价和分档区间会调整，别记数字，到 /official-api/providers/alibaba 和 /price-watch 核对当前口径。
用工具换算拿不准自己是多少量，用 /tools/model-cost-calculator 这类工具先把用量换成费用区间。

特别提醒：单价和分档区间是会变的，别人截图里的数字过一阵就可能不准。写死的数字一律以站内当期页面为准，这也是为什么本文只讲口径、不给具体值。

开通前花十分钟做一遍下面的检查，比月底对着账单找原因轻松得多。这四步的顺序也是推荐的排查顺序：先定用途，再看额度，然后设限制，最后复盘。

先定用途明确是纯备份、做图床，还是给训练任务拉数据集。三种用途的计费大头完全不同，先定性再谈优化。
确认当期额度开之前先去控制台看当前地域的免费额度条目和有效期，别照搬别人的截图，地域和时间都可能不一样。
设预算告警和流量上限给 bucket 配预算告警和流量封顶，把跑飞限制在一晚以内，具体做法可参考 /guides/budget-alert-five-gates。
一周后复盘曲线上线一周后回来看用量曲线，判断是请求数先涨还是流量先涨，再决定要不要换存储类型或加缓存。

OSS 的免费额度是每个月都重置吗？

多数免费额度是按月给、按月刷新的，但也有只对新用户一次性发放的条目，还有带有效期的活动额度。别按「一定每月刷新」来规划，去控制台的费用中心确认你这张账号下每条额度的类型和到期时间，再决定要不要提前设告警。

只有存储超了才收费吗？

不是。存储、请求次数、下行流量是分开算的，很多时候存储还在免费范围内，流量早就超了。尤其是做图床或给公网页面直接引用文件的场景，流量往往是最先出账的那一项，建议优先盯这一条。

内网访问和外网访问的差别在哪？

同区域的内网互通一般不计流量费，走公网或跨区域才会。判断方法很简单：你的调用方和 bucket 在不在同一个地域、是不是通过内网地址访问。如果不是，那这部分外发量就是账单的主要来源，预算要按它来估。