サービス選定
CRM・SFAをEC2、ECS、EKS、Lambdaのどれで動かすか
Level 1：AWSへの初期移行では、Nortia CRMのCRM・SFAをEC2上で動かす判断をしました。この記事では、なぜその時点でEC2を選び、なぜ将来のLevelでは結論が変わるのかを、EC2・ECS・EKS・Lambdaの4択で整理します。
サービスの機能一覧を比較しても、答えは出ません。 判断を決めるのは、アプリケーションの実装言語・チーム体制・運用負荷・移行フェーズという「今回の企業・業務状況」側の条件です。
今回の企業・業務状況（比較の前提）
- 開発・運用担当：3〜5人（Kubernetes運用経験なし）
- アプリケーション：.NET Framework 4.5（ASP.NET）、Windows Server上でIISにより稼働
- 現在のフェーズ：Level 1（自社利用、単一構成からの移行直後）
- 将来のフェーズ：Level 3（複数企業向けSaaS化、Coming Soon）でデプロイ頻度・スケーリング要件が変化する見込み
比較対象と評価軸
| 評価軸 | 見るポイント |
|---|---|
| アプリケーション特性 | 実装言語・ランタイムが各サービスで実行可能か |
| 開発チーム体制 | 運用に必要な知識を、今のチームが持っているか |
| 運用負荷 | パッチ適用・スケーリング・デプロイに人手がどれだけ要るか |
| コンテナ化の要否 | コンテナ化にどれだけの改修コストがかかるか |
| スケーリング | 負荷変動への対応のしやすさ |
| コスト | 最小構成での月額と、規模拡大時の増え方 |
決定表
| サービス | アプリケーション特性 | 開発チーム体制 | 運用負荷 | コンテナ化の要否 | スケーリング | コスト（小規模時） |
|---|---|---|---|---|---|---|
| EC2 | ◎ .NET Framework をそのまま実行可能 | ◎ 既存のWindows運用知識で対応可 | △ OSパッチ・ミドルウェア管理が必要 | 不要 | △ Auto Scalingは可能だが起動が遅い | ◎ 最小構成では最安 |
| ECS（Windows／Fargate） | ○ Windowsコンテナ化すれば実行可能 | △ コンテナの知識が新たに必要 | ○ OSパッチの一部をAWS側に委譲 | 要（Windowsコンテナ化） | ○ EC2よりは速いが、Linuxコンテナより起動が遅い | △ Windowsコンテナは追加コストあり |
| ECS（Linux／Fargate） | × .NET Frameworkは非対応（.NET Core/.NET 5+への移植が必須） | △ コンテナの知識が新たに必要 | ◎ サーバー管理が実質不要 | 要（かつフレームワーク移植） | ◎ 秒単位でスケール | ○ 稼働時間分のみ課金 |
| EKS | ×〜○（Linux移植前提） | × Kubernetesの学習コストが高い | × クラスタ自体の運用が発生 | 要（かつフレームワーク移植） | ◎ 高度な制御が可能 | × 小規模には過剰 |
| Lambda | × .NET Frameworkは非対応。実行時間・ステート保持の制約もある | △ サーバーレス特有の設計知識が必要 | ◎ サーバー管理が不要 | 要（フレームワーク移植＋ステートレス化） | ◎ 自動 | ◎ 低頻度アクセスなら最安 |
◎○△×は、あくまで今回の企業・業務状況における評価です。別の前提（例えば最初からLinux/.NET Coreで新規開発する場合）では結論が変わります。
初期移行ではなぜEC2を選ぶのか
理由は機能比較ではなく、ほぼ1点に集約されます。アプリケーションが.NET Framework 4.5で書かれており、Linuxコンテナ環境（ECS Fargate for Linux、EKS、Lambda）では動作しないためです。
- .NET Frameworkは Windows専用のランタイムであり、.NET Core／.NET 5以降のようなクロスプラットフォーム対応がありません
- Linux上でコンテナ化するには、アプリケーションを.NET Core／.NET 8等へ移植する必要があり、これは「移行」ではなく「作り直し」の規模になります
- Windowsコンテナ化（ECS on Windows Fargate）という選択肢はありますが、コンテナの知識習得というコストが新たに発生し、3〜5人という体制ではEC2運用の知識をそのまま活かせるEC2に劣ります
さらに、Level 1の非機能要件（移行時のダウンタイム週末8時間以内、アプリ改修は接続文字列・ファイル参照のみ）を踏まえると、移行とフレームワーク移植を同時に行うリスクを取らないという判断にも合致します。「今すぐコンテナ化しない」ことは、技術的に劣った選択ではなく、リスクを分離した結果です。
後にECSへ移行する理由
Level 3：複数企業向けSaaS化（Coming Soon）に進むと、前提そのものが変わります。
| 変化 | EC2運用への影響 |
|---|---|
| デプロイ頻度の増加 | テナントごとの機能差分が増え、リリースサイクルが速くなる |
| テナント単位のスケーリング | 特定企業の負荷が他社へ影響しないよう、分離したスケールが必要 |
| 環境の増加 | 検証・ステージング・本番に加え、テナント種別ごとの環境も検討対象になる |
EC2でこれらに対応しようとすると、AMI管理・Auto Scaling設定・デプロイスクリプトが複雑化し、3〜5人の運用負荷が急増します。この時点で、アプリケーションを.NET（Core系）へ段階的に移植し、ECS Fargateへ移行する判断が現実的になります。
ここで重要なのは、「ECSの方が高機能だから」ではなく「デプロイ頻度とテナント分離という新しい要件に対して、EC2運用の複雑化コストがコンテナ化の移植コストを上回るタイミングが来た」という判断だという点です。同じ結論（コンテナ化）でも、Level 1の時点で下すのと、Level 3の時点で下すのとでは、根拠が異なります。
EKSを見送る理由
ECSではなくEKSを選ぶ理由は、複数クラスタの一元管理、既存のKubernetesエコシステム資産の活用、マルチクラウド前提の設計など、限られた状況で生まれます。Nortia CRMの場合、
- 単一チーム・単一クラウド（AWS）が前提
- 3〜5人にKubernetesの運用経験者がいない
- コントロールプレーンの学習・運用コストに見合うだけの複雑さがまだ組織にない
という状況のため、Level 3以降でコンテナ化する場合も、まずは学習コストの低いECS（Fargate）を優先します。EKSは「将来的に複数チーム・複数クラスタを本格運用する規模になった場合」の選択肢として保留します。
Lambdaを見送る理由
Lambdaは低頻度アクセスや非同期処理には強力ですが、CRM・SFAの中核機能（商談情報のCRUD、検索、添付ファイル操作）とは相性がよくありません。
- .NET Frameworkは非対応（.NET Core/.NET 8ランタイムへの移植が必須）
- 既存アプリケーションはセッションやキャッシュを前提にした作りで、Lambdaのステートレス性・実行時間制限（最大15分）に合わせた再設計が必要
- 営業担当が業務時間中に常時アクセスする用途では、コールドスタートの影響を無視できない
Lambdaは、Architecture Journeyの後続Level（例えばCSV取込・通知処理などの非同期バッチ）で部分的に採用する余地はありますが、CRM本体のコンピューティング基盤としては選択肢に入りません。
意思決定のまとめ
- アプリケーションのランタイムが動く場所を先に絞り込む（.NET Frameworkの場合、Linuxコンテナ・Lambdaは移植なしでは選択肢から外れる）
- 残った選択肢の中で、チームが運用できる複雑さかどうかを見る
- デプロイ頻度・スケーリング要件が変わるタイミングで、コンテナ化の移植コストと運用コストを比較し直す
「今のフェーズで最適な選択」と「将来のフェーズで最適な選択」は一致しません。Architecture Journeyでは、この結論の変化そのものを追っていきます。