服務定位

Cloudflare WAF 的核心定位是 把攻擊擋在 origin 之前的一站式 edge security。流量打到 Cloudflare anycast IP、經過 WAF / DDoS / Bot / Rate Limit / Page Shield 多層處理、再 proxy 到 origin。這跟 AWS WAF 跑在 AWS 內部 ALB / CloudFront / API Gateway 前是不同部署模型 — AWS WAF 流量 已經進到 AWS、Cloudflare WAF 流量 還沒到 origin。對 origin 是 任意雲 / on-prem 的客戶、Cloudflare 是天然選項；對 AWS-only 客戶、AWS WAF 整合更深但 edge 範圍小。

跟 Fastly Next-Gen WAF（前 Signal Sciences）相比、Cloudflare 走 signature + managed rule + ML 混合、Fastly NG-WAF 走 語意分析 + behavioral detection（不靠 regex signature）。Cloudflare managed rule 覆蓋廣但 false positive 較常見、需要 sensitivity tuning；Fastly NG-WAF 預設較低 FP 但需要 自己定義業務 anomaly。

關鍵張力：客戶信任的不只是 WAF rule 攔截能力、還包括 Cloudflare control plane 的安全性。Cloudflare 2023 control plane token 跟 Cloudflare 2026 route leak 兩個事件展示：vendor 自己被打進去 / 自動化配置失誤時、客戶側 直接修不了、只能等公告 + 客戶側 token rotation + emergency bypass。

本章目標

讀完本頁、讀者能判斷：

1. Cloudflare WAF 在 edge security stack 中承擔哪一段（DDoS / WAF / Bot / Page Shield / API Shield）、哪些要靠 origin 自己做
2. Managed Rule vs Custom Rule 的取捨、sensitivity tuning 跟 false positive curve
3. Cloudflare control plane 出事時的客戶側補強路徑（API token rotation、Origin Rules bypass、第二邊界 fallback）
4. 何時用 Cloudflare、何時走 AWS WAF / Fastly NG-WAF 的取捨

最短判讀路徑

判斷 Cloudflare WAF 配置是否健康、最少看四件事：

• 誰能改 WAF 規則：Cloudflare account 的 admin / member role 配置、API token scope（不要用 Global API Key、用 scoped API token + 限定 zone / 限定 permission）、Audit Log 是否同步到 SIEM
• 規則覆蓋面：Managed Ruleset（OWASP Core Ruleset + Cloudflare Managed Ruleset + Exposed Credentials Check）是否開、Sensitivity（Low / Medium / High）對應的 FP rate 是否監控、Custom Rule 是否進版控（Terraform provider）
• 入口暴露：origin IP 是否曝光（DNS 直查 / 歷史 SAN cert / 子域名）、Argo Tunnel / Authenticated Origin Pull 是否強制、繞過 Cloudflare 直連 origin 的路徑是否封住
• 證據可回查：Security Events Log 是否同步到 SIEM（Logpush 推到 R2 / S3 / Splunk）、Page Shield 偵測異常 script 是否 alert、API token 異常操作（特別 zone settings 變更）是否 alert

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Managed Ruleset 分層：Cloudflare 提供三類 managed rule — OWASP Core Ruleset（OWASP CRS、寬覆蓋、FP 較多）、Cloudflare Managed Ruleset（Cloudflare 維護、針對熱門 CMS / framework）、Exposed Credentials Check（檢測登入流量中的已洩漏 credential）。production 通常開全部三套 + 各設適當 sensitivity。Sensitivity 不是「敏感度越高越好」— High sensitivity 攔截更多 borderline traffic、business-critical endpoint 可能誤殺合法請求。建議從 Log Mode 開始、觀察 1-2 週的 FP pattern、再切到 Block。

Custom Rule（Cloudflare Rules）：用 Rules language（類 SQL 表達式）定義條件 + 動作（Block / Challenge / Log / JS Challenge / Managed Challenge）。常見用法：geo block（特定國家）、known bad IP（threat intel feed）、URI path-based limit（admin endpoint 限定 IP）、header anomaly（缺 User-Agent / 異常 Referer）。所有 Custom Rule 走 Terraform provider 進版控、避免 console 直接改、變更走 PR review。

