AWS – CloudFormationで環境構築　序章

今回からナレッジに CloudFormation を使用しての環境構築も記載していきたいと思います。

 
そもそも、CloudFormation とは

AWS CloudFormation は Amazon Web Services リソースのモデル化およびセットアップに役立つサービスです。リソース管理に割く時間を減らし、AWS で実行するアプリケーションにより注力できるようになります。使用するすべての AWS リソース (Amazon EC2 インスタンスや Amazon RDS DB インスタンスなど) を記述するテンプレートを作成すれば、AWS CloudFormation がお客さまに代わってこれらのリソースのプロビジョニングや設定を受け持ちます。AWS リソースを個別に作成、設計して、それぞれの依存関係を考える必要はありません。AWS CloudFormation がすべてを処理します。

要はテンプレートを作成して実行すれば環境が構築できる機能ということです。

 
AWS CloudFormation 価格設定についてですが

AWS CloudFormation に対する追加料金はありません。AWS リソース (Amazon EC2 インスタンス、Elastic Load Balancing のロードバランサーなど) に対して料金が発生します。AWS CloudFormation を使用して作成した AWS リソース（例: Amazon EC2 インスタンス、Elastic Load Balancing ロードバランサー）に対して料金をお支払いいただきます。お支払いはお客様が実際に使用した分だけです。最低料金や前払いの義務は発生しません。

参照先:AWS CloudFormation 価格設定

インスタンスを立ち上げたりする際に発生する以外は追加料金がないみたいなので、気軽に利用できる機能になっています。

 
メリットとしては
・スタックを実行するだけで後はお任せで構築してもらえるので構築時間の短縮につながる
・値を変更するだけで同一環境が複数作成できる。
・設定漏れやオペレーションミスが起きにくくなる。
・イベントが追えるので画面のキャプチャー撮らなくて済む

 
よく画面キャプチャーの張り合わせ的な構築手順書や構築記録書を作成している人は思っているはず…
「構築記録として画像をエビデンスで取得しているけど、キャプチャした画像って加工できるよね？」

私が記録書をチェックする立場だと指摘します。
そこを指摘しない方はたぶんその書類に重要な意味を持ち合わせていないのでしょう…

 
デメリットとしては
・設計書がすべてなので構築中の微調整が効きにくい
・スタックの内容を手動で更新すると整合性が取れなくなる

微調整はスタックを細分化して実行することで実現可能ですので左程問題にはならないと思いますが、構成を手動で更新すると整合性が取れないことが一番のネック。
その状態でスタック内容を更新して実行しても、スタックで設定した内容と現状の構成に相違があると動作しない状態になります。

なので、最初の構築は CloudFormation だけど、結局は手動で更新しているという方も多いはず。
丁寧に管理して更新すれば、よい機能の筈なのです。

 
テンプレート言語は「JSON」か「YAML」が使用できます。
私的には JSON が書きやすいのですが、他のナレッジを見ると YAML で書かれている方が多いように見受けられます。ただ、言語の選択は自由に変更できるので、サイトを参考にして YAML で記載し、その後 JSON に変換して記述の方法を確認することも可能となっています。

 
また、テンプレートにオブジェクトを配置してビジュアル的に構築する方法もありますが、こちらの方が高難易度です。

 
今回の連載では
・VPCの構築から、インターネットゲートウェイ、ルートテーブル、サブネット等の作成とアタッチ
・EC2インスタンスの起動、RDSインスタンスの起動、EBSボリュームの変更
・ロードバランサーの構築、ターゲットグループの作成とターゲットの登録
等々、基本的な AWS 構成を CloudFormation を使用してできる範囲で自動化を目指す連載にしたいと思っています。