費用と停止｜クラウドの基本・IAM・責任

このページはプロモーション（広告）を含みます。

クラウドの基本・IAM・責任（中級・読む30分＋演習40分）

この授業のゴール

• クラウドの費用を、計算時間・保存容量・データ転送・リクエスト数などの項目に分け、架空の単価表から月額を見積もれる
• 見積もりの仮定（使用量・単価・無料枠・含めない項目）を表にして明示できる
• 「停止」と「削除」で止まる費用・残る費用を区別し、停止後も課金が続く資源を見つけられる
• 無料枠や予算の通知を費用の上限装置とみなさず、上限・自動停止・タグ・棚卸しを組み合わせた歯止めを設計できる

仕事でどう使うか

クラウドの請求は、使い方を誤ると静かに増え続けます。検証用に作ったサーバーの消し忘れ、外部への大量のデータ転送、漏れた鍵による不正利用などで、気づいたときには予算を大きく超えていた、という事例は珍しくありません。費用を見積もり、止め方まで設計することは、技術の仕事の一部です。

この授業の単価はすべて教材用の架空の値で、実在のサービスの料金ではありません。実際の料金体系・無料枠・通知の機能は提供者ごとに異なり、頻繁に変わります。執筆時点（2026年）の一般的な説明として読み、見積もりの前に必ず公式の料金表で確認してください。演習は端末内の計算だけで完結し、実際の課金は発生しません。

前提

次の内容を使います。

• 固定費と従量課金、損益分岐時間 → クラウドとオンプレミス
• 計算・保存・ネットワークの種類 → 計算・保存・ネットワーク
• リージョンと複製（複製は保存と転送の費用を増やす）→ リージョンと可用性
• IAMと最小権限（資源を作れる権限は費用を生む権限）→ IAMと最小権限
• GB（ギガバイト）：データ量の単位。この教材では 1TB＝1,000GB として計算します（提供者によって 1,024 を使う場合があります）。

Pythonでは、辞書と for 文、max() を使います。

身近な状況：試作が終わったのに請求が続く

みなと商店の分析者が、商品の需要予測モデルを試作しました。試作期間の1か月、架空の単価で計算すると次の費用でした。

試作が終わり、分析者はサーバーを「停止」しました。ところが翌月も、そのまた翌月も請求が来ています。調べると次のものが残っていました。

• サーバーに付けていたディスク（200GB）：停止しても容量の料金がかかり続ける。
• 実験の途中で取ったスナップショット（ディスクの複製）5個：合計800GB。
• 試作中に一度作って消し忘れた別のサーバー：検証用で、ずっと動いていた。

さらに、「無料枠があるから大丈夫」と考えていた別のチームでは、無料枠を超えた分がそのまま請求されていました。

この授業では、費用を項目に分けて見積もる方法と、止める・消す・残すを正しく区別する方法を学びます。

直感的な説明：電気・倉庫・宅配の請求書

クラウドの請求は、性質の違う3種類の請求書が合わさったものだと考えるとわかりやすくなります。

• 電気代（計算）：機械を動かした時間だけかかる。スイッチを切れば止まる。
• 倉庫代（保存）：物を置いている間ずっとかかる。機械を止めても、荷物（ディスク・スナップショット・保存ファイル）を置いている限り続く。
• 宅配便の送料（データ転送）：外へ送った量だけかかる。受け取る側（クラウドへの入力）は無料のことが多いが、外へ出す量が多いと高くなる。

ほかに、窓口の手数料（リクエスト数）のように回数で数える項目もあります。

「停止」は電気のスイッチを切ることで、倉庫代は止まりません。「削除」は荷物ごと処分することで、費用は止まりますが元に戻せません。何を残し、何を消すかを決めてから操作します。

無料枠は「最初の何時間・何GBまでは無料」という割引で、それを超えた分は請求されます。予算の通知は「使いすぎです」と知らせる火災報知器のようなもので、多くの場合、自動で火を消す（資源を止める）装置ではありません。

正確な定義：費用の項目と、停止・削除・上限

• 月額費用の見積もり：項目 $i$ の使用量を $q_i$、単価を $p_i$、無料枠を $f_i$ とすると、

$$C = \sum_{i} p_i \times \max(0,\ q_i - f_i)$$

$\max(0,\ \cdot)$ は「無料枠のほうが大きいときはマイナスにせず0にする」ための記号です。例：仮想サーバー $q=60$ 時間、$f=0$、$p=120$ 円なら 7,200円。リクエストが $q=3{,}000$ 千回、$f=1{,}000$ 千回、$p=0.4$ 円/千回なら $0.4 \times 2{,}000 = 800$ 円。