Rate Limiting：跟 WAF rule 是 獨立 product、配置是 threshold + window + action（例：1000 req/min per IP → challenge）。Rate Limiting 比 WAF 適合處理 legitimate-looking high volume（credential stuffing、scraping、API abuse）。注意 NAT pool IP 的問題 — 一個公司 / ISP NAT 出口可能合法產生高 QPS、簡單 per-IP rate limit 會誤殺、需要組合 cf.threat_score 或 cookie-based identification。

Bot Management（單獨 SKU）：免費版 WAF 不含 Bot Management、需要 Pro / Business / Enterprise 才有。Bot Management 用 ML + behavioral fingerprint 區分 human / good bot（搜尋引擎）/ likely bot / verified bot、給 bot score（1-99）。客戶在 Custom Rule 用 cf.bot_management.score < 30 之類條件挑出 likely bot 處理。簡單 user-agent 過濾擋不住現代 headless browser、必須走 Bot Management。

Page Shield（JS supply chain 防護）：Page Shield 監測客戶網頁載入的 JS / connect 來源、發現 新出現的腳本 或 已洩漏的 script（CT log + threat intel）就 alert。意義是 防 third-party script 被供應鏈攻擊（類 Magecart）— WAF 攔不住、因為攻擊發生在 browser 端 而非 origin 流量。需要在 Page 載入 Page Shield 的 monitoring script。

API Shield：用 OpenAPI schema validation、auto-discovery API endpoint、mTLS 驗證、JWT validation。對於有 schema 的 API、可以擋掉 schema 不符的請求（多餘欄位、型別錯誤、缺必要欄位）— 比 generic WAF rule 精準。

Origin 暴露面收緊：Cloudflare 唯一有效的前提是 流量必須經過 Cloudflare。如果攻擊者拿到 origin 真實 IP（DNS 歷史記錄、漏洞披露網站、SSL cert SAN）、可以繞過 Cloudflare 直打 origin。控制方法：origin firewall 只允許 Cloudflare IP range 入站、Argo Tunnel（origin 主動建 outbound 連線到 Cloudflare、不開任何入站 port）、Authenticated Origin Pull（origin 用 cert 驗證請求來自 Cloudflare）三選一或組合。

API token 治理：避免 Global API Key（全帳號 root token）、改用 scoped API token（限 zone + 限 permission + 限 IP + 限 TTL）。token 進 Secret Management / Vault、定期 rotate。對應 Cloudflare control plane token 2023 揭示的 lesson：Cloudflare 自己也踩過 token 治理不足、客戶側不能假設 vendor 完美。

核心取捨表

選 Cloudflare WAF 的核心訴求：多雲 / on-prem origin + 需要 整套 edge security suite（DDoS + WAF + Bot + Page Shield + API Shield） + 接受 Cloudflare 控制面風險、且有預算做 Enterprise tier 才能拿到完整功能。純 AWS-internal app + ALB origin 用 AWS WAF 整合更直接。

進階主題

Workers + Workers AI 作為 custom logic：當 managed rule + custom rule 表達力不夠（例：根據 user account tier 決定 challenge 強度、整合內部 risk score API）、可以用 Cloudflare Workers 寫 JavaScript / TypeScript / Rust 在 edge 執行。Workers AI 提供 edge ML inference、可以做 inline content moderation 或 anomaly detection。代價是 Workers code 進 Cloudflare 控制面、變更要走部署流程、debug 跟 origin 是兩條 trace。

Logpush 跟 SIEM 整合：Cloudflare Security Events 量大、free / Pro 在 dashboard 看、Business / Enterprise 走 Logpush 到 R2 / S3 / Splunk / Datadog / Sumo Logic。production 必須走 Logpush、不能只在 dashboard — 事件 30 天保留期是 Cloudflare 端、SIEM 留更久。Logpush 也是 SIEM 上做 跨來源 correlation 的前提（WAF event + origin app log + IdP log）。

Multi-account / Tenant：大企業有多個 Cloudflare account（不同 BU / 不同產品線）、要走 Cloudflare for SaaS 或 Account-level access、API token scope 要限定 account。Single account 多 zone 是常見小組織配置、但跨組織 / 跨產品線必須拆 account 隔離 admin compromise blast radius。

