個人的 CloudFormation ベストプラクティスまとめ

はじめに

最近よく耳にする IaC （Infrastructure as Code）であるCloudFormation を触る機会があったため、使用するにあたりベストプラクティスをまとめました。

CloudFormation概要

テンプレートを使用してAWSリソースの環境構築を行うサービスです。
テンプレート化しておけば、同じ環境構成を何度も作ることができます。

スタックとテンプレート

• テンプレート
  • スタックを構成する AWS リソースの定義されたファイルをテンプレートと呼びます。
• スタック
  • テンプレートから作成されたリソースの集合のことをスタックと呼びます。1つのテンプレートから1つのスタックが生成されます。
    

IaCのメリットとデメリット

IaCのメリット

1. 手動オペレーションによる人的ミスの削減
   • 本番環境と同じ環境を手作業で作ると、ヒューマンエラーが起きるがIaCは確実に同じ構築ができる
   • IaCをCl/CD化時に効果を発揮
2. 不要なリソースができない
   • 謎のEIPやSGなど
3. 環境を即構築でき、工数削減
   • 掃除が楽、作り直しが楽
4. インフラ構築の手順書を作る現場だと、コンソール画面のuiは変更頻度が多いため、IaCで手順書を作成する方が手間が少ない

IaCのデメリット

1. コード化するのに時間がかかる
2. 部分的な修正でもテンプレートからスタックを作成して適用する必要があるため、手動で修正するよりも時間がかかる場合がある
3. 理解が不十分だと意図せずリソースが削除される

ベストプラクティス

設計時、テンプレート作成時、運用時の観点からAWSのベストプラクティス等を参考にし、まとめます。

設計時

1. IaC使い方を設計時に決める

   • 運用もIaCを使い続けるか、IaCを初期構築のみで使用するか
     • 構築のみIaC：初期構築をIaCで構築し、その後は、プロジェクトごとにコンソールで構築
     • 運用までIaC：設計だけでなくIaCのデプロイ方法まで考える（下記の1~3をするには、ハードル高い）
       1. IaCをgit管理し、プルリク時に複数人でチェックする
       2. IaCにCl/CDを導入し、自動デプロイ
       3. AWS環境をコンソールでリソースに対して、手動操作できないよう、IAMユーザー権限は、ReadOnlyにする。緊急時のみadmin権限使用する。

2. ライフサイクルと所有権を考慮し、スタックを整理する

   • 「ライフサイクルが同じ」= 「スタックの作成・削除が同じタイミング」

     • AWSリソースのライフサイクルが同じなら同じスタックにまとめる
       1. ネットワークスタック（vpc,subnet,igw）
       2. セキュリティスタック（sg,IAM）
       3. アプリケーションスタック（cloudfront,elb,fargate,rds）
          • スタックを細分化しすぎると、１つのスタックを修正しようとしても、他のスタックとの依存関係で修正しにくくなる。
            • スタックをどう分けるかは→ 正解はないよう。。
            

   • 誰がそのリソースの変更を担当するのか?（= 所有権）

     • アプリケーションとDBのスタックを担当する部署が別れている場合は、その単位でスタックの分割をすべき
     

テンプレート作成時

1. 命名規則を決めておく

   • スタック内のリソースの命名ルールを最初にちゃんと決めておく
     • 「プロジェクト名 - AWSサービス名 - 環境名」
       • 環境名は、prod や dev とつける

2. 複数環境を同じテンプレートで管理する

   • 本番環境、開発環境など複数の環境を使用している場合に、環境ごとに別のテンプレートにせず、同じものを使うようにした方がします。
     1. テンプレートの数を減らして、管理が楽になります
     2. 同じテンプレートを使うことで、必ず同じ構築にすることができます。

3. ParameterやMappingを使用しすぎない

   • 使いすぎると、実際にどのような設定がされているかテンプレートを見てもわからない
   • 使用する判断基準
     1. Gitで管理しなくても運用上問題ない値であること
     2. 複数環境を1つのテンプレートで管理できるか
        • OK：環境名やスペックをパラメータにすることで、本番環境、開発環境を1つのテンプレートで管理できる
          • パラメータ入力値の制限をすると、なおよい。AllowedValues: [ prod, stg, dev ]
        • NＧ：RDSのスナップショットやメンテナンス時間は、プロジェクトによって変わることは考えくく、レビュー時に確認できた方がよいので固定値がよい。

4. テンプレートを開発で役に立つツール

   • VSCodeのプラグイン
     • cfn-lint ：CloudFormationの構文チェックツール
       • 使い方は、こちら
   • Webサービス
     • former2：作成済みのリソースからテンプレートが作成できるツール
       • IAMユーザーで認証情報とReadOnlyAccess権限必要
         • former2はAWSで紹介されており、認証情報は、AWS APIのエンドポイント以外の外部サーバーには送信しない設計になっており安心
           • 使い方は、こちら
         • Dockerでローカル環境でも実行可能

テンプレート作成時に参考になる記事

運用時

1. スタック間のパラメーターの参照は、クロススタック参照を用いる

   • スタックの特定のリソースを別のテンプレートから参照する場合、クロススタック参照を用いることで、動的に参照できる
     • メリット
       1. 値のハードコードを避けることができて、テンプレートが再利用できる
       2. 強い依存関係を作れる
          • 他のスタックに依存されているリソースがある場合、そのリソースを変更したり削除したりできなくなる
          • ただ、スタックが多いと修正しにくいといったデメリットも。
          

2. スタック間で機密情報の受け渡す場合、ダイナミック参照する

   • パラメータを SSMのパラメータストア や Secrets Manager に出力し、スタックは、そこからパラメータを取得する
   • 具体的な方法はこちら

3. スタックの更新は、 変更セット や ドリフト検出 を使用する

   • スタックを修正する場合、変更セットを使用をすることで、変更を反映する前にどのリソースにどのような影響があるかを把握できる
     • リソースが作り直されるか、現状のリソースのままで設定が変わるだけなのか確認できる
   • スタックを手動で修正していた場合、ドリフト検出で差分を検出しましょう
     • Configルールと組み合わせて、通知することも可能です。
     

4. 複数の環境に同時にスタックを作成する場合、Stack Setsを活用する

   • 異なるリージョンや異なるAWSアカウントに対して、同時に実行可能
     • AWS Config等をすべてのアカウントに展開ができる
     

参考