Amazon EC2(購入オプション・プレースメントグループ)

Amazon EC2(Elastic Compute Cloud)は、AWS 上で仮想サーバー(インスタンス)を必要なときに必要な台数だけ動かすサービスです。SAA では「どのインスタンスタイプを選ぶか」「どの購入オプションで買えば最も安いか」「インスタンスをどう配置するか」が、コスト最適化と高パフォーマンスの設計でよく問われます。

ひとことで言うと: EC2 は「借りられるサーバー」で、同じサーバーでも買い方(購入オプション)と置き方(プレースメントグループ)を選べます。

たとえるなら、購入オプションは車の使い方です。必要なときだけ借りるレンタカー(オンデマンド)、長期契約で安くなるリース(Savings Plans・リザーブドインスタンス)、空いている車を格安で借りられるが返却を求められることもある在庫車(スポット)があります。

このページで押さえる論点

EC2 の基本

インスタンスを起動するときは、AMI(Amazon マシンイメージ。OS や初期設定済みのソフトウェアをまとめた「ひな形」)と、インスタンスタイプ(CPU・メモリ・ネットワーク性能の組み合わせ)を選びます。停止中はコンピューティング料金がかかりませんが、EBS など保存したリソースの料金は続きます。不要になったら終了し、不要なボリュームや Elastic IP も確認します。台数を自動で増減させる仕組み(EC2 Auto Scaling)と、複数台への振り分け(ELB)は「ELB と Auto Scaling」のページで扱います。

ネットワーク・権限・ストレージの基本

EC2 に入る通信はセキュリティグループで許可します。セキュリティグループは許可ルールだけを持つステートフルな仮想ファイアウォールです。アプリから S3 などの AWS サービスを使う権限は、アクセスキーをファイルに置かずIAM ロール(インスタンスプロファイル)で渡します。インスタンスメタデータへのアクセスは IMDSv2 を使う設定が推奨されます。

ブロックストレージでは、停止・終了後も保持できるEBSと、ホスト上の一時的なインスタンスストアを区別します。EBS は独立したボリュームとしてデータを保持できます(終了時に削除する設定もあります)。インスタンスストアはインスタンスの停止・終了・基盤障害でデータを失うため、複製可能なキャッシュや一時データに向きます。

インスタンスタイプの読み方

たとえば m7g.xlarge は、「m」がファミリー(用途の種類)、「7」が世代、「g」がオプション(この場合は AWS Graviton プロセッサ)、「xlarge」がサイズです。AWS はファミリーの最初の文字を「シリーズ」と呼んでいます。試験ガイドでは「ワークロードに適したインスタンスファミリーとサイズを選ぶ」ことが求められます。

ファミリーの種類代表的な記号向いている処理
汎用M、TWeb サーバー、中小規模のデータベースなど、CPU とメモリをバランスよく使う処理
コンピューティング最適化C動画エンコード、バッチ処理、科学計算など、CPU を多く使う処理
メモリ最適化R、X大規模なデータベース、インメモリキャッシュ、リアルタイム分析など、大量のデータをメモリに載せる処理
ストレージ最適化I、D、Hデータウェアハウス、分散ファイルシステム、NoSQL データベースなど、ローカルディスクへの大量の読み書き
高速コンピューティングP、G、Trn、Inf機械学習、グラフィックス処理など、GPU や専用チップを使う処理
ハイパフォーマンスコンピューティング(HPC)Hpc大規模な並列計算、科学技術計算

T 系(バーストパフォーマンスインスタンス)は、普段は基準(ベースライン)程度の CPU 性能で動き、必要なときだけ基準を超えて性能を上げられます(バースト)。CPU を基準以下しか使っていない間に CPU クレジットがたまり、バーストするとクレジットを消費します。普段は負荷が軽く、ときどき忙しくなる開発・テスト環境や小規模な Web サーバーに向きます。

垂直スケーリングと水平スケーリング、停止と休止