Magic Transit / Zero Trust integration：Magic Transit 是 L3 DDoS（不只 HTTP、TCP / UDP 也 anycast）、Zero Trust 是 employee access（取代 VPN）。跟 WAF 是不同產品、但常一起部署 — Magic Transit 防 L3/L4 attack、WAF 防 L7、Zero Trust 防內部 east-west。

排錯與失敗快速判讀

• Managed Rule 誤殺合法請求：High sensitivity 開後 business endpoint 變慢 / 報錯 — 看 Security Events 找 rule_id、用 Custom Rule skip 該 rule 在特定 path / 特定 user-agent、不要全 zone 關 rule
• Bot Management 太嚴 / 太鬆：bot score threshold 設不對、合法 API client 被當 bot、或攻擊者拿到 verified bot 假冒 — 用 Bot Analytics 看分數分布、調整 threshold 同時加白名單（API key + IP CIDR）
• Rate Limit 誤殺 NAT 用戶：per-IP rate limit 在 NAT 出口 IP 上炸 — 改 per-session（cookie-based）或 cf.threat_score 條件
• Origin IP 外洩：DNS 歷史 + 漏洞披露 + cert SAN 揭露真實 origin、攻擊繞 Cloudflare 直打 — 換 IP + 開 origin firewall（只允許 Cloudflare CIDR）+ Argo Tunnel
• API token over-scoped：CI / 第三方 SaaS 拿到 Global API Key、整 account 都被改 — 改 scoped token、限 zone + permission + IP、進 Vault
• Security Events 沒進 SIEM：事件只在 dashboard、跨來源 correlation 沒法做 — 配 Logpush + alert 規則
• Page Shield 沒裝：客戶端 JS 被植入、伺服器端日誌看不到攻擊、第三方 script CDN 被打 — 啟用 Page Shield + CSP report-uri 雙軌
• 第二邊界沒設：完全依賴 Cloudflare、Cloudflare 出事流量全停（2023 / 2026 自家事件）— 高 SLA 服務應該設 fallback origin / secondary DNS（如 Route53 health check failover 到 Fastly 或直連 origin）

何時改走其他服務

不在本頁內的主題

• Cloudflare 完整 product line（Workers / Pages / R2 / D1 / Magic Transit / Zero Trust 各自細節）
• WAF Rules language 完整語法 reference
• Page Shield / API Shield Enterprise tier 完整功能對照
• 各 PCI DSS / SOC 2 / FedRAMP 合規矩陣
• Cloudflare 在中國的部署模式（JD Cloud Union 合作）

案例回寫

Cloudflare WAF 在 07 案例庫有 兩個直接 vendor-level 事件 + 多個 edge-exposure 對照：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：AWS WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（Cloudflare API token 存放）、Okta（Cloudflare admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 / Cloudflare 自家事件如何 routing 進 IR）
• 官方：Cloudflare WAF Documentation

服務定位

Fastly NG-WAF 設計的第一順位是 production 可直接走 Block 模式。Signature WAF 的成本不在 rule 本身、在 false positive — 一條 SQLi pattern 可能誤判合法 SQL-like 字串（搜尋查詢、CSV 上傳）、production 開 Block 立刻炸合法流量、所以多數 signature WAF 跑在 Detect / Log Only 模式、攔不下真正攻擊。Fastly NG-WAF 走 Signal 模型：每個請求被解析後標記若干 Signal（SQLi、XSS、CMDI、Traversal、Anomaly 等）、再依 threshold-based rule（N 個 Signal 在 M 秒內聚集）才動作 — false positive 自然降低、Block 模式可開。

跟 Cloudflare WAF 的對照：Cloudflare 走 signature + managed rule + ML 三層、覆蓋廣但需要 sensitivity tuning；Fastly NG-WAF 預設低 FP 但需要 客戶自己定義業務語意（哪些 path 是 admin、哪些 header 不該出現、哪些 anomaly 對自家業務代表攻擊）— 用 Tag + Match Conditions 表達。跟 AWS WAF 的對照：AWS WAF 跟 ALB / CloudFront / API Gateway 整合深、跨雲弱；Fastly NG-WAF 部署模型多樣（Edge / Agent / Cloud）、跨 AWS / GCP / on-prem / K8s 一致。

關鍵張力：低 FP 的 代價 是要花時間理解自家業務語意。Signature WAF 是「裝上就有保護」、Fastly NG-WAF 是「裝上有 baseline、業務 anomaly 要自己標」。沒有人定義 Tag + Power Rules、就只用到產品 30% 能力。