• 費用の主な項目（一般的な分類。名称と単位は提供者ごとに異なる）：

• 停止（stop）：計算資源を止めること。ディスクやデータは残り、再開できる。
• 削除（delete / terminate）：資源をなくすこと。費用は止まるが、データは戻らない。必要なものはバックアップや別の保存場所に移してから削除する。
• 孤立した資源：本体を削除した後に残った付属品（ディスク、スナップショット、IPアドレス）や、誰のものかわからなくなった資源。費用が続くうえ、管理されないまま放置される。
• タグ（ラベル）：資源に付ける「キー＝値」の札。例：owner=sato、project=demand-poc、expires=2026-06-30。費用の部門別集計や、期限切れの資源の発見に使う。
• 予算の通知：月の費用が設定額に近づいたら知らせる仕組み。多くの場合、通知だけで資源は止まらない（自動の操作を追加で設定できるサービスもある）。
• 上限（クォータ）：作れる資源の数や量の上限。上限を低くしておくと、鍵が漏れたときなどの被害の最大値を抑えられる。

段階付き例題：需要予測バッチの月額を見積もる

問題：毎日1回、需要予測のバッチ処理を動かす。月額を見積もり、仮定を明示する（単価・無料枠は架空）。

ステップ1：使用量を見積もる。

ステップ2：単価表と無料枠を当てる。

ステップ3：項目ごとに計算する。

• 計算：$120 \times \max(0, 60-0) = 7{,}200$ 円
• 保存：$3 \times (500-5) = 1{,}485$ 円
• 転送：$15 \times (45-10) = 525$ 円
• リクエスト：$0.4 \times (3{,}000-1{,}000) = 800$ 円
• 合計：$7{,}200+1{,}485+525+800 = 10{,}010$ 円

ステップ4：Pythonで確かめる。

prices = {"compute_h": 120, "storage_gb": 3, "egress_gb": 15, "req_k": 0.4}   # 架空
free   = {"compute_h": 0,   "storage_gb": 5, "egress_gb": 10, "req_k": 1000}   # 架空
usage  = {"compute_h": 60,  "storage_gb": 500, "egress_gb": 45, "req_k": 3000}

total = 0
for k in usage:
    billable = max(0, usage[k] - free.get(k, 0))
    cost = prices[k] * billable
    total += cost
    print(f"{k:<11} 使用 {usage[k]:>6} 課金対象 {billable:>6} -> {cost:>8,.0f} 円")
print(f"合計 {total:,.0f} 円/月")

usage_forgot = dict(usage, compute_h=720)   # 停止を忘れて1か月動かし続けた場合
c = sum(prices[k] * max(0, usage_forgot[k] - free.get(k, 0)) for k in usage_forgot)
print(f"停止忘れの場合 {c:,.0f} 円/月")

出力：

compute_h   使用     60 課金対象     60 ->    7,200 円
storage_gb  使用    500 課金対象    495 ->    1,485 円
egress_gb   使用     45 課金対象     35 ->      525 円
req_k       使用   3000 課金対象   2000 ->      800 円
合計 10,010 円/月
停止忘れの場合 89,210 円/月

ステップ5：仮定と感度を書く。最大の項目は計算（約72%）で、停止を忘れると約9倍になります。したがって、見積もりと同時に「処理が終わったら自動で計算資源を止める」仕組みを要件に入れます。含めていない項目（ログの保存、監視、ディスク）も仮定として列挙します。

操作して理解する：停止後も残る費用を棚卸しする

試作の後片付けで、資源の一覧から「今も費用が発生しているもの」を探します。状態 state が stopped の仮想サーバーは計算の費用が止まり、ディスクやスナップショットは状態に関係なく容量の費用がかかる、という模擬です。

