サーバレス & エッジ関数 2026 完全ガイド - AWS Lambda・Cloud Run・Cloudflare Workers・Deno Deploy・Vercel・Fastly・Fermyon Spin・Fly.io 徹底解説

はじめに — 2026年5月、サーバレスは「ただのインフラ」になった

2020年のサーバレスは「機能検証用 PoC ツール」、2023年は「MAU100万くらいまでなら無難」だった。2026年5月現在、サーバレスとエッジランタイムはもはや傍流の選択肢ではない。Coupang のスパイク吸収、Toss の決済後処理、LY(LINE Yahoo)の通知ファンアウト、Mercari の検索バックエンドの一部、Sansan の名刺 OCR 後処理 — 日韓を代表するサービスが Lambda、Cloud Run、Workers を本番トラフィックの一部として運用している。

この記事はマーケティング比較表ではない。2026年5月時点で 各プラットフォームが本当に向いているワークロードは何か、コールドスタートはどこまで解決したか、WebSocket とストリーミングはどこまで動くか、価格は何で決まるか、を実コードと合わせて並べる。

サーバレス vs エッジ — 2026年の二軸を整理し直す

まず用語を分離する。2026年時点の「サーバレス」は実質3つのレーンに分かれる。

1. リージョン・サーバレス:AWS Lambda、Google Cloud Functions / Cloud Run、Azure Functions / Container Apps。単一リージョンでコンテナか microVM を借りるモデル。
2. エッジランタイム:Cloudflare Workers、Vercel Edge、Netlify Edge、Deno Deploy、Fastly Compute@Edge、Akamai EdgeWorkers。PoP 単位で分散される V8 isolate または Wasm ランタイム。
3. コンテナ PaaS(サーバレスコンテナ):AWS App Runner、Google Cloud Run、Fly.io、Railway、Render、Koyeb、Northflank。「Dockerfile を投げれば動かす」に近いモデル。

3つのレーンはそれぞれ違う限界を持つ。Lambda は15分タイムアウト、Workers は CPU 時間30秒(有料プランで最大5分)、Cloud Run は最大60分リクエスト、Fly.io は実質フル VM。だから「サーバレス1つで全部やる」は嘘だ。2026年の正解は、それぞれのワークロードに合う場所に合う道具を置くことである。

コールドスタートはほぼ解決した — 2026年の実測値

コールドスタートは2019年からサーバレス最大の弱点とされてきた。2026年5月現在、この弱点はほぼ消えている。

• AWS Lambda SnapStart:Java/.NET/Python 3.12 以降で GA。Firecracker スナップショットを事前に作っておき復元するため、Java 関数のコールドが1〜2秒から100〜300ms に落ちる。
• Cloudflare Workers:V8 isolate モデルでコールドスタートは事実上ゼロ(通常5ms 未満)。
• Cloud Run:min-instances 設定が標準化。0 インスタンスからは1〜3秒、min-instances=1 なら実質ウォーム。
• Vercel Fluid Compute:同じインスタンスで複数リクエストを同時処理し、コールドの頻度自体を減らした。
• Fermyon Spin:Wasm モジュールのインスタンス化が約1ms。「コールド」という概念がほぼ意味を持たない。

プラットフォーム別の P50 コールドスタート(2026年5月実測):

「コールドスタートのせいでサーバレスは使えない」という2019年の主張は、2026年にはほぼ嘘である。

AWS Lambda — 依然デフォルト、そして2026年の新機能

Lambda は2014年に登場し、2026年も依然としてサーバレスのデフォルトだ。ただし2024〜2026年の間に意味のある変化があった。

• Lambda SnapStart:前述の Firecracker スナップショット復元。2026年5月時点で Java、.NET、Python 3.12 以降が GA。Node.js はベータ。
• Lambda Web Adapter:Express/Fastify/Hono/Spring/Flask など標準 HTTP サーバーをそのまま Lambda に載せる。実質コンテナイメージでのデプロイ。
• Lambda Powertools:AWS 公式ミドルウェアライブラリ。ロギング、トレーシング、メトリクス、idempotency、parameter store を一括提供。
• Lambda Layers:共通依存を分離。2026年でもモノレポで有用。
• Lambda Function URL + RESPONSE_STREAM:API Gateway なしで直接 HTTP。レスポンス・ストリーミングにより LLM トークン・ストリーミングが可能。

