前言

終於來到最後一篇啦 🎉
從 Day1 開始，我們一步步探索 Cloud Native：先理解概念，再學 SDK、CDK、CI/CD，接著實作 Cognito、API Gateway、Lambda、DynamoDB，最後組合起來。

今天，就是展示我們 30 天努力的成果。
我會帶你看完整的架構圖，介紹專案 Repo，並進行一次完整 Demo。最後，談談這個專案的限制與未來展望，為這趟旅程畫下句點。

系統架構圖

在進入 Showcase 前，先來看看我們最終完成的架構圖。

這張圖清楚描繪了整體設計：

• 使用者登入 (Cognito) → 提供身分驗證與 JWT Token。
• 前端 (Amplify / React Demo) → 串 Cognito Hosted UI，管理登入狀態。
• API Gateway → 充當入口，驗證 Token，分派請求。
• Lambda → 負責業務邏輯，與資料庫互動。
• DynamoDB → 採單表設計，集中管理專案、成員與事件。
• CI/CD (GitHub Actions + CDK) → 自動化部署整個架構。

專案 Repo

如果你想實際操作，可以參考這個專案的程式碼：

👉 GitHub Repo - Cloud Native Demo Project

Repo 內容包含：

• 前端程式碼：支援本地端 (localhost) 測試，透過 Cognito Hosted UI 登入。
• 後端程式碼：CDK 定義的 API Gateway + Lambda + DynamoDB。
• CI/CD Workflow：GitHub Actions 自動部署設定。

只要依照 README 設定 IAM 與環境變數，就能跑起來。

Demo Showcase

使用者登入

專案管理

行事曆編輯

30天過去了，我們學會了甚麼？

1. Stateless (無狀態)

雲原生強調 服務應該盡量無狀態，讓系統可以彈性擴展、自由調度。
在這個專案裡，使用者的狀態並不是存在伺服器記憶體，而是透過 Cognito 的 JWT Token 來攜帶。

2. Event-Driven (事件驅動)

在雲原生系統裡，事件通常比請求/回應更重要。
雖然我們的 Demo 主要透過 API Gateway 呼叫 Lambda，但其實同樣的 Lambda 也能被 S3 上傳事件 或 DynamoDB Stream 觸發。

3. Infrastructure as Code (IaC)

雲原生的一個基礎原則是 自動化基礎建設。
我們不是手動在 Console 上點來點去，而是用 AWS CDK 把 API Gateway、Lambda、DynamoDB 這些資源寫進程式碼，並透過 CI/CD 自動化部署。

4. Cost Awareness (成本意識)

雲原生不只是技術選型，也包含 隨需付費的思維。
在這個專案裡，我們選擇 Serverless 架構（Lambda、DynamoDB On-Demand），這代表不用考慮伺服器維護成本，也不用擔心低流量時的浪費。

5. Observability (可觀測性)

一個雲原生系統如果「看不到內部狀態」，就不可能維護。
因此 可觀測性 (Observability) 是雲原生很重要的一環。
在這個專案裡，我們透過 CloudWatch 集中管理：

• Log Group & Log Stream：每個 Lambda 的輸出會被集中在 CloudWatch Log Group。
• Metrics：例如 Lambda 的執行次數、延遲時間。
• Dashboards：可以視覺化系統健康狀態。

成果與展望

在過去三十天的部件實作之上再加上一些 UI/UX (AI 都做得很好)
前端能流暢地呈現登入與操作體驗，後端則透過 Cognito、API Gateway、Lambda 與 DynamoDB 串接，真正支撐起一個多人協作平台的基礎。

對我來說，最大的收穫是證明了雲原生應用並不需要龐大的團隊或昂貴的成本，Free Tier 也能做出實用的系統。

未來，這個專案完全可以延伸：

• 擴展更多協作功能（通知、日曆整合）。
• 加上事件驅動架構（EventBridge / SQS）。

希望這樣一個簡簡單單但已經算是完善的小小專案能啟發更多人踏出第一步。

結語

30 天的系列文章，從基礎概念到完整專案，帶我們實際體驗了 雲原生的設計思維。
這不只是一次技術堆疊，而是一趟學習旅程。

希望這個專案能啟發你，無論是學習 AWS、雲原生，或是打造自己的 Side Project，都能更有方向。

謝謝你陪我走完這 30 天 🚀
我們雲端再見！