決定好雲端元件畫完架構圖後我們要來做成本的估算，在使用雲端資源時成本估算是非常重要的一環就，各大雲端平台針對每個元件都有公開的定價可供參考，通常都是一系列複雜的公式來計算費用，但是整個系統的雲端元件使用數量會非常多，如我我們想要快速的估算一個金額，CSP 通常會提供一個簡單的計算機工具方便我們估算成本，我們這裡就使用 GCP 提供的計算機來估算一下我們的成本。

這裡大致說明一下每個元件設定的依據

Cloud Run

CPU 跟 Memory 就不多說明

CPU Allocation: 是只 你的 Cloud Run CUP 在 Request 結束時是否會保留 CPU 資源做運算，通常適合一些有後台處理的應用場景，我們這裡並不需要，而且開啟 Allocation 費用會提升我們這裡就選擇關閉

Minimum number of instances: 最小的實體數量，通常對外部開放的服務至少都會給到 1 個，不然這種 Serverless 的服務都會有 Cold start 的問題，我們給他最少 1 個，可以降低 Cold start 發生的機率

Number of requests per month (million): 每個月的 Request 數量

Execution time per request (ms): 每個 Request 所需的時間

Number of concurrent request per instance: 每個 Instance 同時可以處理的Request

Cloud Run 是根據 CPU 運算時間來做計費的，所以會需要以上三種資訊來估算費用

最後的 Committed use discounts 是保證使用給的折扣，基本上很多元件都有，但我們只是窮小子練習，不考慮。

Redis

Service tier: 主要就是有沒有HA機制，會增加成本不考慮使用HA

Storage amount: 雖然我們用不到那麼多，但最小只能 1GB

Average hours per month: 開啟時間，基本上沒事不會去關掉，就都給 730 小時

Pub/Sub

Amount of published data daily: 每天推送的訊息數，我們的使用情境原則上不會超過 1GB

Topic retention days: 訊息保存天數，不會超過 1 天

Number of subscriptions: 訂閱數量，我們只有 1 個訂閱

Retention storage: 保留處理過的訊息，會增加成本不需要，且都持久化存入DB了

Snapshot storage: 快照，預防資料丟失，會增加成本不需要

Cloud SQL

Cloud SQL Edition: Plus 有更高的硬體設備可以選擇，我們不需要

Number of instances: 實體數量

Total instance usage time: 運行時間

我們只有 1 個 DB，且不會做關閉的動作

CPU 跟 Memory 就不解釋

Storage: 儲存空間，這裡要注意當容量不足時 Cloud SQL 會自動擴容，所以一開始可以開小一點降低成本

大致加總一下全部的雲端元件，我們的費用大致落在 150USD/Month 有點超出預算不過還行，每個月 5000NTD 不到可以跑一套峰值 3000RPS 的系統感覺還是挺划算的，如果用量沒那麼高費用還會稍低一些。

https://cloud.google.com/products/calculator