AWSアーキテクチャパターン入門｜3層Web・サーバーレス・イベント駆動の構成設計と選定基準

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWSアーキテクチャパターン入門｜3層Web・サーバーレス・イベント駆動の構成設計と選定基準
AWSを使ってシステムを構築しようとしたとき、「どのアーキテクチャパターンを選べばいいのか分からない」という壁にぶつかることは多い。
EC2でサーバーを立てるのか、Lambdaでサーバーレスにするのか、コンテナ（ECS/EKS）で組むのか——選択肢が多すぎて、何を基準に判断すればよいか迷う。

この記事では、AWSで実際に使われる代表的なアーキテクチャパターン4種類の特徴と、要件に応じた選定基準を解説する。RHEL 9系～Amazon Linux 2023を想定環境として、各パターンの構成要素とAWSサービスの組み合わせを体系的に整理する。

この記事のポイント

・AWSの主要アーキテクチャパターンは3層Web・サーバーレス・イベント駆動・マイクロサービスの4種類
・トラフィック特性・開発体制・コスト構造の3軸で選定基準を整理できる
・単一パターンに縛られず複数パターンを組み合わせるのが現場の実態
・パターン選択の前に「変化しやすい箇所」と「安定している箇所」を分けることが設計の出発点


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AWSアーキテクチャパターンを体系化する意味

AWSのサービスは2024年時点で200を超える。何も考えずにサービスを組み合わせると、後から「もっとシンプルにできた」「スケールしない」「コストが読めない」という状況に陥る。

アーキテクチャパターンとは、こうした失敗を繰り返さないための「設計の型」だ。パターンには名前があり、それぞれに得意な状況と苦手な状況がある。パターンを知っていれば、要件を聞いた瞬間に「これは3層Webで組むか、サーバーレスで組むか」という判断が素早くできる。

AWSはWell-Architected Frameworkという設計指針を公開しており、その中でも「信頼性」「パフォーマンス効率」「コスト最適化」の3つはアーキテクチャパターンの選択と直結する。

代表的な4つのAWSアーキテクチャパターン

1. 3層Webアーキテクチャ（クラシック構成）

最も広く使われる実績のあるパターンだ。プレゼンテーション層（ALB）・アプリケーション層（EC2 Auto Scaling Group）・データ層（RDS Multi-AZ）の3層で構成する。

代表的なAWSサービス構成：
・フロントエンド: Application Load Balancer（ALB）+ CloudFront
・アプリ: EC2（Auto Scaling Group）、Amazon Linux 2023
・データ: Amazon RDS（MySQL/PostgreSQL、マルチAZ有効）
・ストレージ: Amazon S3（静的コンテンツ）

向いているケース：
・既存のオンプレミスシステムのリフトアンドシフト
・チームがLinuxサーバー運用に慣れている
・トラフィックが比較的安定していて予測しやすい

注意点：
EC2は常時稼働なので、トラフィックが少ない夜間・休日もコストが発生する。Auto Scalingでスケールアウトはできるが、スケールインの設定を怠るとコストが膨らむ。

2. サーバーレスアーキテクチャ

API Gateway + Lambda + DynamoDB（またはRDS Proxy経由のRDS）を組み合わせるパターンだ。EC2のようなサーバー管理が不要で、使った分だけ課金される。

代表的なAWSサービス構成：
・API: Amazon API Gateway（REST API または HTTP API）
・ロジック: AWS Lambda（Python/Node.js/Java 等）
・データ: Amazon DynamoDB（NoSQL）または Amazon RDS（RDS Proxy経由）
・認証: Amazon Cognito


# Lambda関数のディレクトリ構成例（Python）
my-lambda-function/
├── lambda_function.py      # ハンドラ（lambda_handler関数を定義）
├── requirements.txt        # 依存ライブラリ
└── layer/                  # Lambda Layer（共通ライブラリ）
    └── python/
        └── lib/python3.12/
            └── site-packages/
