Amazon EC2 (Elastic Compute Cloud)

は、AWS クラウド上でを起動して利用するためのコンピューティングサービスです。、、メモリ、ストレージ、ネットワーク、セキュリティ設定を選び、Web サーバー、アプリケーションサーバー、バッチ処理、踏み台サーバー、レガシーアプリケーションの移行先などに使います。

SAA では、EC2 を「仮想マシン」として覚えるだけでは不十分です。、、、、ロール、、、購入オプション、配置戦略を組み合わせて、可用性、性能、コスト、運用負荷を判断できることが重要です。

Point

EC2 = Elastic Compute Cloud の略です。
Elastic は「伸縮する」、Compute は「計算処理」、Cloud は「クラウド」という意味です。
EC2 は「必要なときに増減できる仮想サーバー」と覚えます。
和訳
- Elastic: 伸縮性のある
- Compute: 計算する
- Cloud: クラウド
- Weblio英和辞書「compute」

概要

は、AWS 上に自分で管理するサーバーを作るサービスです。インスタンスという単位でを起動し、やミドルウェアを設定してアプリケーションを動かします。やより管理範囲は広いですが、OS レベルの制御、既存アプリケーションの移行、細かい実行環境の調整に向いています。

EC2 インスタンスは、、、ストレージ、ネットワーク、セキュリティ設定を組み合わせて起動します。

SAA では、「EC2 を 1 台置く」よりも、「複数に分散する」「とを組み合わせる」「状態を、、、へ分離する」「適切な購入オプションを選ぶ」といった設計判断が中心です。

見るポイント	代表的な判断
、メモリ、、I/O のどれが重要か	インスタンスファミリーを選びます。
データを永続化するか	EBS、EFS、S3、RDS などへ分離します。
障害に強くするか	複数 AZ、Auto Scaling、ELB を使います。
を置かず AWS を使うか	EC2 ロールを関連付けます。
コストを下げるか	、Reserved Instances、Spot Instances を使い分けます。

主要技術

①AMI、インスタンスタイプ、起動テンプレート

は、インスタンスを起動するためのテンプレートです。、アプリケーション、設定、起動時に使うルートボリューム情報などを含みます。同じ AMI から複数のインスタンスを起動すると、標準化された環境を再現できます。

は、、メモリ、ネットワーク、ストレージ、などのリソース構成を決めます。アプリケーション要件に合わせて、汎用、コンピューティング最適化、メモリ最適化、ストレージ最適化、高速コンピューティングなどから選びます。

分類	向いている用途	試験での判断ポイント
汎用	Web サーバー、小規模 DB、開発環境	CPU とメモリのバランスがよい通常用途です。
コンピューティング最適化	CPU 集約処理、ゲーム、、バッチ	CPU 性能が重要な場合に選びます。
メモリ最適化	DB、、大規模分析	大量メモリが必要な場合に選びます。
ストレージ最適化	高 I/O、ローカルストレージ、分析	ローカル NVMe や高いディスク I/O が必要な場合に選びます。
高速コンピューティング	GPU、ML、画像処理、HPC	GPU や専用アクセラレータが必要な場合に選びます。
バースト可能	普段は低負荷、たまに高負荷	CPU クレジットの概念を理解します。

起動テンプレートは、AMI、インスタンスタイプ、、ロール、ユーザーデータなど、起動設定をまとめる仕組みです。グループでは起動テンプレートを使い、同じ設定でインスタンスを自動作成します。

Point

AMI = Amazon Machine Image の略です。
EC2 インスタンスを起動するための「サーバーのひな形」です。
HPC = High Performance Computing の略で、高性能計算を意味します。
和訳
- Machine: 機械
- Image: イメージ、複製元
- Performance: 性能
- Weblio英和辞書「performance」

⚠️ 頻出: 「同じ設定の EC2 を Auto Scaling で増やす」は起動テンプレートを使います。「OS と初期ソフトウェアを含む起動元」は AMI です。

②ストレージ、EBS、インスタンスストア

のストレージでは、永続化するデータと一時データを分けて考えます。は EC2 にアタッチする永続的なです。は物理ホストに付属する一時ストレージで、停止や終了、基盤障害でデータが失われる可能性があります。

