前面的篇章著重在營養domain、公式設計與計算，以及怎麼讓 AI 讀懂使用者描述的飲食習慣——但把規則訂下來之後，接下來要面對的是另一個問題：這些邏輯要放在哪裡跑? 要怎麼存取得生成的結果? 也就是”如何實行”的部分，因此接下來會把焦點從「營養邏輯」延伸到「系統實作」。
所謂「雲端」，白話一點來說就是跟”雲端服務商”（例如AWS、GCP、Azure等等）租用一台電腦，而電腦的各種配備跟運算資源都可以任意選擇/更換。舉例像是伺服器、儲存空間，至於電腦硬體的維護、電力、故障排除等等都將由廠商負責，而這台電腦會是24小時不間斷運轉，使用者唯一需要做的就是選好配備後，透過網路連上遠端的伺服器，即可享有服務。
這麼一來，”雲端伺服器”跟”本地端伺服器”的差別就顯而易見了。
如果是用本地端伺服器，也就是自己買一台主機、或直接用自己的電腦當伺服器，硬體、電力、網路、備援統統要自己顧，機器關掉或斷線，服務也就跟著斷了，甚至如果想用一些比較高級的顯卡，或者更高階的配備，還得自行課金QQ。
由於這個專案的流量大概是”偶爾打一下”的等級，如果自己顧一台機器 24 小時開著，還要連環境設定、系統更新、當機重啟這些部署瑣事都要自己扛，我覺得不划算~而且以成本來說，AWS Serverless 的計費邏輯是「有人呼叫才算錢」,平時沒人用幾乎是 0，機器本身也完全不用自己碰，正好符合我的需要。最後重點是，這次專案的目的之一就是想透過實作多接觸AWS Cloud，因此~就決定上雲啦!
決定要上雲端之後，我原本以為這個專案頂多用到 Lambda 跟一個資料庫。實際做完一輪才發現，光是「把一個網頁跟一支 API 送上雲端」，就串了這麼多服務：
| 服務 | 在這個專案裡負責什麼 |
|---|---|
| Amazon S3 | 兩個角色：① 存放前端打包後的靜態檔案 ② 存放 Food DB 的 foods.json（跟 Lambda 程式碼解耦，之後加資料不用重新部署） |
| Amazon CloudFront | 前面掛一層 CDN，把 S3 裡的前端變成一個可以公開分享的網址 |
| Amazon API Gateway | 對外的單一入口，把 HTTP 請求轉發給 Lambda |
| AWS Lambda | 真正的後端邏輯：固定公式計算、呼叫 Bedrock、組裝回應 |
| Amazon Bedrock | AI 的部分：理解自由文字、生成菜單 |
| AWS IAM | 管兩種身份：一個是我自己拿來部署用的 IAM 使用者，一個是 Lambda 執行時用的 Role（授權它呼叫 Bedrock、讀 S3） |
| Amazon CloudWatch | 集中收 Lambda 的 log，雲端跑起來出問題時唯一能看到「發生了什麼事」的地方 |
| AWS SAM | 不是執行期服務，是部署工具——用 template.yaml 描述上面這些資源，一個指令建立/更新整套架構 |
| AWS Budgets | 帳單守門員，超過設定金額寄信通知，避免不小心燒錢 |
簡單說，Serverless 就是把「養一台電腦」這件事外包出去。你不用管背後有沒有一台機器在待命、系統好不好、要不要更新，只要把程式碼交出去，有人用的時候它才被叫醒執行，做完事就休息——有點像叫計程車：車子平常停在哪、有沒有保養好都不是你的事，你只有在真的搭車那段時間才付錢。前面提到的「有人呼叫才算錢」，講的就是這個道理。而雲端服務其實不是每種都這樣（像 EC2 就是租一整台電腦給你自己顧），這次選的剛好都是「不用自己管機器」的這種。
上述表格裡的服務就是「Serverless」具體落地後的樣子，單獨看每一個服務，規則都不複雜，真正重要的反而是把它們串在一起，例如誰能呼叫誰(權限)、誰的輸出接誰的輸入(資料流)，只要漏一個環節，整條路徑就打不通。
接下來幾篇，會來介紹這些服務，以及我是怎麼使用的。
iThome鐵人賽
看影片追技術