問題情境
最近測試 ECS auto scaling，capacity provider 為 EC2 instance，service auto scaling policy 為 ALBRequestCountPerTarget，於是用 Locust 壓力測試，然後檢查 task 數量是否增加。
Locust 打高 Request 之後 task 確實增加了，但是有一個 task 卡在 provisioning 狀態，依照 EC2 instance 和 task 的 vCPU 和 Memory 數量來看，確實塞不進已有的 EC2 instance，而是應該加開 EC2 instance，但等了老半天都沒加開，task 也跟著 timeout 導致 stop。
解決
在拼命檢查 ECS capacity provider、service 和 ASG 後，發現 ASG 的 CapacityProviderReservation 相關的兩個 alarm 竟然顯示 Insufficient data，仔細看發現該 alarm 的 ClusterName 和 CapacityProviderName 完全沒對上，八成是之前打錯字導致的。
於是移除 ASG、ECS service 和 capacity provider 並重新建立，這下 alarm 正常運作了。
會移除 service 是因為原本沒移除的情況下直接更改 capacity provider，發生沒跟 ASG 連結的問題（發現 ASG Lifecycle hook 為空），索性砍掉重練解決問題。
原理
讓 ECS auto scaling 去控制 ASG auto scaling 的情況下，AWS 會自動建立四個 alarm：
- 其中兩個是 service track 的 metric，例如我 auto scaling policy 是 ALBRequestCountPerTarget 5000，那 AWS 就會建立
TargetTracking-service/{cluster name}/{service name}-AlarmLow-xxx和TargetTracking-service/{cluster name}/{service name}-AlarmHigh-xxx兩個 alarm，告警時 scale out/in。 - 另兩個是 ASG 的 CapacityProviderReservation alarm，
TargetTracking-{asg name}-AlarmLow-xxx和TargetTracking-{asg name}-AlarmHigh-xxx，CapacityProviderReservation 這指標 AWS blog 講得超詳細，簡單說就是 AWS 用來判斷要不要 scale out/in EC2 instance 的指標，該 alarm 就是 metric 大於或小於 100% 時會告警並 scale out/in。
這次正是因為 CapacityProviderReservation metric 沒資料導致 alarm 沒動作，才會出現沒開 EC2 instance 的問題。
附帶一提，這些 alarm condition 的幾分鐘內幾個 datapoint 都是 AWS 預設的，無法更改。有人提出 request 已經是 2019 年的事了。
結論
文件沒看清楚的下場就是 debug 超久！
以及，
人生苦短，我用 Terraform。
說真的 ECS 要設定的東西實在太多了，用 Terraform 建了什麼資源看得明明白白。要不是公司專案，我鐵定選擇紅燒牛腩 Terraform。