ストレージ	特徴	向いている用途
EBS	永続的なブロックストレージ	ルートボリューム、DB、アプリデータ
Instance Store	一時的なローカルストレージ	、テンポラリ、再作成可能な高速データ
	複数 EC2 から共有できる Linux	共有コンテンツ、CMS、複数共有
		静的ファイル、バックアップ、ログ、
	マネージドファイルシステム	Windows ファイル共有、Lustre、NetApp ONTAP など

EBS ボリュームは AZ 内のリソースです。ある AZ の EBS ボリュームを別 AZ の EC2 に直接アタッチすることはできません。別 AZ や別へ移す場合は、を使います。

EBS スナップショットはバックアップや複製に使います。を作るときにも EBS スナップショットが関係します。暗号化が必要な場合は EBS 暗号化とキーを確認します。

⚠️ 頻出: 「EC2 停止後もデータを残す」は EBS、「一時的な高速スクラッチ領域」はインスタンスストア、「複数 EC2 から同時共有」は EFS を検討します。

③ネットワーク、セキュリティグループ、IAM ロール

インスタンスはの内で起動します。に置くか、に置くかで到達性が変わります。インターネットから直接受ける Web サーバーはパブリックサブネットに置くこともありますが、SAA の設計ではをパブリックサブネット、EC2 をプライベートサブネットに置く構成がよく使われます。

は EC2 の仮想ファイアウォールです。許可ルールだけを定義し、に動作します。たとえば、EC2 のセキュリティグループでは、ALB のセキュリティグループからの / だけを許可する設計ができます。

機能	役割	試験での判断ポイント
Security Group	インスタンス単位のステートフル制御	ALB から EC2、踏み台からなど、送信元を絞ります。
NACL	サブネット単位の制御	明示的な deny やサブネット境界の追加制御に使います。
Role	EC2 から AWS へ安全にアクセス	を保存せず、を使います。
Key Pair	SSH/ ログイン	private key の管理責任があります。
Session Manager	ポート開放なしの管理接続	SSH/RDP を閉じたい場合に有効です。

EC2 上のアプリケーションから、、などへアクセスする場合は、IAM ロールをインスタンスに関連付けます。アクセスキーを EC2 内の設定ファイル、、ユーザーデータ、コードに埋め込む設計は避けます。

⚠️ 頻出: 「EC2 から S3 に安全にアクセス」は IAM ロールです。「SSH のために 0.0.0.0/0 を開ける」より、Session Manager や接続元制限を考えます。

④Auto Scaling、ELB、高可用性

を高可用にする基本は、複数に分散し、で受け、で台数を自動調整する構成です。単一 EC2 にを付けるだけでは、インスタンス障害や AZ 障害への耐性が不足します。

Auto Scaling グループは、希望容量、最小容量、最大容量に基づいて EC2 を維持します。異常なインスタンスを置き換えたり、に応じて・スケールインしたりできます。

要素	役割	判断ポイント
Launch template	起動設定	、、SG、ロールなどを定義します。
Auto Scaling Group	インスタンス台数の維持	複数 AZ にまたがって可用性を高めます。
Scaling policy	増減条件	、リクエスト数、キュー深度などで調整します。
Health check		EC2 または ELB の状態で置き換えできます。
ELB Target Group	トラフィック分散先	正常なインスタンスへだけリクエストを送ります。

アプリケーションをスケールさせるには、インスタンスをに近づけることが重要です。セッション情報はや、データは、、など外部の永続ストアに置くと、EC2 の置き換えや増減がしやすくなります。

⚠️ 頻出: 「EC2 で高可用 Web アプリ」は、複数 AZ の Auto Scaling グループ + ALB が基本です。単一 AZ や単一インスタンスは高可用構成ではありません。

⑤購入オプションとコスト最適化

のコストは、、実行時間、、、ストレージ、データ転送、購入オプションで変わります。 SAA では細かい価格暗記ではなく、ワークロードの性質に合う購入オプションを選ぶことが重要です。

購入オプション	向いている用途	試験での判断ポイント
On-Demand Instances	短期、不規則、予測困難	長期コミットなしで柔軟です。
	一定の利用量が見込める	時間あたり利用額にコミットして割引を受けます。
