手動作業からの脱却 — AWS CloudFormationのすゝめ

Tweet

こんにちは！クラウドソリューション開発部の北島です。

私が参画しているプロジェクトでは現在、AWS CloudFormationを使ってAWSリソースをコード管理しています。
当初、私はIaCをあまり知らなかったため苦戦する部分もありましたが、恩恵も大きかったため、多くの方に知ってもらいたく本ブログを執筆しました。

本記事では、以下の内容を記載しています。

•  CloudFormationとは何か — 基本概念とスタックの構成
•  導入のメリット — 再現性、バージョン管理、自動化、チーム管理、コスト管理
•  CloudFormationの使い方 — Create Stack、Change Set、Update Stackの操作方法
•  実プロジェクトでの活用例 — ECS Fargateのコンテナデプロイの事例紹介

CloudFormation導入を検討している方、「聞いたことはあるけど実際どうなの？」という方のご参考になれば幸いです。

手動操作による懸念

皆さんはこんな経験、ありませんか？

「本番環境にはこの設定があるのに、開発環境にはない」
「数ヶ月前の設定意図が分からず、触るのが怖い」
「環境を1つ構築するのに数時間かかる」
「リソースの削除し忘れで予想外の請求が来た」

AWS環境を手動でコンソール操作により管理し、複数の環境（開発、ステージング、本番等）を運用する際にはよく起こり得ますね。

こうした課題を解決してくれるのが、今回紹介する AWS CloudFormation です。

AWS CloudFormationって何？

CloudFormationの基本概念

AWS CloudFormationとは、AWSが公式で提供するインフラストラクチャ管理サービスです。

JSON または YAML形式でテキストファイルを書き、そこにEC2やRDS、S3といったAWSリソースの構成を定義します。
そのファイルを実行すれば、AWSが自動的に全てのリソースを立ち上げてくれます。

イメージとしては「Webアプリケーションのソースコードをバージョン管理するのと同じ感覚で、インフラ設定も管理する」ということですね。

スタック（Stack）という単位

CloudFormationはスタック（Stack）という単位で、関連するリソースを一括管理できるのが特徴です。

「RDS用スタック」「ECSのタスク用スタック」みたいな感じで、リソース別にまとめられます。
このスタック単位で環境全体を管理できるため、環境の作成、更新、削除が体系的に行えます。

当プロジェクトでも、リソース別にスタックを分ける構成になっています。
ただし、基盤系の細かい設定などはひとつのスタックに集約させるなど、プロジェクトの要件に応じて柔軟に調整しています。

CloudFormationの基本構成

CloudFormationを使うには設定ファイルとパラメータファイルが必要になります。

設定ファイル（テンプレート）

AWSリソース（EC2、RDS、S3など）の種類と設定を定義するファイルです。
リソース間の関連性（依存関係）も記述します。
「これを実行したら、こんな環境ができるよ」という設計図ですね。

設定ファイルはJSON または YAML形式で記述します。
この設定ファイルは環境を横断して共通で使えるように設計されます。

パラメータファイル（可変値の定義）

環境別の設定値（本番/開発環境等の切り替え）を定義します。
リソース名、インスタンスサイズなどの可変値をここに記述することで、設定ファイルの再利用性を高めます。

変動しうる値（タスク定義、インスタンスID、エンジンバージョン等）はパラメータファイルに定義することが可能です。
また、パラメータファイルを環境別に作成することで、同じ設定ファイルを使い続けられます。

例えば、同じWebアプリ用の設定ファイルがあっても、本番環境では大きめのEC2インスタンス、開発環境では小さめのインスタンス、という設定が必要だったりします。
そういう時、設定ファイルは同じで、パラメータファイルだけ切り替え可能だということです。

設定ファイルとパラメータファイルを分離することで、同じ設定ファイルを複数環境で柔軟に使用できるわけです。

CloudFormation導入のメリット

「結局、手動でもできるじゃん」と思いますよね。
でも実際に使ってみると、多くのメリットが実感できます。
ここでは5つの利点を紹介します。

1. 再現性：同じ環境を何度でも確実に構築できる

CloudFormationを使えば、本番環境と完全に同じ構成を別の環境で再現できます。

「開発環境と本番環境で設定が異なっていて、ローカルでは動いてたのに本番で動かない」という最悪のシナリオも防ぐことができます。
環境差分は意図的に作られた可変値だけになり、不本意な差分は生まれません。

