Amazon EC2のインスタンス配置・性能・購入方式

Amazon EC2が提供するもの

**Amazon Elastic Compute Cloud（Amazon EC2）**は、AWS上で仮想サーバーを起動するサービスです。AWSが管理する物理サーバーの計算資源を仮想化し、利用者はOS、アプリケーション、ネットワーク、ストレージの構成を選んでインスタンスとして利用します。物理サーバーを調達して設置する場合と比べ、必要な環境を短時間で作成し、不要になれば停止または削除できます。

インスタンスタイプは、汎用サーバーからCPU・メモリ・ローカルストレージ・GPUなどを強化したものまで幅広くあります。アプリケーションの特性に合わせてタイプとサイズを選べることがEC2の強みです。一方、インスタンスが1台あるだけでアプリケーションの高可用性が得られるわけではありません。物理ホスト、アベイラビリティーゾーン（AZ）、リージョンの障害を考慮し、複数台や複数AZへの分散、ヘルスチェック、データの複製などを組み合わせます。

EC2のサービスレベル契約（SLA）に示される稼働率は、対象となる配置や契約条件に基づく月次の指標です。特定の仮想マシンが常に稼働する保証として読み替えることはできません。試験では「高いSLAの数字」だけで単一インスタンスの障害対策が不要と判断せず、複数AZ構成が必要かを要件から判断します。

インスタンスの状態とデータ

インスタンスを再起動すると、通常は同じホスト上でOSを再起動します。停止するとコンピューティング料金が止まり、後から再び起動できます。停止・起動では基盤ホストが変わることがあり、インスタンスストアのデータは失われます。EBSルートボリュームや追加のEBSボリュームは、削除時の設定に応じて保持できます。

終了はインスタンスを削除する操作です。終了したインスタンスを再起動することはできません。デフォルト設定ではルートEBSボリュームも削除される場合がありますが、ボリュームの DeleteOnTermination 設定によっては残ります。終了時に失われる一時データと、保持するEBSデータを区別し、必要なデータを事前にバックアップしてください。

料金の請求対象も状態ごとに分けて考えます。

状態・操作	EC2コンピューティング料金	残り得る料金・注意
実行中	発生する	EBS、データ転送、ライセンスなども条件に応じて発生
停止中	通常は発生しない	EBSボリューム、スナップショット、割り当てたままのパブリックIPv4アドレスなどは課金対象になり得る
終了後	発生しない	残したEBSボリュームやスナップショットなどは課金対象になり得る

インスタンスの課金粒度は購入方式、OS、ライセンス、インスタンスタイプなどによって確認が必要です。「起動時間だけを見ればEC2関連費用がすべて分かる」とは限らないため、料金見積もりではストレージやネットワークも含めます。最新の課金単位はAmazon EC2料金ページで確認できます。

AMIで環境を再利用する

**Amazon Machine Image（AMI）**は、EC2インスタンスの起動に使うイメージです。OSやソフトウェアを準備したインスタンスからカスタムAMIを作れば、同じ構成のインスタンスを繰り返し作成できます。AMIはバックアップや環境複製の一部として活用でき、別リージョンへコピーしてリージョンをまたぐ復旧や展開にも利用できます。

AMIはリージョンに属するため、別リージョンで使うにはコピーが必要です。また、AMI作成だけでアプリケーションの全データや外部サービスの状態まで保護されるわけではありません。AMIが取得するEBSスナップショット、インスタンスストア上の一時データ、アプリケーションデータベースなどの扱いを分けてバックアップ計画を立てます。

プレイスメントグループで配置を設計する

**プレイスメントグループ（Placement Group）**は、EC2インスタンスを物理基盤上でどのように配置するかを指定する機能です。配置戦略により、ネットワーク性能を優先したり、障害ドメインを分散したりできます。

戦略	配置の考え方	主な用途と制約
Cluster（クラスター）	インスタンスを単一AZ内の近い場所にまとめる	ノード間の低レイテンシや高いネットワークスループットが重要なHPC、密結合型分散処理などに向く。AZ障害の影響を受け得る
Partition（パーティション）	インスタンスを複数の論理パーティションに分け、別パーティション同士で基盤ハードウェアを共有しないよう配置する	Hadoop、Kafkaなど、大規模な分散・複製ワークロードの障害分離に向く。1つのグループに設定できるパーティションはAZごとに最大7つ。グループは複数AZにまたがれる
Spread（スプレッド）	個々のインスタンスを異なる基盤ハードウェアに分散する	少数の重要インスタンスで同時障害のリスクを下げたい場合に向く。AZをまたぐ配置が可能。インスタンス単位のSpreadでは1つのAZにつき最大7台まで実行できる

