AWS CloudFormation
公式サイトAWS CloudFormationとは
AWS CloudFormationは、AWS上のサーバー、ネットワーク、データベース、権限などの構成を定義ファイルとして記述し、「スタック」という単位でまとめて構築・変更・削除するための、AWS標準の仕組みです。定義ファイルにはYAMLやJSONという形式を使います。変更を適用する前にどの資源がどう変わるかを確認でき、適用に失敗した場合は自動で元の状態に戻す機能を備えています。AWS CDKやAWS SAMといったツールは、内部でこのCloudFormationの定義を生成して適用しているため、AWSでインフラをコード化する際の土台となる存在です。
弊社が採用する理由
弊社では、AWSのインフラをコードで管理する土台としてCloudFormationを採用しています。直接定義ファイルを書く場面と、AWS CDKを通じて間接的に使う場面があります。直接書くのは、構成が比較的単純な場合や、AWSが提供する既製の定義を活用する場合、既にCloudFormationで管理されている環境を引き継ぐ場合です。AWS標準の仕組みのため追加のツールを導入せずに使え、適用の履歴と切り戻しがAWSの管理画面で確認できる点は、お客様側の担当者にとってもわかりやすい利点です。一方で、記述量が多くなる複雑な構成ではAWS CDKで生成し、複数のクラウドや外部サービスをまたぐ構成ではTerraformを使うなど、構成の性質に応じて使い分けています。どの方法でもステージング環境と本番環境を同じ定義から構築し、環境差による不具合を防ぐ考え方は共通です。
向いている案件
- AWS標準の仕組みだけでインフラをコード管理したい場合
- CloudFormationで管理されている既存環境の引き継ぎ・改修
- 比較的単純な構成を追加ツールなしで再現可能にしたい場合
保守・移行の観点
CloudFormationで管理している資源を管理画面から手作業で変更すると、定義と実際の状態がずれ、次の適用で意図しない変更が起きることがあります。変更は必ず定義ファイルを通して行い、定期的にずれの検出機能で確認する運用を徹底します。データベースなど消えては困る資源には削除防止の設定を入れ、変更内容によって資源の作り直しが発生しないかを適用前の差分で確認します。定義ファイルはソースコードと同じく版管理し、変更の理由を履歴に残しておくと、引き継ぎ時の理解が早くなります。
組み合わせて使う技術
よくあるご質問
CloudFormationとTerraformはどちらがよいですか?
AWSだけを使い、追加ツールを入れたくない場合はCloudFormation、複数のクラウドや外部サービスをまたぐ場合や記述の簡潔さを重視する場合はTerraformが向いています。既存環境の管理方法があれば、それに合わせるのが基本です。
手作業で作ったAWS環境をCloudFormationに移せますか?
既存の資源を取り込む機能があり、段階的に管理下に移せます。まず現状を調査し、影響の少ない資源から順に取り込む進め方をご提案します。
関連するサービス
関連する開発ガイド
- レンタルサーバー・VPS・クラウドの違いと選び方レンタルサーバー・VPS・クラウドの3種を、管理範囲・自由度・運用負荷の観点で比較し、中小企業のWebサイトや業務システムにどれが合うかを判断する考え方と、保守との関係を解説します。
- 納品後の保守・運用で何が必要かシステムは納品後も動かし続ける必要があります。監視、バックアップと復元テスト、OS・ミドルウェア・CMSのアップデート、ステージングでの検証、保守契約の範囲という基本を整理します。
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
監修: Unlogical Systems合同会社(杉並区・西荻窪)公開