🔹 前言

⚠️ 提醒：這篇文章是完整的雲端環境評估記錄。
內容會涵蓋成本試算、安全權衡、部署方式等細節，屬於「實務考量」的展開。本文適合「想控制雲端成本」且「熟悉 AWS/Cloudflare 基礎」的讀者。如果只是想快速驗證功能，直接用 Vercel/Zeabur 更快。如果是雲端新手，建議先熟悉基礎後再閱讀。

既然這個系列放在 DevOps 分類，沒有搬到公有雲感覺就少了那一味 🥳。

所以把功能在本機跑通（Day27）後，今天我們會進入最容易「燒錢」也最常被忽略的環節：雲端環境評估。我會用最小可行（但安全）的方式，把 Demo 架構搬到雲上：

• 計算 EC2/Redis/S3 等 AWS 成本、用 Cloudflare（Access + Worker + Tunnel） 做邊緣驗證與反向代理
• 搭配 GitHub Actions 部署與 Grafana Cloud 監控。
• 是把「認證、限流、CORS」前移到 Edge，大幅簡化基礎建設、壓低總持有成本，同時保留未來切換到 ALB/WAF 的升級路徑。

今天的內容會是架構評估與成本試算，明天（Day29）則是實際部署以及處理入口安全性。

本文所有價格以 2025/09–10 的官方定價為準，文末會標註我的假設與取捨。

系統架構圖（System Architecture Diagram）

🔹 費用/成本評估

在上生產線實戰環節，我會分成五個表格來羅列可能會花費的成本，分別是：AWS、Cloudflare、GitHub、Grafana Cloud 以及 OpenAI。這份表格的有效性建立在 2025 年 9 ～10月的期間，如果後續有人看到這篇文章與實際上的價目表有出入，請自行查找官方文件，以免造成費用損失。

我是部署在東京區域，以東京區域（ap-northeast-1）為準，通常北美區域的定價會是最便宜的。我這個 AWS 帳號是在 2025 年 8 月辦的，所以只有 6 個月 Free Tier / $100 Credits 可以折抵。

☁️ AWS

🌐 Cloudflare

🐱 GitHub

📊 Grafana Cloud

🧠 OpenAI

💰 總成本評估：

AWS：

OpneAI :

整體合併成本（含 OpenAI Token）

🔹 用 Terraform 在 AWS 建立 Infrastructure 資源

本專案使用到的 Terraform IaC 程式碼也會放在 GitHub，有興趣的讀者可以拉下來研究。

⚠️ 這邊請絕對要自己去查 Free Tier 的區域和額度！實務上建立資源都很快，很多時間都是花在事前的評估和 Infrastructure 費用計算，因為 AWS 的 Free Tier Policy 有可能會變。

EC2 能支援 gp3 的 20 GB 免費不代表可以支援 RDS 的 gp3 的 20 GB，而且有沒有獨立計入 Free Tier 也要留意。

另外還有一個容易忽視的成本就是 AWS 的網路費用，特別是 egress 出網費用以及 AZ 之間的網路流量費用。所以這個 Demo 架構會把資源都放在同一個 AZ，我們先犧牲高可用換來節省費用。

• ✅ VPC（Default VPC）
• ✅ Public Subnet x 1
• ✅ Private Subnet x 2 (Required by ElastiCache)
• ✅ Route Table + IGW（出網）
• ✅ EC2（t4g.medium, Amazon Linux 2023, 15GB gp3）+ IAM Role + SSM
• ✅ Security Group (EC2 / ElastiCache)
• ✅ Secrets Manager * 2 (App / ElastiCache)
• ✅ ElastiCache for Redis（Single AZ, Redis7.0）

AWS Infrastructure 架構圖

建立好所有 Infra 資源之後，確認一下 ec2 instance 能夠順利連線到 RDS Instance 以及 ElastiCache Instance。順便把 Budgets 設定好，不然哪天設定錯誤帳單下來會哭 🫠

AWS Budgets Dashboard

🔹 簡單撰寫後端 API，並搞定 GitHub CI/CD

Infra 資源都建立好之後，接下來的工作就是撰寫簡單的後端 API。

如果要串 GitHub CI/CD 這邊要先做幾件事情：

• 建立 GitHub OIDC Provider
• 一個專用的 部署 IAM Role : 限制 repo/分支可以 AssumeRole
• 最小必要權限：ssm:SendCommand、ssm:List*、ec2:DescribeInstances
• 輸出 deploy_role_arn：放在 Actions Secrets 的 AWS_ROLE_TO_ASSUME
• 因為 GHCR 是 private 的關係，稍後會需要在 Secrets Manager 存一把 PAT（read:packages）
• 確保 EC2 的 Instance Role 可以讀到上面的 Secret
• 申請 GitHub PAT（classic），並且填入上面建置好的 secret