Clusterは「近接させて通信を速くする」、PartitionとSpreadは「障害の影響を分離する」という違いで整理します。Partitionは大規模なノード群をパーティション単位で分け、Spreadは少数の重要インスタンスを個別に分ける設計です。プレイスメントグループを使っても、AZ障害をまたいだ可用性が自動で得られるわけではありません。Clusterは単一AZに限定されるため、複数AZが必要な構成ではアプリケーション側でAZ間の冗長化を設計します。

インスタンスタイプを選ぶ

インスタンスタイプ名には、用途を表すファミリー、世代、必要に応じたプロセッサーなどの追加属性、サイズが含まれます。たとえば c7i.large では、c がコンピューティング最適化のファミリー、7 が世代、i が追加属性、large がサイズを表します。サイズによってvCPUやメモリなどの資源量が変わりますが、ネットワークやストレージの性能も含めて仕様を比較します。

ファミリーの分類	名前から読み取る例	典型的なワークロード
汎用（General Purpose）	M、T、Aなど	Webアプリケーション、開発環境、一般的なサーバー。T系はバースト型
コンピューティング最適化（Compute Optimized）	C	CPU負荷の高いバッチ、科学計算、トランスコードなど
メモリ最適化（Memory Optimized）	R、X、uなど	大きなメモリ上で処理するインメモリDB、分析、キャッシュ
高速コンピューティング（Accelerated Computing）	P、G、F、Inf、Trnなど	GPUや専用アクセラレーターを使う機械学習、グラフィックス、推論
ストレージ最適化（Storage Optimized）	I、D、Hなど	ローカルストレージへの高いI/O性能や大容量を必要とする処理

ファミリー記号は候補を絞る手掛かりになりますが、アルファベットだけでCPU性能や価格を決めつけないでください。CPUアーキテクチャ、ネットワーク、ローカルストレージの有無、EBS帯域などはタイプごとに異なります。実際のデプロイではAWSのインスタンスタイプ仕様を確認し、アプリケーションの実行環境やライセンスとの互換性も検証します。

T系のバースト性能とCPUクレジット

T系インスタンスは、CPUを常時最大まで使わない一般的なワークロード向けのバースト型インスタンスです。各サイズにはベースライン性能があり、CPU使用率がベースラインを下回っている間にCPUクレジットを蓄積します。ベースラインを超えて処理すると、蓄積したクレジットを消費し、一時的に高いCPU性能を使えます。

Standardモードでは、クレジット残高がある間にベースラインを超えてバーストできます。残高が不足すると、CPU性能はベースラインに制限されます。したがって、CPU負荷が長時間高いままのワークロードにT系を選ぶと、期待した性能を持続できない可能性があります。継続的なCPU性能が必要なら、M系やC系などの非バースト型を含めて比較します。

Unlimitedモードでは、蓄積済みクレジットを使い切った後もベースラインを超えるCPU性能を利用できます。ただし、余剰クレジットが常に無料になるわけではありません。インスタンスの平均CPU使用率がローリング24時間（またはインスタンスの稼働期間のうち短い方）でベースラインを超えた場合、超過分のクレジット料金が発生し得ます。T3、T3a、T4g、T8gなどはUnlimitedが既定のものがありますが、ファミリーや起動設定により異なるため個別に確認してください。

この仕組みは、短時間の負荷上昇を吸収する一方、継続的な高CPU負荷を低価格で無制限に処理するものではありません。CloudWatchのCPUクレジット残高やCPU使用率を監視し、ピークの頻度、継続時間、料金を踏まえてサイズやファミリー、モードを選びます。

Dedicated HostとDedicated Instance

通常のEC2は、AWSが管理する物理ホスト上で複数の顧客のインスタンスが動作するマルチテナント型のサービスです。コンプライアンスやソフトウェアライセンスの条件で、専有ハードウェアが必要な場合はDedicated HostまたはDedicated Instanceを検討します。

比較項目	Dedicated Host（専有ホスト）	Dedicated Instance（専有インスタンス）
基盤	物理サーバー全体を専有	他のAWS顧客と物理ハードウェアを共有しない
可視性・配置制御	ホストID、ソケット、物理コアなどを把握し、インスタンス配置を管理できる	物理ホストの可視性や配置を利用者が細かく制御する機能はない
ライセンス	ソケット単位・コア単位・VM単位など、条件に合うBYOLに適する	専有ハードウェアは使うが、Hostほど広範なBYOL機能はない
料金の考え方	ホスト単位の料金。利用条件に応じたオンデマンドまたは予約方式がある	専有インスタンスの稼働時間などに応じた料金