Reserved Instances	特定構成の継続利用	インスタンス属性やリージョンに基づく割引です。
Spot Instances	中断可能な処理	バッチ、分散処理、CI、 worker に向きます。
Dedicated Hosts	物理ホスト専有、ライセンス要件	既存ライセンスや要件で使います。
On-Demand Capacity Reservations	特定の容量確保	割引ではなく容量確保が主目的です。

Spot Instances は未使用キャパシティを安く使えますが、AWS 側の都合で中断される可能性があります。そのため、チェックポイント、再試行、キュー、、複数インスタンスタイプ・複数 AZ を使い、中断に耐える設計にします。本番の状態を持つ単一サーバーには向きません。

Savings Plans と Reserved Instances は、安定して長く使うワークロードのコスト削減に向きます。急な検証や短期利用では On-Demand、常時稼働のベースラインでは Savings Plans や Reserved Instances、中断可能な追加処理では Spot を組み合わせます。

Dedicated Host は物理ホストのソケット数やコア数を把握できるため、物理コア単位・ソケット単位の既存ライセンスを持ち込む要件に向きます。ホスト利用量を長期間予測できる場合は Dedicated Host の予約で割引を受けます。Dedicated Instances はテナンシーを専有できますが、特定の物理ホストへライセンスを割り当てて追跡する要件には Dedicated Host を選びます。

開発・検証などの非本番環境は、本番と同じ可用性を求めないことが多く、コストの判断も変わります。本番は複数 AZ に冗長化し、可用性の要件がない非本番は台数を減らして冗長化を省く、という区別が基本です。使わない時間帯はインスタンスを停止します。停止中はインスタンスの使用料金がかからず、ボリュームなどのストレージ料金だけが残ります。 Scheduler はユニバーサルターゲットで EC2 の StopInstances や StartInstances のを直接呼べるため、のコードを書かずに夜間・週末の停止と朝の起動を自動化できます。

起動後にメモリへデータを読み込むまで時間がかかるアプリケーションでは、休止 (hibernation) を使います。休止はメモリ (RAM) の内容を暗号化された EBS ルートボリュームへ保存して停止し、次の起動でメモリの内容と実行中のプロセスを復元します。休止中もインスタンスの使用料金はかからず、RAM の内容を含む EBS の保存料金だけがかかります。休止は起動時に有効にする必要があり、既存のインスタンスに後から有効にすることはできません。Linux では RAM が 150 GiB 未満であることなどの前提条件があります。

インスタンスサイズはとメモリの両方の実績から決めます。CPU 使用率が低いのにメモリを多く使うワークロードを、コンピューティング最適化の大きなサイズで動かしていると、使わない vCPU に料金を払い続けることになります。メモリ対 vCPU の比率が大きいメモリ最適化 (R ファミリーは 1 vCPU あたり 8 GiB) の小さいサイズへ移すと、必要なメモリを保ったまま費用を下げられます。arm64 で動作するアプリケーションなら、AWS Graviton プロセッサを搭載したインスタンス (r7g など、世代の数字の後に g が付くタイプ) も候補になり、同じ vCPU とメモリの x86 インスタンスより低い料金で使えます。

⚠️ 頻出: 「中断されても再実行できるバッチ処理」は Spot、「常時稼働で利用量が予測可能」は Savings Plans や Reserved Instances、「特定 AZ の容量を確保」は On-Demand Capacity Reservations です。

⑥配置、メタデータ、運用管理

配置戦略は、性能や障害分離に影響します。 Placement group を使うと、インスタンスをどのように物理配置するかを制御できます。

Placement group	用途	判断ポイント
Cluster	低、高	や密な通信が必要な処理に向きます。
Spread	障害分離	少数の重要インスタンスを別ハードウェアに分散します。
Partition	大規模分散システム	Hadoop、Cassandra などでパーティション単位に障害分離します。

Cluster placement group は 1 つのの中でインスタンスを物理的に近づけて配置します。同じ AZ に閉じるため、ノード間のレイテンシとパケット毎秒の性能を最も高められる代わりに、AZ 障害には弱くなります。マイクロ秒単位の通信や毎秒数十万件のメッセージ交換のように、可用性より通信性能が優先される要件で選びます。

Spread placement group は各インスタンスを別のラックへ分散するため、AZ ごとに配置できるインスタンス数に上限があります。少数の重要なインスタンスを守る用途で、大量のノードを近接配置したい要件とは目的が逆です。

