IaC（Infrastructure as Code）としてAWSではCloudFormationを利用して
インフラのプロビジョニングを行うことがある。
Githubなどで公開されたyamlを利用することで簡単に
AWSのインフラサービスが使用可能な状態（セキュリティグループ設定、IAM設定、バッチ処理（Lambda））になっていたりする。
今回Githubなどで公開されたyamlをベースに追加のリソースや設定の追加を行う際に
特に考えずともインフラが払い出せてしまい、カスタマイズやチューニングする際に
CloudFormationに書かれていることを解読する羽目になり、
シーケンス図を記載したりしながら依存関係を洗うこととなった。
こんな大変なら
全部手書きできるほうが早いじゃんと思ったので
まずIaC化に対する目的から整理し、道具に使われてしまうSEが減ることを願って
足跡を残していこうと思う。
IaC（CloudFormation）の目的を整理してみた
①自動化することで、人件費を削減したい
②自動化することで、人為的なミスを減らし、担当者の負荷を下げたい
③インフラの管理コストを削減したい
環境の再構築時を自動化でき、
コード自体が環境のバックアップとなる。
また、Gitなどを用いたバージョン管理により、Excelなどに比べ管理しやすい
GUIで作っちゃった環境も
Former2を利用すれば、既存環境のリソースに合わせた設定値のテンプレートを作成することができる
https://former2.com/
CloudFormationだけでなく、TerraformをはじめとしたOutputsを無料で提供しているため、
IaCを何時からでも始めることはできる。
ここで一つ問題が発生する。
Former2で作成するテンプレートには環境固有値（IamgeID）が入ってしまうため、
バックアップには使用できる＆10分以内に作成できるが、
テンプレートとしてプロビジョニング用途には使用ができない。
そこでCloudFormationの書き方を勉強することになった。
CloudFormationの書き方は以下を参照
https://dev.classmethod.jp/articles/cloudformation-beginner01/
結論
書きなれていなければ、GUIで考えながら作ったほうが圧倒的にデプロイは早い（と思う）
ただ、品質や再現性、管理工数を鑑みるにIaCテンプレートを作成したほうが良い場合もある。
どれだけテンプレートを作成したとしても、使う人間が考えずに使用すればまた道具に使われてしまうだけなので
目的と運用の立て付けが必要だと感じた。