【CLF学習ログ】 EC2で混乱した初学者が料金モデルとインスタンスファミリーを整理してみた

【CLF学習ログ】 EC2で混乱した初学者が料金モデルとインスタンスファミリーを整理してみた

2026.04.30

こんにちは、26新卒の城元です。

現在AWS Certified Cloud Practitioner(CLF)取得に向けて勉強中なのですが、序盤も序盤のEC2について学んでいる時点で、早速「それ別の機能でも同じこと言ってませんでした?!」や「結局どういうこと??」となってしまいました。

サービス自体は「仮想サーバーを借りられる」といった点はイメージできたんですが、

  • 料金モデルが6種類もあって、どれを選べばいいかわからない
  • インスタンスファミリーの種類が多すぎて覚えられない

この2点でかなり詰まりました。

なので、この記事では「この場面ではこの料金モデル・インスタンスファミリーがおすすめ」という解説ではなく「CLFに向けて学習する上で、自分なりにどう整理したか」をまとめてみたいと思います。
同じところで悩んでいる初学者の方の参考になれば嬉しいです。
※公式ドキュメントをベースに学習した内容です。

事前知識

私はAWS未経験者です。
学生時代に独学で技術書を参考にしながらWordPressを立ち上げたことはあったのですが、深く学習したというより「このボタンを押せばサーバー構築できるんだ〜^^」といったレベルでした。
ですのでこの記事に出てくる料金モデルやインスタンスファミリーについてはほぼ初見の状態から学習を始めています。

そもそもEC2の料金モデルって何種類あるの?

EC2の料金モデルは以下の6種類とされています。

モデル名 一言まとめ
オンデマンド 使った分だけ支払う・縛りなし
リザーブド 長期契約で最大75%割引
Savings Plans 金額ベースの柔軟な割引
スポット 最大90%割引・中断リスクあり
ハードウェア専有インスタンス 他アカウントと物理ハードウェアを共有しない
専有ホスト 物理サーバーを丸ごと占有

料金モデルだけで6……多いですね。
一見すると似たようなモデルがあるのですが、それぞれ「どんな場面で使うか」が全然違うようです。
順番に整理しましょう。

①オンデマンドインスタンス

6種類の中で、個人的に一番すんなり理解できたのがこれです。

一言でいうと、使った時間分だけ料金が発生するモデルです。
サブスクや年間契約といった縛りは一切なく、 起動したら課金開始、止めたら課金終了というシンプルな仕組みです。
「使ったら使った分だけ」というのは直感的でわかりやすいですね。
ただ、柔軟な分だけ割高というのも特徴です。
ずっと動かし続けるような用途には向いていないので、 「常時稼働させたい」という場面では他のモデルを検討する必要があるようです。

公式ドキュメントでは、オンデマンドは以下のような場面に適しているとされています。

  • 初めてAWSを触る・試してみたい
  • 開発・テスト環境など短期間の利用
  • 使用量が予測できないアプリケーション

私自身、以前軽くAWSに触れた際はこのオンデマンドを選択した記憶があります。
まずAWSを触り始める段階では、 迷ったらオンデマンドを選んでおけば問題なさそうです。

②リザーブドインスタンス:長期利用ならお得だけど注意点あり

特定のインスタンスファミリーとAWSリージョンを使用し、予測可能なワークロードに対して1年または3年の利用をコミット(約束)することで、最大75%の割引が受けられるモデルです。

「コミット」というのは、「このインスタンスを長期間使い続けます」とAWSに対して宣言するイメージです。

社内システムや本番サーバーのように「毎日必ず動いているもの」には向いていると学びました。

ここで気になったのが、途中でやめられるのかという点です。
結論としては、原則途中解約はできないようです。
対象のEC2インスタンスを停止・削除しても、リザーブドインスタンスの契約期間が終了するまでは料金が発生し続けます。

「安いから」という理由だけで契約すると、使わなくなっても料金が発生し続けるので注意が必要だと感じました。