向いているケース：
・トラフィックの変動が激しい（バースト型のアクセスパターン）
・バッチ処理・Webフック受信・IoTデータ収集など短時間で終わる処理
・小規模スタートアップで運用コストを最小化したい

注意点：
Lambdaのコールドスタート（初回起動の遅延）は、ユーザー向けAPIでは体感できる遅延になる場合がある。RDSへの接続はコネクションプール管理が必要で、RDS Proxyの導入が推奨される。

3. イベント駆動アーキテクチャ

コンポーネント間をイベント（メッセージ）でつなぎ、疎結合を実現するパターンだ。SQS・SNS・EventBridgeが中核サービスになる。

代表的なAWSサービス構成：
・イベントバス: Amazon EventBridge（スケジュール実行にも使える）
・キュー: Amazon SQS（Standard または FIFO）
・Pub/Sub: Amazon SNS（ファンアウトパターン）
・処理: AWS Lambda または ECS（バッチ処理）


# SQSキューへのメッセージ送信（AWS CLI）
aws sqs send-message \
  --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/order-queue \
  --message-body '{"orderId": "ORD-001", "status": "created"}'

# 出力例（環境により異なります）
{
    "MD5OfMessageBody": "d41d8cd98f00b204e9800998ecf8427e",
    "MessageId": "a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
向いているケース：
・受注処理・在庫更新・通知送信など複数の後続処理が連鎖するビジネスフロー
・マイクロサービス間の非同期通信
・ピーク時の処理量をキューで吸収したい（バックプレッシャー制御）

注意点：
非同期処理のため、エラー発生時のデバッグが同期処理より複雑になる。Dead Letter Queue（DLQ）を必ず設定し、失敗したメッセージを取りこぼさない設計が必要だ。

4. マイクロサービスアーキテクチャ

機能単位でサービスを分割し、それぞれを独立してデプロイ・スケールできるパターンだ。ECS（Fargate）またはEKSでコンテナを管理する。

代表的なAWSサービス構成：
・コンテナオーケストレーション: Amazon ECS（Fargate）または Amazon EKS
・サービス間通信: AWS App Mesh（サービスメッシュ）または ALB
・コンテナレジストリ: Amazon ECR
・CI/CD: AWS CodePipeline + CodeBuild

向いているケース：
・複数チームが独立してサービスを開発・デプロイする大規模組織
・機能ごとに異なる言語・フレームワークを採用する必要がある（ポリグロット）
・特定の機能だけ高速スケールが必要（例：検索機能だけ集中する）

注意点：
マイクロサービスは「小さいサービスを多く動かす」ため、サービス間通信の遅延・障害伝播の管理が必要になる。小規模チームで導入するとオーバーヘッドが勝ることが多い。コンウェイの法則が示すように、チーム構造とサービス分割を一致させることが設計成功の鍵だ。

パターン選定の3つの判断軸

1. トラフィック特性で選ぶ


トラフィック特性 適するパターン 理由
安定・予測可能 3層Web EC2固定コストが無駄にならない
バースト型（急増・急減） サーバーレス リクエスト数に応じた自動スケール
非同期・大量メッセージ イベント駆動 キューで流量を吸収できる
機能ごとに異なる負荷 マイクロサービス サービス単位でスケール制御できる

2. 開発・運用体制で選ぶ

チームが5人以下の小規模スタートアップでマイクロサービスを選ぶのは、多くの場合オーバーエンジニアリングだ。サービス分割・デプロイパイプライン・サービスメッシュの維持コストが開発速度を下げる。

・3層Web: Linuxサーバー管理の知識があるチームに向く。既存の運用手順をそのまま活かせる
・サーバーレス: インフラ管理の工数を最小化したいスタートアップや小規模チームに向く
・イベント駆動: データエンジニアリングやバッチ処理が多いチームに向く
・マイクロサービス: 複数チームが独立して動ける組織規模（エンジニア20人以上が目安）になってから検討する

3. コスト構造で選ぶ


パターン コスト変動 注意点
3層Web 固定費（EC2）+ 従量 低トラフィック時もEC2課金が続く
サーバーレス 完全従量制 高トラフィック時はEC2より割高になる閾値がある
イベント駆動 メッセージ数に比例 SQSのAPI呼び出し数・転送量に注意
マイクロサービス コンテナ数に比例 サービス数が多いとベースコストが高い

アーキテクチャ設計の実践ステップ

1. 要件と制約を洗い出す

設計を始める前に、以下の問いに答えられるようにしておく。

・1日あたりのリクエスト数とピーク時の倍率はどのくらいか
・データの整合性（強整合性が必要か、結果整合性でよいか）はどちらか
・レスポンスタイムの許容上限は何ミリ秒か
・チームのAWS経験レベルはどのくらいか

AWSでLinuxサーバーを動かす際の基礎は、Amazon LinuxでのAWS入門ページで確認しておくと、3層Webパターンの実装をスムーズに進められる。

2. 変化しやすい箇所と安定している箇所を分ける

ドメインの中で「頻繁に変わる機能」と「変化しにくい機能」を分けることが、パターン選択の実質的な出発点だ。

・認証・決済・通知など汎用的な機能: SaaSまたはマネージドサービスで代替する
・ビジネスロジックのコアになる機能: チームが直接管理する
・将来的に切り出す可能性が高い機能: 最初からモジュール境界を意識して設計する

最初から完全なマイクロサービスを目指す必要はない。「モジュラーモノリス（単一デプロイ・モジュール分割）」として始め、スケールや組織の成長に合わせてサービス分割を行う段階的アプローチが現実的だ。

3. パターンの組み合わせを設計する

実際の本番システムは単一パターンだけで構成されていることは少ない。典型的な組み合わせ例：

・3層Web + イベント駆動: メインのWebアプリは3層Web、非同期の後続処理（メール送信・帳票生成）はSQS + Lambdaで担う
・サーバーレス + CDN: API GatewayのバックエンドをLambdaで動かし、静的コンテンツはS3 + CloudFrontで配信する
・マイクロサービス + イベント駆動: ECS上のサービス間通信にSNS/SQSを使い、同期呼び出しを最小化する

設計時のよくある迷いどころ

「サーバーレスにすべきか、EC2にすべきか」

月間リクエスト数が1億を超えるようなシステムでは、Lambda単価（0.2ドル/100万リクエスト）とEC2の固定費を比較すると、EC2の方がコスト効率が高い場合がある。

一方、リクエスト数が不確かなスタートアップフェーズでは、サーバーレスから始めてトラフィックが読めるようになった段階でEC2へ移行するアプローチも合理的だ。

「DynamoDBかRDSか」

DynamoDBはJOINが使えない代わりに、テーブル設計次第で非常に高いスループットを発揮する。アクセスパターンが事前に確定できるなら有力な選択肢だ。

一方でRDSは既存のSQLスキルがそのまま使えるため、移行コストが低い。複雑なクエリや集計処理が必要なシステムにはRDSの方が適合しやすい。

本記事のまとめ


パターン 主なAWSサービス 向いているケース
3層Web ALB + EC2 + RDS 安定トラフィック・オンプレからの移行
サーバーレス API Gateway + Lambda + DynamoDB バースト型・小規模スタート
イベント駆動 SQS + SNS + Lambda 非同期処理・マイクロサービス連携
マイクロサービス ECS/EKS + ECR + App Mesh 複数チーム・大規模組織

アーキテクチャパターンは「どれが一番優れているか」ではなく「今のチームと要件に最も合うか」で選ぶものだ。最初のシステムは3層Webかサーバーレスのシンプルなパターンでスタートし、スケールや組織の成長に合わせて進化させていく方針が、現場での成功率が高い。

AWSアーキテクチャの「なぜこのパターンか」を語れる力は、Linuxサーバー構築の「型」から生まれます

クラウドの設計力は、オンプレミスのLinuxサーバー構築から体系的に身につけた基礎があってこそ活きる。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。