AWSに限らずクラウドインフラの構築において、IaCは必須ツールになっています。今回は、TerraformとCloudFormationの使い分けの一例を紹介していきます。TerraformとCloudForamationどちらにしようか悩んでいる方、または、IaCをどれにしようか悩んでいる方の参考になれば幸いです。
社内でのTerraformとCloudFormationの使い分け紹介
私の社内では、AWSリソースはTerraformとCloudFormation両方使って管理しています。使い分け方は、以下の通りです。
- Terraform：システムで利用するAWSリソースを管理（ECS, EC2, RDS, VPCなど）
- CloudForamation：アカウント管理系のAWSリソースを管理（IAMUser, CloudTrail, S3(CloudTrailログ用), Organizations）
サービス提供・アプリケーションが乗っかるインフラ周りはTerraform、アカウント管理はCloudFormationで管理しています。
使い分けるようになった背景
もともとは、CloudFormation一本ですべてのAWSリソースを管理していました。社内では、AWSアカウント管理者（AdminUser）と開発者（PowerUser）で分かれており、アカウント管理者はIAMUserの作成やAWS自体の管理を行います。開発者はアプリケーション開発に必要なインフラを試しで作ったりしていました。
ある日、アカウント管理者が開発者が作成したCloudFormationテンプレートを削除してしまう事件が起きてしまいました。開発環境だから何とかなった話ですが、本番環境でも起りうる可能性があるとのことで、IaCを使い分けるということになりました。
メリット
- 各IaCで役割が明確に分離されたので管理者と開発者の間で混乱が少なくなった
- 管理者と開発者がそれぞれ管理しているリソースを間違えて削除するようなことがなくなった
デメリット
- アカウント管理と開発両方している人は、CloudFormationとTerraform両方の仕組みを理解する必要がある
- 手順書を作成する場合は、TerraformとCloudFormation両方必要になる
TerraformとCloudFormation使い分けてみての感想
現在は、問題なく運用できている印象です。個人的なイメージですが、Terraformはインフラ変更に柔軟に対応できる印象です。例えばインフラ変更するときplan実行することでDryRunを走らせることができ、変更内容を簡単に（わかりやすく）表示してくれます。さらに、既存インフラのインポートも用意です。一方、CloudFormationはインフラの変更自体はできるのですが変更セットを用意する必要があるので、少し面倒なイメージを持っています。また、1ファイルでコンポーネントをまとめていると後からファイル分割が難しいことがあります。
このことから、インフラ構成が変わる可能性のある、インフラはTerraformで構築するのが向いているのかなと感じてます。また、IAMUserなど一回作ってしまえばあとは変更することのない（または変更頻度が少ない）はCloudFormationで作成するのが良いのではないかと思います。
CloudFormationのメリットは、新規機能の反映の速さだったり、AWSサポート対象だったりほかにもいろいろありますが、我々の社内では上記のように使い分けています。
おわりに
TerraformとCloudFormationの使い分けについて記載しました。最終的には社内の要件に合わせて選定する必要があると思うのですが、Terraform、CloudFormationどちらも記載できるようになるので今回紹介した使い分けもありかなと思ってます。
そのほかにもCDKを利用している方もいるので、選定項目に入れて検討してもらえればと思います。
コメント