販売サイトで AWSを学ぶ

Amazon EC2なら、LinuxやWindowsのサーバーを必要なときに起動できます。起動した1台がインスタンス。OSとアプリを設定し、リクエストを受けて処理を返します。物理サーバーの購入・設置から始める必要はありません。

仮想化は、物理的なCPUやメモリを複数の独立したコンピューターとして扱う技術です。ハイパーバイザーがリソースの割り当てと分離を担い、複数の利用者が基盤を共有する形をマルチテナントと呼びます。

ここで押さえるEC2はアプリを動かす場所。物理基盤の管理と、OS・アプリの管理を分けて考える。

インスタンスファミリーは性能の系統、サイズはリソースの量です。タイプ名は両方を含みます。例えばm5.largeなら、m5がファミリー、largeがサイズ。「汎用」などは、その上の用途別カテゴリです。

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

最初は小さめの構成で実測し、CPU・メモリ・I/Oのどこが詰まるかを見直します。EBS（EC2で使う永続ストレージ）の容量は別に設定でき、サイズを上げればストレージまで一律に増えるとは限りません。

ここで押さえる用途に合う系統を選び、その中で必要なサイズを選ぶ。

AWS APIは、リソースの作成・参照・変更を受け付ける窓口です。Management Console、CLI、SDKは、そのAPIへ操作を届ける入口。どの入口でも認証と適切な権限が必要です。

Consoleは設定の理解や状態確認、CLIはコマンドや運用スクリプト、SDKはアプリへの組み込みに向きます。CLIはローカル端末だけでなく、CLIが用意されたAWS CloudShellでも使えます。自動化しても、操作の中身は確認します。

ここで押さえる入口を変えると操作の仕方が変わる。使える権限が増えるわけではない。

負荷に合わせて能力を拡張できる性質がスケーラビリティ。増えた需要に合わせて増やし、落ち着いたら減らせる性質が伸縮性です。Scale Outには、複数台で処理できるアプリ設計が必要です。

毎回手で増減する代わりに、CloudWatchのCPU使用率などを使い、EC2 Auto Scalingがポリシーに沿って台数を調整します。平均CPUの目標値を追う方式がターゲット追跡です。

ここで押さえる負荷を測る役割と、台数を変える役割を組み合わせる。

ELB（Elastic Load Balancing）はリクエストを複数のターゲットへ分散します。Web向けのALBを共通の入口にすれば、利用者は各EC2のアドレスを知る必要がありません。

リージョンは地理的なエリア、AZはリージョン内の独立した配置単位で、1つ以上のデータセンターで構成されます。サブネットはネットワークを区切った範囲で1つのAZに属し、EC2はその中に配置されます。複数AZへ分散して、高可用性、つまり障害時もサービスを継続しやすい構成を目指します。

注文受付から処理サーバーへ送る内部通信にもELBを使えます。バックエンドの個別アドレスを隠せますが、同期通信では相手の応答を待つ関係が残ります。

ここで押さえる高可用性は障害への備え。スケーリングは需要に合う容量。両方を設計する。

SQSはメッセージキュー。仕事をためて、ワーカーが自分のペースで取りに行きます。SNSは発行・購読（Pub/Sub）。注文のイベントを配送・分析などの購読先へ配ります。相手の状態への依存を減らす設計が疎結合です。

メッセージの中身はペイロード。例えば注文IDや配送先です。SNSから用途別のSQSへ配信すると、同じイベントをそれぞれ別のペースで処理できます。受付側はSQSへの送信成功を確かめ、受付済みと配送済みを別の状態として扱います。

ここで押さえるSQSで処理する時刻を分け、SNSで受け取る先を分ける。

使い方が読めない初期はオンデマンド、安定した利用が見えたらSavings PlansやReserved Instancesを検討。中断に耐えられるバッチにはSpotが候補になります。専有ホストは物理サーバーを専有する配置方法で、割引方式とは別の選択軸です。

ここで押さえる不要な容量を減らすことと、長期コミットで割引を得ることを分けて判断する。

販売サイトの流れを思い出して、サービス名の一覧ではなく「困りごとに対する役割」として説明してみましょう。

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

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