プロジェクト概要
アパレル向けBtoB受発注SaaSを運営する企業様。AWS上にEC2インスタンス8台を常時稼働させてAPIサーバー・バッチ処理・管理画面を運用していましたが、月額クラウド費用が増加の一途をたどり「トラフィックは深夜ほぼゼロなのにずっと課金されている」という課題が浮上しました。
分析したところ、リクエスト数のピーク（平日昼間）と閑散時（深夜・休日）の差が約50倍あることが判明。常時稼働型のEC2は閑散時にリソースを無駄に消費していました。テクノスフィアはアーキテクチャを全面的にサーバーレス構成へ再設計し、トラフィックに完全連動する従量課金に切り替えることでコスト問題を根本解決しました。
移行前の問題：なぜコストが高いのか
- EC2（t3.large × 4台）でAPIサーバーを常時稼働
- EC2（t3.medium × 2台）でバッチ処理サーバーを常時稼働
- EC2（t3.small × 2台）で管理画面サーバーを常時稼働
- RDS MySQL（db.r5.large）を常時稼働
- 深夜・休日はトラフィックがほぼゼロだが課金は同額
- スパイク時はスケールアップが間に合わず503エラー発生
- 月額費用：約42万円（EC2+RDS+ALB等）
- APIサーバー → AWS Lambda + API Gateway
- バッチ処理 → AWS Lambda + EventBridge（スケジュール）
- 管理画面 → S3 + CloudFront（静的配信）
- DB → DynamoDB（オンデマンド）+ Aurora Serverless v2
- 非同期処理 → SQS + Lambda
- 使った分だけ課金・深夜はほぼ0円
- 月額費用：約12万円（72%削減）
サーバーレスアーキテクチャ構成図
▼ APIリクエストフロー
▼ 管理画面（静的配信）
▼ バッチ・非同期処理
Serverless v2
移行前後のコスト内訳比較
| コンポーネント | 移行前（EC2構成） | 移行後（サーバーレス） | 削減 |
|---|---|---|---|
| APIサーバー | EC2 t3.large × 4台 約158,000円/月 |
Lambda + API Gateway 約18,000円/月 |
▼ 89% |
| バッチ処理 | EC2 t3.medium × 2台 約36,000円/月 |
Lambda + EventBridge 約2,000円/月 |
▼ 94% |
| 管理画面 | EC2 t3.small × 2台 約16,000円/月 |
S3 + CloudFront 約1,500円/月 |
▼ 91% |
| データベース | RDS MySQL db.r5.large 約88,000円/月 |
DynamoDB + Aurora Serverless v2 約42,000円/月 |
▼ 52% |
| その他（ALB・NAT等） | 約22,000円/月 | 約6,000円/月 | ▼ 73% |
| 合計 | 約420,000円/月 | 約117,000円/月 | ▼ 72% 年間▼363万円 |
3ヶ月移行タイムライン
AWSコスト分析（Cost Explorer）でリソース別コスト内訳を可視化。トラフィックパターン分析（CloudWatch）でピーク・閑散の差を定量化。サーバーレス化可能箇所の特定と優先順位づけ。Lambda/DynamoのABC試算。新アーキテクチャ設計・APIインターフェース確定。
APIサーバーのNode.js Expressロジックを Lambda関数に分割移植（約40関数）。Serverless Framework でデプロイ自動化（IaC化）。DynamoDB テーブル設計・RDSからのデータ移行。管理画面をReactで再構築しS3静的配信へ切り替え。ステージング環境で全APIの動作検証・負荷テスト。
API GatewayのRoute weighting機能で10%→50%→100%と段階的にLambdaへトラフィック移行。CloudWatchアラームでエラー率を監視しながら進行。全切り替え完了後、EC2インスタンスを順次停止・削除。Aurora Serverless v2 への最終データ移行。コスト確認・チューニング。
移行の技術的ポイント
Lambdaコールドスタート対策
サーバーレスの課題として挙げられる「コールドスタート（初回起動遅延）」に対し、以下の対策を実施しました。
- Provisioned Concurrency：常に一定数のLambdaを暖機状態に保ち、ユーザーが体感する初回遅延を解消。コスト増は最小限に抑えつつ、ユーザー体験を維持。
- 関数の軽量化：不要な依存パッケージを削除し、Lambda Layerで共通ライブラリを分離。デプロイパッケージを最小化してコールドスタート時間を短縮。
- 接続プーリング：Aurora Serverless v2へのDB接続はRDS Proxyを経由し、Lambda の大量並列起動時のDB接続枯渇を防止。
RDS → DynamoDB データモデル変換
RDSの正規化されたリレーショナルスキーマをDynamoDBのシングルテーブル設計に変換しました。主要なアクセスパターンを洗い出し、Partition Key / Sort Key を最適設計。N+1問題を発生させないDynamoDBらしいデータ取得パターンに変更することで、RDS比でクエリレスポンスを平均60%高速化しました。
Serverless Framework による IaC 化
全インフラをServerless Frameworkのyamlで定義し、sls deploy一発で全環境（dev/stg/prod）に再現可能な状態にしました。Lambda関数・API Gateway設定・DynamoDBテーブル・IAMロール・CloudWatch設定がすべてコードで管理されているため、設定ミスによる障害リスクを大幅に低減しています。
サーバーレスが向いているケース・向いていないケース
- リクエスト数に波がある（深夜少・昼多など）
- バッチ処理が定時実行中心
- マイクロサービス構成にできるAPI
- 静的コンテンツ主体の管理画面・フロントエンド
- 非同期メッセージ処理・キュー処理
- イベント駆動（ファイルアップロード→処理など）
- スタートアップ・低コスト重視
- 常時高負荷・リクエストが均一に多い
- 処理時間が15分を超える（Lambda上限）
- メモリを大量に使う重いバッチ処理
- ステートフルな接続が必要（WebSocket 常時接続等）
- 既存コードが大規模モノリスで分割が困難
- 厳格な実行環境・OS設定が必要なシステム
※ テクノスフィアでは現状分析を行い、サーバーレスが最適かどうかを含めて中立的にご提案します。向いていないケースでは、コンテナ化（ECS Fargate）やスポットインスタンス活用など別のコスト最適化手法をご提案します。
移行結果・成果
（42万円→12万円）
（移行費用は約4ヶ月で回収）
（DynamoDB最適化）
（運用工数も大幅削減）