知っている物語から、 AWSへつなぐ

アプリを動かしたい。そのために物理サーバーを購入して、設置して、配線して…と準備する代わりに、AWSへ必要な処理能力をリクエストする。これがAmazon EC2の出発点です。

起動した1台をインスタンスと呼びます。LinuxやWindowsのOSを選び、Webアプリ、データベース、バッチ処理などを載せられます。OSやアプリを自由に設定できる分、その管理も利用者の仕事です。

1台の物理サーバーを複数のコンピューターとして扱うのが仮想化。その割り当てと分離を担うのがハイパーバイザー。複数の利用者が物理基盤を共有する形がマルチテナントです。

ここで押さえるEC2は、アプリを動かす独立したサーバーを必要なときに使う仕組み。

EC2には用途に合わせた性能の系統があります。ファミリーとサイズを分けて読むと、選ぶポイントを整理できます。m5.largeならm5がファミリー、largeがサイズで、全体がインスタンスタイプです。「汎用」などは用途別カテゴリです。

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

まず必要な能力を選び、その量を決めます。大きなサイズにしても、処理の原因が別のところにあれば期待ほど速くなりません。負荷を測って見直しましょう。EBS（EC2で使う永続ストレージ）の容量は別に設定できます。

ここで押さえる性能の特性を選ぶのがファミリー。必要なリソース量を選ぶのがサイズ。

最初は画面で1台を起動する。それが毎日の作業になったらコマンドにする。アプリの中から操作したくなったらコードに組み込む。使い方は変わっても、その先ではAWSのAPIが操作を受け付けます。

APIはソフトウェア同士がやり取りするための仕様です。Consoleはブラウザー、CLIはコマンド、SDKはPythonなどのプログラムから呼び出します。CLIは、ローカル端末やCLIが用意されたAWS CloudShellから利用できます。

ここで押さえる見た目が違う3つの入口が、AWS APIへの操作につながる。

スケーラビリティは、負荷が増えても処理能力を拡張できる性質。伸縮性は、混んだときに増やして、落ち着いたら減らせる性質です。常にピーク人数を動かし続けるより、必要な容量へ調整します。

増減の判断には状況の観測が必要です。CloudWatchがCPUなどを監視し、EC2 Auto Scalingが設定したポリシーに従って台数を変えます。平均CPUの目標値を追うターゲット追跡なら、図のように観測と制御のループを作れます。

ここで押さえる観測するCloudWatch、増減するAuto Scaling。役割を分けて覚える。

サーバーを複数台にした。でも、その全員が同じ場所の障害に巻き込まれたら、処理は止まってしまいます。台数とは別に、どこへ置くかを考えます。

リージョンは地理的なエリア。AZ（Availability Zone）はその中の独立した配置単位で、1つ以上のデータセンターから構成されます。ネットワークを区切ったサブネットは1つのAZに属し、EC2はそこへ配置。複数AZへ分散すると、配置場所の障害に備えやすくなります。

ELBが受け付けたリクエストを分散し、ヘルスチェックで状態を見ます。通常は正常なターゲットへ送ります。Auto Scalingとの連携を設定すれば、新しいインスタンスも分散先へ登録できます。

内部ELBは、フロントエンドから見えるバックエンドの入口を共通のDNS名にします。個別アドレスの増減を隠せますが、相手の応答を待つ依存は残ります。EC2以外にも、データベース・セッション保存先などの単一障害点を見直します。

ここで押さえる強くする、増やす、場所を分ける、仕事を振り分ける。それぞれ別の設計。

注文は受け付けたい。でも配送処理が忙しくて、毎回その終了を待っていたら受付まで詰まる。そんなときは「依頼を渡す」と「実行を終える」のタイミングを分けます。

SQSは処理待ちの仕事を保存するキュー。ワーカーがポーリングして取りに行きます。SNSはイベントを複数の購読先へ配るトピック。Pub/Sub（発行・購読）で配送・分析などへ同じイベントを届けます。

SNSから用途別のSQSへつなげば、配送と分析がそれぞれ自分のペースで進めます。メッセージの中身がペイロードで、例えば注文IDや配送先です。相手の状態や内部実装への依存を減らすことが疎結合。直接通信をすべて悪い設計と決めつける話ではありません。

ここで押さえる受付済みと処理完了は別。ためるSQSと、配るSNSを組み合わせる。

使わないサーバーを稼働させ続けると、容量も費用も余ります。ただ、減らせばすべての支払いが消えるとは限りません。リソースの増減と契約を分けて見ましょう。

利用が読めないうちはオンデマンド。安定した利用額が見えたらSavings Plans、特定条件の継続利用にはReserved Instancesも候補です。Compute Savings PlansはEC2に加えLambda・Fargateの対象利用にも適用し、EC2 Instance Savings Plansは対象が限定されます。専有ホストはライセンスや規制などの要件に応じて物理サーバーを専有する別の選択です。

ここで押さえる価格だけではなく、継続利用の約束や、中断してもよいかまで含めて選ぶ。

例えは入口です。最後はサービス名と役割だけで説明できるか、次の問いで確かめてみましょう。

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

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