MPI を使う密結合の HPC や分散では、Elastic Fabric Adapter (EFA) も組み合わせます。 EFA は対応するに接続するネットワークデバイスで、のカーネルを迂回 (OS バイパス) して MPI や NCCL の通信を直接ネットワークへ送るため、より低く安定した遅延でノード間通信を行えます。 EFA の通信は AZ をまたげないため、ノードは 1 つの AZ に集め、Cluster placement group と併用するのが基本です。通常の通信の帯域を高める拡張ネットワーキング (ENA) とは役割が異なります。

配置は通信費用にも影響します。同じ AZ 内でプライベート IPv4 アドレスを使う同士の通信にはデータ転送料がかからず、AZ をまたぐ通信には送受信の両方向で料金がかかります。「インスタンス間のデータ転送コストを下げたい」という条件は、複数 AZ への分散ではなく単一 AZ への集約を示す手掛かりになります。

⚠️ 頻出: 「ノード間のレイテンシを最小化」「インスタンス間の転送コストを削減」は単一 AZ + Cluster placement group、「重要インスタンスを別ハードウェアへ」は Spread placement group です。

Instance Metadata Service は、EC2 インスタンス自身がメタデータやロールの一時認証情報を取得する仕組みです。 IMDSv2 はセッション指向の方式で、SSRF などのリスクを下げるために推奨されます。 SAA では、インスタンスメタデータから IAM ロール認証情報が取得できるため、IAM ロールの権限を最小化することが重要です。

運用管理では、、、、、EC2 Image Builder を組み合わせます。 CloudWatch でとログを監視し、Systems Manager でパッチ、コマンド実行、Session Manager 接続を行い、AWS Backup やで復旧に備えます。

運用機能	用途	試験での判断ポイント
CloudWatch	、ステータスチェック、ログ監視	やに使います。
Status checks	システム・インスタンス障害検知	EC2 基盤障害と OS/ネットワーク問題を切り分けます。
Systems Manager	パッチ、Run Command、Session Manager	/ を減らした運用に使います。
AWS Backup / EBS Snapshot	バックアップ	EBS や EC2 の復旧計画に使います。
EC2 Image Builder	作成の自動化	標準化された安全なイメージ管理に使います。

Point

IMDS = Instance Metadata Service の略です。
EC2 インスタンスが自分自身の情報や IAM ロールの一時認証情報を取得する仕組みです。
SSRF = Server-Side Request Forgery の略で、サーバー側から意図しないリクエストを送らせる攻撃です。

⚠️ 頻出: 「EC2 に SSH せず安全に操作したい」は Systems Manager Session Manager、「EC2 の一時認証情報を安全に扱う」は IMDSv2 との IAM ロールを考えます。

⑦ステータスチェックと自動復旧

のステータスチェックは 2 種類あり、どちらが失敗したかで原因の層と打ち手が変わります。

ステータスチェック	見ているもの	失敗したときの打ち手
システムステータスチェック	AWS 側の基盤（物理ホスト、ネットワーク、電源）	インスタンスの復旧、または停止・起動で別ホストへ移します。
インスタンスステータスチェック	インスタンス内部（、ファイルシステム、カーネル、ネットワーク設定）	OS 側の設定やログを調査して修正します。

システムステータスチェックの失敗をで監視し、アラームアクションに recover を指定すると、基盤障害の検知後に同じインスタンスを別の物理ホストで自動的に再起動できます。復旧後もインスタンス ID、プライベートアドレス、アドレス、アタッチされたボリュームは引き継がれるため、インスタンスの同一性に依存する構成でもそのまま復旧できます。ライセンスの都合で同時に複数インスタンスを起動できない、アプリケーションを改修できない、といった制約があるワークロードで有効な選択肢です。

対応するインスタンスでは、起動時から簡易自動復旧 (simplified automatic recovery) が既定で有効になっており、システムステータスチェックが失敗すると AWS が追加料金なしで同じように別ホストへの復旧を試みます。結果はのイベントで通知されます。CloudWatch アラームの recover アクションは自分で設定する方式で、による任意の通知先を指定でき、簡易自動復旧より速い復旧を試みます。起動時にを付けたインスタンスやベアメタルのサイズは簡易自動復旧の対象外で、CloudWatch アラームによる復旧なら対応するタイプで設定できます。どちらの方式でも、メモリ上のデータは失われます。

