なぜIaCが必要なのか、実務で理解した話
はじめに
最近では CloudFormation や Terraform などの IaC（Infrastructure as Code）が広く利用されています。
AWS 学習を始めた頃の私は、CloudFormation の存在を知ったときにこう思いました。
AWS コンソールでリソースを作成できるのに、なぜわざわざテンプレートを書く必要があるのだろう？
実際に使うようになってからは、考え方が大きく変わりました。
今回は、私自身の経験をもとに、IaC の必要性やメリットについて紹介します。本記事は CloudFormation を中心に書いていますが、Terraform など他の IaC ツールにも通じる考え方だと感じています。
最初は CloudFormation の必要性が分からなかった
AWS を学び始めた頃は、コンソール操作でリソースを作成していました。
EC2 や S3 などは数クリックで作成できますし、画面も分かりやすいため、特に不便を感じていませんでした。
そんな中で CloudFormation というサービスを知りました。
しかし、最初にテンプレートを見た感想は、
- YAML が長い
- 覚えることが多い
- コンソールの方が簡単そう
というものでした。
正直なところ、
コンソールで作れるのに、なぜこんな複雑なものを使うのだろう
と思っていました。
テンプレート作成よりもエラー修正が大変だった
実際に CloudFormation を触り始めると、さらに苦手意識を持つようになりました。
テンプレートを書いても、
- プロパティ名の記述ミス
- リソース参照のミス
- パラメータ設定の不備
などでスタック作成に失敗することがあります。
当時はエラーメッセージを見ても原因が分からず、半日以上かけて修正したこともありました。
そのため、
IaC は便利と言われているけれど、学習コストが高すぎるのでは？
と感じていました。
この「テンプレートを書くまでのハードル」の高さは、今でも初学者が IaC に踏み込むうえでの大きな壁だと思います。私自身も、あのときの経験が、後に CloudFormation を GUI で組み立てられる学習支援ツールを個人開発するきっかけのひとつになっています（末尾の「おまけ」で紹介しています）。
業務で初めて IaC の価値を実感した
考え方が変わったのは、検証環境のコスト改善を行ったときです。
検証環境では、
- Application Load Balancer（ALB）
- NAT Gateway
- Interface VPC Endpoint
などのリソースを利用していました。
これらは利用していなくても一定の料金が発生します。ALB や NAT Gateway は時間課金のため、検証作業をしていない夜間や週末にもコストが積み上がっていました。
そこで CloudFormation を利用し、
- 検証開始時に環境を作成
- 検証終了後に環境を削除
という運用に切り替えました。
[検証開始] → スタック作成（ALB / NAT / VPC Endpoint などをまとめて構築）
[検証作業] → 通常の検証・開発
[検証終了] → スタック削除（関連リソースをまとめて削除）
結果として、
- 環境構築の手間を削減
- 検証環境のコスト削減
の両方を実現できました。使わない時間帯の課金を抑えられるようになった実感もありました。
このとき初めて、
CloudFormation は単なる自動構築ツールではない
と感じるようになりました。
「AWS 環境をバージョン管理できないか？」という質問
さらに印象的だったのが、
AWS 環境そのものをバージョン管理できないか？
という話が出たときです。
コンソール中心で構築している場合、
- 誰が変更したのか
- 何を変更したのか
- 以前はどのような設定だったのか
を追跡するのは簡単ではありません。
一方で CloudFormation を利用していれば、テンプレートを Git で管理することで、
- 変更履歴の確認
- レビュー
- 差分管理
- ロールバック
が可能になります。
ここで初めて、
インフラもコードとして管理する
という IaC の考え方を理解できました。
現在感じている IaC のメリット
実際に利用するようになった現在は、次のメリットを強く感じています。
1. AWS 環境を資料として残せる
CloudFormation テンプレートを見るだけで、
- どのサービスを利用しているか
- どのような構成になっているか
を把握できます。設計資料としても活用できるため、環境の可視化に役立ちます。
2. 環境を再現できる
同じテンプレートを利用することで、
- 開発環境
- 検証環境
- 本番環境
を同じ構成で作成できます。環境差異によるトラブルも減らしやすくなります。
3. Git で管理できる
アプリケーションコードと同じように、
- 差分確認
- レビュー
- 履歴管理
を行うことができます。
4. 不要な環境を簡単に削除できる
検証環境などは、スタック削除だけでまとめて削除できます。リソースの削除漏れ防止やコスト削減にもつながります。
おわりに
CloudFormation を初めて見たとき、私は
コンソールで作れるのに、なぜこんな複雑なものが必要なのだろう
と思っていました。
しかし実際に利用してみると、IaC の本当の価値は自動構築だけではなく、
- 再現性
- バージョン管理
- ドキュメント化
- コスト最適化
にあると感じています。
もし今、
「コンソールで十分では？」
と思っている方がいたら、私も同じ考えだったことを伝えたいです。実際に使うことで、IaC の価値が見えてくるかもしれません。
おまけ
私は現在、CloudFormation を GUI で作成できるツール を個人開発しています。
S3 や CloudFront などの設定をフォーム入力で作成し、CloudFormation テンプレートを生成できるようにしています。テンプレートの記述ミスやプロパティ名の試行錯誤に時間を取られがちだった頃の自分に、少しでも届くツールにしたいと考えています。
現在は試験公開中で、どのような機能が役立つかを検証しています。
もし興味があれば触ってみていただき、感想をいただけると嬉しいです。