長期以來 CloudFormation 就不能管理「非 CloudFormation 建立」的 Resource，但是一般專案執行都是從「不熟」情況下先手動在 Web Console 點出想要的服務，等到熟悉之後才會開始玩到 CloudFormation 這類型的 IaC 服務，而同類型的 Terraform import 本來就內建了。
還在煩惱怎麼讓已存在的 Resource IaC (infrastructure as code) 的時候，AWS re:Invent 19 前幾天來了一個及時雨「New – Import Existing Resources into a CloudFormation Stack」馬上來試試看
先整理一下
CloudFormation import 「可以做」的事情
- 把現有資源 import 到「現有」 Stack
- 把現有資源 import 到「新的」 Stack
CloudFormation import 「解決」的事情
- 透過 CloudFormation 管理手動建立的資源
- 解救已經 detected drift 狀態的 Stack
- Stack 之間的資源管理遷移
CloudFormation import 的「特性」和「限制」
- 當執行 import 的動作就只會 import，並不會 Modify, Add and Remove。
- import 並不會把 Resource 的所有 Parameter 加進來，而是你有寫的才有。
- 只有寫 DeletionPolicy 的 Resource 才會觸發 import，同一個 Stack 可以有「非 import」的 Resource 存在。
- DeletionPolicy 建議設定為 Retain
- 並沒有全部的 Resource 都支援 import，參考「Resources that Support Import Operations」
CloudFormation import 的「延伸議題」
- 如果 import 後只有指定 Bucket name，但該 Bucket 有開啟 Version 等其他參數沒寫在 CloudFormation 會怎樣？
不會怎樣，當下次拿相同的 CloudFormation Update 也不會覆蓋現有 Resource 參數，因為 CloudFormation template 並無異動
- 如果我 import 把 AutoScaling DesiredCapacity 填成 2 而且還 import 成功，但實際是 DesiredCapacity 為 1，下次拿同樣的 Stack update 會發生什麼事情？
不會有任何 ChangeSet，因為是拿「同樣」的 Stack update，CloudFormation 的 ChangeSet 是看前後版本 CloudFormation 差異產生。
- 乘 2. 所以使用 import 有可能 CloudFormation 和真實 Resource 會發生不同步的狀況？
對，所以必須再透過 drift 檢查狀態是否正常。