1. AWS 原生工具 (Official AWS Tools)
這些工具與 AWS 整合度最高，通常能最快支援 AWS 的新功能。
A. AWS CloudFormation (核心引擎)
- 定位： AWS IaC 的基石，類似於組合語言。
- 語言： JSON 或 YAML。
- 特點：宣告式 (Declarative)： 你告訴 AWS 你要什麼資源，AWS 負責建立。狀態管理： AWS 託管狀態 (State)，能夠偵測設定偏移 (Drift Detection)。缺點： 語法冗長，缺乏程式邏輯（迴圈、判斷式難寫）。
- 適用對象： 喜歡穩定、不需要頻繁變更邏輯的維運團隊。
B. AWS Cloud Development Kit (AWS CDK)
- 定位： 開發者的首選，CloudFormation 的加速器。
- 語言： TypeScript, Python, Java, C#, Go。
- 特點：命令式 (Imperative)： 使用通用程式語言來寫基礎設施。高抽象化： 提供 L2/L3 Constructs (模組)，一行程式碼就能建立符合最佳實踐的 VPC 或 ECS Cluster。編譯： 執行時會編譯成 CloudFormation Template 再部署。
- 適用對象： 軟體工程師、需要構建複雜架構的團隊。
C. AWS Serverless Application Model (AWS SAM)
- 定位： 專為 Serverless 架構設計的 CloudFormation 擴充版。
- 語言： YAML (簡化版)。
- 特點：簡化語法： 定義 Lambda、API Gateway、DynamoDB 比標準 CloudFormation 簡單非常多。本地測試： 提供 sam local invoke 功能，可在本地 Docker 模擬 Lambda 執行環境。
- 適用對象： 專注於 Serverless (Lambda/API Gateway) 開發的團隊。
D. AWS Copilot CLI
- 定位： 專為「容器化應用」設計的高階 CLI 工具。
- 特點：以應用為中心： 你不需要懂 VPC、Subnet 或 Load Balancer，只需告訴它「我要部署一個 Load Balanced Web Service」，它會自動幫你建好 ECS、Fargate 和網路環境。
- 適用對象： 不想處理底層網路細節，只想快速部署 Docker 容器的開發者。
2. 主流第三方工具 (Third-Party / Open Source)
這些工具通常支援「多雲 (Multi-cloud)」，如果你公司同時使用 AWS、Azure 或 GCP，這些是更好的選擇。
A. Terraform (by HashiCorp)
- 定位： 業界標準，市佔率極高的多雲 IaC 工具。
- 語言： HCL (HashiCorp Configuration Language)。
- 特點：多雲支援： 同一套工作流 (Workflow) 可用於 AWS, Azure, GCP, VMWare 等。狀態管理： 狀態檔 (State file) 需自行管理（通常存放在 S3 + DynamoDB Lock），這點與 CloudFormation 不同。模組化： 擁有龐大的社群 Module 資源。
- 適用對象： 混合雲環境、DevOps 工程師、尋求業界標準技能的人。
B. Pulumi
- 定位： Terraform 的競爭對手，但使用通用程式語言 (類似 CDK)。
- 語言： TypeScript, Python, Go, C#。
- 特點：真．程式碼： 結合了 CDK 的開發體驗 (使用程式語言) 與 Terraform 的多雲優勢。測試： 非常容易撰寫單元測試。
- 適用對象： 想要多雲支援，但討厭寫 HCL 或 YAML 的開發者。
C. Serverless Framework
- 定位： Serverless 領域的元老級工具 (比 SAM 還早)。
- 語言： YAML (serverless.yml)。
- 特點：跨雲 Serverless： 支援 AWS Lambda, Azure Functions, Google Cloud Functions。外掛生態： 擁有極其豐富的 Plugin 生態系，可擴充各種功能。
- 適用對象： 需要跨雲 Serverless 部署，或依賴特定 Plugin 的團隊。
3. 設定管理工具 (Configuration Management)
雖然這些主要用於管理 OS 內部的軟體設定，但也常被歸類在廣義 IaC 中，或與上述工具搭配使用。- Ansible / Chef / Puppet:主要用於 EC2 啟動後的軟體安裝與組態設定（例如：安裝 Apache, 修改 config 檔）。區別： Terraform/CloudFormation 負責「生出 EC2」，Ansible 負責「設定 EC2 裡面的軟體」。
綜合比較與選擇建議
簡單結論：
- 如果您是 DevOps 工程師 且公司可能用多雲：選 Terraform。
- 如果您是 軟體開發者 且全押 (All-in) AWS：選 AWS CDK。
- 如果您只寫 Lambda/Serverless：選 AWS SAM。
補充資訊
AWS Application Composer
與AWS Serverless Application Model (AWS SAM)不是競爭對手，而是相輔相成的關係。
用最簡單的比喻來說：
- AWS SAM 就像是 HTML 語法（底層的語言規則）。
- AWS Application Composer 就像是 Dreamweaver 或 Wix（用來幫你寫 HTML 的視覺化編輯器）。
以下是詳細的差異與關係解析：
1. 本質上的差異
2. 它們如何「合作」？ (工作流程)
在實際開發中，你通常會同時使用這兩者：
- 設計階段 (使用 Application Composer):你打開 Application Composer，拖入一個 API Gateway 和一個 Lambda。你畫一條線把它們連起來。Application Composer 會在背後自動幫你寫好 AWS SAM 語法 的 template.yaml 檔案。
- 開發與部署階段 (使用 AWS SAM CLI):你在電腦上打開終端機 (Terminal)。你使用 SAM 的指令（如 sam build 和 sam deploy）來讀取剛剛 Composer 生成的那個檔案。SAM CLI 負責將這個檔案轉換成 CloudFormation 並推送到 AWS 雲端進行部署。
3. 為什麼有了 SAM 還需要 Composer？
如果你直接手寫 AWS SAM 的 YAML 檔，常常會遇到這些痛苦：
- 語法繁瑣： 縮排錯一格就報錯。
- 屬性難記： 忘記 DynamoDB 的屬性名稱是 AttributeName 還是 AttributeDefinitions。
- 權限頭痛： 忘記給 Lambda 讀取 S3 的 IAM 權限，導致部署後跑不動。
Application Composer 的價值就在於它幫你處理上述這些繁瑣的細節，自動生成正確的 SAM 語法，並自動補上缺少的權限設定。
總結
- AWS SAM 是 Serverless 的**「語言」與「部署引擎」**。
- AWS Application Composer 是用來更輕鬆撰寫這個語言的**「畫圖工具」**。
建議用法： 用 Composer 來起草架構（因為快且不具語法錯誤），然後用 SAM CLI 來測試與部署。
