トラフィック増加前に Cloud Run 費用を管理する

Cloud Run の費用は、各インスタンスに割り当てるリソースと、そのリソースが有効な時間に左右されます。現実的な負荷テストに耐える最小の CPU とメモリ設定から始め、Cloud Monitoring を見てから増やします。

リリース前は過剰に割り当てがちです。CPU 使用率が低いのに full vCPU を確保したり、必要以上のメモリを持たせたりすると、控えめなリクエスト量でも不要な月額費用につながります。

最小インスタンスはコンテナを warm に保ち、最初のリクエストを速くしますが、アイドル中のインスタンスにも費用が発生します。すべての API で有効にするのではなく、cold start がコンバージョンに影響するユーザー向け経路に絞って使います。

リクエスト間でもバックグラウンド処理が必要なら、そのサービスを分けて別に見積もります。そうでなければ、低トラフィックの管理ツール、Webhook、プロトタイプ、内部ジョブでは scale-to-zero が適していることが多いです。

サービスレベルの最大インスタンス数を早めに設定します。高い最大値は急増時の可用性を守りますが、bot、リトライ、キューの急増、誤設定されたクライアントによる請求リスクも大きくします。

最大インスタンスは、適切な同時実行、Cloud SQL・Firestore・Storage に近いリージョン配置、Billing アラートと合わせて考えます。リリース前に、楽観的なトラフィックと保守的なトラフィックの両方を計算機で比較してください。