典型的な2026年スタイルの Lambda ハンドラ(Node.js、Powertools):

import { Logger } from '@aws-lambda-powertools/logger'
import { Tracer } from '@aws-lambda-powertools/tracer'
import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics'
import middy from '@middy/core'
import { injectLambdaContext } from '@aws-lambda-powertools/logger/middleware'
import { captureLambdaHandler } from '@aws-lambda-powertools/tracer/middleware'
import { logMetrics } from '@aws-lambda-powertools/metrics/middleware'

const logger = new Logger({ serviceName: 'orders-api' })
const tracer = new Tracer({ serviceName: 'orders-api' })
const metrics = new Metrics({ namespace: 'orders', serviceName: 'orders-api' })

const handler = async (event: any) => {
  logger.info('received order', { orderId: event.orderId })
  metrics.addMetric('OrderReceived', MetricUnit.Count, 1)
  return { statusCode: 200, body: JSON.stringify({ ok: true }) }
}

export const main = middy(handler)
  .use(injectLambdaContext(logger))
  .use(captureLambdaHandler(tracer))
  .use(logMetrics(metrics))

Python では次のように書く。

from aws_lambda_powertools import Logger, Tracer, Metrics
from aws_lambda_powertools.metrics import MetricUnit
from aws_lambda_powertools.utilities.typing import LambdaContext

logger = Logger(service="orders-api")
tracer = Tracer(service="orders-api")
metrics = Metrics(namespace="orders", service="orders-api")

@logger.inject_lambda_context
@tracer.capture_lambda_handler
@metrics.log_metrics
def handler(event: dict, context: LambdaContext):
    logger.info("received order", extra={"order_id": event.get("orderId")})
    metrics.add_metric(name="OrderReceived", unit=MetricUnit.Count, value=1)
    return {"statusCode": 200, "body": '{"ok": true}'}

Lambda の限界は今も同じだ。最大15分、メモリ10GB、/tmp 10GB、デフォルト同時実行1000。15分を超えるジョブは Step Functions で細分化するか、Fargate/Batch に渡す。

AWS Fargate vs App Runner — Lambda で解けない場所

Lambda が窮屈なワークロードは2つ。1つ目は15分超のバッチ。2つ目は永続接続(WebSocket プール、gRPC サーバー)が必要なケース。AWS はこのスロットに2つの答えを用意する。

• AWS Fargate:ECS あるいは EKS のコンピュート・バックエンド。「マネージド・コンテナ・ホスティング」の王道。cluster、task definition、service は運用者が直接面倒を見る。
• AWS App Runner:コンテナイメージか GitHub リポを渡すだけで、ビルド・デプロイ・HTTPS・オートスケールまで自動でやる。Cloud Run に最も近い AWS サービス。

App Runner は2024年に ALB 統合と VPC Connector を強化し、Cloud Run との差をかなり縮めた。ただしリージョン数と価格では Cloud Run の方が一歩前という評価が多い。

Google Cloud Run — 「コンテナ・サーバレス」の事実上の標準

Cloud Run は2019年 GA 以降、コンテナ・サーバレスのデフォルトになった。2026年5月時点の強みは:

• リクエストタイムアウト最大60分(Lambda の4倍)。
• CPU always-on オプションでバックグラウンド処理(Pub/Sub 非同期、WebSocket fan-out)が可能。
• min-instances でコールドスタートを実質ゼロ化。
• GCS、Pub/Sub、Cloud Tasks、Eventarc とネイティブ連携。
• HTTP/2、gRPC、WebSocket すべて対応。

典型的な Cloud Run サービス定義:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: orders-api
  annotations:
    run.googleapis.com/launch-stage: GA
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "200"
        run.googleapis.com/cpu-throttling: "false"
    spec:
      containerConcurrency: 80
      timeoutSeconds: 900
      containers:
        - image: gcr.io/myproj/orders-api:2026.05
          resources:
            limits:
              cpu: "2"
              memory: 1Gi
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-url
                  key: latest

Mercari は2022年から検索バックエンドの一部を Cloud Run に移しており、韓国では Toss の一部決済後処理が Cloud Run で動くと言われている(ミートアップ発表ベース)。

Cloud Functions 2nd gen — Cloud Run の上に乗った関数モデル