長期利用が確定しているサービスに絞って使うのが正しい使い方のようです。

公式ドキュメントでは、リザーブドは以下のような場面に適しているとされています。

  • 予測可能なワークロードで長期間稼働し続けるアプリケーション
  • 本番環境など常時稼働が前提のシステム

③Savings Plans

リザーブドとSavings Plans、何が違うの?

勉強していて「似てるけど何が違うんだろう?」と思ったのがSavings Plansです。

Savings Plansは1年または3年にわたって 一定の使用量をコミットすることで、さまざまなインスタンスタイプやサービスで最大72%の割引が受けられるとされています。

大きな違いは柔軟性です。

リザーブドは「特定のインスタンスファミリーと AWSリージョン」に紐づく割引ですが、 Savings Plansは「さまざまなインスタンスタイプやサービスで割引が受けられる」仕組みとされています。

イメージとしては、

リザーブド → 指定席を1年予約する感じ
Savings Plans → 月〇万円以上使うと割引になる定期券的な感じ

EC2だけでなくLambdaなど他のサービスにも割引が適用されるのがSavings Plansの特徴とのことです。

④スポットインスタンス:安すぎるけど、え、止まるの?!

正直、最初にスポットインスタンスの説明を読んだ時「最大90%オフ?!なんで?!」と驚きました。

仕組みを調べてみると、AWSのデータセンターにある使われていない余ったサーバーを格安で貸し出すモデルとされています。

ただし条件があり、他のユーザーがそのリソースを必要とした場合、2分前に通知されて強制終了されることがあるとのこと。

最初は「それって運ゲーすぎじゃないですか?!そんなの実際に使う人いるの?」と思いました。

でも調べていくと、ちゃんと使い道があるようです。

ポイントは 「止まっても困らない処理に限定する」 ことです。

たとえば深夜に大量のデータを処理するバッチ処理や、大量の画像・動画の変換処理など、「多少時間がかかっても、途中で止まっても再実行できる」ような用途であれば、コストを大幅に抑えられるとされています。

逆に、ECサイトの本番サーバーや決済処理など「絶対に止まってはいけない処理」には絶対に使ってはいけないモデルです。

公式ドキュメントでは、スポットは以下のような場面に適しているとされています。

  • バッチ処理・データ分析など中断・再開が可能な処理
  • コスト削減が最優先で、柔軟なスケジュールが可能な処理

「安さ最優先&止まってもOK」という条件が揃ったときだけ選ぶモデルと覚えておくと整理しやすいかなと思います。

⑤ハードウェア専有インスタンス:他のアカウントとハードウェアを共有したくない場合に

一言でいうと、自分のAWSアカウント専用の物理ハードウェアでインスタンスを動かせるモデルです。

次に紹介する専有ホストも「このハードウェア専有インスタンスも物理サーバーを専有して使えるってこと??」と混乱しました。

大きな違いは占有の単位です。

ハードウェア専有インスタンスは「他のAWSアカウントとは物理ハードウェアを共有しない」ことを保証するモデルですが、同じ自分のアカウント内の他のインスタンスとはハードウェアを共有する場合があるとされています。

公式ドキュメントでは、以下のような場面に適しているとされています。

  • コンプライアンス上、他のアカウントと物理ハードウェアを共有できない要件がある場合

専有ホストとの使い分けのポイントは、「既存のライセンスを持ち込む必要があるか」です。
ライセンス持ち込みが必要な場合は専有ホスト、そうでなければハードウェア専有インスタンスで対応できるケースが多いと学びました。

⑥専有ホスト:特殊な事情がある企業向け

一言でいうと、物理サーバーを丸ごと自分専用で占有するモデルです。
料金は6種類の中で最も高くなります。

「なんでわざわざ高いのを選ぶの?」と思いましたが、主に以下のような特殊な事情がある場合に使われるとされています。

  • 既存のWindows Serverライセンスをそのまま持ち込みたい
  • 法規制やコンプライアンス上、物理サーバーの占有が必要