グループによる置き換えは、異常なインスタンスを終了して新しいインスタンスを起動する仕組みです。台数を維持できますが、インスタンス ID もプライベート IP も変わるため、インスタンスの同一性やインスタンスストアのデータを前提にした構成では同じ結果になりません。 Dedicated Host には、電源やネットワークの障害を検知すると交換用の専有ホストでインスタンスを再起動するホスト復旧がありますが、物理サーバーを丸ごと専有する分だけ費用が高く、ソケット単位のライセンスなどで専有が必要な場合に選ぶものです。単一インスタンスの復旧のためだけに移す選択肢ではありません。別サイトへ継続的にして待機環境を維持するは、規模の災害復旧向けで、単一ホストの障害対策としては費用と運用が過剰になります。

⚠️ 頻出: 「単一インスタンスのまま、ハードウェア障害のダウンタイムを最小化」はシステムステータスチェックのアラーム + recover アクションです。「台数を維持したい」は Auto Scaling グループです。

試験対策

SAA の問題では、まず「EC2 が本当に必要か」を考えます。やミドルウェアを細かく管理したい、既存アプリケーションをそのまま移行したい、特定のソフトウェアを動かしたい場合は EC2 が候補です。単純なオブジェクト保存なら、マネージド DB なら、なら /、イベント処理ならも比較します。

EC2 を選んだら、可用性設計を確認します。単一 EC2 ではなく、複数のグループ、、、外部化された状態管理を組み合わせます。データベースやセッションをローカルディスクに閉じ込めると、や復旧が難しくなります。

問題文のキーワード	優先して考える機能	理由
同じ構成の EC2 を自動起動	Launch template + Auto Scaling	標準化された設定で台数を維持できます。
高可用 Web アプリ	ALB + Auto Scaling + 複数 AZ	障害時に正常な AZ/インスタンスへ分散できます。
EC2 から S3 へ安全にアクセス	Role	を保存せず一時認証情報を使えます。
停止後もデータを保持		永続的なです。
複数 EC2 からファイル共有		複数 AZ の Linux ファイル共有に向きます。
中断可能なバッチ	Spot Instances	コストを下げられますが中断対策が必要です。
常時稼働の予測可能な利用	/ Reserved Instances	長期コミットで割引を受けます。
物理コア単位のを予測可能な期間利用	Dedicated Host + Dedicated Host Reservation	物理ホストを追跡しながら予約割引を使えます。
特定 AZ の容量確保	On-Demand Capacity Reservations	割引ではなく容量確保が目的です。
低なノード間通信	Cluster placement group	物理的に近い配置で通信性能を狙います。
インスタンス間の転送コストを下げたい	単一 AZ へ集約	同一 AZ のプライベート通信には転送料がかかりません。
単一インスタンスの基盤障害から自動復旧	ステータスチェックの + recover	同じインスタンス ID と EBS のまま別ホストで再起動します。
を開けず管理	Session Manager	管理ポートを閉じやすくなります。

よくある誤答は、EC2 内にアクセスキーや重要データを固定配置することです。 AWS へのアクセスは IAM ロール、シークレットはや Systems Manager Parameter Store、永続データは EBS/RDS/S3/EFS へ分離します。

もう一つの頻出ポイントは、EC2 とストレージサービスの使い分けです。 EBS は 1 つの AZ の EC2 にアタッチするブロックストレージ、EFS は複数 EC2 から共有する、S3 はです。要件が「ファイル共有」なのか「ブロックデバイス」なのか「オブジェクト保管」なのかを先に切り分けます。

コストでは、インスタンス料金だけでなく、EBS、、データ転送、 Gateway、、 Logs も影響します。 SAA では価格暗記より、安定利用はコミット割引、中断可能処理は Spot、可用性重視は複数 AZ と Auto Scaling という判断軸を押さえます。

Amazon EC2 (Elastic Compute Cloud)

概要

主要技術

①AMI、インスタンスタイプ、起動テンプレート

②ストレージ、EBS、インスタンスストア

③ネットワーク、セキュリティグループ、IAM ロール

④Auto Scaling、ELB、高可用性

⑤購入オプションとコスト最適化

⑥配置、メタデータ、運用管理

⑦ステータスチェックと自動復旧

試験対策

参考文献