本文以案例形式介紹對象存儲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天的存儲費用。
為幫助您更經濟地使用深度冷歸檔存儲,請參見深度冷歸檔存儲使用最佳實踐。