# 1か月あたりの架空単価
VM_PER_HOUR, DISK_PER_GB, SNAP_PER_GB, IP_IDLE_PER_HOUR = 120, 4, 2, 1
HOURS = 720
resources = [
    {"id": "vm-train",  "type": "vm",       "state": "stopped", "tags": {"owner": "sato", "project": "demand-poc"}},
    {"id": "disk-1",    "type": "disk",     "gb": 200,  "attached_to": "vm-train", "tags": {"owner": "sato"}},
    {"id": "snap-1..5", "type": "snapshot", "gb": 800,  "tags": {}},
    {"id": "vm-test",   "type": "vm",       "state": "running", "tags": {}},
    {"id": "ip-1",      "type": "ip",       "attached_to": None, "tags": {}},
]
total = 0
for r in resources:
    if r["type"] == "vm":
        cost = VM_PER_HOUR * HOURS if r["state"] == "running" else 0
    elif r["type"] == "disk":
        cost = DISK_PER_GB * r["gb"]
    elif r["type"] == "snapshot":
        cost = SNAP_PER_GB * r["gb"]
    elif r["type"] == "ip":
        cost = IP_IDLE_PER_HOUR * HOURS if r["attached_to"] is None else 0
    total += cost
    owner = r["tags"].get("owner", "不明")
    print(f"{r['id']:<10} {r['type']:<9} 所有者={owner:<5} {cost:>7,} 円/月")
print(f"合計 {total:,} 円/月")

出力：

vm-train   vm        所有者=sato        0 円/月
disk-1     disk      所有者=sato      800 円/月
snap-1..5  snapshot  所有者=不明      1,600 円/月
vm-test    vm        所有者=不明     86,400 円/月
ip-1       ip        所有者=不明        720 円/月
合計 89,520 円/月

読み取れること：

• 停止したサーバー（vm-train）は0円でも、そのディスクとスナップショットで月2,400円かかっています。
• 最大の費用は、所有者タグのない消し忘れのサーバー（vm-test）です。タグがないと、誰に確認すればよいか、消してよいかが判断できません。
• 「使われていない固定IP」のように、使っていないことで課金される資源もあります（この扱いは提供者により異なる）。

片付けの手順は「(1) 所有者に確認 → (2) 必要なデータを保存場所へ退避 → (3) 削除 → (4) 翌日の費用で減ったことを確認」です。

発展：費用の歯止めを重ねる

費用の事故は、1つの仕組みだけでは防げません。性質の違う歯止めを重ねます。

通知の遅れ：請求の集計は一般にリアルタイムではないため、鍵の漏洩による大量作成のような急な増加には、通知より上限と権限のほうが効きます。

転送費用の設計：大量のデータを外へ出す処理（利用者への動画配信、別リージョンへの複製、他社クラウドへの移行）は、転送費用が支配的になることがあります。保存場所と計算を同じリージョンに置く、結果だけを転送する、などで減らせます（保存・計算・転送の費用の詳細は 「転送・計算・保存費用」（有料版）、費用上限の仕組みは 「費用上限と停止」（有料版））。

よくある失敗

失敗1：無料枠を「費用の上限」だと思う

誤った理解：「無料枠の範囲で使うから0円」として、学習用サーバーを大きめにし、上限も通知も設定しなかった。

free_hours, price = 750, 120   # 架空：月750時間までの無料枠は小さいサーバーだけが対象、という条件だった
used_hours_large = 300         # 実際に使ったのは無料枠の対象外の大きいサーバー
print("想定:", 0, "円")
print("実際:", used_hours_large * price, "円（無料枠の対象外）")
used_small = 900               # 対象のサーバーでも、枠を超えれば請求される
print("対象サーバーで枠超え:", max(0, used_small - free_hours) * price, "円")

出力：想定: 0 円、実際: 36000 円（無料枠の対象外）、対象サーバーで枠超え: 18000 円。

なぜ誤りか：無料枠は「条件を満たす使い方の、一定量までの割引」で、対象の種類・期間・量に条件があり、超えた分や対象外の分は請求されます。使いすぎを止める仕組みではありません。

直し方：無料枠の条件（対象・量・期間）を公式情報で確認して見積もりに書き、別に予算の通知と上限を設定する。

失敗2：「停止したから費用はかからない」と考える

誤った理解：試作のサーバーを停止したので、費用は0円になったと報告した。

なぜ誤りか：停止で止まるのは計算の費用だけです。ディスク・スナップショット・使っていないIPアドレスなどは、停止中も費用が続きます（操作して理解するの例では、停止後も月2,400円以上）。

disk_gb, snap_gb = 200, 800
print("停止中も続く費用:", disk_gb * 4 + snap_gb * 2, "円/月（架空単価）")

出力：停止中も続く費用: 2400 円/月（架空単価）

直し方：試作の終了時は「停止」ではなく、残すもの・消すものを一覧にして判断する。残すデータはオブジェクト保存などの安い保存先へ移し、不要なディスク・スナップショットは削除する。削除前に所有者と、復元が必要かを確認する。

