TL; DR
ナイスな導入
そうそれ。
ただ、場合によってはマネジメントコンソールではなく、設定ファイルからリソースを一括で自動作成する方が早いこともあるんだよ。
さらば憂鬱すぎるやり直し作業
ああああ…… CloudWatch で監視設定したら、アラーム名をタイポしてしまった……。
一度設定したアラーム名はもう変更できないから、もう一度はじめからやり直しになっちゃう……。
ドジっ子さんめ。 再作成が1つや2つならいいけど、10個、20個になるとキツいね。
マネジメントコンソールの GUI をチマチマ操作する作業を何十回も繰り返すのは切ない。
なるほど!
エクスポートした設定はどんな形式になるの?
それはすごい。
まさしく僕が求めていたものだ。
Former2 は、サードパーティ製ツール
必要なのは、ReadOnlyAccess ポリシーを持つ IAM ユーザ
Former2 はものすごく直感的に使えるので、改めてここで手順を説明するほどでもないんだけど、注意点が2つあるんだ。
一つはリージョンを間違えないこと、そしてもう一つは実行用の IAM ユーザを用意する必要があること。
スタックを削除すると、作成したリソースも道連れになる
それを消すと、リソースも一緒に消えるよ。
もし、スタックを消してもリソースを残したい場合は、設定ファイルのリソースのところに DeletionPolicy 属性を明示的に設定しないとダメだよ。
AWSTemplateFormatVersion: '2010-09-09' Resources: myS3Bucket: Type: AWS::S3::Bucket DeletionPolicy: Retain
設定ファイルにはインスタンス ID とかがベタで書かれていたりするので、いまいち長持ちしない気がするけどね。
もともと手作りしたリソースだったら、DeletionPolicy 属性を Retain にして、スタックは消しておいた方が地球に優しいと思う。
今日のまとめ
既存のリソースをエクスポートしたいときは Former2 を使おう。
マネジメントコンソールで同じ設定作業を何度も繰り返しているなーと思ったら、自動化を検討した方がいいね。
単純な定型作業はできるだけ自動化して、僕たちは開発に集中したいよね。
それでは今日はこの辺で。