AWSアーキテクチャパターン集

周辺資料: 学習インデックス · AWSサービス一覧（2026） · サービス選定ガイド · アンチパターン集

AWS設計で頻出するアーキテクチャパターンを、採用条件・実装ポイント・落とし穴で整理。

1. サーバーレス API パターン

構成

• Client → CloudFront → API Gateway → Lambda → DynamoDB / S3
• ↑ WAF ↑ ElastiCache（キャッシュ）
• Cognito（認証） SQS（非同期処理オフロード）

採用条件

• リクエストが散発的でコールドスタートが許容できる
• 実行時間 < 15分
• 運用チームが小さくインフラ管理コストを最小化したい

実装ポイント

• Lambda は 冪等性を前提に設計（SQS のAt-Least-Once配信に対応）
• DynamoDB のアクセスパターンを先に定義し Single Table Design を検討
• CloudFront でキャッシュ可能なエンドポイントは TTL を設定してコスト削減

落とし穴

• コールドスタートが問題になる場合は Provisioned Concurrency または ECS へ切替
• Lambda 内で長い外部呼び出し → タイムアウト設計が必要（SQS でオフロード）

2. コンテナ 3層 Web パターン

構成

Route 53 → CloudFront → WAF → ALB
                                 → ECS Fargate（App）
                                       → Aurora（RDS）/ ElastiCache Redis
                       CloudWatch / X-Ray（監視・トレース）
                       Secrets Manager（DB認証情報）

採用条件

• 常時起動の HTTP サービスでコールドスタート許容不可
• 複雑なビジネスロジック / 長時間処理が必要
• RDB トランザクションが必要

実装ポイント

• Aurora Multi-AZ + Read Replica を最低ライン
• ALB のターゲットグループに Deregistration Delay 30秒 を設定（ローリング更新時のドレイン）
• ECS タスク定義の cpu / memory を本番トラフィック計測で調整

落とし穴

• ElastiCache のコネクション数上限（Redis デフォルト65,000接続）を事前確認
• Aurora Serverless v2 はウォームアップ時間があるため高トラフィック直後に注意

3. イベント駆動（非同期処理）パターン

構成

API / S3 Event → EventBridge → SQS → Lambda（Consumer）
                     │                      ↓ 失敗
               EventBridge Rule      DLQ（Dead Letter Queue）
                     │                      ↓
               複数のターゲット       CloudWatch Alarm → SNS → PagerDuty

採用条件

• Producer と Consumer を疎結合にしたい
• 処理失敗時に再試行・保全が必要
• 複数のコンシューマーが同一イベントを処理

実装ポイント

• 冪等性キー: DynamoDB に idempotencyKey を保存し重複実行を防ぐ
• 再試行ポリシー: exponential backoff + jitter（最大再試行3〜5回）
• DLQ 監視: DLQ の ApproximateNumberOfMessagesVisible > 0 でアラーム
• EventBridge Archive で全イベントを記録し障害調査・再処理を可能にする

落とし穴

• SQS Standard はメッセージ順序を保証しない（順序必要なら FIFO）
• Lambda の同時実行数制限でコンシューマーが詰まる → Reserved Concurrency 設定

4. CQRS（コマンドクエリ責任分離）パターン

構成

[Write Side]                    [Read Side]
Client → API GW → Lambda    →   DynamoDB Streams → Lambda → OpenSearch
                  ↓                                          （検索用）
              Aurora（ACID）  →  EventBridge → Lambda → ElastiCache
                                                         （キャッシュ）

採用条件

• 読み取りと書き込みのスケール要件が大きく異なる
• 検索・集計クエリが複雑で OLTP DB での実行が重い
• 結果整合性が許容できる（数秒〜数十秒の遅延可）

実装ポイント

• DynamoDB Streams の Trim Horizon で全変更を捕捉
• 読み取りモデルは用途別に最適化（OpenSearch: 全文検索 / ElastiCache: 低レイテンシ）
• 同期の遅延をクライアントに明示（「最新データは数秒後に反映」）

5. Saga パターン（分散トランザクション）

構成

Order Service → [Step Functions State Machine]
                 ├── 在庫確保（Inventory Service）
                 │      失敗 → 補償: 在庫解放
                 ├── 決済処理（Payment Service）
                 │      失敗 → 補償: 在庫解放 + 決済キャンセル
                 └── 出荷手配（Shipping Service）
                        失敗 → 補償: 全ステップ逆順で補償

採用条件

• マイクロサービス間をまたぐトランザクションが必要
• 各サービスが独立したDBを持つ（分散2フェーズコミットが使えない）

実装ポイント

• Step Functions の Wait for Callback で非同期ステップを統合
• 各補償トランザクションは べき等 に実装
• タイムアウトと補償ロジックを全ステップで定義

6. ストリーム処理パターン

構成