Cloud Functions 2nd gen は実質、Cloud Run の上に抽象化された関数ランタイムである。したがって60分タイムアウト、コンテナ同時実行、Eventarc 統合をそのまま継承する。1st gen 関数も2026年5月時点で互換モードとして残るが、新規コードは 2nd gen がデフォルトだ。

Azure Functions + Container Apps — そして Durable Functions

Azure 側も2つのレーンに分かれる。

• Azure Functions:Consumption / Premium / Dedicated プラン。Consumption は Lambda 同様の従量制、Premium はコールドスタート除去用。
• Azure Container Apps:KEDA ベースのコンテナ・サーバレス。Dapr 連携が強み。Cloud Run と直接競合。

Durable Functions は Azure の特長だ。C#/JS/Python でオーケストレーション・ワークフローをコードとして書き、Azure がチェックポイントとリトライを管理する。AWS Step Functions をコード親和的にしたモデル、と捉えればよい。

Cloudflare Workers — V8 isolate という別次元

Workers は他のサーバレスと根本的に違う。コンテナでも microVM でもなく、V8 isolate を使う。同一プロセス内に複数ユーザーのコードを分離して動かすので、コールドスタートはほぼゼロ、デプロイは300以上の PoP に自動配信される。

2026年5月時点の Workers 生態系は以下のとおり:

• Workers:V8 isolate ベースの関数。
• Workers AI:GPU 上で LLaMA、Mistral、Whisper、BGE 埋め込みなどの OSS モデルを実行。リクエスト単位の課金。
• R2:S3 互換オブジェクトストレージ。下り無料。
• KV:グローバル分散 key-value。結果整合性、60秒の読み取りキャッシュ。
• D1:SQLite ベースの分散 DB。2024年からマルチリージョン読み取りに対応。
• Durable Objects:状態を持つオブジェクト。1オブジェクトにつき単一インスタンスが保証されるため、WebSocket fan-out、カウンター、レートリミットに自然。
• Queues:at-least-once メッセージキュー。
• Vectorize:ベクター DB。RAG 用途。
• Pages Functions:Pages サイトの隣で動く Workers。

典型的な Worker コード:

export interface Env {
  ORDERS_KV: KVNamespace
  DB: D1Database
  AI: Ai
}

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const url = new URL(req.url)
    if (url.pathname === '/embed' && req.method === 'POST') {
      const { text } = await req.json<{ text: string }>()
      const out = await env.AI.run('@cf/baai/bge-base-en-v1.5', { text: [text] })
      return Response.json({ embedding: out.data[0] })
    }
    if (url.pathname.startsWith('/orders/')) {
      const id = url.pathname.split('/')[2]
      const cached = await env.ORDERS_KV.get(id, 'json')
      if (cached) return Response.json(cached)
      const row = await env.DB.prepare('SELECT * FROM orders WHERE id = ?').bind(id).first()
      if (row) await env.ORDERS_KV.put(id, JSON.stringify(row), { expirationTtl: 60 })
      return row ? Response.json(row) : new Response('not found', { status: 404 })
    }
    return new Response('ok')
  },
}

Workers にも限界は明確にある。CPU 時間デフォルト30秒(有料プラン5分)、メモリ128MB、Node.js 互換モードはあるが一部 npm パッケージは動かない。そして KV は結果整合性なので、「書いた直後の値がすぐ見えないことがある」点は常に頭に入れておく。

Cloudflare D1 マルチリージョン — 2026年にようやく実用的

D1 は SQLite を分散システム化したものだ。2024年に read replicas が追加され、2025年に multi-region writes ベータが開き、2026年5月時点でグローバル読み取り整合性と単一リージョン書き込みモデルとして安定した。Coupang のような韓国・東南アジア同時運用に興味深い選択肢になったが、強整合性が必要な決済・財務は依然として RDS や Spanner の方が安全だ。

Deno Deploy — Workers の Web 標準寄り版

Deno Deploy は Cloudflare Workers と非常に似たモデル(V8 isolate、グローバルエッジ)だが、Deno ランタイム上で動くので、ES モジュール、ネイティブ TypeScript、Web Standard API(fetch、Request、Response、WebSocket)に忠実だ。

Deno.serve((req: Request) => {
  const url = new URL(req.url)
  if (url.pathname === '/hello') {
    return new Response(JSON.stringify({ hello: 'world' }), {
      headers: { 'content-type': 'application/json' },
    })
  }
  return new Response('not found', { status: 404 })
})

