Azure Container Apps 中的計費
Azure Container Apps 中的計費是以您的 方案類型為基礎。
方案類型 | 描述 |
---|---|
取用方案 | 無伺服器計算選項,其中您只會針對應用程式執行時所使用的資源計費。 |
專用方案 | 針對配置給每個 工作負載配置檔的實例計費的自定義計算選項。 |
- 您的方案選擇會決定計費計算。
- 環境中的不同應用程式可以使用不同的方案。
本文說明如何計算執行容器應用程式的成本。 如需帳戶貨幣中的定價詳細數據,請參閱 Azure Container Apps 定價。
取用方案
在取用方案中執行的應用程式計費包含兩種類型的費用:
下列資源在每個行事曆月份、每個訂用帳戶中是免費的:
- 前 180,000 個 vCPU 秒
- 前 360,000 GiB 秒
- 前2百萬個 HTTP 要求
免費使用量不會出現在您的帳單上。 您只需要支付資源使用量超過每月免費授與金額的費用。
注意
如果您使用容器應用程式搭配 您自己的虛擬網路 ,或您的應用程式使用其他 Azure 資源,可能會收取額外費用。
資源耗用量費用
Azure Container Apps 會根據您針對每個修訂設定的 調整規則和複本計數限制 ,執行應用程式的複本。 觸發作業執行時,Azure Container Apps 作業 會執行複本。 執行時,系統會向您收取配置給每個複本的資源數量的費用。
資源耗用量有 2 公尺:
- vCPU 秒:每秒配置給容器應用程式的 vCPU 核心數目。
- GiB 秒:每秒配置給容器應用程式的記憶體數量。
每個日曆月每個訂用帳戶的前 180,000 個 vCPU 秒和 360,000 GiB 秒是免費的。
容器應用程式
您為資源耗用量付費的費率取決於容器應用程式修訂和複本的狀態。 根據預設,複本會以使用中費率收費。 不過,在某些情況下,複本可以進入 閑置 狀態。 處於 閑置 狀態時,資源會以較低的費率計費。
未執行任何複本
當修訂調整為零個復本時,不會產生任何資源耗用量費用。
正在執行的複本數目下限
當容器應用程式的修訂在特定情況下執行時,可能會套用閑置使用量費用。 若要符合閑置費用的資格,修訂必須是:
- 設定的複本 計數 下限大於零
- 調整為最小復本計數
使用量費用會針對每個復本個別計算。 當下列所有條件都成立時,複本會被視為閑置:
- 復本正在修訂中執行,該修訂目前符合閑置費用的資格。
- 復本中的所有容器都已啟動並正在執行。
- 復本不會處理任何 HTTP 要求。
- 復本使用小於0.01個 vCPU 核心。
- 復本每秒接收的網路流量少於1,000個字節。
當復本閑置時,資源耗用量費用會以較低的閑置率計算。 當複本未閑置時,就會套用使用中的速率。
超過執行中的複本數目下限
當修訂調整為高於 最小復本計數時,其所有執行中的複本都會以使用中速率支付資源耗用量的費用。
工作
在取用方案中,Azure Container Apps 作業所耗用的資源會收取使用費率。 閑置費用不適用於作業,因為執行會在作業完成之後停止耗用資源。
要求費用
除了資源耗用量之外,Azure Container Apps 也會根據容器應用程式收到的 HTTP 要求數目收費。 只有來自 Container Apps 環境外部的要求才能計費。
- 每個日曆月每個訂用帳戶中的前 2 百萬個要求是免費的。
- 健康情況探查 要求無法計費。
要求費用不適用於 Azure Container Apps 作業,因為它們不支持輸入。
專用方案
您會根據工作負載配置檔實例來計費,而不是由個別應用程式計費。
專用方案中執行的應用程式和作業計費是以工作負載配置檔實例為基礎,而不是個別應用程式。 費用如下:
固定管理成本 | 可變成本 |
---|---|
如果您的環境中有一或多個專用工作負載配置檔,則會向您收取專用方案管理費用。 除非您在環境中使用專用工作負載配置檔,否則不會向您收取任何方案管理費用。 | 隨著配置檔向外延展,額外的成本適用於額外的實例;隨著配置檔相應縮小,計費會減少。 |
請務必將部署至專用工作負載配置檔的應用程式優化。 評估應用程式的需求,讓應用程式可以使用配置檔可用的資源數量最多。
動態工作階段
動態工作階段有兩種類型的工作階段集區:程式代碼解釋器和自定義容器。 每個會話類型都有自己的計費模型。
程式代碼解釋器
程式代碼解釋器會話是根據配置會話數目的執行持續時間計費。 針對每個已配置的會話,您會從配置的時間計費,直到解除分配一小時為止。
自訂容器
自定義容器會話會根據 用來執行會話集區和使用中會話的計算資源數量,使用專用方案計費。
一般條款
- 如需帳戶貨幣中的定價詳細數據,請參閱 Azure Container Apps 定價。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應