本文以案例形式介绍对象存储OSS费用的计算方法,帮助您理解常见场景下的OSS使用成本。
注意事项
以下案例单价来自2024年11月20日阿里云官网公布的OSS详细价格信息。单价的变动请以阿里云官网发布的数据为准。
案例一:OSS分发静态资源(高频访问)
李先生计划于2024年10月使用OSS在华东1(杭州)地域创建一个Bucket来托管静态网站。该Bucket中预计存放约505GB的数据,这些数据主要由HTML、CSS、JavaScript等类型的文件组成,并且选择了标准存储(同城冗余)类型进行存储。考虑到用户访问模式,李先生预估每天从早上8点到晚上12点之间,其网站平均每小时会收到大约1000次GET请求;此外,在这个时间段内,由于用户浏览网页或下载资源等原因,预计每天会有大约5 GB的数据流量从OSS流向客户端。其本月支付总费用约为151.47元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
存储了505 GB标准存储(同城冗余)类型文件 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 505GB/月 | 75.75元 |
每小时平均产生1000次GET类请求 | Get类型请求次数 | GetRequest | 0.01元/万次 | 1000次/小时×24小时×30天 | 0.72元 |
每天8:00~24:00时间段内外网流出流量约为5 GB | 外网流出流量 | NetworkOut | 0.50元/GB | 5GB/天×30天 | 75元 |
案例二:OSS分发静态资源 (低频访问)
张先生在2024年10月01日于华东1(杭州)地域的Bucket中存储了总量达100GB的数据,这些数据被设定为低频访问(同城冗余)类型。其中,Bucket内包含了10000个大小为30 KB的文件。尽管大部分时间,这些文件并不需要频繁地被访问或修改。但在当月20号那天,由于业务需求紧急变更,急需对其中一个大小为1 GB的大文件进行即时处理。为此,张先生从OSS下载了该文件到本地,并根据最新的业务要求对其内容进行了必要的更新。完成修改后,为了保证信息的及时性和可用性,张先生将文件内容更新之后重新上传至OSS,更新后的文件大小仍为1 GB。其本月支付总费用约为10.5975元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
存储了100 GB的低频存储(同城冗余)类型文件 | 低频访问(同城冗余)容量 | ChargedDatasizeZRS | 0.10元/GB/月 | 100.32GB/月① | 10.032元 |
下载大小为1 GB的文件到本地 | 外网流出流量费用 | NetworkOut | 0.50元/GB | 1GB | 0.5元 |
低频访问数据取回容量 | RetrievalData | 0.0325元/GB | 1GB | 0.0325元 | |
上传的当月20号将1GB文件内容更新之后重新上传至OSS | 低频访问(同城冗余)不足规定时长容量 | LessthanMonthDatasizeZRS | 0.10元/GB/月 | 1GB存储10天② | 0.033元 |
①单个低频存储(同城冗余)类型的文件最小计量为64 KB,不足64 KB按64 KB计算。因此,10000个30 KB的文件计量存储量比实际存储量增加了10000×(64-30)KB(换算后约等于0.32 GB),总计量存储量=100 GB+0.32 GB=100.32 GB。
②当月20号上传同名文件到OSS,导致OSS内原低频存储类型文件被覆写。而低频存储类型文件存储时间不足30天被覆写或删除,会收取剩余时间10天的存储费用。
案例三:CDN加速OSS静态资源分发
张先生在2024年10月使用OSS存放静态资源的同时,启用了阿里云CDN来加速这些资源的访问。根据统计,在这个过程中,从CDN边缘节点直接向客户端传输的数据量达到了90GB;当CDN边缘节点需要更新或首次请求特定文件时,CDN会回源至OSS拉取最新版本,这一过程产生的回源流量总计为60GB。此外,CDN边缘节点访问OSS以获取或验证文件信息时都会触发对OSS API的调用,这一过程共产生10,000次API请求。其本月支付总费用30.61元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
数据从CDN边缘节点传输到客户端 | CDN下行流量 | cdn_flow_out | 0.24元/GB | 90GB | 21.6元(由CDN收取费用) |
数据从OSS传输到CDN边缘节点 | CDN回源流出流量 | CdnOut | 0.15元/GB | 60GB | 9元(由OSS收取费用) |
CDN边缘节点访问OSS时涉及调用OSS API请求 | GET类请求 | GetRequest | 0.01元/万次 | 10000次 | 0.01元(由OSS收取费用) |
案例四:OSS远距离传输加速
李先生于2024年09月在华东1(杭州)的Bucket部署了一个面向全球用户的热门应用,该应用中包含了视频和高清图片等多种类型的文件,总存储容量达到了2TB,并采用了标准存储(同城冗余)方案来保证数据的安全性和可靠性。为了优化非中国内地用户的访问体验,特别是针对需要下载或流式传输大文件的情况,李先生计划启用OSS提供的传输加速服务。这样一来,使用传输加速域名访问Bucket内的文件,可以显著降低数据传输延迟,提高响应速度。其本月支付总费用为3,891.2元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
存储了2TB标准存储(同城冗余)类型的文件 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 2TB/月 | 307.2元 |
通过传输加速域名从非中国内地访问华东1(杭州)地域的资源 | 传输加速AccO2MOut | AccO2MOut | 1.25元/GB | 2TB | 2,560元 |
外网流出流量 | NetworkOut | 0.50元/GB | 2TB | 1,024元 |
案例五:ECS挂载访问OSS
王先生于2024年09月在华东1(杭州)地域的Bucket内存储了1 TB容量的标准存储类型文件,并选择了同城冗余来增强数据的安全性和可用性。同月,同一地域的一台阿里云ECS实例通过OSS提供的内网地址对该Bucket中的文件进行了访问。在此过程中,产生了总计100 GB的内网流出流量、执行了大约10万次GET请求操作来获取或查看这些文件内容。通过该方式不仅提高了数据访问速度还降低了数据下行流量成本。其本月支付总费用153.7元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
存储了1TB标准存储(同城冗余)类型文件 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 1TB/月 | 153.6元 |
使用内网地址访问该Bucket中的资源 | 内网流出流量 | 不涉及 | 免费 | 100GB | 0元 |
访问Bucket资源产生的GET类请求 | GET类型请求 | GetRequest | 0.01元/万次 | 10万次 | 0.1元 |
案例六:OSS跨地域容灾
王先生于2024年10月01日在华东1(杭州)地域的Bucket A内存储了100 GB标准存储(同城冗余)类型的文件,并且从10月02日起,Bucket A每天新增3 GB的文件。为了进一步提升数据的安全性和可靠性,防止因单一地域出现故障而导致的数据丢失或访问中断,王先生设置了跨区域复制功能,将数据同步至华东2(上海)地域的Bucket B内。这样一来,即使某个地域发生自然灾害、电力故障或其他不可预见的问题,王先生仍然可以使用另一个地域的数据,从而确保业务连续性。此外,Bucket A和Bucket B平均每天处理的请求数量(包括PUT类型和GET类型请求)总计约为20000次。其本月支付总费用约为152.6元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
存储了100 GB标准存储(同城冗余)类型的文件 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 200GB/月③ | 30元 |
Bucket A每天新增3GB的文件 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 180GB/月④ | 27元 |
通过跨区域复制,将数据从Bucket A复制到Bucket B | 跨区域复制流量 | ReplicationDatasize | 0.50元/GB | 190GB | 95元 |
Bucket A和Bucket B平均每天产生20000次读写请求 | PUT类型请求 | PutRequest | 0.01元/万次 | 600000次 | 0.6元 |
GET类型请求 | GetRequest |
③由于Bucket A和Bucket B因跨区域复制规则存储了相同的100GB两份数据,因此存储容量为200GB。
④10月02日起Bucket A每天新增3 GB的文件,截至10月31日共30天内,Bucket A新增的数据量为90GB(3 GB/天×30天) ,因跨区域复制规则Bucket B也同步新增了90GB数据,因此新增存储容量为180GB。
案例七:自动转储和清理OSS数据
示例一:数据从标准转为归档后删除
王先生于2024年09月01日在华东1(杭州)地域的Bucket存储了150万个文件(假设所有文件的文件大小均大于64 KB),其存储总容量100 GB。所有文件均存放在目录dir
下。为应对不同阶段数据的访问需求变化,王先生设置了以下生命周期规则:
第一阶段:数据初期需要频繁访问,所有
dir
目录下的文件以标准存储(同城冗余)状态进行存储。此阶段持续10天。第二阶段:数据访问频率较低(单文件月访问不到1次)但仍需确保实时访问,所有
dir
目录下的文件转储为低频访问(同城冗余)存储类型。此阶段持续25天。第三阶段:数据进入单文件90天访问不到1次的阶段,所有
dir
目录下的文件转储为归档(同城冗余)类型。此阶段持续5天。第四阶段:数据进入不再需要保留的阶段。在数据以归档(同城冗余)类型存储5天后,删除所有
dir
目录下的文件。
针对以上场景,其本月支付总费用32.575元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
100GB文件以标准存储(同城冗余)类型存储了10天 | 标准存储(同城冗余)容量 | StorageZRS | 0.15元/GB/月 | 100GB存储10天 | 4.995元 |
100GB文件以低频访问(同城冗余)类型存储了25天 | 低频访问(同城冗余)容量 | ChargedDatasizeZRS | 0.10元/GB/月 | 100GB存储25天 | 8.33元 |
100GB文件以归档(同城冗余)类型存储了5天 | 归档(同城冗余)容量 | ChargedDataSizeArcZRS | 0.033元/GB/月 | 100GB存储5天 | 0.55元 |
100GB文件以归档(同城冗余)类型存储5天后删除 | 归档存储(同城冗余)不足规定时长容量 | LessthanMonthDatasizeArcZRS | 0.033元/GB/月 | 100GB存储20天⑤ | 2.2元 |
通过生命周期转换存储类型涉及请求操作 | 标准转低频访问请求费用 | PUT类请求 | 0.01元/万次 | 1500000次 | 1.5元 |
低频访问转归档请求费用 | PUT类请求 | 0.1元/万次 | 1500000次 | 15元 |
⑤归档(同城冗余)类型最低存储时长为60天。最低存储时长以Object的LastModified时间(以标准类型开始存储的时间)开始计算。因此,该场景下将产生20天(即60-10-25-5)的归档存储不足规定时长容量费用。
示例二:数据从低频转为冷归档后删除
张先生于2024年09月01日在华东1(杭州)地域的Bucket存储了2500万个文件(假设所有文件的文件大小均大于64 KB),其存储总容量为2.5 TB,所有文件均存放在目录dir
下。为应对不同阶段数据的访问需求变化,张先生设置了以下生命周期规则:
第一阶段:数据访问频率较低(单文件月访问不到1次)但仍需确保实时访问,所有
dir
目录下的文件以低频访问(本地冗余)的方式进行存储。此阶段持续100天。第二阶段:数据进入单文件90天访问不到1次的阶段,将所有
dir
目录下的文件转储为归档(本地冗余)类型。此阶段持续200天。第三阶段:数据进入单文件年访问不到1次的阶段,将所有
dir
目录下的文件转储为冷归档(本地冗余)类型。此阶段持续5天。第四阶段:数据进入不再需要保留的阶段。在数据以冷归档(本地冗余)类型存储5天后,删除所有
dir
目录下的文件。
基于以上场景,其支付总费用为1976.3元,计费明细如下:
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
2.5TB文件以低频访问(本地冗余)类型存储 100天 | 低频访问(本地冗余)容量 | ChargedDatasize | 0.08元/GB/月 | 2.5TB存储100天 | 682.7元 |
2.5TB文件以归档存储(本地冗余)类型存储200天 | 归档(本地冗余)容量 | ChargedDatasize | 0.033元/GB/月 | 2.5TB存储200天 | 563.2元 |
2.5TB文件以以冷归档存储(本地冗余)类型存储5天 | 冷归档(本地冗余)容量 | ChargedDatasizeCA | 0.015元/GB/月 | 2.5TB存储5天 | 6.4元 |
2.5TB文件冷归档存储(本地冗余)类型存储5天后删除 | 冷归档存储(本地冗余)不足规定时长容量 | ChargedDatasizeDeepCA | 0.015元/GB/月 | 2.5TB存储175天⑤ | 224元 |
通过生命周期转换存储类型涉及请求操作 | 低频访问转归档存储请求费用 | PUT类请求 | 0.1元/万次 | 2500万次 | 250元 |
归档存储转冷归档存储请求费用 | PUT类请求 | 0.1元/万次 | 2500万次 | 250元 |
⑦冷归档(本地冗余)类型最低存储时长为180天。最低存储时长以Object转储为冷归档类型的时间开始计算。因此,该场景下会产生175天的冷归档存储不足规定时长容量费用。
为避免产生不足规定时长容量费用,您需要了解不同存储类型Object的最低存储时长计算方法,确保满足其最低存储时长后再进行转储或者删除。更多信息,请参见如何避免产生存储不足规定时长容量费用?。
案例八:恢复极冷的OSS数据
王先生于2024年10月01日在华东1(杭州)地域的Bucket存储了大约6亿个文件,考虑到这些文件可能需要长期保留不需要频繁访问,起初选择了存储成本最低的深度冷归档类型进行存储,总容量达到了900TB。由于业务需求的变化,现在需要访问部分文件,这些文件占总容量的5%,涉及文件个数为3000万。基于深度冷归档文件的特点,对数据执行读取操作之前需要先完成解冻操作。假设深度冷归档设置的解冻状态持续时间为10天,在这期间OSS会生成一份标准存储(本地冗余)类型的文件副本用于临时访问。
基于以上场景,其本月支付的费用明细如下:
标准取回
按标准取回,支付的费用为7,682.64元。
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
解冻3000万个文件,占900TB总存储容量5% | 深度冷归档标准取回请求 | DeepCAStdRetrievalRequest | 1.67元/万次 | 3000万次 | 5,010元 |
深度冷归档标准取回容量 | DeepCAStdRetrievalData | 0.018元/GB | 45TB | 829.44 | |
生成一份标准存储(本地冗余)类型的文件副本供解冻状态持续时间10天内进行数据访问 | 临时存储容量 | TempStorageCAStd | 0.12元GB/月 | 45TB存储10天⑤ | 1,843.2元 |
高优先级取回
按高优先级取回,支付的费用为28,833.6元。
操作 | 涉及计费项 | 计费项Code | 单价 | 计费量 | 费用 |
解冻3000万个文件,占900TB总存储容量5% | 深度冷归档高优先级取回请求 | DeepCAHighPriorRetrievalRequest | 7 元/万次 | 3000万次 | 21,000元 |
深度冷归档高优先级取回容量 | DeepCAHighPriorRetrievalData | 0.13 元/GB | 45TB | 5,990.4元 | |
生成一份标准存储(本地冗余)类型的文件副本供解冻状态持续时间10天内进行数据访问 | 临时存储容量 | TempStorageCAStd | 0.12GB/月 | 45TB存储10天⑥ | 1,843.2元 |
⑥生成一份标准存储(本地冗余)类型的文件副本供解冻状态持续时间10天内进行数据访问,此时900TB的数据将按照标准存储(本地冗余)类型收取10天的存储费用。
为帮助您更经济地使用深度冷归档存储,请参见深度冷归档存储使用最佳实践。