"Iac"
- IaC 工具選型與 state 地基
Terraform / OpenTofu / CDK / Pulumi 的選型判準，state 作為 IaC 工具對現實的唯一記憶，以及 remote state backend 的自管與託管路線
- Infrastructure as Code (IaC)
用程式碼描述基礎設施的最終狀態，由工具負責收斂現實與描述的差異
- 手動環境的可控底線與納管準備
還沒有 IaC 的環境怎麼守住底線、讓變更可追溯、降低未來納管成本，以及辨識何時該開始導入 IaC
- 從單一環境到環境分離：infra 需求的浮現過程
單一 EC2 + RDS 的結構在需要測試環境、多人協作時會撞到哪些操作極限，以及環境分離怎麼牽出身分、網路、變更流程等後續 infra 關注點
- 部署順序與資料庫上 IaC
核心服務的依賴圖決定部署順序，資料庫作為第一批上層服務需要最謹慎的 IaC 描述 — 涵蓋 RDS 接線、連線管理、read replica 與端點暴露
- 環境分離與模組化 — 目錄結構、module 參數化與 retrofit 路徑
用目錄結構在第一天就隔開 dev 與 prod 的 state，用 module 讓環境共用同一套邏輯只差參數，以及已經單環境跑起來後怎麼安全拆分
- IaC plan、apply、drift 與 recovery 流程
說明 Terraform / Helm / Pulumi 等平台變更 CI/CD 如何用 plan review、state lock、drift detection 與 recovery gate 控制風險
- Dotfile 跟 Infra IaC 的平行關係
想理解 dotfile 管理在工程實踐裡的定位、或釐清「重建指令」跟「備份」的差異時回來讀
- Console 唯讀鐵律與最小可行資源集合
Console 只用來看不用來改的操作紀律、drift 的延遲浮現與偵測，以及能跑出第一個完整 apply 迴路的最小資源集合
- infra 的責任邊界、成熟度階梯與 day 1 鐵律
基礎設施承擔五個面向的責任，每一面都有獨立的失效模式；成熟度階梯用來對齊現況而非追求滿分，day 1 鐵律則劃出早期團隊該優先鋪的地基
- 運算平台上 IaC — ECS 與 EKS
容器運算平台的 IaC 描述：ECS 與 EKS 選型、task definition 與映像版本解耦、IAM task role 分離、auto-scaling 策略
- 斷網環境的 IaC
Terraform provider mirror、離線 plugin cache、本地 state backend、沒有雲端時的 plan/apply 流程與內網 CI
- Drift（設定漂移）
IaC 的 state 與雲端實際狀態之間的不一致，通常因為有人繞過 IaC 直接在 Console 改設定
- 儲存上 IaC — S3 bucket 的安全與生命週期
S3 bucket 的加密、版本控制、公開存取封鎖、生命週期規則、bucket policy 與事件通知怎麼寫進 IaC，讓儲存的安全與成本防線可審查可追蹤
- 入口上 IaC — ALB、TLS 與健康檢查
Application Load Balancer 的 listener、target group、健康檢查閾值設計，以及用 ACM 把 TLS 憑證的簽發、驗證與掛載整條鏈寫進版本控制
- Stateful 資源保護與跨服務依賴表達
stateful 資源的保護策略（multi-AZ、備份、刪除保護）、stateful 與 stateless 的操作差異，以及用 output 與 data source 表達服務間依賴
- Infrastructure Drift
說明真實基礎設施狀態與 IaC 宣告分叉時的偵測、判讀與修復責任
- State Lock
說明 IaC apply 如何用狀態鎖避免併發變更覆寫基礎設施狀態