方式やり方特徴
垂直スケーリング(スケールアップ)インスタンスタイプを大きいものに変えるアプリを変えずに済むが、変更には停止が必要で、1 台の性能には上限がある。1 台が止まれば全体が止まる
水平スケーリング(スケールアウト)インスタンスの台数を増やすAuto Scaling で自動化でき、複数の AZ に分ければ障害にも強い。アプリが複数台で動ける作り(状態を外部に持つなど)である必要がある

SAA では「伸縮自在(需要に合わせて増減できる)」「高可用性」を求められたら、水平スケーリングを選ぶのが基本です。

停止・終了・休止(ハイバネーション)

休止を使うには、起動時に休止を有効にしておく必要があり、ルートボリュームは暗号化された EBS でなければなりません(インスタンスストアは使えません)。メモリの大きさにも上限があり、Linux では 150 GiB 未満、Windows では 16 GiB 以下です。休止している間はコンピューティング料金がかからず、EBS など保存リソースの料金は続きます。

購入オプション

同じインスタンスでも、買い方によって料金が大きく変わります。試験では、使い方の条件(期間・中断してよいか・ライセンス・容量の確保)から最も安い、または条件を満たす買い方を選ばせる問題が頻出です。

購入オプション仕組み向いている場面
オンデマンドインスタンス約束なし。起動した分だけ秒単位で支払う短期間・予測できない使い方、中断できない処理を試す段階
Savings Plans1 時間あたりの利用額(USD)を 1 年か 3 年約束して割引を受ける長期間、安定して使い続ける処理。AWS はリザーブドインスタンスより Savings Plans を推奨
リザーブドインスタンス(RI)インスタンスタイプやリージョンなどの設定を 1 年か 3 年約束して割引を受ける長期間、同じ構成で使い続ける処理
スポットインスタンスAWS の使われていないキャパシティを、オンデマンドより最大 90% 安く使う。AWS がキャパシティを必要とすると中断される中断されてもやり直せる処理(バッチ、データ分析、CI/CD、コンテナなど)
Dedicated Hosts(専有ホスト)物理サーバー 1 台を丸ごと自社専用にする。ホスト単位で支払うソケット・コア単位のソフトウェアライセンスの持ち込み(BYOL)、コンプライアンス要件
Dedicated Instances(ハードウェア専有インスタンス)他の AWS アカウントと物理サーバーを共有しないインスタンス。インスタンス単位で支払う物理サーバーを他社と共有しないことだけが求められる場合
オンデマンドキャパシティ予約特定の AZ にキャパシティ(起動できる枠)を予約する。割引はない特定の期間・AZ で確実に起動したい(イベント、災害対策の切り替え先など)

Savings Plans の種類

種類対象と柔軟性割引の上限
Compute Savings PlansEC2・Fargate・Lambda が対象。インスタンスファミリー、サイズ、リージョン、OS、テナンシーを変えても割引が続く最大 66%
EC2 Instance Savings Plans選んだリージョンの特定のインスタンスファミリーが対象。そのファミリー内ならサイズ・OS・テナンシーは変えられる最大 72%

柔軟性が高いほど割引率は下がります。「将来、インスタンスファミリーやリージョンを変える可能性がある」「EC2 から Fargate や Lambda へ移す予定がある」なら Compute Savings Plans です。

リザーブドインスタンスの種類

支払い方法は、全額前払い・一部前払い・前払いなしの 3 種類で、Savings Plans も同じです。前払いの額が大きいほど割引も大きくなるのが一般的です。期間は 3 年のほうが 1 年より割引が大きくなります。

専有ホストとハードウェア専有インスタンスの違い

どちらも物理サーバーを他のアカウントと共有しない点は同じです。Dedicated Hosts はソケット数と物理コア数が見え、どのホストにインスタンスを置くかも制御できるので、ソケット・コア単位のライセンスを持ち込めます。Dedicated Instances ではソケットやコアは見えず、配置も制御できません。「既存のサーバー単位のライセンスを使いたい」なら Dedicated Hosts です。