接下來確認一下能夠把後端程式碼打包以及推到 ghcr.io，目前結構長這樣，要透過 GitHub Workflow 打包推送 ：

.
├── README.md
├── backend
│   ├── Dockerfile
│   ├── app
│   │   └── main.py
│   └── requirements.txt
└── frontend
└── index.html

第一次打包會比較久是正常的

接下來要把打包好的 Image 部署到 EC2 上面，我們要先把以下值存到 GitHub Repo 的 Repository Secrets:

• AWS_ROLE_TO_ASSUME（gha-deploy-ssm 的 Role ARN）
• EC2_INSTANCE_ID（EC2 ID）
• GHCR_SECRET_ARN（Secrets Manager 裡存 PAT 的 ARN）

寫好部署腳本和 GitHub Workflow 之後，可以在 deploy 的 logs console 看到：

連線到 EC2 後驗證容器確實有起來：

sh-5.2$ sudo docker ps
CONTAINER ID   IMAGE                                  COMMAND                  CREATED          STATUS          PORTS                                   NAMES
6a8d07544a34   ghcr.io/hazel-shen/rag-qa-bot:latest   "uvicorn app.main:ap…"   14 minutes ago   Up 14 minutes   0.0.0.0:8080->80/tcp, :::8080->80/tcp   rag-qa-bot
sh-5.2$ curl -i localhost:8080
HTTP/1.1 200 OK
date: Sat, 20 Sep 2025 09:11:27 GMT
server: uvicorn
content-length: 35
content-type: application/json

{"message":"hello from rag-qa-bot"}

🔹 使用 Cloudflare 實作前端頁面入口認證加流量限制

如果是一般的 Demo 情況的話，當然可以自己實作認證的功能。但是實務上在後端加上這些邏輯不但會拉長交付時程，這些功能也不是專案的核心價值，所以我選擇外包給 Cloudflare。

認證這種高風險的基礎建設，如果自己實作不但容易出漏洞，交給 Cloudflare Access / Zero Trust，可以直接用 SSO、多因子驗證、細緻存取策略，安全性與合規水準都比自建高，重點是Cloudflare 免費方案真的有夠佛。

Cloudflare Zero Trust 架構圖

這邊用一張表格說明上面架構圖的元件之間的關係，以及使用到的功能：

先部署Day7 的範例前端頁面到 Cloudflare Page 上面，可以選擇匯入現有 Git：

部署完成，點開域名就可以查看頁面，要注意這邊的域名是 對外公開 的。

先拿 Day7 的 Demo 頁面來部署，結果如下：

🔑 用 Cloudflare Zero Trust 實作網頁認證

在這邊我們會需要用到 GitHub APP 作為 Cloudflare 認證的媒介：

設定好了之後可以在 Cloudflare 端測試是否串接成功：

如果不是設定條件的帳號就會登入失敗，這邊在條件設定遇到了神秘的情況，貌似只用 email 會連自己也無法登入：

解法，把 GitHub username 寫上去包含條件：

後來這個設定也可以...? 總之後面有成功。

🔹 建立 Cloudflare Worker 作為後端 API 反向代理

在前端 Cloudflare Pages 與後端 EC2 / Container Service 之間，我們不直接暴露後端，而是透過 Cloudflare Worker 做一層反向代理（Reverse Proxy）。這樣可以：

• ✅ 統一流量入口，讓 API 與前端在同一網域下工作
• ✅ 加上安全控管（CORS、Header 驗證、Access 驗證）
• ✅ 利用 Cloudflare Edge 的低延遲節點，提升體驗

為了保護我們的後端 API，會限制來源 Domain 為 https://${你的專案名字}.pages.dev 才能存取這個 URL，所以直接 curl 會得到以下結果：

❯ curl -i https://api-proxy.XXXX.workers.dev/
HTTP/2 403
...
...
...
Forbidden: invalid caller%

但是只靠 CORS 並沒有辦法防止有心人士偽造來源並存取，且 DoS / DDoS 等暴力攻擊仍然會消耗每天十萬次的免費 quota。那要如何兼顧免費又安全的需求呢？

🤝 Cloudflare Access 仍然是你最好的朋友（本文並沒有收到任何廠商贊助）

Cloudflare Access (Zero Trust) 可以在 Worker 入口 就攔截非法請求，沒帶對的 Service Token / Identity 就直接擋掉。不只可以擋掉偽造 Origin，連「根本不應該存在的請求」也不會進到 Worker。

⚠️ 此處有坑，等等會講這張圖的坑在哪...

加上 Access 之後就沒有辦法直接存取 reverse proxy 的域名了。

