CloudFormation でリソースを意図しない消失から保護する 3 つの機能を試してみた

CloudFormation でリソースを意図しない消失から保護する 3 つの機能を試してみた

2026.01.07

はじめに

立神です。

前回、CloudFormation で ROLLBACK_FAILED が発生する仕組みとその対処法を学びました。自動で元に戻るロールバックは便利ですが、実務では「意図せず削除されてしまうと困るリソース」を保護することや、操作ミスによる削除を防ぐことも重要です。

https://dev.classmethod.jp/articles/cloudformation-rollback_failed/

そこで今回は、リソースを保護・保持するための 3 つの設定を実際にやってみようと思います。

リソース保護の機能

今回は以下の 3 つの機能を使って、リソースの安全性を高める検証を行います。

1. 削除保護

スタックそのものの削除をロックし、操作ミスによる環境全消去を防ぎます。

2. DeletionPolicy (削除ポリシー)

スタックを削除しても、特定の重要なリソース(S3 バケットなど)だけは物理的に残します。
DeletionPolicy は、スタック削除(またはリソース置換などで"削除"が発生)したときに、そのリソースをどう扱うかを指定する属性です。デフォルト値は多くの場合「Delete(削除=残さない)」です。

指定可能な値は
Delete
Retain
Snapshot(一部のリソースで対応)

今回はテンプレートで「Retain」(保持)を指定します。

3. ロールバックの無効化

作成失敗時にあえてロールバックを無効化し、保存しておくことでエラー原因を特定しやすくします。

やってみた

事前準備

  • 以下の権限を持つ IAM ユーザー/ロール
    • CloudFormation の操作権限
    • S3 の操作権限
  • CloudFormation テンプレートファイルの準備
    今回は下記の YAML ファイルを用意しました。
    DeletionPolicy: Retain を指定しており、後ほどこの効果を確認します。
test-template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TategamiTestBucket:
    Type: 'AWS::S3::Bucket'
    DeletionPolicy: Retain
    Properties:
      # 重複しないユニークな名前を指定してください
      BucketName: "safety-test-bucket-20260105"

1. 削除保護

スタックの作成

  1. CloudFormation コンソールで「スタックの作成」をクリックし、「新しいリソースを使用」を選択
  2. 作成した YAML ファイルをアップロード
  3. スタック名を入力し、「スタックオプションの設定」へ進む
  4. 「スタックの作成オプション」を展開し、「削除保護」を 「アクティブ化済み」 に設定して作成

削除保護

削除を試みる

作成完了後、スタック一覧から「削除」をクリックしてみます。
すると、「削除保護がこのスタックで有効になっています。」というメッセージが表示され、スタックが保護されていることが確認できました。

削除試行

2. DeletionPolicy (削除ポリシー)

次に、スタックは消すが、中身のリソースは残す設定を試します。

削除保護の解除とスタック削除

  1. 「スタックアクション」から「削除保護を編集」を選択し、非アクティブ化します。
  2. その後、スタックを削除します。ステータスが DELETE_COMPLETE になるまで待ちます。

S3 バケットの確認

S3 コンソールを開き、作成したバケットを検索します。
CloudFormation 上ではスタックが削除されているにもかかわらず、S3 バケットがそのまま残っていれば成功です。

S3確認

3. ロールバック無効化(デバッグ)

最後に、エラーが発生しても状況を保持しておく設定を試します。

失敗の再現準備

先ほど残った S3 バケットは削除せずにそのままにしておきます。同じ名前のバケットを作ろうとすることで、強制的にエラーを発生させます。

スタックの作成

  1. 同じテンプレートを使い、新しいスタック名で作成を開始します。
  2. 「スタックオプションの設定」画面にある 「スタックの失敗オプション」 に進みます。
  3. 「正常にプロビジョニングされたリソースの保持」 を選択して作成を実行します。

プロビジョニング

エラー状態の確認

通常ならエラー後に自動削除されますが、今回は CREATE_FAILED のステータスでスタックが残り続けます。

ロールバック一時停止

イベントタブを見ると AlreadyExists というエラー原因が残っており、なぜ失敗したのか一目で確認できました。

まとめ

今回は CloudFormation でリソースやエラーの証拠を、意図しない消失から保護する 3 つの方法をやってみました。

機能 対象 主な活用シーン
削除保護 スタック全体 操作ミスによる本番環境の消失防止
DeletionPolicy 個別のリソース データの永続化・保護
ロールバックの無効化 失敗時の状態 エラー原因の調査

CloudFormation には削除防止や状態保持のための機能がしっかり用意されています。
今回紹介した 3 つの設定を使えば、スタック・リソース・エラー情報をそれぞれ意図的に残すことができます。
状況に応じて、これらの設定を活用していただければと思います。
本ブログが誰かの参考になれば幸いです。

参考資料

スタックの作成オプション - AWS CloudFormation
リソースのプロビジョニング時における失敗への対応方法を選択する - AWS CloudFormation

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました

この記事をシェアする

FacebookHatena blogX

関連記事