どちらも専有物理サーバー上でインスタンスを実行しますが、Dedicated Hostはホスト単位の可視性と配置制御が必要なケースに向きます。既存のソケット・コア・VM単位のライセンスをAWSへ持ち込む（BYOL）要件がある場合は、ライセンス条項とAWSの対象条件を確認します。単に他のAWS顧客とハードウェアを共有したくないという要件なら、Dedicated Instanceで足りるかを比較します。Dedicated Hostが必要かどうかは、コンプライアンスやライセンス要件から判断し、一般的なEC2との価格差だけで決めません。

EC2の購入方式を使い分ける

購入方式は、利用時間が不確実か、長期の利用額を約束できるか、中断を許容できるか、特定AZの容量確保が必要かで選びます。

購入方式	コミットメント・割引	容量の扱い	代表的な用途
On-Demand	長期コミットメントなし。利用したコンピューティング資源に応じて課金	起動できる容量はAWSの現在の空き状況に依存する	利用量が読めない開発環境、新規サービス、短期実行
Reserved Instance（RI）	通常1年または3年の期間を選び、条件に一致する利用へ割引を適用	Regional RIは容量を予約しない。Zonal RIは指定AZの容量を予約できる	長期利用が予測でき、属性条件に合う割引や容量確保が必要
Savings Plans	通常1年または3年の期間で、1時間あたりの利用額をコミット	それ自体は容量を予約しない	長期の利用額を約束し、RIより柔軟な割引を利用したい
Spot Instance	余剰EC2キャパシティを変動するSpot料金で利用	AWSの容量状況や制約によって中断され得る	停止・再試行できるバッチ、並列処理、耐障害性のあるワーカー
On-Demand Capacity Reservation	割引コミットではなく、予約した容量に対する料金が発生	指定AZ・インスタンスタイプなどの条件に一致する容量を確保	特定AZで必要時にインスタンスを起動できることが重要

On-Demandは利用を始めやすく、長期コミットが不要です。課金は起動しているコンピューティング資源に対して発生し、利用時間の粒度や最低時間は購入条件・OSなどに従います。停止すれば通常EC2のコンピューティング料金は止まりますが、先述のとおりEBSやIPアドレスなどの費用は残ることがあります。

容量予約は時間スケジュールではない

On-Demand Capacity Reservationは、特定のAZで指定条件に一致するEC2容量を確保する機能です。予約を有効にしている期間は、インスタンスを起動していない時間も予約容量に対する料金が発生します。RIやSavings Plansの割引と組み合わせられる場合があります。

これは「毎月決まった時刻にインスタンスを起動・停止する」ためのスケジューラーではありません。繰り返し実行するバッチなら、EventBridge Scheduler、Systems ManagerやLambdaなどを使って起動・停止を自動化します。指定時間にインスタンスを確実に起動できるだけの容量を確保したい場合は、Capacity Reservationなどを別に検討します。

Reserved InstanceとSavings Plans

**Reserved Instance（RI）**は、通常1年または3年の期間で条件に合うEC2利用の割引を受ける購入方式です。RIはインスタンスそのものを常時起動する予約というより、請求に適用される割引特典として理解すると正確です。Regional RIはリージョン内の条件に合う利用に割引を適用し、容量は確保しません。Zonal RIは特定AZで容量を予約し、対象属性の利用に割引を適用します。

Standard RIは割引が大きい傾向がある一方、属性変更の自由度が限られます。Convertible RIは規定の条件を満たす範囲でRIの交換ができ、ファミリーやプラットフォームなどの変更に対応しやすい代わりに、Standardより割引が小さくなる傾向があります。RIを購入するときは1年または3年の期間に加え、全額前払い、一部前払い、前払いなしなどの支払い方法も選びます。対象属性、リージョンまたはAZ、OSやライセンス、テナンシーも確認してください。料金の具体的な割引率は条件や時点で変わるため、固定の割合として覚えず料金ページで確認します。

Savings Plansは、1時間あたりの利用額（ドル/時間）を一定期間コミットして、対象サービスの利用料金を割り引く仕組みです。

• Compute Savings Plansは、対象リージョンにおけるEC2、AWS Fargate、AWS Lambdaなどの使用量に広く適用できます。インスタンスファミリー、サイズ、OS、テナンシーなどが変わる可能性のある利用に柔軟です。
• EC2 Instance Savings Plansは、指定リージョンとインスタンスファミリーに対するEC2利用に適用されます。Compute Savings Plansより対象範囲が狭い分、割引条件が異なります。

Savings PlansはAWS Cost Explorerから購入・管理できます。購入時はプランの種類、コミット期間、1時間あたりの利用額、支払い方法（全額前払い、一部前払い、前払いなし）、開始日を選びます。支払い方法はキャッシュフローと適用される割引条件に影響します。

