― 高可用性・スケーラビリティ・コスト最適化を同時に実現する構成 ―
はじめに
多くの企業では、オンプレミス環境に複数の Windows サーバーを配置し、業務アプリケーションを稼働させています。
しかし近年では、可用性向上・需要変動への対応・コスト最適化を目的として、AWS への移行が進んでいます。
本記事では、以下の要件を満たす 最適な AWS アーキテクチャ を解説します。
- 高可用性（HA）を確保したい
- アクセス増減に応じて自動でスケールしたい
- 無駄なコストを抑えつつパフォーマンスを向上させたい
問題概要
早速問題を見ていきましょう。
ある企業には、オンプレミス環境にWindowsサーバーを複数利用したアプリケーションを実行しています。あなたはソリューションアーキテクトとして、このアプリケーションをAWSに移行することになりました。その際は、高可用性を確保して、需要に応じてインスタンス数を調整することで、コスト最適とパフォーマンス向上を達成できる構成が必要です。
ソリューションアーキテクトとして、どのようにソリューションを構成すれば良いでしょうか。
選択肢
- EC2インスタンスを複数のアベイラビリティゾーンに均質に展開するAuto Scalingグループを設定して、ALBをターゲットグループに設定する。
- ベースラインキャパシティとなるオンデマンドインスタンスとスケール用のスポットインスタンスを構成したスポットフリートを複数アベイラビリティゾーンに設定する。
- ベースラインキャパシティとなるオンデマンドインスタンスとスケール用のスポットインスタンスを構成したEC2フリートを複数アベイラビリティゾーンに設定する。
- ベースラインキャパシティとなるオンデマンドインスタンスとスケール用のスポットインスタンスを構成したスポットブロックを複数アベイラビリティゾーンに設定する。
※これより先は回答と解説が載っているので皆さんもまずは考えてみてください。
正解
- EC2インスタンスを複数のアベイラビリティゾーンに均質に展開するAuto Scalingグループを設定して、ALBをターゲットグループに設定する。
(+α ベースラインキャパシティはオンデマンド、スケール分はスポットインスタンスを使用する。)
なぜこの構成が最適なのか
① 高可用性（High Availability）
- 複数アベイラビリティゾーン（Multi-AZ）
- AZ 障害が発生しても、ALB が正常な EC2 に自動でトラフィックを振り分け
- 単一障害点（SPOF）を排除
② スケーラビリティ
- Auto Scaling Group
- CPU 使用率やリクエスト数に応じて自動スケール
- 突発的なトラフィック増加にも即応
③ コスト最適化(+α)
- ベースライン：オンデマンドインスタンス
- 常時必要な最低限のキャパシティを安定確保
- スケール分：スポットインスタンス
- 最大 90% 割引でコスト削減
- 中断されても Auto Scaling が補充
構成図（アーキテクチャ）
インターネット
|
+----------------+
| Application |
| Load Balancer |
+----------------+
| |
--------+ +--------
| |
+-------------+ +-------------+
| EC2 (Win) | | EC2 (Win) |
| On-Demand | | On-Demand |
| AZ-A | | AZ-B |
+-------------+ +-------------+
| |
+-------------+ +-------------+
| EC2 (Win) | | EC2 (Win) |
| Spot | | Spot |
| AZ-A | | AZ-B |
+-------------+ +-------------+
↑
Auto Scaling Group
（複数 AZ・混在インスタンス）
不正解の選択肢とその理由
❌ オプション2
スポットフリートを複数 AZ に設定
- スポットフリート単体では
- ALB との直接的なスケーリング連携が弱い
- アプリケーションレベルのスケーリング制御が困難
- Auto Scaling による柔軟な制御が前提のシナリオでは不適
❌ オプション3
EC2 フリートを複数 AZ に設定
- EC2 フリートは「起動戦略」の制御が主目的
- Auto Scaling Group のような
- ヘルスチェック連携
- 動的なスケーリングポリシー
が前提ではない
👉 SAA試験では「Auto Scaling Group + ALB」が鉄板
❌ オプション4
スポットブロックを使用
- スポットブロックは
- 最大6時間の中断なしスポットインスタンス
- 現在は廃止済み
- 試験・実務ともに選択肢として不適
試験対策ポイント（SAA頻出）
- 高可用性 + スケーリング
→ Auto Scaling Group - Web / アプリ層の分散
→ ALB - コスト最適化
→ オンデマンド + スポットの混在 - 複数 AZ が明示されていたら ALB + ASG を最優先で検討
まとめ
オンプレミスの Windows アプリケーションを AWS に移行する場合、
- ALB
- 複数 AZ の Auto Scaling Group
- オンデマンド + スポットの混在構成
この組み合わせが
👉 可用性・スケーラビリティ・コスト最適化をすべて満たす最適解です。
SAA 試験だけでなく、実務設計でもそのまま使える王道パターンなので、確実に押さえておきましょう。
以上でオンプレミスの Windows アプリケーションを AWS に移行する最適解の解説を終了します。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