2024年に Deno KV が GA、2025年に Deno Queues が追加された。Deno1ファイルでフルスタック・サーバレス・バックエンドが書ける、というのが大きな変化だ。

Bun Edge — 2026年の新顔

Bun は2024年に1.0 GA した JS ランタイムで、2025年末から Bun Edge というホスティングサービスをベータ運用している。Cloudflare Workers / Deno Deploy と同じスロットだが、Bun が持つ ONNX、TensorRT 連携でエッジ ML 推論に強い。2026年5月時点ではまだベータなので、本番のマルチテナント配備は慎重に。

Vercel Functions / Edge / Fluid Compute — Next.js のデフォルト

Vercel は Next.js ユーザーにとって実質デフォルトのデプロイ先だ。2026年5月時点で次の3モードがある。

• Vercel Functions:AWS Lambda の上の抽象。Node.js 関数。
• Vercel Edge Functions / Edge Middleware:Cloudflare Workers に近いエッジ isolate。
• Vercel Fluid Compute:2024年末に導入。同一インスタンスが複数の同時リクエストを受け、コールドスタートと idle コストを同時に下げる。

Fluid Compute は特に「Next.js サーバーコンポーネントが外部 API を待つ間、同じ Lambda が別のリクエストも捌く」というシナリオで効く。AI チャットボットのように I/O 待ちが長いワークロードに直接効果がある。

Netlify Edge / Background Functions — Deno に乗ったエッジ

Netlify Edge Functions はバックエンドに Deno ランタイムを採用する。だから URL import、ネイティブ TypeScript、Web Standard API が自然だ。Netlify Functions(非エッジ)は AWS Lambda の上で動き、Background Functions として15分の非同期ジョブもサポートする。

import type { Context } from 'https://edge.netlify.com'

export default async (req: Request, ctx: Context) => {
  const country = ctx.geo?.country?.code ?? 'JP'
  return new Response(JSON.stringify({ country }), {
    headers: { 'content-type': 'application/json' },
  })
}

Fastly Compute@Edge — Wasm でいくもう一つの道

Fastly Compute@Edge は V8 isolate ではなく WebAssembly を使う。だから Rust、AssemblyScript、Go(TinyGo)、JavaScript(SpiderMonkey on Wasm)が全部走る。コールドスタートはマイクロ秒オーダーだ。

use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK).with_body("hello edge")),
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND).with_body("not found")),
    }
}

Wasm Component Model が2024〜2025年に標準化され、「一度ビルドすればどこでも動く」という約束はますます現実に近づいている。

Akamai EdgeWorkers — 伝統 CDN のエッジ関数

Akamai は伝統的な CDN ベンダーだが、EdgeWorkers という名で独自のエッジ関数ランタイムを動かしている。V8 ベースで、レスポンス変換、A/B テスト、トークン検証など CDN 親和的なワークロードに最適化されている。Cloudflare Workers のようにフルバックエンドを書くより、CDN 前段の軽量ロジックという用途が多い。

Fermyon Spin — Wasm ネイティブ・サーバレス

Fermyon Spin は Wasm ネイティブ・サーバレスの代表選手だ。関数単位の Wasm コンポーネントを作って配備する。コールドスタートは約1ms、ポリグロット(Rust、Go、JS、Python、.NET)を全部サポートする。

spin_manifest_version = 2

[application]
name = "orders-api"
version = "0.1.0"

[[trigger.http]]
route = "/orders/..."
component = "orders"

[component.orders]
source = "target/wasm32-wasi/release/orders.wasm"
allowed_outbound_hosts = ["https://api.stripe.com"]

[component.orders.build]
command = "cargo build --target wasm32-wasi --release"

Spin は Spin Cloud、Fermyon Cloud、Kubernetes 上の SpinKube でほぼ同様に動く。2026年時点で Lambda / Cloud Run ほどの認知はないが、Wasm Component Model を最も真剣に推進するプレイヤーだ。

Fly.io — Firecracker で作る「エッジのフル VM」

Fly.io は他のエッジプラットフォームとは違う。Firecracker microVM を世界30以上のリージョンに敷き、ユーザーの Dockerfile をその上で丸ごと動かす。すなわち 「エッジに近い本物のコンテナ」 を運用するモデルだ。WebSocket、TCP、UDP、永続ディスク(Fly Volumes)、Postgres クラスタまで自前で運用できる。

app = "orders-api"
primary_region = "nrt"