就是這裡 🔥
請千萬要選 Service Auth，不然你會一直卡在上面人類用的 302 轉導頁面，Cloudflare 會以為你是人類要登入。

官方文件這裡有寫：You can now configure your Access applications and device enrollment permissions to accept this service token. Make sure to set the policy action to Service Auth; otherwise, Access will prompt for an identity provider login.

Response 出現 200 就是過了。

❯ curl -i -s -o -L /dev/null -w '%{http_code} %{redirect_url}\n' \
  https://api-proxy.8qrsvmh9rs.workers.dev/ping \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
  -H "x-from-pages: $PAGES_SECRET"
...
...
...
{"ok":true,"time":"2025-09-20T13:23:28.757Z","worker":true}200

Tips：

1. Access 規則有順序，請把「Service Auth」放在最上面，避免被後面的 Login 規則覆蓋。
2. Worker 代理到後端前，先刪掉外部來的機敏 Header（如 Authorization、Cookie），只保留你要轉發的簽章或 Service Token。

到這邊比較細心的讀者可能會想說，那假設有人剛好猜中 Service Token，或是有使用者行為比較奇特，會一直拿正確的 Service Token 重複嘗試存取 Worker 的話，我要怎麼做？

明天（Day29）在實際部署的文章中，會示範如何在 Cloudflare Pages Function 實作認證以及 Rate Limit 功能。就算是內部人員，也要防止他們的應用程式亂打（筆者親身經驗😃）。

🔹 建立 Cloudflare Tunnel，打通 EC2 以及 Cloudflare Worker

首先我們要先建立一條開發通道，連上 EC2 之後安裝 .rpm 套件：

curl -LO https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-aarch64.rpm
sudo yum install -y ./cloudflared-linux-aarch64.rpm

# 打開開發通道，Cloudflare 會給你一個臨時網址
cloudflared tunnel --url http://localhost:8080

在沒有自己的網域時，可以暫時維持 Workers 的 *.workers.dev 作為固定入口，讓外部世界始終透過同一個網址存取。實作方式是把 Quick Tunnel 隨機產生的 URL 放到 Worker 的 Secret（例如 BACKEND_ORIGIN），並在每次重啟 cloudflared 後自動更新 Secret、重新 deploy Worker，如此外界只需使用固定的 https://your-worker.xxx.workers.dev。

⚠️ 不過，這種方式只是不花錢的權宜（Demo）之計：

• Quick Tunnel 本身的網址並不穩定，每次重啟都會更換。
• 後端 Quick Tunnel 若外洩，仍可能被繞過 Worker 直接存取。
• 官方定位 Quick Tunnel 只適合測試，不建議用於正式環境。

正式上線方案仍應該使用 Named Tunnel + 綁定自己的網域，並加上 Cloudflare Access / WAF / Rate Limit 等機制，才能確保連線的穩定性與安全性。

正式 / Demo 風險比較

🔹 推送測試的 Metrics 到 Grafana Cloud 上

如果是以省錢為目標的話，自然是花錢的基礎建設能夠不要自建就不要自建。剛好之前有看到 Grafana Cloud 有一些錢包友善的 Free Plan 給獨立開發者，索性直接拿來用。

登入 Grafana Cloud Portal：

不知道為什麼網站上面產生的範例呼叫會有 400 Error，改寫了一下，然後傳送測試 metrics：

# 1) 產生奈秒時間（任何環境都可）
TIME_NANO=$(python3 - <<'PY'
import time; print(int(time.time()*1_000_000_000))
PY
)
echo "timeUnixNano=$TIME_NANO"

# 2) 建 payload（注意 asInt 是數字，timeUnixNano 也是數字，沒有引號）
cat > payload.json <<EOF
{
  "resourceMetrics": [{
    "resource": { "attributes": [
      { "key": "service.name", "value": { "stringValue": "curl-demo" } }
    ]},
    "scopeMetrics": [{
      "scope": { "name": "manual" },
      "metrics": [{
        "name": "test_metric",
        "unit": "s",
        "gauge": { "dataPoints": [{
          "timeUnixNano": $TIME_NANO,
          "asInt": 1,
          "attributes": [
            { "key": "bar_label", "value": { "stringValue": "abc" } }
          ]
        }]}
      }]
    }]
  }]
}
EOF

# 3) 送出 Request
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${Grafana 給你的 instance ID}:${你的 API Token}" \
  --data-binary @payload.json \
  https://${Grafana 給你的 endpoint}}$/otlp/v1/metrics

在 Grafana Cloud Console 上面看到測試資料了 🎉

如果 API Token 沒有存到的話，可以回到一開始的 Console 頁面找 Access Policies:

或是可以在 Grafana Cloud Console 找下面這個子頁面，也可以看到一樣的東西：

