🪣

RetainExceptOnCreateを指定したバケットでもロールバック時の削除が走る時点で空でなければ削除は失敗するかを一応確認した

2023/08/10に公開

AWS

CloudFormation

retainexceptoncrea

tech

RetainExceptOnCreateが誕生

2023/07/31日 Cloudformationスタックの作成失敗時のみDeleteし、それ以外はRetainとするDeletionPolicy「RetainExceptOnCreate」が誕生しました。

以下詳しく纏めておられる記事となります。

本記事ではドキュメント記載の以下部分のみ確認したいと思います。

テンプレート

S3バケットにVPCフローログを設定した際、「/AWSLogs/[アカウントID]/空」が自動作成されます。
つまり実際のログが蓄積され始める前ですがバケットは空でなくなる為、その後に何らかのリソース作成が失敗しロールバックが走った際の挙動で検証します。

Bucket2はスタック作成を失敗させる意図で用意したものです。

sample.yml

AWSTemplateFormatVersion: 2010-09-09
Resources:
  # ------------------------------------------------------------#
  # Bucket
  # ------------------------------------------------------------#
  Bucket: # RoleBack時DeleteFailedになるバケット
    Type: AWS::S3::Bucket
    DeletionPolicy: RetainExceptOnCreate # Flowlogが作成された段階で「/AWSLogs/[アカウントID]/空」がバケット内に作成される為、Roleback時のDelete動作は失敗する。
    Properties:
      BucketName: !Sub test-bucket-${AWS::AccountId}
      AccessControl: LogDeliveryWrite
      OwnershipControls:
        Rules:
          - ObjectOwnership: ObjectWriter

  Bucket2: # スタック作成が失敗するようにわざとバケット名を↑と同じにしてあるバケット。
    Type: AWS::S3::Bucket
    DependsOn: FlowLog # 一番最後に作成されるよう依存関係を仕込む。
    DeletionPolicy: RetainExceptOnCreate # こちらはオブジェクトは作成されない為Deleteされる。
    Properties:
      BucketName: !Sub test-bucket-${AWS::AccountId} # 上のバケットと名前が重複するので作成が失敗する。
  # ------------------------------------------------------------#
  # VPC
  # ------------------------------------------------------------#
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.1.0.0/16
  # ------------------------------------------------------------#
  # FlowLog
  # ------------------------------------------------------------#
  FlowLog:
    Type: AWS::EC2::FlowLog
    DependsOn: Bucket
    Properties:
      LogDestination: !Sub arn:aws:s3:::${Bucket}
      LogDestinationType: s3
      ResourceId: !Ref VPC
      ResourceType: VPC
      TrafficType: ALL

確認

黄色い文字で簡単な説明を添えました。(下が古いアクション、上が最新となります。)

【結果】
ドキュメント通り、空でないバケットはDeleteに失敗する事が確認出来ました。

特に新らしい発見はありませんでしたが

こうしたログバケットは削除こけますという事の確認でした。
では上記のようなログバケットには今まで通りRetainを指定するのが妥当でしょうか。

その他に当該オプション誕生後もRetainを設定する旨味があるケースが思いついていませんが、おわかりになる方からそっとコメントくだされば喜びます。

CDKにも対応

ちなみにこのオプションはCDKにも対応したようです。

こちらはあえてテストしていませんが、CDKでAutoDeleteObject:trueと一緒に設定した場合は、仕組みとしては以下記事にあるようにオブジェクトを削除してくれるLambda関数が作成されるものである為、先に関数が走り空になったバケットは削除に失敗する事も避けられるのではと思います。

以上でした。

有難うございました。