失敗3：外部への転送費用を見積もりから落とす

誤った見積もり：予測結果のファイルを利用者がダウンロードする仕組みで、計算と保存だけを見積もった。

egress_price = 15            # 円/GB（架空）
downloads_gb = 2 * 1000      # 月2TB（1TB=1,000GBで計算）
print("見積もり漏れの転送費用:", egress_price * downloads_gb, "円/月")

出力：見積もり漏れの転送費用: 30000 円/月

なぜ誤りか：クラウドから外へ出るデータ転送には、一般に量に応じた費用がかかります。ダウンロードが多い用途では、計算や保存より大きくなることがあります。

直し方：見積もり表に「外部への転送量」の行を必ず置き、ダウンロード回数×ファイルサイズで見積もる。ファイルの圧縮、必要な列だけの出力、配信網の利用（料金体系は公式で確認）なども検討する。

まとめ

• 費用は計算（時間）・保存（GB・月）・転送（GB）・リクエスト（回数）などの項目に分け、単価×max(0, 使用量−無料枠) で見積もる。
• 単価・無料枠は架空または変わり得るものとして扱い、使用量の根拠・含めない項目を仮定として明記する。
• 停止で止まるのは一般に計算の費用だけ。ディスク・スナップショット・未使用のIPなどは残る。削除は戻せない。
• 無料枠も予算の通知も上限装置ではない。上限（クォータ）・権限・自動停止・タグ・棚卸しを重ねる。
• 停止忘れや転送量の見落としは、費用を何倍にもする。見積もりと同時に止め方を設計する。

用語

無料枠（free tier）

条件を満たす使い方について、一定量まで料金がかからない割引。超えた分や対象外は請求される。

データ転送（外向き）（data transfer out / egress）

クラウドから外部へデータを送ること。一般に量に応じて課金される。

スナップショット（snapshot）

ある時点のディスクの複製。保存している間、容量の費用がかかる。

タグ（tag / label）

資源に付けるキーと値の札。所有者・案件・期限などを記録し、費用の集計や棚卸しに使う。

上限（クォータ）（quota）

作れる資源の数や量の上限。被害や使いすぎの最大値を抑える。

孤立した資源（orphaned resource）

本体の削除後に残った付属品や、所有者がわからなくなった資源。

よくある質問

なぜ分析者やエンジニアが費用を見積もる必要があるのですか？

費用を決めるのは技術的な選択（サーバーの大きさ、動かす時間、保存するデータの量、転送の仕方）だからです。経理や管理者は請求書を見られますが、どの処理を止めれば減るかはわかりません。見積もりと停止の設計は、作った人の責任です。

停止と削除はどう使い分けますか？

近いうちに再開するなら停止（ディスクの費用は残る）、使い終わったなら削除（データは戻らない）です。迷う場合は、必要なデータだけを安い保存先へ移してから削除し、再開時は構成をコードから作り直せるようにしておくと安全です（構成のコード化は 「構成をコード化」（有料版））。

見積もりと実際の請求がずれるのはどこですか？

使用量の見積もり（処理時間・データ量・アクセス数）のずれ、見積もり漏れの項目（転送・ログ・スナップショット・固定IP）、無料枠の条件の誤解、停止忘れが典型です。請求の内訳を項目別・タグ別に毎月見て、見積もりとの差を記録します。

使用量が10倍になったら費用も10倍になりますか？

従量課金の項目はおおむね比例しますが、無料枠の分だけ比例より速く増えたり、量が多いと単価が下がる段階制の料金があったり、一定の上限を超えると別の構成が必要になったりします。主要な項目について、使用量を変えたときの費用を計算しておく（感度の確認）と安心です。

仕事で費用の上限をどう提案すればよいですか？

見積もり額に余裕を持たせた予算額を決め、50%・80%・100%で通知、作れる資源の上限、資源を作れる権限の限定、夜間・休日の自動停止、所有者・期限のタグの必須化、月1回の棚卸しをセットで提案します。超過時に誰が何を止めるかの手順も決めておきます。

確認問題

次に学ぶこと

これでCL01の6授業は終わりです。モジュールの総合テストと、自力課題（データ処理の権限図と費用の仮定を作る）に進んでください。

次のモジュール ストレージ・DWH・レイク（有料版） では、保存の形式・データウェアハウス・データレイクと、その費用（「転送・計算・保存費用」（有料版））を学びます。費用の上限と停止の仕組みを構成として作る方法は 「費用上限と停止」（有料版） で扱います。