Home > Administration > Users and access > Cloud access policies

🔹 選型考量以及釋疑

專案的擴展性和 Log 會留待本系列最後一天（Day30）回覆。

🤔 為什麼不選擇 AWS + WAF?

從上面的架構圖來看，不難發現我的實作其實是使用 Cloudflare (Worker + Access + Rate Limit)
去模擬 ALB (反向代理) + WAF (規則/限流) + Cognito/OIDC (驗證)。

以下從 成本、延遲、架構 三個面向說明我在模擬雲端生產環境時的取捨：

💰 成本

ALB 光是「開著不用（流量都還沒進來）」就有固定費（約 $20／月等級），再加上 WAF 基本費，每月硬成本大概 $25–$40。用 Cloudflare 實作，在流量不大時幾乎沒有固定費，能把 TCO（總持有成本，Total Cost of Ownership） 壓到很低。

⚡ 延遲

把驗證／限流前移到 Edge，能就近終止 TLS 與擋壞流量；有效請求雖多了極薄的邊緣處理開銷，但整體體感更快、更穩。

註：AWS WAF 綁在 ALB，能在 ALB 就擋下，不會到 EC2，但已進到 AWS 區域與 ALB。

🏗️ 架構

跟認證有關的設定全部都用 worker 在 Edge 處理掉、前端與 API 同域治理，可以讓環境配置更單純一些：

🤔 為什麼選擇 Secret Manger?

主要原因是因為筆者個人習慣用 Secret Manager，差異如下表，有版本 Stage 功能的話可以防止 Secret 更新後 App 直接連不到 DB 之類的連線中斷問題。如果是 Demo 之類的想極致省錢其實用 Parameter Store 也可以用。

Parameter Store vs Secret Manager

請 OpenAI 幫忙畫了一張圖（？)

🔹 小結

今天做了三件事，把「能跑」推進到「能上雲」：

1. 盤點成本：AWS／Cloudflare／GitHub／Grafana／OpenAI 的花費，圈出最小產線 Demo 的月費範圍。
2. 前移安全：用 Cloudflare Edge（Access＋Worker＋Rate Limit）取代自建認證／WAF／反向代理，在邊緣先擋壞流量。
3. 收斂架構：交付可重複使用的 最小生產化架構（同域控管、SSM 管理、指標上拋 Grafana），並保留未來切換 ALB/WAF 的升級路徑。

這篇不是「怎麼跑起來」，而是「怎麼花小錢、保留升級路徑地跑起來」。
如果想讓 Demo 更接近生產水準，Day28 就是那第一道上雲門檻。

明天（Day29） 會把 Day27 的後端透過 GitHub CI/CD 搬上 EC2，補上自動化與安全細節。

📚 引用來源文章

AWS（費用與政策）

• EC2 T 系列（含 T4g）與按需計價總覽（含 EIP 收費連結與說明）
• 公網 IPv4（含 EIP）自 2024-02-01 起一律 $0.005/小時收費公告
• EBS gp3（定價與說明；地區價格請以定價頁查詢為準）
• ElastiCache 定價（含節點等級與免費層條款；以頁面為準）
• CloudWatch 定價（內建 Metrics 免費層、付費多在自訂指標）
• Systems Manager Parameter Store（標準參數屬 Always Free 的官方說明頁）
• Secrets Manager 定價（$0.40/secret/月 + $0.05/1k API calls）
• S3 Free Tier：標準儲存 5GB / 12 個月
• AWS Budgets / Free Tier 總覽（含 Budgets 前兩個帶動作免費）
• 資料傳輸費用概念與常見架構流量收費重點（AWS 官方架構博客）

Cloudflare（Workers / Pages / Zero Trust / Tunnel）

• Workers 免費額度：每日 100,000 requests（Pages Functions 也計入）
• Pages：免費方案每月 500 次部署上限（官方文件）
• Zero Trust / Access：免費方案上限 50 位使用者（官方/社群說明）
• Access「Service Auth」政策（機器對機器；Service Token/mTLS）
• Access 應用 Token／JWT 到後端的機制
• （可選補充）在 WAF/Workers 做 Token/HMAC 驗證的官方範例

GitHub（Actions / GHCR）

• GitHub Actions 計費與免費額度（私有 repo 每月 2,000 分鐘，乘數規則）
• GitHub Free 方案一覽（含「2,000 分鐘 / 500MB Packages」）
• GitHub Packages / GHCR 計費與配額說明
• Working with the Container registry

Grafana Cloud（免費方案）

• 官方定價頁：Free 方案 10k active series / 14 天保留

OpenAI（模型單價）

• GPT-4o mini 發布與定價：$0.15 / 1M input、$0.60 / 1M output
• OpenAI 官方 Pricing 細則（總覽頁）