IoT / App → Kinesis Data Streams（シャード設計）
                 ↓
           Managed Service for Apache Flink（ウィンドウ集計）
                 ↓
       ┌─────────────────────────┐
       OpenSearch（リアルタイム）  Kinesis Firehose → S3（バッチ）
       （Dashboards で可視化）

採用条件

• 秒〜分単位の集計・異常検知が必要
• 複数のコンシューマーが同一ストリームを並列処理
• 過去データの再処理（リプレイ）が必要

シャード設計の目安

Kinesis Data Streams:
  1シャード = 1MB/s (write) + 2MB/s (read)
  必要シャード数 = Max(write_rate / 1MB, consumer数 × read_rate / 2MB)

パーティションキーの選定:
  カーディナリティが高いキーを選ぶ（偏りを避ける）
  例: userID > 都道府県コード

7. マルチリージョン パターン

Active-Passive（DR）構成

ap-northeast-1（Primary）                us-east-1（Secondary）
  Route 53 Failover ←──────────────────→ Route 53 Failover
  ALB → ECS/Lambda                        ALB → ECS/Lambda（停止中）
  Aurora Primary ──── Global DB Replica ─→ Aurora Secondary
  DynamoDB ──────────── Global Tables ──→ DynamoDB
  S3 ────────────────── CRR ────────────→ S3
  └── Pilot Light: 最小リソースのみ起動, フェイルオーバー時にスケールアップ
  └── Warm Standby: 本番の1/5〜1/10 規模で常時稼働

Active-Active（グローバル低レイテンシ）構成

Route 53 地理的ルーティング / Global Accelerator
  ├── ap-northeast-1（Asia向け）
  │     ALB → ECS → DynamoDB Global Tables（Write）
  └── us-east-1（North America向け）
        ALB → ECS → DynamoDB Global Tables（Write）

  DynamoDB Global Tables: どのリージョンからも書き込み可（最終的整合性）
  Aurora Global Database: Write は Primary のみ（Read Replica を各リージョンに）

DR 戦略比較

8. RAG（検索拡張生成）パターン

構成

[取り込みパイプライン]
S3（文書）→ Lambda/Glue → Bedrock Titan Embedding
                                    ↓
                          OpenSearch Serverless
                          （ベクトルインデックス）

[推論パイプライン]
User Query → API Gateway → Lambda
                               ├── Bedrock Embedding（クエリベクトル化）
                               ├── OpenSearch kNN検索（関連文書取得）
                               └── Bedrock Claude（コンテキスト＋回答生成）
                                          ↓
                                     引用ソース付きで返答

Bedrock Knowledge Bases vs 自前実装

Bedrock Knowledge Bases を選ぶ場合:
  - RAGをマネージドで使いたい
  - チャンキング設定（固定/階層型/意味的）だけカスタマイズすれば十分
  - Bedrock Agents と統合したい

自前実装を選ぶ場合:
  - 独自のリランキング・ハイブリッド検索ロジックが必要
  - RAGASなどの評価パイプラインを細かく制御したい
  - コスト最適化のためEmbedding をバッチ処理したい

9. マルチアカウント基盤パターン

構成

Organizations（Root）
  ├── Management Account（請求・SCP管理専用）
  ├── Security OU
  │     ├── Security Tooling Account
  │     │     GuardDuty Master / Security Hub Master / Macie / Detective
  │     └── Log Archive Account
  │           CloudTrail（全アカウント集約） / Config / S3 Access Logs
  ├── Infrastructure OU
  │     └── Shared Services Account
  │           VPC 共有（RAM） / IAM Identity Center / ECR / Route 53
  └── Workloads OU
        ├── Prod Account
        ├── Staging Account
        └── Dev Account（複数可）

SCP 設計の原則

[推奨: 許可リスト戦略ではなく拒否リスト戦略]
  Management Account に全権限
  各 OU には以下を拒否:
    - GuardDuty / CloudTrail / Config の無効化
    - ルートアカウントの日常利用
    - 特定リージョン以外のリソース作成
    - IAM パスワードポリシーの弱体化

[例: SCP で東京リージョン以外を禁止]
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1"]
    },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/BreakGlassRole"
    }
  }
}

10. パターン選定フローチャート

新システムの設計
  │
  ├─ リアルタイム処理が必要？ ─────────────── Yes → ストリーム処理パターン
  │
  ├─ 複数マイクロサービスのトランザクション？ → Saga パターン
  │
  ├─ 読み書きのスケール要件が大きく異なる？ → CQRS パターン
  │
  ├─ 生成AI / LLM を使う？ ──────────────── Yes → RAG パターン
  │
  ├─ マルチアカウント管理が必要？ ──────────── Yes → マルチアカウント基盤パターン
  │
  ├─ 常時起動の HTTP API？ ──────────────── Yes → コンテナ3層パターン
  │                                         No
  └─ イベント駆動・散発的 → サーバーレス API パターン
                              または
                           イベント駆動（非同期）パターン

11. 各パターンの運用監視ポイント