一般的な用途ではまず選ばないモデルですが、「ライセンス持ち込み・法規制対応」というキーワードが出てきたら専有ホストと結びつけて覚えておくと良さそうですね。

結局どれを選べばいいの?場面別まとめ

6種類を学んでみて、
「で、結局どれを使えばいいの?」となったのでシナリオ別に整理してみました。

シナリオ 選ぶモデル
とりあえず試したい・使用量が読めない オンデマンド
長期間ずっと稼働させる本番環境 リザーブド
EC2以外も含めて柔軟に割引したい Savings Plans
止まってもOKな処理・コスト最優先 スポット
他アカウントと物理ハードウェアを共有したくない ハードウェア専有インスタンス
ライセンス持ち込み・法規制対応が必要 専有ホスト

個人的には「まず用途が決まっているか」と「止まっても大丈夫か」の2点で絞り込むと選びやすくなると感じました。

次に混乱したのがインスタンスファミリー

料金モデルを理解した次に待ち構えていたのが「インスタンスファミリー」でした。

正直、最初に一覧を見たとき「多いな???」と思いました。

t3、m5、c5、r5、p3…
アルファベットと数字の組み合わせが並んでいて、何がなんだかわからなくなりますね。
整理してみると、大きく5つの系統に分かれているようです。

汎用(t・m系):まずはここから

一番よく登場するのがこの系統です。

CPUとメモリのバランスが良く、特別な要件がなければだいたいこれで対応できるとされています。

勉強していて正直思ったのが、「よほど特殊な用途でなければ汎用でいいのでは?」ということでした。

実際、Webサーバーや開発環境など一般的な用途には汎用インスタンスが幅広く使われているようです。

コンピューティング最適化(c系):CPU重視の処理向け

CPUの性能が特に強化された系統です。

動画のエンコードや科学計算など、とにかくCPUをフル活用するような処理に向いているとされています。

メモリ最適化(r系):大量データの処理向け

大量のデータをメモリに乗せて処理するような用途に向いている系統です。

データベースやビッグデータの処理など、「とにかくメモリをたくさん使う」場面で選ばれるとされています。

ストレージ最適化(i・d系):高速読み書き向け

大量のデータを高速に読み書きする処理に特化した系統です。

データウェアハウスや大規模なデータベースなど、ディスクへのアクセスが多い処理に向いているとされています。

高速コンピューティング(p・g系):AI・機械学習向け

GPUを搭載した系統で、機械学習や3D処理などGPU性能が必要な処理に使われるとされています。

CLFの試験範囲では「AI・機械学習向けのインスタンスがある」という認識で十分そうです。

インスタンスファミリーの選び方まとめ

「結局どれを選べばいいの?」となったので用途別に整理してみました。

用途 選ぶ系統 覚えるキーワード
一般的なWebサーバー・開発環境 汎用(t・m系) バランス型
動画処理・科学計算 コンピューティング最適化(c系) CPU重視
データベース・大量データ処理 メモリ最適化(r系) メモリ重視
データウェアハウス ストレージ最適化(i・d系) 高速読み書き
AI・機械学習 高速コンピューティング(p・g系) GPU

個人的な感想として、特殊な要件がなければまず汎用を選んでおけばOKで、「CPU・メモリ・ストレージ・GPUのどれかが特に必要」という場面で他の系統を検討する、という理解が一番スッキリしました。

まとめ

今回はAWS CLFの勉強で個人的につまずいたEC2の2つのポイントをまとめてみました。

勉強してみて感じたのは、EC2は「とりあえず全部覚える」より 「用途から逆引きで選ぶ」 という考え方の方がずっと整理しやすいということです。

試験でも「このシナリオならどれ?」という問われ方をすることが多いので、場面をイメージしながら覚えると良さそうですね。

この記事が同じところでつまずいている方の参考になれば嬉しいです!


参考リンク

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました。

この記事をシェアする

関連記事