[build]
  image = "ghcr.io/myorg/orders-api:2026.05"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 512

韓国・日本のトラフィックが多いなら nrt(東京)、kix(大阪)リージョンを置くのが自然だ。Cloud Run よりも永続接続と状態管理で柔軟。

Railway / Render / Koyeb / Northflank — 「GitHub プッシュでデプロイ」の新世代

この4プラットフォームはすべて「GitHub リポ接続 → 自動ビルド/デプロイ」の PaaS だ。

• Railway:最速のスタート。Postgres、Redis、Mongo を1クリックで追加できる。価格は従量制。
• Render:Heroku の正統な後継ポジション。Static sites、services、cron jobs、workers を1つの UI で。
• Koyeb:グローバルエッジにコンテナを配備する。Fly.io に近いモデルだが UX は Railway 寄り。
• Northflank:マルチクラウド(BYOC、自前クラスタ持ち込み)対応が差別化点。ややエンタープライズ寄り。

2026年時点で Heroku を離れたユーザーが一番多く着地しているのが Railway と Render だ。

コールドスタートをもう一度 — SnapStart はどう動いているか

Lambda SnapStart は単なるメモリキャッシュではない。関数の初期化完了直後に Firecracker microVM のメモリページをスナップショットとして保存し、コールドリクエスト時にそのスナップショットを新しい microVM に復元する。JVM や CLR のように初期化が重いランタイムで特に効く。注意点が1つある。スナップショットにメモリ状態が丸ごと入るので、「関数開始時に作ったデータベース接続がそのまま入る」点には気を付ける(復元後に接続が切れている可能性がある)。

WebSocket とストリーミング — どこまでできるか

サーバレスでの WebSocket と SSE の扱いは2026年も依然として難しい場所だ。

• AWS Lambda:普通の関数は WebSocket を受け取れない。API Gateway WebSocket と組み合わせる。Function URL の RESPONSE_STREAM モードで SSE / ストリーミングは可能。
• Cloud Run:HTTP/2 + WebSocket を正式サポート。60分リクエスト上限内で永続接続が可能。
• Cloudflare Workers:WebSocket を正式サポート。Durable Objects と組めば fan-out パターンも自然。
• Vercel Edge:SSE ストリーミングは良好、WebSocket は2024年に正式対応。
• Fly.io:フル TCP なので WebSocket、gRPC、UDP まで自由。

要するに「エッジで WebSocket プールを受ける」なら Cloudflare Workers + Durable Objects あるいは Fly.io が第一候補。

価格モデル — 何で課金されるのか

サーバレス価格は大きくいくつかのモデルに分かれる。

1. リクエスト + 実行時間(GB-second):AWS Lambda、Cloud Functions、Azure Functions。
2. リクエスト + CPU 時間(リクエスト単位):Cloudflare Workers、Vercel Functions。
3. コンテナ実行時間(vCPU 秒 + メモリ秒):Cloud Run、App Runner、Container Apps。
4. VM 実行時間(分単位):Fly.io、Railway、Render。

2026年5月時点のおおよその単価。正確な数値は各社の価格ページを参照。

{
  "aws_lambda": { "per_million_requests": "$0.20", "per_gb_second": "$0.0000166667" },
  "cloud_run": { "per_million_requests": "$0.40", "per_vcpu_second": "$0.000024", "per_gib_second": "$0.0000025" },
  "cloudflare_workers": { "per_million_requests": "$0.30 paid", "first_10m_free": true, "per_million_duration_ms": "$0.02" },
  "vercel_pro_functions": { "included_gb_hours": "1000", "overage_gb_hour": "$0.18" },
  "fly_io_shared_1x_cpu": { "per_month": "~$1.94", "memory_256mb_month": "~$0.50" }
}

ここで1つトリックがある。Cloudflare Workers は「CPU 時間」だけを数え、I/O 待ち時間は課金しない。外部 API を待つ LLM チャットボットワークロードに非常に有利だ。

エッジ ML 推論 — 2026年の新スロット

エッジで ML 推論を動かす流れが2024〜2026年に本格化した。

• Cloudflare Workers AI:LLaMA 3、Mistral、Whisper、BGE 埋め込み、Stable Diffusion など30以上のモデルをグローバル GPU 上で呼び出す。リクエスト単位課金。
• Vercel AI SDK:OpenAI、Anthropic、Google、Cohere、ローカルモデルまで単一 API で呼び出す。ストリーミング、ツール呼び出し、RSC 統合。
• Bun + ONNX Runtime:Bun Edge で ONNX モデルを直接推論。埋め込み、分類、OCR に最適。

