3層Webアプリ（高可用構成）
プレゼン層・アプリ層・データ層を分離し、複数AZ＋Auto Scaling＋Multi-AZ DBで可用性を確保する王道構成。
中級信頼性セキュリティパフォーマンス効率
このパターンは？
最も基本的で頻出の「3層アーキテクチャ」。役割ごとに層を分け、各層を複数AZに冗長化します。SAAでも実務でも王道です。
- プレゼン層: 静的配信とロードバランシング
- アプリ層: ビジネスロジック（自動スケール）
- データ層: 永続データ（高可用DB）
構成
[ユーザー]
│ HTTPS
▼
Route 53 (DNS) ──► CloudFront (CDN) ──► S3 (静的アセット/画像)
│
▼
ALB (L7ロードバランサ・複数AZ)
│
▼
アプリ層: EC2 or ECS/Fargate (Auto Scaling・複数AZ・プライベートサブネット)
│
▼
データ層: RDS / Aurora (Multi-AZ・プライベートサブネット・暗号化)
各層の役割
- Route 53: ドメイン解決。apexはAliasでCloudFront/ALBへ。フェイルオーバーでDRも
- CloudFront + S3: 静的アセットをエッジ配信し、オリジン負荷を軽減
- ELB(ALB): リクエストを複数AZのアプリへ分散、ヘルスチェックで異常を除外
- EC2 / ECS: アプリ本体。Auto Scalingで負荷追従
- RDS / Aurora: Multi-AZで自動フェイルオーバー、読み取りはリードレプリカ
設計の勘所
ステートレス＋層の分離
アプリ層はステートレスにし、セッションは DynamoDB や ElastiCache へ。そうすれば台数を自由に増減でき、Auto Scalingが効きます。
- サブネットは**パブリック（ALB）/ プライベート（アプリ・DB）**で分離
- DBはプライベートに置き、外部公開しない
- 各層のサブネットを2つ以上のAZに配置
Well-Architected の観点
- 信頼性: 複数AZ・Auto Scaling・Multi-AZ DBで単一障害点を排除
- セキュリティ: 層の分離・最小公開・IAMロール・暗号化
- パフォーマンス効率: CDN＋水平スケール＋リードレプリカ
よくある落とし穴
アンチパターン
- 単一AZ構成（AZ障害で全停止）
- DBをパブリックサブネットに置く
- アプリ層がローカルにセッション/ファイルを持ち、スケールできない
監視は CloudWatch でアラーム→Auto Scaling連携。各層のメトリクスとログを集約しましょう。
AWS Pattern
3層Webアプリ（高可用構成）を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
reliability
比較で見る軸
クラウド: AWS / 難易度: intermediate / 関連サービス: 9件
導入後に効く点
プレゼン層・アプリ層・データ層を分離し、複数AZ＋Auto Scaling＋Multi-AZ DBで可用性を確保する王道構成。
先に潰すリスク
パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。
数字・仕様の読み方
- クラウド
- AWS
- 難易度
- intermediate
- 関連サービス
- 9件
- 設計柱
- reliability / security / performance
判断チェックリスト
- 自社の用途が「reliability / security」に近いか確認する。
- 強みである「プレゼン層・アプリ層・データ層を分離し、複数AZ＋Auto Scaling＋Multi-AZ DBで可用性を確保する王道構成。」が本当に評価軸になるか確認する。
- 注意点の「パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
reliabilitysecurityperformanceAmazon Route 53Amazon CloudFrontElastic Load Balancing (ELB)Amazon EC2Amazon ECS / Fargate