2. バージョン管理：誰がいつ何を変更したか明確

インフラ設定をコード化すれば、Gitなどで変更履歴を追跡できます。

設定ファイルをGitで管理していると、設定を変更する際に「なぜこの設定がされているのか」を確認できます。

Gitログを見れば「3ヶ月前、〇〇機能対応のためにこの設定が追加された」と変更意図や背景が一目瞭然です。

手動設定では、こうした履歴が残らないため、時間が経つと「なぜこうなってるのか分からない。怖いから触らない」という属人化が生まれやすくなります。
一方、設定ファイルとコミットメッセージがあれば、新しく参画したメンバーでも過去の変更意図を理解でき、インフラの理解が格段に進みます。

3. 自動化：デプロイと環境構築の手間が劇的に減る

設定ファイルさえあれば、新しい環境の構築や既存環境の更新が自動化できます。

ソースコードのデプロイやインフラ構成の更新も、基本的にはスタック更新コマンドを実行するだけで対応が完了します。

複数のスタックを管理したり、複雑な手順が必要な場合には、スクリプトにまとめることで、より簡単に作業を行えます。

4. チーム管理：インフラ知識がチーム全体で共有される

コード化されたインフラ設定は、チーム全員が読めます。
つまり、インフラに詳しい人が1人しかいなくても大丈夫。

新しくバックエンド開発に参画したメンバーが、CloudFormationの設定ファイルを読むことで「あ、こういうリソース構成なんだ。このRDSはこのECSタスクから使われてるんだ」と数日でキャッチアップすることができます。

手動設定だと「この設定について詳しい人に聞かないと分からない」という状況になりやすいですが、設定ファイルがあれば、コードリーディングで理解できます。
インフラナレッジが属人化する問題も解消できます。

5. コスト管理：環境の一括削除が簡単

スタックを1つ削除すれば、関連する大部分のリソースが一括で消えます。

機能検証用の環境を頻繁に作ったり消したりする運用では、手動設定だと「あ、このサーバー削除し忘れた」というケースも起こり得るため、意図せぬ請求が来ることもあります。

CloudFormationなら、スタック削除で紐づくEC2、ELB、EBS、セキュリティグループなどのコンピュートリソースが自動的に削除されるので、運用の手間が大幅に減ります。

ただし、S3やDynamoDBなどのデータストレージはデータ保護のため削除されないよう設定されていることが多いため、必要に応じて手動で削除する必要があります。

CloudFormationの実際の使い方

では、このCloudFormationでどのようにリソースを操作するのでしょうか。
留意点を含め、ここではリソースの作成と更新、変更差分の確認操作について紹介します。

Create Stack（初期構築）

新しい環境を構築する時に使います。

設定ファイルとパラメータファイルを用意して実行。最初のデプロイ時のみこれを使います。
AWSが設定ファイルを読み込んで、数分後に対象リソースが立ち上がります。感動的です。

Change Set（変更差分の事前確認）

本番環境での更新は特に注意が必要です。だから、更新前にチェンジセットで変更差分を事前確認します。
チェンジセットは「このファイル変更で、具体的にどんなリソースが変わるのか」を事前に把握できる機能です。
これを使えば、予期しない変更を防げます。

まずはチェンジセットを作成します。

次に、変更差分を下記コマンドで確認します。

変更がある際は、このチェンジセット確認を必ず行うこと。
これが運用のセオリーとなります。

Update Stack（リソースの更新）

既存スタックに設定ファイルの内容を反映させます。
先ほどのチェンジセットで予期せぬ変更がないことを確認した上で更新します。

たったこれだけの作業で、リソースの操作ができてしまいます。素晴らしいです。
他にもスタックの削除やリソース一覧等の操作も行えるので、状況に応じて使い分けてください。

実プロジェクトでの活用例：ECS Fargateのコンテナデプロイ

「じゃあ具体的にどうやって活用してるんだよ」と思う方に向け、CloudFormationを活用した実例を紹介します。

デプロイの流れ

我々のプロジェクトでは、コンテナイメージをECRにpushし、CloudFormationのUpdate Stackを使ってタスク定義を更新/ECS Fargateを再起動することでデプロイを行っています。

具体的には以下のフローです：

