AWS サーバーレスは、インフラ運用を減らしながら小さく始められる選択肢です。しかし「サーバー管理がないから、どのシステムにも向く」と考えると、実行時間や起動遅延、データ設計の制約が後から効いてきます。情シスやスタートアップ CTO に必要なのは、サービス一覧ではなく適用範囲を切る物差しです。
本記事では AWS Lambda、Amazon API Gateway、Amazon DynamoDB を軸に、向く用途と向かない用途を分けます。常時稼働するコンテナを検討している場合は、姉妹記事の AWS ECS 入門 が構築と運用を詳しく扱っています。本記事は、イベント駆動で処理を起動する側に焦点を絞ります。
AWS サーバーレスとは ─ 主要サービスと役割
サーバーレスとは、アプリケーションの利用者がサーバー OS の調達、更新、台数管理を直接行わず、処理やデータの設計へ集中する運用モデルです。物理的なサーバーが消えるわけではなく、基盤の管理責任をクラウド事業者へ寄せます。
AWS サーバーレス アーキテクチャでは、単一製品ですべてを賄いません。入口、処理、データ、連携、監視をマネージドサービスで組み合わせます。
| 役割 | 主なサービス | 設計時に決めること |
|---|---|---|
| HTTP の入口 | Amazon API Gateway | 認証、ルート、流量制御、エラー応答 |
| コードの実行 | AWS Lambda | 起動イベント、割り当て資源、失敗時の扱い |
| データ保存 | Amazon DynamoDB | アクセスパターン、キー、整合性、保持期間 |
| 非同期連携 | Amazon SQS / Amazon EventBridge | 順序、再試行、重複、滞留の許容範囲 |
| ファイル起点 | Amazon S3 | オブジェクトの命名、再処理、保存方針 |
| 観測 | Amazon CloudWatch / AWS X-Ray | ログ、メトリクス、追跡、通知 |
Lambda はイベントを受けて実行環境を用意し、設定したコードを動かします。実行環境は永続的なサーバーとして扱えないため、処理に必要な状態は外部へ置きます。同じ環境が再利用される場合はありますが、再利用を前提に正しさを組み立ててはいけません。
API Gateway は公開 API の前段でリクエストを受け、認証やルーティングを行い、Lambda などの統合先へ渡します。DynamoDB は分散型のキー・バリュー / ドキュメントデータベースです。RDB のテーブル設計をそのまま移すのではなく、必要な読み書きからキーを逆算します。
要点
「サーバーを管理しない」と「運用しない」は別です。OS 管理は減りますが、サービス間の権限、失敗時の再試行、ログ、費用の監視は残ります。
向く用途・向かない用途を先に分ける
判断の核は、処理を独立したイベントへ分けられるかです。リクエスト、メッセージ、ファイル作成、時刻などを起点に処理が始まり、外部へ結果を保存して終わるならサーバーレスと噛み合います。
| 用途 | 適性 | 理由と確認事項 |
|---|---|---|
| 低トラフィックまたは波の大きい Web API | 向く | 待機中の計算資源を抱えにくい。起動遅延の許容範囲は測る |
| ファイル投入後の変換・検査 | 向く | オブジェクト作成を起点に分割しやすい。重複実行へ備える |
| キューを使う非同期ジョブ | 向く | 負荷を平準化し、失敗したメッセージを隔離しやすい |
| 定時の集計・通知バッチ | 条件付きで向く | 小さく分割できるか、時間内に完了できるかを確認する |
| 常時高負荷の Web API | 比較が必要 | 実行量が積み上がるため Fargate の常時稼働と総額を比べる |
| 長く接続を保つ処理 | 向かない場合が多い | 接続状態と実行環境の寿命が結び付く。別方式を検討する |
| 長時間の単一ジョブ | 向かない場合が多い | 分割、途中保存、再開が難しければコンテナが扱いやすい |
| 特殊な OS 設定や常駐プロセス | 向かない | 実行環境を細かく制御する要件と衝突する |
製品名から決めるのは危険です。同じバッチでも、独立して処理できる画像変換と、巨大なデータを単一プロセスへ載せる集計では適性が違います。
FIXITサーバー管理が減るなら、まず Lambda で作ればいいの？
Dodaiまず壊れ方から考えます。途中で再実行されても正しい処理だけを載せます。
FIXITじゃあ、長い処理やずっと動く API は？
DodaiECS / Fargate も並べます。実行モデルに逆らう設計は運用で事故ります。
判断に迷う場合は、候補処理を「起点」「終了条件」「保存先」「再実行時の結果」で書き出します。ローカル状態が必要、再実行すると二重請求になる、といった処理は別の実行基盤も比較します。
Lambda + API Gateway + DynamoDB の最小構成パターン
典型的な最小構成は、利用者からの HTTP リクエストを API Gateway が受け、Lambda が業務処理を行い、DynamoDB へ状態を保存する流れです。認証が必要なら認証基盤を入口へ組み込みます。処理を後回しにできる場合は、同期応答の途中で重い処理をせず、キューへ渡します。
flowchart LR
U[利用者] --> A[API Gateway]
A --> L[Lambda]
L --> D[(DynamoDB)]
L --> Q[Queue]
Q --> W[Lambda worker]
W --> D設計では正常系より失敗経路が重要です。Lambda の失敗時に何を返すか、保存後の再送をどう扱うか、繰り返し失敗する処理をどこへ隔離するかを決めます。
静的アセットは Amazon S3 と Amazon CloudFront から配信し、API の実行経路と分けられます。AWS CDK でコード化し、API、関数、権限、データストアを同じ変更としてレビューします。
同期 API の境界
同期 API では、利用者が待つ処理だけを Lambda 内で完了させます。メール送信やファイル変換はキューへ渡し、受付結果を先に返せるか検討します。
入力値の検証と認可も入口で行います。API Gateway の認証と Lambda 内の業務認可を混同しないでください。
DynamoDB はアクセスパターンから設計する
DynamoDB の設計は問い合わせ一覧から始めます。「利用者 ID で最新のジョブを取得する」のように読み書きを列挙し、キーと必要なインデックスを決めます。
全件走査や複雑な結合が必要なら、Amazon RDS や Amazon Aurora を選ぶ分岐も残します。サーバーレス構成でも、データ要件に合うデータベースを選べます。
注意
イベントは複数回届く可能性を前提にします。注文確定や外部 API 呼び出しでは、同じイベントを再処理しても結果が重複しない冪等性の設計が必要です。
費用試算 ─ Lambda と Fargate を同じ条件で比べる
具体的な料金単価はリージョンや契約、AWS の改定によって変わります。ここでは単価を固定せず、試算の考え方を整理します。実額は AWS Lambda の公式料金ページ や AWS Fargate の公式料金ページ と料金計算ツールで確認してください。
Lambda の主な課金軸はリクエストと処理に使う計算資源です。試算では、1 日のリクエスト数だけでなく、平均と上位の実行時間、割り当てメモリ、繁忙時間の集中度を使います。API Gateway、DynamoDB、キュー、ログ、データ転送、外部接続に必要なネットワーク構成も別に積み上げます。
Fargate は、タスクへ割り当てる CPU とメモリ、および稼働時間が比較の中心です。最低タスク数を維持する場合は、アクセスがなくても費用が発生します。一方で常時高負荷なら、同じコンテナが連続して処理する構成のほうが費用を読みやすくなる場合があります。
| 判断軸 | Lambda 中心 | ECS / Fargate 中心 |
|---|---|---|
| 待機時間 | 実行しなければ計算費用を抑えやすい | 常駐タスク分が継続する |
| 負荷の波 | 急な増減へ合わせやすい | タスク増減と起動時間を設計する |
| 常時高負荷 | 実行量の積み上がりを確認する | 安定負荷では比較しやすい |
| 周辺費用 | API、キュー、DB、ログを足す | ロードバランサー、ログ、ネットワークを足す |
| 運用工数 | OS 管理は少ないが分散した設定が増える | コンテナとサービス運用が必要 |
| 実行環境 | 制約の範囲で設計する | コンテナ内を制御しやすい |
試算は次の順で行うと比較条件が揃います。
- 平日、休日、繁忙日のリクエスト分布を分けます。
- 処理ごとに平均実行時間と重いケースを実測します。
- Lambda 側の入口、実行、データ、ログ、転送を積み上げます。
- Fargate 側のタスク数、割り当て資源、稼働時間、周辺費用を積み上げます。
- 障害対応、パッチ、デプロイ、監視にかかる社内工数を加えます。
- 通常月だけでなく、繁忙月と事業成長後の条件でも比較します。
逆転点は一律のリクエスト数では示せません。処理時間、必要メモリ、負荷の集中、常駐タスク数、割引制度、周辺構成で変わるためです。
SaaS MVP 開発 では、初期の小さな利用量だけでなく、検証後に利用者が増えた場合の構成変更も見据えて設計します。最初の月額だけを最小化するより、観測結果を基に ECS へ移す、または一部だけ常駐化できる境界を残すことが重要です。
実装の落とし穴 ─ cold start・可観測性・DynamoDB 設計
サーバーレスの問題はコード単体のテストだけでは見えません。初期化、外部依存、再試行、分散したログを本番に近い経路で確認します。システム導入が失敗する兆候 で扱う、目的や運用責任が曖昧な状態も構成選定の前に解消します。
コールドスタートは実測で扱う
Lambda は再利用できる実行環境がないときに新しい環境を初期化します。最初の処理では、環境を再利用するときより遅延が増えることがあります。影響はランタイム、パッケージ、初期化処理、ネットワーク接続で変わります。
対策は「常に温める」から始めません。同期経路か非同期経路かを分け、依存関係と初期化処理を見直し、自社コードで応答時間を測ります。要件を満たさなければ常時稼働方式を比較します。バージョン依存の一般値を設計値にしないことが大切です。
可観測性は業務イベントを軸にする
関数ごとのログだけでは、「申請を受け付けたが通知されていない」といった業務上の未完了を追えません。入口で相関 ID を付け、キューや後続処理へ引き継ぎます。構造化ログには処理種別、結果、相関 ID を含め、機密情報は残しません。
監視は Lambda のエラーだけでなく、キューの滞留、隔離されたメッセージ、DynamoDB の失敗、外部 API の応答、処理完了までの時間を含めます。分散トレーシングは調査を助けますが、計測の追加だけで業務完了を保証できるわけではありません。
権限とデプロイ単位を小さく保つ
すべての関数へ広い IAM 権限を与えると、脆弱性の影響範囲が広がります。責務ごとに操作を絞り、開発・検証・本番を分けます。CDK で権限やアラームを含む差分をレビューします。
関数を細かく分けすぎると、認知負荷と障害調査の時間が増えます。独立した再試行やスケールが必要な境界で分けます。
Amazon Bedrock と組み合わせるサーバーレス構成
生成 AI を使う機能では、API Gateway と Lambda でリクエストを受け、Amazon Bedrock のモデル呼び出しやエージェント処理へつなぐ構成が候補です。非同期化できる文書分類、要約、埋め込み生成、ナレッジ更新は、キューやオブジェクト作成イベントと組み合わせやすい領域です。
ただし、AI エージェントの処理は外部ツールの呼び出しや複数段階の推論を含み、完了までの時間が読みづらくなります。1 回の Lambda 呼び出しに全工程を閉じ込めず、処理状態を外部へ保存し、ステップを分け、再開できる構成を検討します。利用者へ逐次応答を返す要件では、接続方式も含めて別の実行基盤と比較します。
| AI 機能 | サーバーレスとの相性 | 設計上の注意 |
|---|---|---|
| 文書到着後の分類・要約 | 良い | 再試行、重複保存、入力サイズを管理する |
| 埋め込み生成と検索索引更新 | 良い | 差分更新、失敗した文書の隔離を設計する |
| 短い同期応答 | 条件付き | モデル応答時間、タイムアウト、流量を測る |
| 複数ツールを回る AI エージェント | 条件付き | 状態保存、再開、外部操作の冪等性が必要 |
| 長時間の学習・重い推論 | 別基盤を比較 | コンテナや専用サービスの適性を検討する |
プロンプトやモデルの結果は非決定的です。コードの成功と業務品質を分け、応答の評価、監査、利用量の上限を設計します。費用の監視方法は LLM のコスト最適化 でも整理しています。モデル名や機能は更新されるため、利用時点の Amazon Bedrock 公式ドキュメント を確認してください。
AI エージェント開発 でも、失敗時に人へ渡す経路と評価を含めて扱います。外部ツール連携の境界は MCP サーバー構築ガイド も参考になります。サーバーレスは処理の部品であり、AI の品質保証そのものではありません。
FIXITAI エージェントも Lambda ひとつで動かせる？
Dodaiひとつに閉じ込めません。外部操作の途中で失敗しても再開できる形に分けます。
FIXIT分ければ安心ってこと？
Dodai境界ごとの状態と監視が必要です。分けすぎも障害調査を難しくします。
サーバーレス構築を任せる判断軸
サーバーレス構築を外部へ委託・外注する基準は、Lambda のコードを書けるかではありません。失敗経路を設計し、社内へ引き継げるかです。
候補先には次の成果物と説明を求めます。
- AWS サーバーレスを選ぶ根拠と、ECS / Fargate / EKS を選ばなかった理由
- 正常系と失敗系を含む構成図、データフロー、権限の境界
- 再試行、重複実行、タイムアウト、隔離、手動再開の方針
- 通常時と繁忙時を分けた費用試算と公式単価の確認日
- 負荷試験、障害試験、セキュリティテスト、デプロイの方法
- ログ、アラーム、運用手順、Infrastructure as Code の引き継ぎ物
「マネージドサービスだから保守不要」という説明だけでは不十分です。障害の伝わり方、自動復旧の範囲、手動対応の担当を確認します。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、Lambda と ECS / Fargate の境界、データ設計、監視、引き継ぎまでを 1 つの設計として扱います。コンテナ側の判断材料は AWS ECS 入門 も参照してください。
まとめ ─ 実行モデルに合う処理だけを載せる
AWS サーバーレスが向くのは、イベントごとに始まり、外部へ状態を保存して終わり、重複して実行されても正しさを保てる処理です。低トラフィック API、イベント駆動処理、分割できるバッチでは、待機資源と基盤管理を減らせます。
反対に、長時間処理、常時高負荷、接続状態を長く保つ処理、実行環境を細かく制御する処理は、ECS / Fargate などと比較します。費用は変動する単価を断定せず、実行量と周辺サービス、運用工数を同じ条件で積み上げてください。
最初に候補処理を「起点・終了条件・状態・再実行・負荷の波」で棚卸しします。載せる範囲が切れれば、Lambda、API Gateway、DynamoDB の設計は具体化できます。