计费案例

本文以案例形式介绍对象存储OSS费用的计算方法,帮助您理解常见场景下的OSS使用成本。

注意事项

以下案例单价来自20241120日阿里云官网公布的OSS详细价格信息。单价的变动请以阿里云官网发布的数据为准。

案例一:OSS分发静态资源(高频访问)

李先生计划于202410月使用OSS在华东1(杭州)地域创建一个Bucket来托管静态网站。该Bucket中预计存放约505GB的数据,这些数据主要由HTML、CSS、JavaScript等类型的文件组成,并且选择了标准存储(同城冗余)类型进行存储。考虑到用户访问模式,李先生预估每天从早上8点到晚上12点之间,其网站平均每小时会收到大约1000GET请求;此外,在这个时间段内,由于用户浏览网页或下载资源等原因,预计每天会有大约5 GB的数据流量从OSS流向客户端。其本月支付总费用约为151.47‬元,计费明细如下:

操作

涉及计费项

计费项Code

单价

计费量

费用

存储了505 GB标准存储(同城冗余)类型文件

标准存储(同城冗余)容量

StorageZRS

0.15元/GB/月

505GB/月

75.75

每小时平均产生1000GET类请求

Get类型请求次数

GetRequest

0.01元/万次

1000次/小时×24小时×30

0.72

每天8:00~24:00时间段内外网流出流量约为5 GB

外网流出流量

NetworkOut

0.50元/GB

5GB/天×30

75

案例二:OSS分发静态资源 (低频访问)

张先生在20241001日于华东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 KB64 KB计算。因此,1000030 KB的文件计量存储量比实际存储量增加了10000×(64-30)KB(换算后约等于0.32 GB),总计量存储量=100 GB+0.32 GB=100.32 GB。

当月20号上传同名文件到OSS,导致OSS内原低频存储类型文件被覆写。而低频存储类型文件存储时间不足30天被覆写或删除,会收取剩余时间10天的存储费用。

案例三:CDN加速OSS静态资源分发

张先生在202410月使用OSS存放静态资源的同时,启用了阿里云CDN来加速这些资源的访问。根据统计,在这个过程中,从CDN边缘节点直接向客户端传输的数据量达到了90GB;当CDN边缘节点需要更新或首次请求特定文件时,CDN会回源至OSS拉取最新版本,这一过程产生的回源流量总计为60GB。此外,CDN边缘节点访问OSS以获取或验证文件信息时都会触发对OSS API的调用,这一过程共产生10,000API请求。其本月支付总费用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远距离传输加速

李先生于202409月在华东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

王先生于202409月在华东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跨地域容灾

王先生于20241001日在华东1(杭州)地域的Bucket A内存储了100 GB标准存储(同城冗余)类型的文件,并且从1002日起,Bucket A每天新增3 GB的文件。为了进一步提升数据的安全性和可靠性,防止因单一地域出现故障而导致的数据丢失或访问中断,王先生设置了跨区域复制功能,将数据同步至华东2(上海)地域的Bucket B内。这样一来,即使某个地域发生自然灾害、电力故障或其他不可预见的问题,王先生仍然可以使用另一个地域的数据,从而确保业务连续性。此外,Bucket ABucket 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 ABucket B平均每天产生20000次读写请求

PUT类型请求

PutRequest

0.01元/万次

600000

0.6

GET类型请求

GetRequest

由于Bucket ABucket B因跨区域复制规则存储了相同的100GB两份数据,因此存储容量为200GB。

1002日起Bucket A每天新增3 GB的文件,截至1031日共30天内,Bucket A新增的数据量为90GB(3 GB/天×30天) ,因跨区域复制规则Bucket B也同步新增了90GB数据,因此新增存储容量为180GB。

案例七:自动转储和清理OSS数据

示例一:数据从标准转为归档后删除

王先生于20240901日在华东1(杭州)地域的Bucket存储了150万个文件(假设所有文件的文件大小均大于64 KB),其存储总容量100 GB。所有文件均存放在目录dir下。为应对不同阶段数据的访问需求变化,王先生设置了以下生命周期规则:

  1. 第一阶段:数据初期需要频繁访问,所有dir目录下的文件以标准存储(同城冗余)状态进行存储。此阶段持续10天。

  2. 第二阶段:数据访问频率较低(单文件月访问不到1次)但仍需确保实时访问,所有dir目录下的文件转储为低频访问(同城冗余)存储类型。此阶段持续25天。

  3. 第三阶段:数据进入单文件90天访问不到1次的阶段,所有dir目录下的文件转储为归档(同城冗余)类型。此阶段持续5天。

  4. 第四阶段:数据进入不再需要保留的阶段。在数据以归档(同城冗余)类型存储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天。最低存储时长以ObjectLastModified时间(以标准类型开始存储的时间)开始计算。因此,该场景下将产生20天(即60-10-25-5)的归档存储不足规定时长容量费用。

示例二:数据从低频转为冷归档后删除

张先生于20240901日在华东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数据

王先生于20241001日在华东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.12GB/月

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天的存储费用。

为帮助您更经济地使用深度冷归档存储,请参见深度冷归档存储使用最佳实践