Docker vs Podman
コンテナ化の業界標準Dockerと、デーモンレス方式を採用したPodmanが対決。セキュリティ、企業コンプライアンス、日常利用の観点でどちらが優れているのか?
V8 isolateでグローバルエッジ上に展開され、VMのコールドスタートがないコンピュート
Firecracker microVM上で動作し、AWSエコシステムに深く統合されたサーバーレスコンピュート
明確な勝者はいません。短時間でレイテンシに敏感なグローバルなリクエスト処理(認証、ルーティング、パーソナライゼーション、APIゲートウェイ、Webhook)にはCloudflare Workersがコストと低いコールドスタートの摩擦の両面で優位です。長時間実行、大量メモリ、VPC内のAWSリソースに依存する処理ではLambdaが優勢です。上限が広く、プライベートネットワークアクセスはGAである一方、WorkersではベータのWorkers VPCにとどまります。最も一般的な本番パターンはハイブリッドで、Workersがエッジの薄いレイヤーを担い、Lambdaが背後で重い処理を引き受けます。
| カテゴリー | Cloudflare Workers | AWS Lambda |
|---|---|---|
| パフォーマンス | 8/10 | 7/10 |
| 学習のしやすさ | 7/10 | 6/10 |
| エコシステム | 6/10 | 9/10 |
| コミュニティ | 6/10 | 8/10 |
| 求人市場 | 6/10 | 8/10 |
| 将来性 | 9/10 | 8/10 |
// Cloudflare Workers - Hyperdriveでpostgresに接続するAPI
import { Hono } from "hono";
import postgres from "postgres";
interface Env {
HYPERDRIVE: Hyperdrive;
}
const app = new Hono<{ Bindings: Env }>();
app.get("/api/users/:id", async (c) => {
// リクエストごとに新しいクライアントを開くのは高速 — Hyperdriveが
// 接続プールをすでにプラットフォーム側で保持しているため。
const sql = postgres(c.env.HYPERDRIVE.connectionString, {
max: 5,
fetch_types: false,
});
// Hyperdriveはリクエスト終了時に接続を自動的にクリーンアップするので、sql.end() を呼ぶ必要はない。
const id = c.req.param("id");
const rows = await sql`
SELECT id, name, plan FROM users WHERE id = ${id} LIMIT 1
`;
if (rows.length === 0) {
return c.json({ error: "not_found" }, 404);
}
return c.json(rows[0]);
});
export default app;
/*
wrangler.jsonc
{
"name": "edge-api",
"main": "src/index.ts",
"compatibility_date": "2026-09-01",
"hyperdrive": [
{ "binding": "HYPERDRIVE", "id": "<hyperdrive-config-id>" }
]
}
*/// AWS Lambda (Node.js) - VPC内のRDS Postgresに接続するハンドラー
import { Client } from "pg";
let client; // コンテナの再利用時(ウォームスタート)に保持される
export const handler = async (event) => {
const id = event.pathParameters?.id;
if (!client) {
client = new Client({
host: process.env.DB_HOST, // RDSプライベートエンドポイント(VPC内)
port: 5432,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
ssl: { rejectUnauthorized: true },
});
await client.connect();
}
try {
const result = await client.query(
"SELECT id, name, plan FROM users WHERE id = $1 LIMIT 1",
[id]
);
if (result.rows.length === 0) {
return { statusCode: 404, body: JSON.stringify({ error: "not_found" }) };
}
return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
} catch (err) {
console.error(err);
return { statusCode: 500, body: JSON.stringify({ error: "internal" }) };
}
};
/*
template.yaml (AWS SAM) — VPC + メモリ + タイムアウト
Resources:
UsersFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs22.x
MemorySize: 512
Timeout: 15 # 秒(上限900 = 15分)
VpcConfig:
SecurityGroupIds: [sg-xxxxxxxx]
SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
Policies:
- VPCAccessPolicy: {}
*/明確な勝者はいません。短時間でレイテンシに敏感なグローバルなリクエスト処理(認証、ルーティング、パーソナライゼーション、APIゲートウェイ、Webhook)にはCloudflare Workersがコストと低いコールドスタートの摩擦の両面で優位です。長時間実行、大量メモリ、VPC内のAWSリソースに依存する処理ではLambdaが優勢です。上限が広く、プライベートネットワークアクセスはGAである一方、WorkersではベータのWorkers VPCにとどまります。最も一般的な本番パターンはハイブリッドで、Workersがエッジの薄いレイヤーを担い、Lambdaが背後で重い処理を引き受けます。
無料相談を受けるワークロードによって変わるため、都度計算する必要があります。Workers Paidプランは月額$5の基本料金に1,000万リクエストと3,000万CPUミリ秒が含まれ、超過分はリクエスト100万件あたり$0.30、CPU時間100万msあたり$0.02が加算されます。I/O待機時間は課金対象外です。一方Lambdaはリクエスト数とGB秒(メモリ×実行時間)ベースで課金され、無料枠は月100万リクエストと40万GB秒を含みます。短時間でI/O主体の処理ではWorkersのCPU時間モデルが安くなる傾向があり、長時間でCPU負荷の高い処理ではLambdaのGB秒モデルがワークロード次第で変動します。