オンプレのシステムをAWSに移行しようとしたとき、「どこから設計を始めればいいのか」と頭を抱えるエンジニアは少なくありません。物理サーバーで何年もインフラを構築してきた経験があっても、クラウドの設計思想は根本的に異なるため、最初はなかなかイメージが掴みにくいものです。
この記事では、クラウド設計の基礎中の基礎である3層アーキテクチャ（Three-Tier Architecture）をAWSでどう実現するかを、オンプレ経験者の目線で丁寧に解説します。VPCのサブネット設計からALB・EC2・RDS の配置、Auto Scaling による可用性確保まで、現場で通用するレベルで順を追って説明します。
なぜ3層アーキテクチャなのか？（オンプレとの違い）
オンプレ環境では、Webサーバー・アプリサーバー・DBサーバーを物理的に分離するか、あるいはすべてを1台の大型サーバーに乗せる構成が一般的でした。しかしAWSを使うと、この「分離」をより柔軟かつ安全に実現できます。
3層アーキテクチャとは、システムを次の3つの論理層に分割する設計パターンです。
・Web層（プレゼンテーション層）: ユーザーからのHTTPリクエストを受け付ける。ロードバランサーと複数のWebサーバーで構成する
・アプリ層（ロジック層）: ビジネスロジックを処理する。外部インターネットから直接アクセスさせない
・DB層（データ層）: データの永続化を担う。最も厳重に保護する
オンプレで同じ構成を作ろうとすると、サーバーの調達・設置・ネットワーク設計・冗長化と手間がかかります。AWSでは、これらを数時間で組み上げられます。
| 比較項目 | オンプレミス | AWS（3層アーキテクチャ） |
|---|---|---|
| 冗長化 | 物理サーバーを2台用意して手動設定 | マルチAZ構成を数クリックで実現 |
| スケーリング | サーバー増設に数日〜数週間 | Auto ScalingでCPU負荷に応じて自動増減 |
| ネットワーク分離 | 物理VLAN設計が必要 | VPCのサブネットで論理的に分離 |
| 障害時の切り替え | 手動またはクラスタリングソフトが必要 | ALBが自動でヘルスチェックして振り分け |
AWSで実現する3層アーキテクチャの全体像
AWSで標準的な3層アーキテクチャを組む場合、主要なサービスは次のように対応します。
| 層 | 役割 | 主なAWSサービス |
|---|---|---|
| Web層 | HTTP/HTTPS リクエストの受付・振り分け | Application Load Balancer（ALB） |
| アプリ層 | ビジネスロジックの処理 | Amazon EC2（Auto Scaling グループ） |
| DB層 | データの保存・取得 | Amazon RDS（マルチAZ配置） |
全体の通信フローは次のようになります。
・インターネット → ALB（パブリックサブネット）
・ALB → EC2インスタンス群（プライベートサブネット）
・EC2 → RDS（別のプライベートサブネット）
この設計では、EC2とRDSはインターネットから直接アクセスできません。ALBがインターネットとアプリ層の間に立ち、不正なリクエストを受け流す役割も担います。
Web層の設計：Application Load Balancer
ALBはHTTP/HTTPSのリクエストをバックエンドのEC2インスタンスに振り分けるL7ロードバランサーです。オンプレのF5やHAProxyに相当します。
ALBの主な設定項目は以下のとおりです。
・リスナー: HTTPS（ポート443）を受け付けてターゲットグループに転送する
・ターゲットグループ: EC2インスタンスのグループ。ヘルスチェックの設定もここで行う
・SSL証明書: AWS Certificate Manager（ACM）で無料取得して ALB に適用する
オンプレでSSL証明書の更新を手動でやって痛い目を見た経験があるなら、ACMの自動更新は特に助かります。
アプリ層の設計：EC2 と Auto Scaling
アプリ層のEC2インスタンスはプライベートサブネットに配置します。インターネットから直接アクセスできない代わりに、ALBからのトラフィックのみを受け付けます。
Auto Scaling グループを設定することで、CPU使用率などの指標をトリガーにインスタンス数を自動的に増減できます。
・起動テンプレート: 使用するAMI・インスタンスタイプ・セキュリティグループを定義
・スケーリングポリシー: 「CPU使用率が70%を超えたらインスタンスを1台追加する」等のルールを設定
・最小・最大・希望台数: 最小2台（可用性確保）、最大10台（コスト上限）等で設定する
DB層の設計：Amazon RDS マルチAZ
DBはアプリ層とは別のプライベートサブネットに配置します。RDSのマルチAZ配置を有効にすると、プライマリとスタンバイの2インスタンスが異なるアベイラビリティゾーン（AZ）に自動配置されます。
・フェイルオーバー: プライマリに障害が発生すると、スタンバイへの切り替えが自動で行われる（通常60〜120秒）
・読み取り負荷分散: リードレプリカを追加すればSELECTクエリを分散できる
・バックアップ: 自動バックアップとスナップショットをRDSが管理する
設計の具体的なステップ
実際にAWSコンソールでこの構成を組む手順を説明します。
1. VPCとサブネットの設計
まず、3層アーキテクチャ専用のVPCを作成します。CIDR例として 10.0.0.0/16 を使用します。
# サブネット設計例（東京リージョン ap-northeast-1 の場合） # パブリックサブネット（ALB配置用） 10.0.1.0/24 → ap-northeast-1a（ALB） 10.0.2.0/24 → ap-northeast-1c（ALB） # プライベートサブネット（アプリ層 EC2 配置用） 10.0.11.0/24 → ap-northeast-1a（EC2） 10.0.12.0/24 → ap-northeast-1c（EC2） # プライベートサブネット（DB層 RDS 配置用） 10.0.21.0/24 → ap-northeast-1a（RDS プライマリ） 10.0.22.0/24 → ap-northeast-1c（RDS スタンバイ）
パブリックサブネットにはインターネットゲートウェイ（IGW）へのルートを設定します。プライベートサブネットのEC2がインターネットにアクセスする必要がある場合（yumやapt等）は、NAT Gatewayをパブリックサブネットにプロビジョニングしてルートを通します。
2. セキュリティグループの設計
3層それぞれにセキュリティグループを作成します。「最小権限の原則」に従い、必要最低限の通信だけを許可します。
# sg-alb（ALB 用セキュリティグループ） インバウンド: TCP 443 from 0.0.0.0/0（インターネットから HTTPS 許可） インバウンド: TCP 80 from 0.0.0.0/0（HTTP → HTTPS リダイレクト用） アウトバウンド: TCP 8080 to sg-app（アプリ層 EC2 への転送のみ） # sg-app（アプリ層 EC2 用セキュリティグループ） インバウンド: TCP 8080 from sg-alb（ALB からのみ許可） アウトバウンド: TCP 3306 to sg-db（RDS への接続のみ） # sg-db（RDS 用セキュリティグループ） インバウンド: TCP 3306 from sg-app（アプリ層からのみ許可） アウトバウンド: なし
セキュリティグループの「ソース」にCIDRではなく他のセキュリティグループIDを指定するのがポイントです。インスタンスが増減してもIPが変わらず、設定変更が不要です。
3. ALBの設定
AWSコンソールの「EC2 → ロードバランサー」から Application Load Balancer を作成します。
・スキーム: インターネット向け（internet-facing）を選択
・サブネット: パブリックサブネット（2AZ以上）を選択
・セキュリティグループ: sg-alb を割り当てる
・リスナー: HTTPS:443 を追加し、ACMの証明書を選択する
・ターゲットグループ: アプリ層のEC2インスタンスを追加する
HTTPSリスナーにはHTTPポート80からのリダイレクトルールも追加しておくと、ユーザーが http:// でアクセスしてきたときに自動的に https:// に誘導されます。
4. Auto Scaling グループの設定
「EC2 → Auto Scaling グループ」から作成します。
・起動テンプレート: 使用するAMI・インスタンスタイプ（例: t3.medium）・sg-appを定義
・VPCとサブネット: アプリ層のプライベートサブネット（2AZ）を選択
・ロードバランサー: 先ほど作成したターゲットグループを関連付ける
・スケーリングポリシー: 「ターゲット追跡」で CPU使用率60% を目標に設定
・希望台数2・最小2・最大6: 最低2台で冗長性を確保する
5. RDS マルチAZの設定
「RDS → データベースの作成」から設定します。
・エンジン: MySQL 8.0 または Amazon Aurora MySQL 互換版を選択
・デプロイオプション: 「マルチAZ DB インスタンス」を選択
・インスタンスクラス: db.t3.medium（開発・ステージング）または db.r6g.large（本番）
・ストレージ: gp3（汎用SSD）、20GB〜で必要に応じて拡張
・VPC: 作成したVPC、DBサブネットグループを指定
・セキュリティグループ: sg-dbを割り当てる
・バックアップ保持: 7日間（本番は30日推奨）
料金の仕組みとコスト感覚
3層アーキテクチャを本番運用する際の料金感覚をつかんでおきましょう。以下は東京リージョン（ap-northeast-1）の参考料金です（2026年4月時点）。
| コンポーネント | 想定構成 | 月額目安（USD） |
|---|---|---|
| ALB | 1台（LCU消費に応じて変動） | $16〜$50 |
| EC2（アプリ層） | t3.medium × 2台（常時稼働） | $60〜$80 |
| RDS（マルチAZ） | db.t3.medium MySQL × 1（マルチAZ） | $80〜$100 |
| NAT Gateway | 1台（データ転送量に依存） | $30〜$60 |
| 合計（目安） | — | $200〜$300程度 |
NAT Gatewayのコストは見落としがちです。EC2からのアウトバウンドデータ量が多い場合、NAT Gatewayの料金が数万円に膨らむことがあります。アプリからの外部通信が多いシステムでは、事前にデータ転送量を見積もっておくことをおすすめします。
コスト削減のポイントとしては、RDSのマルチAZをステージング環境では無効化する（シングルAZに変更するだけで約半額になる）方法が現実的です。本番は必ずマルチAZにしてください。
応用・実務Tips
【Tips 1】セッション管理はElastiCacheで共有化する
Auto ScalingでEC2が増えると、各インスタンスがセッション情報を個別に保持することになり、リクエストを別のインスタンスにルーティングされたユーザーがログアウトされる問題が起きます。
この問題の解決策は、セッションをAmazon ElastiCache（Redis）に外出しすることです。全EC2インスタンスがElastiCacheを参照するため、どのインスタンスにルーティングされても同じセッションが使えます。
【Tips 2】デプロイはBlue/Green方式を検討する
アプリの更新時、インスタンスを1台ずつ差し替える「ローリングアップデート」だとダウンタイムのリスクがあります。ALBのターゲットグループを2つ用意して「Blue（現行）」と「Green（新バージョン）」を切り替えるBlue/Green方式を導入すると、問題発生時に即座に切り戻せます。
【Tips 3】踏み台サーバー（Bastion Host）の代わりにSSM Session Manager
プライベートサブネットのEC2にSSHするために踏み台サーバーを立てていたオンプレ時代の癖が残っているエンジニアは多いのですが、AWSではSSM Session ManagerでSSHポートなしのセキュアなシェルアクセスが可能です。踏み台サーバーのコストも削減できます。
よくあるトラブルと対処法
【トラブル1】EC2がRDSに接続できない
最も多い原因はセキュリティグループの設定ミスです。RDSのセキュリティグループのインバウンドルールで、ソースにEC2のセキュリティグループIDが正しく指定されているか確認してください。CIDRで指定している場合は、EC2のプライベートIPのサブネット範囲と一致しているか確認します。
# AWS CLI でRDSのセキュリティグループを確認する aws rds describe-db-instances --db-instance-identifier your-db-identifier --query 'DBInstances[*].VpcSecurityGroups' # EC2からRDSへの疎通確認（EC2にSSM接続してから実行） nc -zv your-rds-endpoint.rds.amazonaws.com 3306
【トラブル2】ALBのヘルスチェックが失敗する
ALBのターゲットグループでヘルスチェックのパス（例: /health）が404を返している場合、バックエンドのEC2でそのエンドポイントが実装されていないことが原因です。アプリ側にヘルスチェック用のエンドポイントを用意するか、ALBのヘルスチェックパスをアクセス可能なURLに変更してください。
ヘルスチェックのレスポンスコードが2xx系であれば「健全」と判定されます。EC2のセキュリティグループでALBからのポートが許可されているかも同時に確認してください。
【トラブル3】Auto Scalingが想定より遅く起動する
新しいインスタンスが起動してからALBのヘルスチェックを通過するまでに数分かかる場合、AMIにアプリのセットアップが含まれていないことが原因です。UserDataスクリプトでアプリを都度インストールするより、あらかじめアプリを組み込んだ「ゴールデンAMI」を作成しておくと起動時間を大幅に短縮できます。
本記事のまとめ
・3層アーキテクチャ: Web層（ALB）・アプリ層（EC2）・DB層（RDS）を分離する設計パターン。オンプレより冗長化・スケーリングが容易
・サブネット設計: パブリック（ALB）・プライベート（EC2）・プライベート（RDS）の3種を2AZ以上で作成する
・セキュリティグループ: 層ごとに作成し、ソースに他のSGのIDを指定することで最小権限を実現
・コスト目安: 最小構成で月$200〜$300程度。NAT Gatewayのデータ転送料に注意
・実務Tips: セッション共有はElastiCache、デプロイはBlue/Green、踏み台の代わりにSSM Session Managerを活用する
Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。EC2上でLinuxを扱う機会が多い方はあわせてご参照ください。
AWS移行を任されたけど、どこから手を付けるか迷っていませんか？
3層アーキテクチャはクラウド設計の出発点です。しかし、実際の現場では「設計はわかった、でも運用でハマった」という声が後を絶ちません。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
コメント