CloudFormation運用で事故らないための削除防止について

1. はじめに

CloudFormation（以下、CFnと呼ぶ）は、AWSのリソースの構築、管理、更新する上で非常に便利な IaC です。

一方で、CFn でリソースの更新を行う際、意図せずの更新、削除が行われるケースがあります。

本番環境で CFn を運用する中で意図しない更新や削除は行いたくないものです。

CFn 運用時の削除防止について記述していきます。

2. 削除防止機構の種類と説明

2.1. スタックポリシー（Stack Policy）

スタックポリシーは、意図しない更新からリソースを保護することに役立ちます。

スタックを作成するとすべてのリソースが更新を許可されていますが、スタックポリシーを設定することでスタック内のすべてのリソースが更新できないようになります。

デフォルトではすべてのリソースが更新不可になりますがスタックポリシーの設定で更新不可対象のリソースを選択することができます。

※ スタックポリシーは、更新のみ対応しており、削除は対応しいません。

2.2. 削除ポリシー（Deletion Policy）

削除ポリシーは、スタックの削除が行われた際のリソースの扱いを指定することが可能です。

2.2.1. 保持

削除ポリシーで「保持」を設定した場合でもAWSリソースの削除は行われません。

2.2.2. スナップショット

スタック削除された場合、AWS リソースが削除される前にスナップショットを取得します。

※ この機能は、スナップショット機能がサポートされているAWSリソースに限ります。

例）EC2、RDS、EFS等

2.2.3. 削除

削除ポリシーで「削除」を設定した場合、AWSリソースは削除されます。

※ 削除ポリシーはデフォルトでは、「削除」が設定されています。

2.3. 終了保護

終了保護は、スタック自体の削除防止を目的とした機能です。

削除保護を有効にするとAWSマネジメントコンソール等からスタックの削除できなくなります。

また、対象のスタックがネステッドスタックの場合、親スタックに終了保護が適用されていれば、子スタックに対しても終了保護が適用されます。

ただし、注意すべき点があります。終了保護はスタック自体の削除は保護されますが、リソースの更新に伴う削除からはリソースを守ることができません。

例）CFn で S3バケットのリソースを作成されていて、CFn テンプレートからS3バケットの記述を削除後、スッタックの更新をした場合はS3バケットは削除されます。

3. 削除防止で注意すべき点

2. 削除防止機構の種類と説明 でAWS が提供している３つの削除保護機構について説明してきました。

これらはAWSリソース、スタックの意図しない削除や更新から環境を守るために非常に強力な機能です。

しかしながら、これらの機能単体ではスタックやリソースを守り切ることはできません。

スタックポリシーでは、スタック内のリソースの意図しない更新を防ぐことはできますが、スタック内リソースの削除は防ぐことはできません。そのため、スタックポリシーだけではなく、削除ポリシーを有効にすることで意図しない削除からAWSリソースの保護を行うことが必要です。また、スタック自体の削除をフェールセーフの観点から防ぐためにも設定しておく必要があるでしょう。

このように、スタックポリシー、削除ポリシー、スタックポリシーを単体で適用するだけはスタック、リソースを守るには不十分で３つの削除保護機構を組み合わせることでより安全に CFn の運用が可能になります。

ご自身の現場に合う設定の組み合わせを考えてみるのがいいと思います。

4. ポリシーのテンプレート例

4.1 スタックポリシー

AWSドキュメントのスタックポリシー例です。

{
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    },
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "LogicalResourceId/ProductionDatabase"
    }
  ]
}

これは、スタックポリシーの一例で ProductionDatabase の更新がすべて拒否される設定になっています。

Update が Allow(許可) で設定されていますが、明示的にDeny(拒否)が設定されている場合は、Deny(拒否) が優先されます。

4.1.1. アクションの種類

Update:Modify
- リソースを削除したり置換したりせずに、実行中のまま設定を変更するアクションです。
- 例）セキュリティグループのルール追加、インスタンスタイプの変更（一部）など。
Update:Replace
- 設定変更のために、既存のリソースを一度削除して新しいリソースを再作成するアクションです。
- リソースの物理 ID が変わるため、一時的にサービスが停止したり、エンドポイントが変わったりするリスクがあります。
Update:Delete
- スタックの更新によって、テンプレートからリソースの定義が削除された際に、そのリソースを物理的に削除するアクションです。
- スタックポリシーでこれを Deny にしておけば、テンプレートから記述を消して更新をかけても、実際のリソース削除を拒否することができます。

4.2 削除ポリシー

RDSのCFn テンプレートで説明します。

削除ポリシーは、以下のように各リソースごとに設定し、デフォルトでは削除が行われます。設定漏れには注意要です。

AWS Config をルールを適用して削除ポリシーが設定されていないリソースを監視することで、設定漏れの検知を行うことも検討するのが良いかもしれません。

他にも、What is AWS CloudFormation Guard?という CFn の OSS の静的チェックツールでデプロイ前にコンプライアンスチェックを行うことも可能です。

Resources:
  # 重要なデータベース（リソースごとに設定！）
  MyDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Retain # スタックを消してもこのDBは消さない
    Properties:
      ...

  # 消えても良いWebサーバー
  MyEC2Instance:
    Type: AWS::EC2::Instance
    # DeletionPolicyを書かなければ、デフォルトで削除される
    Properties:
      ...

4.3 終了保護

これは削除保護を有効化するための CLIの例です。

aws cloudformation update-termination-protection \
    --stack-name <my-stack-name> \
    --enable-termination-protection

5. まとめ

AWSの削除防止機構について調べてきました。

スタックポリシー、削除ポリシー、終了保護の３種類の削除防止の機能には各々役割が異なり保護するシチュエーションが異なります。そのため、これらの機能を適切に組み合わせてAWS内のリソースの保護を行うことが重要です。

また、これらの機能を適切に理解することが利用されているAWSリソースの意図しない更新、削除から守ることができるとおもいます。

Cloud Steps