💰 コスト最適化の設計原理

【コスト最適化の役割(設計のベストプラクティス)】

目次

🔍 1. 結論

💎 一言でいうと コスト最適化は、「必要な時に必要な分だけリソースを使用し、要件に合わせた最も安い支払いオプションを選択する」 設計原理です。無駄なプロビジョニングを避け、クラウドならではの価格モデル(スポット、リザーブド)を活用します。

  • 常時稼働するリソース → Reserved Instances (RI) / Savings Plans
  • 中断可能な一時的・バッチ処理 → Spot Instances
  • アクセス頻度が減ったデータ → S3の安価なストレージクラスへ移行(ライフサイクル)

📈 2. SAAで出やすいポイント

  • EC2の購入オプション(購入モデル):
    • オンデマンド: 従量課金。予測不可能で短期間のワークロード。
    • リザーブド (RI) / Savings Plans: 1年または3年のコミットメント。定常的で予測可能なワークロード(DBや常時稼働のWebサーバー)で大幅割引。
    • スポット (Spot): 余剰キャパシティを格安で利用。AWSの都合で中断(Terminate)される可能性があるため、中断しても再開できるバッチ処理やコンテナ処理に最適。
  • ストレージ層の最適化: Amazon S3のデータをアクセス頻度に応じて自動的に安い階層(S3 Standard-IA や Glacier)へ移動させる 「S3 ライフサイクルポリシー」 が頻出。
  • サイジングの適正化: Auto Scaling を用いて、夜間や休日などトラフィックが少ない時間帯はインスタンス数を減らす(スケールイン)。

🗝 3. キーワードでの判断

問題文のキーワード 疑うサービス・構成・オプション
📉 「中断してもよい」「バッチ処理」「最も安価に」 EC2 スポットインスタンス (Spot Instances)
🏢 「1〜3年常時稼働する」「ベースライン負荷」 Reserved Instances (RI) / Savings Plans
🗄️ 「古いデータの保存」「アクセス頻度が低い」 S3 Standard-IA, Glacier (ライフサイクルポリシー)
⏱️ 「夜間や休日は使わない」 Auto Scaling (スケジュールスケーリング), インスタンス停止

⚠️ 4. ひっかけポイント

🚫 よくある誤答パターン – 「重要なWebサーバーをスポットインスタンスで動かす」 → スポットインスタンスは突然終了するため、ステートフルな処理や中断不可のWebサーバーには絶対に使ってはいけない。 – 「リザーブドインスタンスを数ヶ月だけ使う」 → RIは最低1年の契約が必要。短期間ならオンデマンドが正解。


💡 5. 覚え方

🧠 暗記ショートカット – スポット = 「訳あり激安品」。途中で取り上げられる覚悟がある処理(バッチ・分散処理)専用。 – リザーブド = 「年間パスポート」。ずっと使うなら絶対お得。 – S3ライフサイクル = 「断捨離」。使わないものは奥の安い倉庫(Glacier)へ自動でしまう。


📚 6. 関連サービス

アイコン サービス / 機能 コスト最適化における役割
🏷️ EC2 Spot Instances 中断可能な処理を最大90%オフで実行
📅 Savings Plans / RI 長期利用を約束する代わりに大幅割引
🧊 Amazon S3 Glacier アクセス頻度が極めて低いデータの超低コスト保管
📉 AWS Cost Explorer どこにコストがかかっているか可視化・分析

🗒️ 7. Obsidian管理メモ

  • 見返すタイミング: EC2の購入オプション、S3のストレージクラスの学習時
  • 関連ノート候補: AWS_SAA_EC2_Pricing, AWS_SAA_S3_Storage_Classes

8. HTMLファイル名: AWS_設計原理_コスト最適化.html

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次