本章目標

讀完本頁、讀者能判斷：

1. Fastly NG-WAF 的 Signal / Tag / Rule / Mode 四個核心 first-class concept 各承擔什麼責任
2. Edge / Agent + Module / Cloud Proxy 三種部署模型的選擇條件
3. Account Takeover Protection、Bot Protection、API discovery 三個進階 module 的適用情境
4. 何時用 Fastly NG-WAF、何時走 Cloudflare WAF / AWS WAF 的取捨

最短判讀路徑

判斷 Fastly NG-WAF 配置是否健康、最少看四件事：

• 部署模型對齊架構：Fastly Edge inline（流量本來就過 Fastly CDN）/ Agent + Module（自管 Nginx / Apache / IIS / Envoy / .NET 加 sigsci-agent local process）/ Cloud Proxy（Fastly 接 origin proxy）三選一或混用、是否覆蓋所有入口（含 admin、internal API、staging）
• Signal 與 Tag 設計：預設 Signal（SQLi / XSS / CMDI / Traversal / Backdoor / Anomaly）是否全開、業務語意 Tag（admin-path、internal-only、payment-flow）是否定義並掛上 Match Conditions、Power Rules 是否組合多 Signal / Tag 走 threshold-based action
• Rule mode 與 threshold：Site-level 跟 Corp-level Rule 是 Block 還是 Off、threshold（連續幾個 Signal / 多久窗口）是否依 endpoint 業務調整、Template Rule（ATO、Bot）是否啟用
• Logging 與 sigsci-agent token 治理：Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）整合是否 production-grade、sigsci-agent 連回控制面的 token 是否進 HashiCorp Vault、跨環境 token 是否分離

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

部署模型選擇：Fastly Edge inline 是最簡部署、流量已過 Fastly CDN 就 inline 加 NG-WAF、沒有額外 agent 要管；Agent + Module 是 self-managed Nginx / Apache / IIS / Envoy / HAProxy / .NET / Java（Tomcat）等加裝 sigsci-module（process 內 module 攔請求）+ sigsci-agent（本機 daemon、跟 Fastly 控制面 sync rule、collect event）— 適合 origin 不過 Fastly CDN、或 internal API；Cloud Proxy 是 Fastly 提供 reverse proxy 端點、客戶 DNS 指過去、origin 在後面 — 適合不想改 origin、又沒用 Fastly CDN。三種混用常見、大企業 edge 用 Fastly Edge、internal service 用 Agent + Module。

Signal 是已知攻擊指標：Fastly NG-WAF 預定義 Signal 包含 SQLi / XSS / CMDI（command injection）/ Traversal（路徑穿越）/ Backdoor / RCE / Anomaly 等。Signal 是 語意解析結果 — request body 被 parser 拆解（JSON / form / multipart）、每個欄位看「這像不像某類攻擊」、不是 regex 比對。意義是 encoding 變化攔不住（base64 / URL encode / Unicode normalize 都會被解開）、跟 signature WAF 的脆性對比明顯。