エッジで推論を回せば、ユーザーに近い場所でトークンを生成し、同じエッジからそのままストリーミングできる。P50 の最初のトークンの遅延を100ms 以下に抑えやすい。

韓国事例 — Toss、Coupang のサーバレス利用断面

韓国でサーバレスがどう使われているか、公開された情報を整理する。

• Toss:決済後処理(レシート送信、精算通知、不正取引フック)の一部を AWS Lambda で運用。0 から1000 RPS まで秒単位で跳ねるワークロードに合う。
• Coupang:Black Friday 級スパイクトラフィックの吸収に Lambda を補助コンピュートとして使用。メインは ECS/EKS だが、非同期処理は SQS + Lambda パターン。
• KakaoBank / LINE Bank:社内ツール、通知、バッチ処理にサーバレス。中核の決済は依然コンテナベース。

共通点は「0 → 1000 のスパイクが頻発する場所」でサーバレスを使うこと。

日本事例 — LY Yahoo、Mercari、Sansan

日本側は公開資料がより多い。

• LY(LINE Yahoo):メッセージ後処理、通知ルーティング、一部 LINE Mini App バックエンドに AWS Lambda と Cloud Functions を併用。
• Mercari:検索・推薦バックエンドの一部を Cloud Run で運用。Go サービスが主力で、コンテナ同時実行と Cloud Tasks 非同期呼び出しパターンが標準。
• Sansan:名刺 OCR 後処理ワークフローに Cloud Run + Cloud Tasks。Functions 2nd gen も一部使用。

3社とも「メインシステムの隣で非同期/スパイクワークロードを受け持つ場所」にサーバレスを置く。

一度ビルド、どこでも実行 — 2026年の実進捗

「Build once, run everywhere」は Wasm Component Model(WIT / WASI Preview 2)の約束だ。2026年5月時点で次が実質可能。

• Fermyon Spin の Wasm コンポーネントは Fastly Compute@Edge、Spin Cloud、SpinKube でほぼ同一に動く。
• Cloudflare Workers は一部 Wasm ランタイムを支援するが、isolate モデルと100%互換ではない。
• Vercel Edge / Netlify Edge は V8 isolate がバックエンドなので Wasm は補助手段。

「本当に一度ビルドして全クラウドで動く関数」はまだ100%ではないが、それに最も近い形が Wasm Component Model の上に収束しつつある。

プラットフォーム比較マトリクス — 2026年5月時点

サーバレスを選んではいけない場所

最後に、2026年でもサーバレスが答えにならない場所は明確にある。

• 高持続 GPU 推論:モデルロードに数十秒かかる LLM。専用 GPU インスタンスや SageMaker、Modal、Replicate の方が向く。
• 長期永続接続 + 状態:大規模マルチプレイヤーゲームサーバー。Fly.io か EC2/GKE の方が自然。
• 数十 ms 以下の末端遅延が一定で必要な取引システム:取引所、広告入札。ベアメタルか dedicated。
• 数十 GB メモリで回す分析/結合:Lambda 10GB では不足。Fargate / EKS。

サーバレスは「使うべき場所」が明確になった分、「使うべきでない場所」も明確になった。

References

• AWS Lambda 公式ドキュメント: https://docs.aws.amazon.com/lambda
• AWS Lambda Powertools: https://docs.powertools.aws.dev
• Google Cloud Run ドキュメント: https://cloud.google.com/run/docs
• Azure Functions ドキュメント: https://learn.microsoft.com/azure/azure-functions
• Cloudflare Workers ドキュメント: https://developers.cloudflare.com/workers
• Deno Deploy ドキュメント: https://docs.deno.com/deploy
• Vercel Functions ドキュメント: https://vercel.com/docs/functions
• Netlify Edge Functions: https://docs.netlify.com/edge-functions/overview
• Fastly Compute@Edge: https://developer.fastly.com/learning/compute
• Fermyon Spin: https://developer.fermyon.com/spin
• Fly.io ドキュメント: https://fly.io/docs
• Railway ドキュメント: https://docs.railway.app
• Render ドキュメント: https://render.com/docs
• Koyeb ドキュメント: https://www.koyeb.com/docs