パターン①：スタンダードな Web アプリ
オンプレミスから AWS に移行する場合や、一般的なWebシステムを構築する場合の基本構成です。
🌐 構成フロー
ユーザー
└─→ Route 53（DNS）
└─→ CloudFront（CDN / HTTPS 終端）
└─→ ALB（ロードバランサー）
└─→ ECS / EC2（アプリサーバー ×複数AZ）
└─→ Aurora（RDS マルチAZ）
└─→ ElastiCache（Redis / セッション・キャッシュ）
静的コンテンツ：S3 → CloudFront で配信
IAM ロールで ECS → Aurora へのアクセスを制御
KMS で RDS の保存データを暗号化
CloudWatch でメトリクス・ログを監視
主なサービス： Route 53 / CloudFront / ALB / ECS（Fargate）/ Aurora / ElastiCache / S3 / IAM / KMS / CloudWatch
💡 設計のポイント
① ALB ターゲットグループを使い、ECS サービスを複数 AZ に分散。② Aurora マルチAZ でDB の高可用性を確保。③ CloudFront でオリジンへの直接アクセスをブロックし、HTTPS を強制。
パターン②：サーバーレス API
インフラ管理をゼロに近づけ、開発者がビジネスロジックに集中できる構成です。スタートアップや小規模 API に向いています。
⚡ 構成フロー
クライアント
└─→ Route 53
└─→ CloudFront（API をキャッシュ / WAF）
└─→ API Gateway（REST API / HTTP API）
├─→ Lambda（ビジネスロジック）
│ └─→ DynamoDB（メインデータ）
│ └─→ Aurora Serverless v2（RDB が必要な場合）
│ └─→ Secrets Manager（DB パスワード取得）
└─→ Cognito User Pools（JWT 認証）
画像・ファイル：S3 に直接アップロード（Presigned URL）
非同期処理：Lambda → SQS → Lambda（Worker）
主なサービス： API Gateway / Lambda / DynamoDB / Cognito / S3 / Secrets Manager / SQS / CloudWatch
⚠️ サーバーレスの落とし穴
Lambda のコールドスタートはレイテンシーに影響します。SLA の厳しい API には Provisioned Concurrency を設定するか、ECS 構成との比較検討が必要です。また DynamoDB の設計はアクセスパターンを先に決めることが必須です。
パターン③：データ分析基盤
ログ・トランザクションデータを収集・変換・分析するデータレイク構成です。
📊 構成フロー
データソース（アプリ / IoT / DB）
└─→ Kinesis Data Streams / Kinesis Data Firehose
└─→ S3（データレイク：ロウデータ層）
└─→ Glue（ETL ジョブ / データカタログ）
└─→ S3（データレイク：加工済み層）
├─→ Athena（SQL クエリ / アドホック分析）
└─→ Redshift（DWH / BIツール接続）
└─→ QuickSight（可視化・ダッシュボード）
Lambda で S3 イベントトリガー → 変換処理
CloudWatch / EventBridge で Glue ジョブをスケジュール実行
主なサービス： Kinesis / S3 / Glue / Athena / Redshift / QuickSight / Lambda / EventBridge
パターン④：コンテナ本番基盤
マイクロサービス化・コンテナ化されたアプリケーションの本番運用構成です。
🐳 構成フロー
ユーザー
└─→ Route 53 → CloudFront → ALB
└─→ ECS（Fargate）/ EKS
├─→ サービスA（タスク）→ Aurora
├─→ サービスB（タスク）→ DynamoDB
└─→ サービスC（タスク）→ ElastiCache
ECR（コンテナイメージリポジトリ）
└─→ ECS / EKS（デプロイ時にプル）
RDS Proxy（Lambda / ECS からの接続プーリング）
Secrets Manager（DBパスワード / APIキー）
CloudWatch Container Insights（監視）
X-Ray（サービス間トレーシング）
主なサービス： ECS（Fargate）/ EKS / ECR / ALB / Aurora / ElastiCache / RDS Proxy / Secrets Manager / CloudWatch / X-Ray
パターン⑤：CI/CD パイプライン
コードプッシュからコンテナデプロイまでを自動化するパイプライン構成です。
🚀 構成フロー
開発者
└─→ git push（GitHub / CodeCommit）
└─→ CodePipeline（トリガー）
├─→ [Source ステージ] ソースコード取得
├─→ [Build ステージ] CodeBuild
│ ├─→ テスト実行（単体テスト）
│ ├─→ Docker ビルド
│ └─→ ECR にイメージプッシュ
└─→ [Deploy ステージ] CodeDeploy
└─→ ECS（Blue/Green デプロイ）
CloudFormation / CDK で インフラも Pipeline 経由で管理（GitOps）
SNS → Slack 通知（デプロイ成功 / 失敗）
主なサービス： CodePipeline / CodeBuild / CodeDeploy / ECR / ECS / CloudFormation / SNS / S3（アーティファクト保存）
パターン比較表
| パターン | 主な用途 | インフラ管理コスト | スケーラビリティ | コスト感 |
|---|---|---|---|---|
| ① Web アプリ | 一般的な業務・Webシステム | 中（ECS + Aurora） | 高（Auto Scaling） | 中 |
| ② サーバーレス API | 軽量API・スタートアップ | 低（Lambda + DynamoDB） | 自動・無限 | 低〜中（従量課金） |
| ③ データ分析 | BI・機械学習・ログ分析 | 低（Glue + Athena） | 高（S3 + Redshift） | 中〜高（DWH） |
| ④ コンテナ基盤 | マイクロサービス・SaaS | 中（ECS/EKS） | 高（Container Auto Scaling） | 中〜高 |
| ⑤ CI/CD | 自動デプロイ基盤 | 低（マネージドサービス） | —（基盤） | 低 |