Tag 是客戶自定 Signal：用 Match Conditions（path / method / IP / header / body content / query 參數）定義「什麼樣的請求叫某 tag」、例：Path: /admin/* AND Source IP NOT IN internal_cidr → tag: admin-external-access。Tag 之後可以走 Rule 處理（看到 admin-external-access 就 alert / block）。Tag 是 Fastly NG-WAF 表達 業務語意 的主要工具、不是用來補強 Signal。

Rule 三層：Site-level Rule（單一 site / property）/ Corp-level Rule（整個 organization 共用、用於 corp-wide block list、跨 BU 統一 policy）/ Template Rule（Fastly 提供的預設複合 rule、如 ATO template、Bot template）。Rule 表達式組合 Signal / Tag / Source IP / Path / Method、走 Block / Off。Power Rules 是進階版 — 支援 threshold + 時間窗口 + 多條件 AND/OR、例：「同 IP 在 60 秒內觸發 5 個 SQLi Signal 就 Block 10 分鐘」。

Mode 兩種：Block（攔截、回 406 / 自訂 status）/ Off（不動作、純 log）。沒有 Cloudflare 的 Sensitivity 滑桿 — 因為 Signal 本身已是語意判讀結果、不需要敏感度調整、調整在 threshold（多少 Signal 才動作）。

Account Takeover Protection（ATO）：偵測 credential stuffing pattern — 同 IP 多 login fail、跨 IP 同 account 多 login、impossible travel、unusual UA。Fastly NG-WAF 內建 login endpoint detection（自動 / 手動標記 /login、/auth/signin 等）、配合 ATO Template Rule 直接 inline 處理（rate limit、challenge、block）。對應 Identity Boundary 的 ATO 對策、但是在 WAF 層直接攔、不等 IdP 內 ATO 邏輯。

Bot Protection：跟 Cloudflare Bot Management 同類、走 behavioral + browser fingerprint + JS challenge、區分 verified bot / likely bot / human。比 user-agent 過濾穩、headless browser 攔得住。

API discovery：Fastly NG-WAF 自動學習 site 的 API endpoint 與 schema、偵測 schema drift（突然出現的多餘欄位、缺欄位、type mismatch）— 比手動維護 OpenAPI schema 輕量、適合內部 API 多但沒寫完整 OpenAPI 的團隊。

Logging 與 sigsci-agent 治理：所有 event 走 Fastly NG-WAF 控制面 + 客戶端 Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）。sigsci-agent 連回控制面用 Site API key — 該 key 進 HashiCorp Vault、跨環境 prod / staging 分離、rotation 走標準 secret rotation 流程、不能寫死在 agent 配置檔。

核心取捨表

選 Fastly NG-WAF 的核心訴求：production 直接 Block + API / schema-rich 業務 + 自管伺服器需要 inline agent + 跨雲 / on-prem mix、且有預算支付 Enterprise tier。純 AWS-internal 簡單 web app 用 AWS WAF 整合更直接；要整套 edge security suite 用 Cloudflare。

進階主題

VCL + Edge custom rule：Fastly Edge 部署模式下、NG-WAF 跟 Fastly CDN 的 VCL（Varnish Configuration Language）共存、複雜邏輯可寫 VCL 在 NG-WAF 處理前後攔截 — 例：geo block 在 VCL 做、NG-WAF 處理通過的請求。Compute@Edge（Fastly 的 edge serverless、類 Cloudflare Workers）也可以接 NG-WAF 結果做進一步處理。代價是 VCL / Compute@Edge code 變另一條 ops trace、要有版控與 staging。

ATO 進階 — credential stuffing 場景：login endpoint 接 ATO Template Rule 後、可進一步整合 已洩漏 credential check（類 Have I Been Pwned 整合）、failed login burst → progressive challenge（先 CAPTCHA、再 block）。對應 Identity Boundary 的 IdP ATO 邏輯、Fastly 在 WAF 層攔的好處是 攻擊不會打到 IdP、減少 IdP 端 rate limit 壓力。

Bot Protection 進階：browser fingerprint + behavioral pattern + JS challenge 三層、可掛 bot score threshold 在 Power Rules 內、配合 ATO 做 high-risk login flow（bot score 高 + login endpoint → 強 challenge）。

Agent + Module 在 K8s / VM：K8s 場景 sigsci-agent 走 sidecar 或 DaemonSet、sigsci-module 在 ingress controller（Nginx Ingress Controller 加 sigsci-nginx module）；VM 場景 sigsci-agent 走 systemd service、module 隨 web server 啟動。跨環境 token 隔離（prod / staging / dev）走 Vault dynamic secret 或環境變數注入、不寫死配置檔。

Corp-level Rule 共用：多 BU / 多產品線在同一 Corp（Fastly NG-WAF 的 organization 概念）下、Corp Rule 跨所有 Site 生效 — 適合表達「全公司禁 IP X」「全公司 ATO Template 都開」、避免每個 Site 重複配置。

排錯與失敗快速判讀

• Signal 沒觸發、攻擊穿過：Encoding 異常 / parser 沒解析該 content-type — 確認 Content-Type 正確、body 大小沒超過 sigsci-module 限制（預設 100KB）、Signal scope 是否包含該 endpoint
• Tag 沒掛上：Match Conditions 寫錯（path 大小寫、trailing slash、wildcard 語意）— 在 Fastly NG-WAF console 用 Rule Evaluation 工具測試 request 是否命中
• Block 模式誤殺：Power Rules threshold 太低、單一合法請求觸發多 Signal — 調 threshold 或加 Site Rule exception 排除特定 path / source
• sigsci-agent 跟控制面失聯：Site API key 過期 / firewall block out-bound / agent 版本太舊 — agent log 看 connection status、輪換 token 走 Vault、保持 agent 在 supported version range
• sigsci-module load 失敗：web server 啟動報 module 載入錯 — 確認 module 版本跟 web server major version 對齊（Nginx 1.20 對 sigsci-nginx 對應版本）
• ATO Template 沒攔到：login endpoint detection 沒標到自家 path — 手動在 console 標記 login endpoint 路徑
• Logging gap：Syslog / webhook 送失敗、SIEM 沒收到 — 確認 destination accept、TLS cert 沒過期、retry policy
• 跨環境 token 漏氣：staging token 流到 prod、改 staging 影響 prod rule — Vault 環境分離、token 加標籤、定期 audit token usage

何時改走其他服務

不在本頁內的主題

• Signal Sciences 收購前的 product line 演進細節
• 完整 Signal 清單與每個 Signal 的內部解析邏輯
• VCL / Compute@Edge 完整語法 reference
• Fastly CDN 本身的 caching / TLS / origin shielding 細節
• Enterprise 合約細節、各國資料駐留選項

案例回寫

Fastly NG-WAF 沒有直接 vendor-level 公開事件、案例庫對照引用以「behavioral detection 在 zero-day / supply chain 場景的 inline mitigation 角色」為主：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、AWS WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（sigsci-agent Site API key 存放）、Okta（Fastly admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 routing 進 IR）
• 官方：Fastly Next-Gen WAF Documentation

本文的判讀錨點是：SQLite compatibility 代表開發入口接近，服務責任仍要重新審查。採用 edge SQLite 前，要先確認 write authority、read freshness、migration limit、backup evidence、observability、cost 與 vendor exit，而非只看 SQL 語法能否執行。

Product Boundary

Product boundary 的核心責任是定義誰持有資料、誰執行 SQL、誰負責恢復。Local SQLite 的資料在你的 filesystem；D1 的資料由 Cloudflare D1 平台管理並和 Workers binding 整合；Turso / libSQL 的資料通常有 remote database 與 client / embedded replica 的分工。

Local SQLite 的判斷重點是 file ownership。若 app 與 database file 位於同一個 host，備份、restore、disk full、permission 與 app upgrade 都在你的 runbook 裡；這條路線承接 file lifecycle / backup boundary。

D1 的判斷重點是 platform integration。Cloudflare 官方 D1 docs 把 D1 放在 Workers 與 Wrangler workflow 內，並公開 D1 limits；因此採用 D1 時要把 database decision 與 Workers deployment、local preview、batch migration、import/export limit 一起審查。

Turso / libSQL 的判斷重點是 replica freshness 與 client semantics。Turso docs 對 embedded replicas 的描述顯示：application 可以持有 local replica 並透過同步取得資料；這會把「讀得快」和「讀到多新」變成同一個設計問題。

Edge Data Model

Edge data model 的核心責任是把 latency 改善與一致性責任拆開。Edge database 的價值常來自 closer read path、serverless deployment 與較低操作表面；風險則集中在 write authority、replication lag、region routing 與平台限制。

Write authority 是 edge SQLite 的第一個分水嶺。若所有 write 都集中到 remote primary，application 要處理 network error、retry、idempotency 與 read freshness；若 write 發生在 local replica，系統要有 conflict resolution、sync ordering 與 delete propagation。

Read locality 是 edge SQLite 的主要收益。它適合 session-local preference、read-mostly catalog、低風險 personalization、feature flag snapshot、tenant-local small dataset；這些情境的共同點是資料量小、write rate 低、freshness 可以定義。

Global transaction 是 edge SQLite 的高風險區。若產品需求包含跨 region balance transfer、inventory reservation、ledger posting、strongly consistent permission decision，設計應路由到 Global Distributed OLTP 或 PostgreSQL / CockroachDB / Spanner 的 transactional model。

Migration Gap

Migration gap 的核心責任是確認 SQLite file 可以搬到 edge product 後，release workflow 仍可驗證。SQL syntax compatibility 只解決起點；真正會造成事故的是 batch limit、extension 差異、driver API、local preview 與 production platform 行為差異。

D1 migration 要把 Wrangler workflow 納入 release gate。Cloudflare D1 的 limits 文件明確列出 import、query、batch 等限制；因此大型 update / delete 要拆 batch，migration 要有 staging dry run 與 production rollback step。

Turso / libSQL migration 要把 driver semantics 納入 release gate。Local SQLite driver 直連 file；libSQL client 可能連 remote endpoint 或 embedded replica；application 要把 connection lifecycle、sync timing、auth token、network failure 與 local cache freshness 寫進測試。

Operational Model

Operational model 的核心責任是把 managed convenience 轉成 ownership map。Edge SQLite 減少了部分 server operation，但新增 platform limit、billing、region behavior、vendor incident、CLI workflow 與 local preview mismatch。

Production runbook 至少要保存五種證據：

1. Schema migration history 與每次 release 的 dry-run result。
2. Data import / export 指令、檔案大小、row count 與 checksum。
3. Region latency、read freshness、write error rate 與 retry count。
4. Platform limit 命中紀錄、batch policy 與成本警戒線。
5. Vendor exit route：回 local SQLite、PostgreSQL 或另一個 edge database 的最小搬遷步驟。

成本模型要同時看 request、storage、egress、operation time 與工程鎖定。Edge product 常把起步成本壓低，但當資料變大、batch migration 變長、observability 需要外掛、vendor API 滲入 repository layer 時，長期成本會出現在 release 與 incident。

Decision Route

Decision route 的核心責任是把需求送到相符的資料模型。D1 / Turso / libSQL 適合 edge locality 與低操作表面；當需求轉向 high-write OLTP、central audit、role-based permission、global transaction 或跨服務資料治理，應轉向 server SQL 或 distributed OLTP。

D1 的採用條件是 edge runtime 本身就是主平台。若 application 已在 Workers 上、資料量可控、query pattern 清楚、migration 可 batch，D1 可以把 database operation 融入 deployment workflow。

Turso / libSQL 的採用條件是 local read value 高於同步複雜度。若產品可明確定義 stale read window、write path 與 conflict policy，embedded replica 可以降低 latency；若使用者需要立即看見跨裝置變更，就要先設計 freshness evidence。

Production Tripwires

Production tripwires 的核心責任是指出何時重新評估 edge SQLite。這些訊號出現時，系統通常已從「SQLite-compatible convenience」進入正式 database governance。

這些 tripwire 要寫進設計文件與 runbook。Edge SQLite 的優勢在於低摩擦起步；它的長期品質來自早期把 ownership、limits、exit 與 evidence 設計清楚。

下一步路由

D1 / Turso / libSQL comparison 完成後，下一步要依壓力路由。要處理 local file 與 backup，讀 file lifecycle / backup boundary；要處理 replica / restore，讀 Litestream / LiteFS replication；要從 local SQLite 移到 edge product，讀 SQLite to D1 / Turso migration；要處理 global write，回到 Global Distributed OLTP。

本文的驗收標準是：你能從 local SQLite 匯出 schema / seed，匯入 D1 或 Turso preview database，跑相同 query set，記錄 unsupported SQL、latency、error mapping 與 rollback route。

Preview Scope

Preview scope 的核心責任是把 lab 限制在 staging / preview。D1 與 Turso 都是平台產品，實際命令會依 CLI version、帳號、region 與專案設定改變；本文提供操作骨架與 evidence 格式，正式命令以官方文件為準。

官方文件路由：

Preview lab 要先確認資料不含 production PII。若 seed data 來自正式資料，先做 masking 或 synthetic data。

Export Local SQLite

Export local SQLite 的核心責任是建立 target platform 的 seed input。沿用 /tmp/sqlite-lab/app.db 或 migration fixture。

1mkdir -p /tmp/sqlite-edge-lab
2cd /tmp/sqlite-edge-lab
3cp /tmp/sqlite-lab/app.db ./app.db
4sqlite3 app.db ".schema" > schema.sql
5sqlite3 app.db ".dump" > seed.sql
6sqlite3 app.db "SELECT COUNT(*) FROM accounts;"
7sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"

schema.sql 用來審查 DDL，seed.sql 用來匯入 preview database。正式 migration 可能要拆 schema / data / index，並處理 target platform limits。

Build Query Matrix

Build query matrix 的核心責任是定義 preview 要驗證什麼。query set 要代表產品行為，而非只跑一個 SELECT 1。

1Q1 list account balances
2Q2 insert ledger entry with unique idempotency key
3Q3 insert duplicate idempotency key and capture error
4Q4 foreign key violation
5Q5 transaction rollback
6Q6 pagination by created_at
7Q7 explain / performance sample if platform supports it

這份 matrix 要保存 expected result。Local SQLite 先跑一次，把 row count、error category、latency baseline 記下來。

1sqlite3 app.db <<'SQL'
2.timer on
3SELECT a.id, a.owner_name, SUM(l.amount_cents) AS balance_cents
4FROM accounts a
5JOIN ledger_entries l ON l.account_id = a.id
6GROUP BY a.id, a.owner_name
7ORDER BY a.id;
8SQL

Import to D1 Preview

Import to D1 preview 的核心責任是驗證 Cloudflare D1 workflow。以下是操作骨架，正式命令與 flags 以 Cloudflare D1 docs 和 Wrangler 版本為準。

1# Example shape only. Use your project naming and official Wrangler docs.
2wrangler d1 create sqlite_edge_preview
3wrangler d1 execute sqlite_edge_preview --file=seed.sql
4wrangler d1 execute sqlite_edge_preview --command="SELECT COUNT(*) FROM accounts;"

D1 preview evidence 要記錄：

若 seed file 太大或某些 SQL 需要改寫，就把 gap 寫進 compatibility matrix，先保留 production migration 的審查邊界。

Import to Turso Preview

Import to Turso preview 的核心責任是驗證 remote database、client SDK 與 embedded replica 行為。以下是操作骨架，正式命令以 Turso docs 與 CLI version 為準。

1# Example shape only. Use your org, group, region and official Turso docs.
2turso db create sqlite-edge-preview
3turso db shell sqlite-edge-preview < seed.sql
4turso db shell sqlite-edge-preview "SELECT COUNT(*) FROM accounts;"

Turso preview evidence 要多記 replica freshness。若使用 embedded replica，測試流程要包含 bootstrap、sync、read query、write delegation 與 sync 後 read。

1embedded replica evidence:
2  bootstrap duration
3  first read latency
4  write path
5  sync command / interval
6  read freshness after write

Freshness 是 product decision。若 query matrix 只測 remote primary，仍需要追加 embedded replica 的使用者體驗驗證。

Compatibility Matrix

Compatibility matrix 的核心責任是把 local SQLite 與 edge target 的差異留下來。建議表格欄位如下：

Decision 欄要寫具體下一步。rewrite workflow 代表 application adapter 要改；split batch 代表 migration runbook 要改；map error 代表 repository error classification 要改。

Latency and Cost Sample

Latency and cost sample 的核心責任是避免只看功能相容。Edge SQLite migration 的收益常來自 region latency 或 managed operation，因此 preview 要量測主要使用者區域的 read / write latency。

最小量測：

1. Local baseline latency。
2. Preview target read latency。
3. Preview target write latency。
4. Error rate / retry count。
5. Estimated request / storage / egress cost。

Latency sample 要搭配 freshness。快速讀到舊資料和稍慢讀到最新資料是不同產品體驗；query matrix 要標註哪個 workflow 可以接受 stale read。

Rollback Route

Rollback route 的核心責任是保留 local SQLite 退路。Preview lab 完成後，要能刪除 preview database、保留 local seed、重跑 local app。

1sqlite3 app.db "PRAGMA integrity_check;"
2sqlite3 app.db "SELECT COUNT(*) FROM accounts;"
3sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"

正式 cutover 的 rollback 還要處理 target-only writes。Preview 階段應避免讓真實使用者寫入 target；若需要 shadow traffic，先用 read-only 或 synthetic write。

Completion Note

Completion note 的核心責任是決定是否進入正式 migration。Lab 完成後應輸出四個 artifact：seed.sql、import log、compatibility matrix、rollback note。

進入正式 migration 的條件：

1. Query matrix 主要 workflow 通過或已有 rewrite plan。
2. Platform limits 對資料量與 migration time 可接受。
3. Error mapping 已接到 repository adapter。
4. Freshness / latency 符合產品需求。
5. Export / rollback route 已演練。

完成本篇後，回到 SQLite to D1 / Turso Migration 補正式 phase plan。