Savings Plansは利用額へのコミットであり、指定時刻に起動できる容量の確保ではありません。請求では対象となるRIの割引が先に適用され、その後にSavings Plansの割引が適用されます。既にRIを購入している場合も、その割引が自動的に無効になるわけではありませんが、新しいコミットメントを決める前にCost Explorerの推奨と利用履歴を確認します。

Spot Instanceは中断を前提にする

Spot Instanceは、EC2の余剰キャパシティを利用する購入方式です。Spotの容量プールはインスタンスタイプとAZの組み合わせなどで分かれ、利用可能な容量と料金は需要・供給の状況で変わります。Spotは「希望価格を入札し、オークションに勝てば起動する」方式として説明するのは適切ではありません。AWSが設定するSpot料金で提供されます。利用可能な容量がなくなったときや、指定条件を満たせなくなったときなどに、AWSがインスタンスを中断することがあります。上限価格を指定することもできますが、その価格がSpot料金を下回ると中断されやすくなります。Spot Instanceの割引率は状況で変わり、「常に最大割引」とは限りません。

中断時には通常、停止または終了の2分前に通知を受け取れます。休止を中断動作に指定した場合も通知は発行されますが、休止処理が直ちに始まるため、2分前の猶予はありません。通知が来てから大量の状態を退避する設計では間に合わないことがあります。

中断が起きるワーカーは、次のような設計にします。

• 実行中の処理を一定間隔でチェックポイント化し、S3など外部の永続ストレージへ保存する
• 処理要求と完了状態をSQSなどのキューやデータストアで管理し、別ワーカーが再試行できるようにする
• インスタンスローカルの一時データに唯一のコピーを置かない
• Spot FleetやEC2 Auto ScalingのMixed Instances Policyで複数のインスタンスタイプや購入方式を混在させ、単一の容量プールに依存しない

Spot Fleetは複数のインスタンスタイプやAZなどの候補をまとめて要求する仕組みです。capacity-optimizedは容量を得やすくする戦略、price-capacity-optimizedは中断リスクと料金の両方を考慮する戦略の例です。ワークロードに応じて戦略を選びます。Spotの割合を増やせばコスト削減につながる可能性がありますが、容量不足や中断の影響も増えます。中断に耐えられない処理はOn-Demandの比率を高めるなど、可用性と費用を一緒に設計します。

要件から選択する例

新しい画像処理サービスを運用するとします。APIを受け付ける常時稼働コンポーネントにはOn-DemandやSavings Plansの適用対象となるEC2を使い、画像の変換キューを処理するワーカーにはSpotを混ぜます。ワーカーはSQSからジョブを受け取り、途中経過をS3へ保存してからメッセージを完了にするため、中断後は未完了の仕事を別インスタンスで再開できます。

同じAZ内のノード間通信がボトルネックになる科学計算ならCluster配置を検討します。大量のパーティション型データを複数ノードで複製する処理ならPartition、少数の重要なノードが同時に故障しないようにしたいならSpreadを候補にします。利用料金を下げたい場合も、Spot・RI・Savings Plansはそれぞれ中断許容度、属性の固定度、利用額の予測可能性が異なるため、同じ「割引」として扱わず要件に合わせます。

試験で整理する判断軸

問題文の要件	判断の方向
ノード間通信の遅延を抑えたい	単一AZ内へ近接配置するCluster Placement Group
大規模分散処理で障害ドメインを分けたい	パーティション単位で基盤を分けるPartition Placement Group
少数の重要インスタンスを個別に分散したい	Spread Placement Group。AZごとの台数上限も確認
CPU負荷に短いピークがあり、通常は低い	T系とCPUクレジット。平均負荷がベースラインを超える場合のUnlimited料金も確認
物理ホストのソケットやコアを把握し、ライセンスを持ち込みたい	Dedicated Host
長期間使うがインスタンス構成が変わる可能性がある	要件に応じたSavings Plans、特にCompute Savings Plansを検討
長期間、特定AZの容量を確保したい	Zonal RIまたはOn-Demand Capacity Reservationなどを検討
中断しても再実行できる大量のバッチを安く実行したい	Spot Instance。チェックポイントと複数容量プールを組み合わせる
特定の曜日・時刻だけバッチを起動したい	EventBridge Schedulerなどで起動・停止を自動化する。Capacity Reservationとは役割が異なる

公式ドキュメント

• Amazon EC2インスタンスタイプ
• EC2プレイスメントグループ
• バーストパフォーマンスインスタンスのCPUクレジット
• Unlimitedモードと余剰クレジット
• Dedicated Hosts
• EC2購入オプション
• Regional RIとZonal RI
• Savings Plansの概要
• Spot Instanceの中断通知
• AWS料金見積りツール