キャパシティ予約と割引の組み合わせ

オンデマンドキャパシティ予約は、すぐに使う予約なら期間の約束がいらない代わりに、割引はありません。使っていなくても予約した分の料金がかかります。割引も受けたい場合は、Savings Plans またはリージョン RI と組み合わせます。ゾーン RI は 1 年か 3 年の約束が必要な点が違います。

比較・選択フローチャート

質問に答えて購入オプションを選ぶ

動かしたい処理を思い浮かべて「はい / いいえ」で答えてください。答えた経路が上から順に表示されます。

    ※簡略化しています: 代表的な選び方だけを分岐にしています。Dedicated Instances、スタンダード RI とコンバーティブル RI の選び分け、ゾーン RI、オンデマンドとスポットを混ぜる構成は分岐に含めていません。

    フローチャートで省いた選び方は、この節の表と「スポットインスタンスの中断と扱い方」で説明しています。実際の構成では、最低限必要な台数を Savings Plans や RI で、増えた分をオンデマンドやスポットで賄うように組み合わせるのが一般的です。

    スポットインスタンスの中断と扱い方

    スポットインスタンスは、AWS がキャパシティを必要としたときに中断されます。終了または停止の場合は通常、中断の 2 分前に通知(スポットインスタンス中断通知)が届きます。休止を選んだ場合は休止がすぐ始まり、2 分間の猶予はありません。通知もベストエフォートです。中断時の動作は終了・停止・休止から選べます。さらに、中断のリスクが高まると「リバランスの推奨」というシグナルが届くことがあり、別のインスタンスへ処理を移し始める時間を確保できる場合があります。

    AWS はスポットインスタンスを、データ分析、バッチジョブ、バックグラウンド処理、必須ではないタスクに向くと案内しています。逆に、途中で止まると困る処理(1 台だけで動くデータベースや、中断できない長時間の処理)には向きません。

    プレースメントグループ

    通常、EC2 はインスタンスを物理サーバーに自動で分散して置きます。プレースメントグループを使うと、インスタンス同士を「近くにまとめる」か「離して置く」かを指定できます。追加料金はかかりません。

    戦略置き方主な制約向いている処理
    クラスター1 つの AZ の中で、インスタンスを物理的に近くにまとめる1 つの AZ のみ。同じインスタンスタイプを 1 回のリクエストでまとめて起動するのが推奨HPC など、インスタンス間で低レイテンシー・高スループットの通信が必要な処理
    パーティションインスタンスを論理的な区画(パーティション)に分け、区画ごとに別のラックを使う1 つの AZ につき最大 7 パーティション。同じリージョンの複数 AZ にまたがれるHDFS、HBase、Cassandra など、データの複製を持つ大規模な分散システム
    分散(スプレッド)1 台ずつ別のラック(別の電源とネットワーク)に置く1 つの AZ につき、実行中のインスタンスは最大 7 台。複数 AZ にまたがれる少数の重要なインスタンスを、同時に故障しないように分けたい場合
    操作できるシミュレーター

    配置戦略とラック障害の影響を比べる

    4 台のインスタンスを、戦略ごとにどのラックへ置くかを示します。「障害を起こすラック」を選ぶと、止まるインスタンスが ✕ で表示されます。

    ラック1 ラック2 ラック3 ラック4

    ※簡略化しています: 1 つの AZ の 4 ラックだけを描いています。クラスターは「同じラック」、パーティションは「区画ごとに 1 ラック」として示しています。実際には、クラスターは AZ 内の近い場所にまとめる配置、パーティションは 1 区画が複数ラックにまたがることがあり、パーティションと分散は複数 AZ にもまたがれます。

    図では省略した上限(パーティションは 1 AZ あたり 7 区画、分散は 1 AZ あたり実行中 7 台)は表のとおりです。分散で 1 つの AZ に 8 台目を起動しようとすると失敗するので、それ以上必要なら分散プレースメントグループを複数作るか、AZ を増やします。

    クラスターの注意点

    クラスタープレースメントグループは 1 つの AZ に閉じるので、その AZ が止まると全台が止まります。また、あとからインスタンスを追加するとキャパシティ不足で起動できないことがあります。AWS は、必要な台数を 1 回のリクエストで、同じインスタンスタイプでまとめて起動することを推奨しています。起動済みのグループでキャパシティ不足のエラーが出た場合は、全インスタンスを停止してから起動し直すと解消することがあります。

    EC2 と一緒に問われるコンピューティングサービス

    試験ガイドの対象サービスには、EC2 を土台にしたサービスや、AWS の外側で EC2 を動かすサービスも含まれます。

    サービス何をするか選ぶ場面
    AWS Batchバッチ処理のジョブ量に合わせて、EC2・Fargate などの計算資源を自動で用意し、ジョブを割り振る。バッチ用のソフトウェアを自分で入れる必要がない大量のバッチジョブを、スポットも使って安く実行したい
    AWS Elastic Beanstalkアプリのコードをアップロードするだけで、EC2・ロードバランサー・Auto Scaling・ヘルス監視を自動で構成する。Beanstalk 自体の追加料金はないインフラの知識が少なくても、Web アプリをすばやく公開したい
    AWS OutpostsAWS のインフラ(ラックなど)を自社のデータセンターに置き、AWS と同じ API で EC2 などを使うオンプレミスの設備と低レイテンシーでつなぎたい、データを自社の拠点内で処理・保管したい
    AWS Wavelength通信事業者の 5G ネットワークの端(Wavelength ゾーン)に EC2 などを置き、VPC を延長するスマートフォンなどのモバイル端末に、非常に低いレイテンシーで応答したい

    問題文のキーワード → 選ぶべき答え

    問題文の言い回し選ぶべき答えと理由
    「中断されても再開できるバッチ処理」「最もコストを抑えたい」スポットインスタンス(最大 90% 割引。終了・停止は通常 2 分前に通知、休止は猶予なし)
    「24 時間 365 日、今後 3 年間使い続ける」「構成は変えない」EC2 Instance Savings Plans または スタンダード RI(3 年)
    「インスタンスファミリーやリージョンを今後変える」「Fargate や Lambda にも割引を」Compute Savings Plans
    「期間中にインスタンスファミリーを交換できる RI」コンバーティブル RI
    「ソケット単位・コア単位のライセンスを持ち込みたい」Dedicated Hosts(ソケットと物理コアが見える)
    「特定の AZ で、決まった期間だけ確実に起動できるようにしたい」「長期の約束はしたくない」オンデマンドキャパシティ予約(割引が必要なら Savings Plans と組み合わせる)
    「短期間の検証」「使用量が予測できない」「中断できない」オンデマンドインスタンス
    「HPC」「インスタンス間の通信を低レイテンシー・高スループットに」クラスタープレースメントグループ
    「HDFS・Cassandra」「ラック障害の影響を区画ごとに分けたい」パーティションプレースメントグループ
    「少数の重要なインスタンスが同時に故障しないように」分散プレースメントグループ(1 AZ あたり最大 7 台)
    「起動に時間がかかるアプリを、メモリの状態を保ったまま止めてすぐ再開したい」休止(ハイバネーション)(暗号化された EBS ルートボリュームが必要)
    「機械学習の学習処理」「大規模なインメモリデータベース」高速コンピューティング(P・G)/メモリ最適化(R・X)のファミリー
    「オンプレミスで AWS と同じ API を使い、データを拠点内で処理」AWS Outposts

    引っかけポイント

    まとめ: SAA 試験で押さえるポイント

    確認問題

    参考リンク

    AWS 公式ドキュメント(外部サイトが開きます)。本文の数値はこれらで確認しています。