1. 開発チームが新しいコンテナイメージをECRにpush
2. パラメータファイルにイメージURIなどを更新
3. update-stack コマンドを実行
4. CloudFormationが自動的にタスク定義とサービスを更新
5. 新しいバージョンでのデプロイが完了

この流れにより、手動でのタスク定義更新やECS再起動といった煩雑な作業が完全に自動化されました。

実際のパラメータ例

当プロジェクトでは、以下のようなパラメータで環境を制御しています。

タスク定義のコンテナイメージ更新：

このパラメータを更新してupdate-stackを実行するだけで、CloudFormationが自動的にタスク定義を更新し、新しいイメージで起動します。

サービスの再起動（タスク定義ARN指定）：

CloudFormationはパラメータ内の TaskDefinition（ARN）の差分を検知すると、ECSへ更新リクエストを送信します。
これによりECS標準のローリングアップデートが自動起動し、旧タスクから新タスクへと安全にコンテナが順次差し替え（再起動）されます。

このようにパラメータで特定のリビジョンを指定することで、ローリングアップデートやロールバックなど、細かい制御も可能になります。

パラメータ駆動型デプロイメントの利点

重要な点は、設定ファイル自体は変わらず、パラメータファイルだけで新バージョンのデプロイが可能ということです。

これにより：

• 設定ファイルは安定的に保つことができる — 本番環境の設定ファイルに不要な変更が入らない
• 本番環境への変更リスクが低減する — 設定ファイル構文エラーなどの心配がない
• パラメータファイルだけを変更管理すればよい — デプロイ履歴もシンプルに追跡できる
• 複数環境での差分管理が明確 — 本番用 vs 開発用のパラメータの違いが一目瞭然

特にCI/CDパイプラインから呼び出す場合、パラメータだけを動的に更新してupdate-stackを実行するように設計すれば、設定ファイルは完全に固定化できます。

導入の成果

CloudFormation導入により、環境構築にかかる時間が大幅に短縮されました。
また、効率的にインフラの調査を行えたり、構成試験が行いやすかったりと、多くの恩恵を享受できています。

何より嬉しいのは、チーム内の知見共有がスムーズになったことです。

インフラ設定がコード化されているから、インフラに詳しくないメンバーも「あ、こういうリソース構成なんだ」と理解しやすい作りになっています。
複数の環境を同時に構築するリクエストが来ても、パラメータファイルを変更するだけで対応できるようにもなっています。

手動作業による設定ミスもほぼなくなりました。変更はコード化され、Gitで追跡される。
これほど安心感のあることはありません。

課題と工夫

もちろん課題もありました。
最初の頃は、CloudFormationの設定ファイル構文を学ぶのに時間がかかりました。
YAMLの複雑さに苦戦した場面も多かったです。

ですが、以下の工夫で乗り越えました：

• 既存の設定ファイルをリファレンスとして活用 — 1つ目の設定ファイル作成は大変だけど、以降は既存ファイルを参考にしながら書ける
• GitHub Copilotなどの補助ツール導入 — CloudFormation構文エラーや最適化の提案が得られ、学習コストが大幅削減
• リソース依存関係をREADMEで可視化 — 複雑な依存関係はドキュメント化し、保守時の参考とする

特にAIとの相性はよいなと思いました。
設定ファイルの作成時に、影響範囲の調査や潜在的なリスクの敵対的検証(事前検証)、構文のレビューなどでAIを活用しています。
AIの支援により、より堅牢で安全なインフラコードを実現できます。

まとめ

CloudFormation導入は当プロジェクトにとって大きな改善をもたらしてくれました。
インフラ管理の透明性・効率性が向上し、チーム全体でインフラの理解が深まりました。

最初の学習コストはありますが、数ヶ月経てば必ず投資効果を実感できるはずです。

もちろん、全ての組織がCloudFormationを必要とするわけではありません。
小規模なプロジェクトや、インフラの変更頻度が低い場合は、手動管理でも十分です。

ただ、複数の環境を運用し、チーム規模が大きく、変更が頻繁に発生する環境であれば、CloudFormationの導入価値は非常に高いと言えます。

本記事が、皆様のインフラ管理の効率化の一助となれば幸いです。

エコモットでは、モノづくりに共感してくれる仲間を募集中です！弊社に少しでも興味がある方、ぜひ下記の採用ページをご覧ください！