AWSの関係を、 図から読み解く

このページでは、図を見てから説明へ進みます。図のサービス名の下にある短い役割を読み、矢印の方向や箱の包含を確かめてください。料金の選択は、これらの構成とは別の契約の軸です。

ここで押さえるEC2を中心に、操作・監視・増減・分散・メッセージングを組み合わせる。

図の外側はAWSが管理する物理サーバー、内側はOS・アプリを実行する独立した仮想マシンです。必要なときに起動し、不要になれば停止・終了できます。利用者はゲストOS・アプリ・ネットワーク設定を管理します。

ここで押さえる包含は「何の上で動くか」。通信の矢印とは意味が違う。

例：m5.large全体がインスタンスタイプです。「汎用」などは用途別のカテゴリで、m5などが具体的なファミリー。命名にはプロセッサなどを示す追加文字が付く場合もあります。上の例は最新世代の推奨ではありません。

「汎用」などは用途別カテゴリ、m5などは具体的なファミリー、m5.large全体がインスタンスタイプです。小さい構成から負荷を実測し、ボトルネックを見つけて調整します。EBS（EC2で使う永続ストレージ）の容量は別に設定できます。

ここで押さえる強いか弱いかという1軸ではなく、性能の特性と量で選ぶ。

APIはソフトウェア間のやり取りの仕様です。AWS APIがリソースの作成・参照・変更を受け付けます。CLIはローカルや、CLIが用意されたAWS CloudShellで利用できます。どの入口にも認証と適切な権限が必要です。

ここで押さえる収束図は「入口は複数でも、共通のサービス操作へつながる」と読む。

スケーラビリティは処理能力を拡張できる性質。伸縮性は需要に合わせて増減できる性質。ループ図ではEC2の観測値がCloudWatchへ進み、Auto Scalingの制御がEC2へ戻ります。

ここで押さえる比較図は「どの能力を変えるか」。ループ図は「変化をどう観測し、調整するか」。

高可用性は、障害が起きてもサービスを継続しやすいこと。複数AZへ分散するのは、同じ配置場所の障害にまとめて巻き込まれないためです。Auto ScalingとELBを連携させれば、新しいEC2を分散先へ登録できます。

内部ELBは、バックエンドの個別アドレスを共通のDNS名の後ろへ隠します。配置への依存を減らしても、同期通信では応答を待つ関係が残ります。

ここで押さえる包含は配置。分岐する矢印はリクエスト。台数の制御はAuto Scalingの役割。

メッセージの中身がペイロードです。仕事をキューへ挟むと、送信側と処理側が同時に動く必要を減らせます。相手の状態や内部実装への依存を減らす設計が疎結合。直接通信かどうかだけで決まるわけではありません。

ここで押さえるSQSの複数ワーカーは分担。SNSの複数購読先はそれぞれ受け取る。

Compute Savings PlansはEC2に加えLambda・Fargateの対象利用にも適用します。EC2 Instance Savings Plansは対象が限定されます。Reserved Instancesも条件に合う利用への割引で、すべてがキャパシティ予約を伴うわけではありません。

ここで押さえる「どう配置するか」「どれだけ動かすか」「どう購入するか」を混ぜない。

色がなくても説明できるか、矢印を消しても関係を思い出せるか。次の問いで役割の違いを確かめます。

ここで押さえるEC2は動かす。CloudWatchは観測する。Auto Scalingは増減する。ELBは分散する。SQSはためる。SNSは配る。

元データはModule 2のトランスクリプトです。仕様の補足はAWS公式資料で確認しています（参照：2026年10月4〜5日）。構成図は概念図で、完全な構築手順ではありません。