請求書の四行

一言でいうと

クラウドの料金は、結局4つの軸に整理されます。起動していた時間、保存した量、移動した量、呼び出した回数です。どの軸でお金が出ていくのかがわかれば、最適化の方向が決まります。

なぜ必要なのか

クラウドの料金は、サーバーの価格1つではなく、実行時間、ストレージの容量とリクエスト、データ転送、マネージド機能の合計です。1つの軸だけを減らすと、別の軸のコストが大きくなることがあるので、請求書はリソースの種類ではなく、コストが発生する原因ごとに読む必要があります。

どう動くのか

4つの軸

軸	課金の基準	減らす方法
コンピューティング	インスタンス×時間	サイズの縮小、使わないときは止める、コミットメント割引
ストレージ	GB×月	ライフサイクルポリシー、安価な階層、削除
データ転送	GB(主に外へ出る方向)	経路の再設計、キャッシュ、圧縮
リクエスト/オペレーション	呼び出し回数	バッチ処理、キャッシュ

「使わないときは止める」が最初の行にあるのが核心です。開発・ステージング環境を平日の業務時間だけ起動すれば、それだけで約70%減ります(24×7=168時間のうち、9×5=45時間だけを使用)。

コミットメント割引の構造

同じインスタンスでも、どう買うかで値段が大きく変わります。

方式	割引	条件
オンデマンド	なし	いつでも起動して停止できる
コミットメント(1–3年)	30–60%	期間を約束する。使わなくても支払う
スポット/プリエンプティブル	60–90%	いつでも回収される可能性がある

スポットは割引幅が圧倒的ですが、突然回収されます。そのため、中断されても構わない作業にだけ使います。バッチ、CIランナー、リトライ可能なキューのコンシューマーなどです。状態を持つサービスに使うと事故になります。

コミットメントはその反対です。最小のベースライン(baseline)の分だけコミットし、変動分はオンデマンドで埋めるのが定石です。ピークを基準にコミットすると、遊ばせた分だけ損をします。

ストレージの階層

アクセス頻度によって、値段が10倍以上違います。

자주 접근  →  가끔  →  드묾  →  보관용(아카이브)
비쌈                              가장 쌈, 꺼내는 데 시간·요금

ライフサイクルポリシーで自動的に移動させます。「30日経ったら低頻度、90日経ったらアーカイブ、365日経ったら削除」のようなルールです。これを設定しないと、ログが何年分もたまって、最も高い階層にそのまま残ります。

注意: アーカイブ階層は、取り出すときに料金と時間がかかります。よく見るデータを入れると、かえって高くなります。

隠れている料金

請求書を初めて見ると、理解できない行がいくつかあります。

• 割り当てられているのに使っていないもの: インスタンスから切り離されたボリューム、アタッチされていない固定IP。どちらも存在するだけで課金されます。
• スナップショットの蓄積: 自動スナップショットに保持ポリシーがないと、ずっとたまり続けます。
• ログの保存: ログの収集を有効にして、保持期間を無制限にしている場合です。
• NATゲートウェイ: 前のコースで扱ったものです。
• リージョン間のレプリケーション: 有効にしたまま忘れやすいものです。

タグがなければ何もできない

コストを減らすには、まず誰が何をなぜ作ったのかを知る必要があります。タグがその役割を果たします。

Owner       = platform-team
Env         = prod | stage | dev
Service     = payments
CostCenter  = 1042

タグのルールは、リソースが少ないうちに決めないと守られません。数百個がタグなしでたまったあとでは、さかのぼって付けるのは事実上不可能です。また、タグのないリソースの作成をポリシーで禁止しておけば、ルールはひとりでに守られます。

現場での姿

• 開発環境を夜も起動したままにして、コンピュートのコストが本番環境と同程度になっています → まずスケジュールを見ます。
• 切り離されたボリュームを消せません → オーナーのタグがなく、使っているかどうかを判断できません。
• アーカイブに移したのにコストが増えました → 復元の頻度まで含めた総コストを見ていませんでした。

次に見ること

4つの軸のなかで最も過小評価されやすいもの、データ転送です。