全レイヤー 判断フロー早見表
各レイヤーの選択フローを1箇所にまとめた。移行設計の初期フェーズにそのまま使える。
【移行戦略】
廃止できる → Retire
今は動かせない → Retain
SaaS で代替 → Repurchase
変えたくない → Rehost（EC2ベース）
少し改修可 → Replatform（RDS・ECS等）
根本から変えられる → Refactor（コンテナ/サーバーレス）
【コンピュート】
OS依存・レガシー → EC2
イベント駆動・15分以内 → Lambda
コンテナ・常時起動・管理不要 → ECS on Fargate
コンテナ・GPU・細かい制御 → ECS on EC2 / EKS
【データベース】
リレーショナル・エンジン固定（Oracle等） → RDS
リレーショナル・MySQL/PG互換・高性能 → Aurora
キャッシュ・セッション → ElastiCache（Redis）
NoSQL・大規模KV・スキーマレス → DynamoDB
全文検索 → OpenSearch Service
【ストレージ】
EC2にアタッチするブロックストレージ → EBS（gp3）
複数サーバーから共有マウント（NAS相当） → EFS
ファイル置き場・バックアップ・静的コンテンツ → S3
【ネットワーク（LB）】
HTTP/HTTPS・パスルーティング → ALB
TCP/UDP・固定IP・超低レイテンシ → NLB
オンプレ接続：本番・専用線品質 → Direct Connect
オンプレ接続：開発・コスト重視 → Site-to-Site VPN
【非同期処理・ジョブ】
定期バッチ（Cron代替） → EventBridge Scheduler
キューイング（Producer-Consumer） → SQS
1対多配信（Pub/Sub） → SNS
複雑なジョブワークフロー → Step Functions
【監視・ログ】
メトリクス監視・アラート → CloudWatch Metrics + Alarm
ログ集約・検索 → CloudWatch Logs（+ Logs Insights）
分散トレーシング → X-Ray
大規模ログ全文検索 → OpenSearch Service
オンプレ → AWS サービス対応マップ
| レイヤー | オンプレ | AWS サービス |
|---|---|---|
| 計算リソース | 物理サーバー / VM | EC2 / ECS(Fargate) / Lambda |
| ネットワーク | VLAN / ルーター | VPC / Transit Gateway |
| ロードバランサー | F5 / HAProxy / Nginx LB | ALB / NLB |
| ストレージ（ブロック） | SAN / ローカルディスク | EBS |
| ストレージ（共有） | NAS / NFS | EFS / FSx |
| オブジェクトストレージ | MinIO / ファイルサーバー | S3 |
| DB（RDB） | Oracle / MySQL / PostgreSQL | RDS / Aurora |
| DB（NoSQL / KV） | MongoDB / Cassandra | DynamoDB |
| キャッシュ | Redis / Memcached | ElastiCache |
| メッセージキュー | ActiveMQ / RabbitMQ | SQS / Amazon MQ |
| Pub/Sub | Kafka / 独自ブローカー | SNS / MSK |
| ジョブスケジューラー | JP1 / Cron / A-AUTO | EventBridge Scheduler + Step Functions |
| 監視 | Zabbix / Nagios | CloudWatch Metrics + Alarm |
| ログ集約 | Fluentd + Elasticsearch | CloudWatch Logs / OpenSearch Service |
| 分散トレーシング | Jaeger / Zipkin | X-Ray |
| 認証・ID 管理 | LDAP / Active Directory | IAM Identity Center / Cognito |
| CI/CD | Jenkins / GitLab CI | CodePipeline / CodeBuild / CodeDeploy |
| DNS | BIND / 独自 DNS | Route 53 |
| CDN | Akamai / 独自 CDN | CloudFront |
よくある落とし穴まとめ
🔴 オンプレスペックの持ち込み
オンプレの「ピーク＋余裕」サイジングを EC2 にそのまま適用するとコストが膨らむ。Auto Scaling と Compute Optimizer で最適化を。
🔴 EC2 のメモリ監視漏れ
EC2 のメモリ使用率はデフォルトで CloudWatch に収集されない。CloudWatch Agent の設定を忘れずに。
🔴 Oracle ライセンス問題
RDS for Oracle の BYOL / License Included を移行前に確認しないと予期しないライセンス費用が発生する。
🔴 VPC CIDR の重複
オンプレと VPC の IP 範囲が重複すると Direct Connect / VPN 接続が機能しない。CIDR 設計は先に確定する。
🔴 SQS の DLQ 未設定
デッドレターキューがないと失敗したメッセージが無限リトライされ、コストと障害調査を難しくする。
🔴 ログ保持期間の未設定
CloudWatch Logs はデフォルトで永続保存。保持期間を設定しないとログコストが際限なく積み上がる。
🔴 RDS のコネクション数
Lambda や ECS からの大量コネクションで RDS の上限に達する。RDS Proxy でコネクションプーリングを。
🔴 NAT Gateway コスト
S3 / DynamoDB へのアクセスが NAT Gateway 経由になっているとデータ転送コストが膨らむ。VPC Endpoint を使う。
設計判断を記録する：ADR の活用
移行設計では「なぜそのサービスを選んだか」を記録しておくことが重要だ。 数ヶ月後に「なぜ EC2 にしたのか」「なぜ RDS で Aurora にしなかったのか」を説明できる状態にしておく。
ADR（Architecture Decision Record） は軽量な設計判断記録だ。 1決定 = 1ファイルで、以下の形式で記録する。
| 項目 | 内容 |
|---|---|
| タイトル | 例：DB を RDS（MySQL）ではなく Aurora を選択 |
| ステータス | 提案中 / 採用 / 廃止 |
| コンテキスト | なぜこの判断が必要になったか（背景） |
| 判断 | 何を選んだか |
| 理由 | なぜそれを選んだか（他の選択肢との比較） |
| 影響・トレードオフ | この選択によるコスト・リスク・制約 |
✅ シリーズを通じて伝えたかったこと
AWS 移行の本質は「サービスを知ること」ではなく、「なぜそのサービスを選ぶのか」を説明できることだ。判断フローは「迷いをなくす」ためのツールだが、最終的な判断はプロジェクトの制約・コスト・チームのスキルセットを加味して下す必要がある。このシリーズが移行設計の羅針盤として役立てば幸いだ。