本稿の目的
要件を「機能」と「規模（DAU・同時接続）」に落とすだけで、どのAWSサービスを選ぶかを即決できるようにする。
要点（先に結論）
- 小〜中規模（同時接続〜5,000） はサーバレス中心（CloudFront/S3/API Gateway/Lambda/DynamoDB）で俊敏に開始し、負荷が安定・増加してきたら ECS Fargate に段階移行するのが定石。
- 中〜大規模（同時接続〜50,000） は ECS Fargate + RDS/Aurora + ElastiCache を基軸に、 SQS/SNS/Step Functions で“詰まりにくい”構造（疎結合）にする。
- 超大規模（>50,000） やKubernetes資産がある場合は EKS や Kinesis/MSK を検討する。
1. 規模（DAU/同時接続）から逆算する
用語の最小セット
- DAU：1日あたり実際に使ったユーザー数
- 同時接続（Concurrency）：同時に処理されているリクエスト数
- RPS（Requests per Second）：1秒あたりのリクエスト数
- p95応答時間：95%のリクエストがこの時間以内に終わる目安（遅いほうの外れ値を除いた指標）
簡易試算（初動の見積根拠）
-
ピークRPS ≒
DAU × ピーク時同時利用率 × 1人あたり毎分リクエスト数 ÷ 60 -
必要同時接続 ≒
ピークRPS × p95応答時間（秒）
例）DAU=10,000、ピーク同時利用率=5%、1人あたり毎分4リクエスト、p95=0.5秒
ピークRPS ≒ 10,000×0.05×4÷60 = 33RPS／必要同時接続 ≒ 33×0.5 = 約16
※実際の数値はアプリの処理内容やデータベース設計で上下する。上式は「初回アーキテクチャの当たりをつける」ための目安。
2. 要件 → AWSサービス 対応表
「最小セット」はPoC〜早期導入。「本番推奨」は監視・可用性・セキュリティを含めた現実解。
「備考」は非エンジニア向けの噛み砕き説明。
| 機能/要件 | 最小セット | 本番推奨 | スケール目安 | 備考 |
|---|---|---|---|---|
| 静的サイト/LP配信 | S3, CloudFront, ACM, Route53 | WAF, CloudFront Functions, アクセスログ | 〜極大 | 画像やHTMLをCDNで高速配信（CDN=世界にキャッシュ置き場がある配信網） |
| SPA+API（認証あり） | S3+CloudFront, API Gateway, Lambda | Cognito, WAF, CloudWatch/X-Ray, IaC | 〜中 | まずは“サーバ不要”構成で俊敏に開始、負荷が増えたらECSへ移行 |
| .NET Web/API（コンテナ） | ECR, ECS Fargate, ALB | AutoScaling, Logs/Metrics, Secrets/Param, IaC | 中〜大 | Windows/IISからの脱出や常時負荷に強い（サーバ管理なしのコンテナ実行） |
| 既存IISの暫定移行 | EC2(Windows), ALB | ASG, SSM, CloudWatch Agent | 小〜中 | まず“動かす”優先→並行でコンテナ化へ |
| RDB（トランザクション） | RDS/Aurora | Multi-AZ, バックアップ, Proxy, Perf Insights | 小〜超 | いわゆる普通のDB。金融や在庫のように整合性重視向き |
| NoSQL/高スループット | DynamoDB | On-demand, DAX, PITR | 中〜超 | キーで高速読む/書く。大きなスパイクや巨大スケールに強い |
| キャッシュ/セッション共有 | ElastiCache for Redis | Multi-AZ, フェイルオーバー, TLS | 中〜超 | 一時的な“置き場”。読取りを速くしてDBの負荷を下げる |
| 全文検索 | OpenSearch Service | Multi-AZ, UltraWarm, ISM | 中〜大 | “検索専用DB”。ログ分析やサイト内検索で活躍 |
| メール送信 | Amazon SES | 専用IP/DMARC/DKIM, 配信統計 | 小〜大 | ドメイン認証や迷惑メール対策までセットで設計 |
| 認証/SSO | Cognito（B2C） | Identity Center（社内SSO）, IdP連携 | 小〜大 | 会員ログインと社内シングルサインオンを役割分担 |
| 秘匿情報の管理 | Secrets Manager / Parameter Store | ローテーション, KMS（鍵） | 小〜大 | パスワードやAPIキーを安全に保管・自動更新 |
| 監視/ログ/追跡 | CloudWatch, CloudTrail | アラーム, ダッシュボード, X-Ray, Log分析 | 小〜超 | いつ・どこで・何が起きたかを“見える化” |
| セキュリティ基盤 | GuardDuty, Security Hub, Config | Organizations, SCP, Access Analyzer | 小〜超 | 危険設定の検出と是正の“土台” |
| CDN/大容量配信 | CloudFront | WAF, Origin Shield, 署名URL/Cookie | 大〜超 | 動画や大ファイルを安定配信（著作権対策も可） |
| ファイルアップロード | S3（プリサインドURL） | Lifecycle, Object Lambda, Macie | 小〜大 | ブラウザ→S3に直接アップでサーバ負荷を減らす |
| VOD（動画変換） | S3, MediaConvert, CloudFront | Step Functions, SQS, DRM | 中〜超 | 自動で解像度/ビットレートを作り分けて配信 |
| ライブ配信 | IVS | CloudFront(録画), モデレーション(Lambda), チャット(DynamoDB) | 中〜超 | 低遅延のインタラクティブ配信 |
| バッチ/定期処理 | EventBridge, Lambda/Batch | Step Functions, SQS, DLQ/リトライ | 小〜大 | “夜間まとめ処理”や“毎時の集計”の枠組み |
| 非同期処理/疎結合 | SQS | SNS, FIFO/遅延, EventBridge | 中〜超 | 混雑時も行列で順番に処理して落ちにくくする |
| データレイク/ETL | S3, Glue Data Catalog, Athena | Glue ETL/Workflow, Lake Formation | 中〜超 | “ためる場所（S3）”と“都度クエリ（Athena）”で低コスト分析 |
| DWH/ダッシュボード | Redshift（Serverless可） | QuickSight, Spectrum | 中〜超 | 大量データを多人数で分析・可視化 |
| 機械学習（推論API） | SageMaker Endpoint / Lambda(ECR) | AutoScaling, Model Monitor | 小〜大 | 予測モデルを“呼べるAPI”として提供 |
| 既成AI（OCR/翻訳等） | Textract/Translate/Rekognition など | Step Functions, S3 Events | 小〜大 | 作り込みなしでAI機能を部品として利用 |
| リアルタイム双方向 | API GW(WebSocket) / AppSync | DynamoDB, Cognito, CloudWatch | 中〜大 | チャットや通知など“押し込み”更新 |
| 位置情報 | Amazon Location | トラッキング/ジオフェンス | 小〜中 | 地図表示・到達検知などを手早く実装 |
| ドメイン/証明書 | Route53, ACM | フェイルオーバー, ヘルスチェック | 小〜超 | 独自ドメインとSSL証明書（自動更新） |
| WAF/DDoS | AWS WAF, Shield(Standard) | Bot Control, Shield Advanced | 中〜超 | 不正アクセスや攻撃を入り口でブロック |
| CI/CD | GitHub Actions / CodePipeline | OIDC, 承認ゲート, Blue/Green | 小〜超 | 自動テストと自動デプロイの仕組み |
| IaC（構成のコード化） | Terraform（S3+DynamoDB Lock） | モジュール分割, CI連携 | 小〜超 | “環境をコードで再現”できるようにする |
| ネットワーク/VPN | VPC, NAT/IGW, Site-to-Site VPN | Direct Connect, Transit Gateway | 小〜超 | 社内とクラウドを安全に専用線/暗号化でつなぐ |
| マルチアカウント | AWS Organizations | Control Tower, SCP | 中〜超 | 本番・検証・運用チームでアカウントを分離し統制 |
| コスト管理 | Budgets, Cost Explorer | Anomaly Detection, タグ配賦 | 小〜超 | 使い過ぎ通知・部門別の費用見える化 |
3. スケール別リファレンス（Web+API／動画）
Web+API（B2C想定）
-
小規模（〜500並列）：CloudFront+S3（フロント）、API Gateway+Lambda（API）、DynamoDBまたはRDS
→ サーバ運用なし、スパイク（急増）に強い。まずはこれで素早く。 -
中規模（〜5,000並列）：CloudFront、ECS Fargate+ALB（API）、RDS/Aurora、ElastiCache、SQS
→ 常時負荷や長時間接続があるならコンテナ有利。キューとキャッシュで“平準化”。 -
大規模（〜50,000並列）：CloudFront、Fargate/EKS、Aurora（リードレプリカ）、Redis、Kinesis/MSK
→ 読み分散・非同期・観測（メトリクス/トレース）を固める。 -
超大規模（50,000+）：EKS、Global Accelerator、マルチリージョン、Shield Advanced
→ SRE体制とガバナンス（権限/監査）を前提に。
動画配信
-
VOD：S3 → MediaConvert（自動で複数ビットレート生成）→ CloudFront
→ 署名URL/署名Cookieでアクセス制御、DRMが必要なら追加。 -
ライブ：IVS + CloudFront（録画配信） + DynamoDB（チャット）
→ 低遅延の配信に強い。放送品質なら MediaLive/MediaPackage も選択肢。
4. Lambda / ECS Fargate / EKS の選び分け
-
Lambda：短時間の処理・イベント駆動・アイドル時間が多い・コネクション保持が不要
→ “使った分だけ”課金で初期コストを抑えやすい。 -
ECS Fargate：常時負荷・接続維持・コンテナ単位のチューニングが必要
→ “サーバ管理なしのコンテナ”。Windows/IIS脱却にも相性良。 -
EKS：既にKubernetesの資産や運用知見がある・サイドカーや高機能メッシュが必要
→ 大規模組織の標準基盤として有力。
5. RDB と NoSQL の使い分け
- RDS/Aurora：整合性重視（ACID）、複雑なJOIN、既存SQL資産の活用。レポート/BIとも親和性が高い。
- DynamoDB：巨大スケールやスパイク、スキーマ進化に強い。アクセスパターン設計（どのキーで読むか）を先に決める。
- 折衷案：書き込みはDynamoDB、集計/可視化はAurora/Redshift（Kinesis/Glueで橋渡し）。
6. 最初に入れておく安全装置
- セキュリティ：GuardDuty / Security Hub / Config、WAF、Secrets Manager、KMS
- 監視と記録：CloudTrail（全リージョン）、CloudWatch（ダッシュボード/アラーム）、X-Ray（遅い箇所の特定）
- ガバナンス：Organizations + SCP、IAM Identity Center（人の権限を集約）
- コストの見張り：Budgets（使いすぎ通知）、Cost Explorer（部門/システム別の配賦タグ）
7. 仕様詰めのためのヒアリング項目
- 負荷：DAU/MAU、ピーク時間、同時接続、1人あたり操作頻度、最大ファイルサイズ
- 機能：ログインの有無、決済/外部SaaS連携、アップロード/配信の有無
- 非機能：SLA、RTO/RPO（どれだけ止められないか/復旧に何分まで許容か）、監査・個人情報の扱い
- 運用：誰が日々の運用・一次対応を行うか、アプリ更新頻度、監視画面/アラートの受け口
- 費用：月額の上限、変動許容、タグ運用（部門別配賦）
- 期限：PoCと本番の予定、移行で止められない期間
8. この表の使い方
- まず DAU・同時接続・p95 の仮置きを出す（計算式でサッと当たりをつける）。
- 対応表で「最小セット」を叩き台に、「本番推奨」を“外せない項目”として上乗せする。
- PoCで実測（RPS/同時接続/コスト）を取り、Lambda→ECS など段階移行の是非を決める。
免責
本稿のスケール目安は一般的なWeb/モバイル向けアプリケーションを想定したものであり、実際の必要リソースはアプリの処理内容やデータ設計、外部連携の有無によって大きく変動する。最終判断はPoCでの実測値を用いて行うことを推奨する。