CloudFormation と CDK によるデプロイ設計(変更セット・DeletionPolicy・StackSets・Construct)

DELETE_FAILED(S3 バケットが空でない)#

CloudFormation は中身のある S3 バケットを削除できない。

• 原則: バケットを空にしてからスタック削除を再試行する(CloudFormation で作ったものは CloudFormation で消す)
• 緊急避難: 数百万オブジェクトやバージョニングで即座に空にできないとき、再実行時に該当リソースを「保持(Retain)」して管理対象から切り離し、スタックだけ先に消す
• 事前対策: DeletionPolicy: Retain をバケットに付けておく

作成・更新時のエラーは自動でロールバックが走り、一世代前の正常な状態に戻る。

ROLLBACK_FAILED#

リソースの手動削除や IAM 変更でロールバック自体に失敗するとスタックがロックされる。削除(またはアップデートロールバック継続)時に原因リソースを「スキップ」して強制的に完了させ、残った不整合リソースを手動で片付ける。

よくあるデプロイ失敗の原因#

• サブネットの IP アドレス不足によるプロビジョニング失敗
• CloudFormation 実行ロールの IAM 権限不足

AMI の指定: Mappings と SSM 動的参照#

• Mappings + !FindInMap: リージョンや環境ごとの静的な値の出し分け。AMI に使うと、公式 AMI が更新されるたびにテンプレートを書き換える運用が発生する
• SSM パラメータの動的参照(/aws/service/ami-amazon-linux-latest/...): デプロイ時点の最新公式 AMI ID を自動で引く。テンプレートの変更が不要

機密情報の動的参照#

テンプレートに平文のパスワードを書かない。{{resolve:ssm-secure:...}} は Parameter Store の暗号化文字列、{{resolve:secretsmanager:...}} は Secrets Manager。ローテーションやランダム生成が要るなら後者。比較は アクセス制御と監査。

ユーザーデータの 4 原則#

1. デフォルトでは初回起動時に 1 回だけ実行される。再起動や停止 → 起動では走らない(cloud-init の設定で毎回実行に変えられる)
2. root 権限で実行される。sudo は不要
3. 1 行目にシバン(#!/bin/bash)が必須。無いとテキストとして無視される
4. 動かないときは /var/log/cloud-init-output.log(スクリプトの標準出力・標準エラー)と /var/log/cloud-init.log(cloud-init 自体のログ)を見る

cfn-init / cfn-signal / CreationPolicy の配置#

1
[テンプレート]
2
  Resources > EC2 > Metadata > AWS::CloudFormation::Init   # 初期化手順(パッケージ、ファイル、サービス)
3
  Resources > EC2 > CreationPolicy                         # 期待するシグナル数とタイムアウト
4
[EC2 内(UserData)]
5
  cfn-init -v --stack ...     # Init の定義を読んで実行
6
  cfn-signal -e $? --stack ...# 成否を CloudFormation に送る

時間内に必要数のシグナルが届かなければ CREATE_FAILED としてロールバックされる。WaitCondition / WaitConditionHandle も同じ目的の古い仕組みで、EC2 や Auto Scaling 単体の起動同期なら CreationPolicy を使う。

App / Stack / Construct#

1
App(ルート)
2
 └── Stack(デプロイ単位。CloudFormation スタックに 1 対 1)
3
      └── Construct(リソースを表す部品。L1 / L2 / L3)

「低レベル / 高レベル」は優劣ではなく、機械の生データに近いか人間の抽象に近いかの距離。

コマンド#

依存関係#

• 暗黙的: オブジェクトを引数で渡す(new Instance(..., { vpc }))と CDK が DependsOn を自動生成する。クロススタック参照の Export / ImportValue も自動で仲介する
• 明示的: データの受け渡しはないが順序を強制したいときは stackB.addDependency(stackA)

レベルの選び方と移行#

1. 要件に完全一致する L3 があれば使う
2. 通常は L2 を組み合わせて自作する(実務の標準。社内共通の L3 として包んでもよい)
3. CDK 未対応のプロパティだけ L1 をエスケープハッチに使う

L3 は「おまかせ構成」に固定されるのでカスタマイズ性が低い。既存の大規模スタックは L2 で書き直さず、cdk migrate で L1 として取り込んでから段階的に L2 へリファクタリングする。既存テンプレートをファイルのまま取り込むなら CfnInclude。

Elastic Beanstalk のデプロイポリシー#

Auto Scaling の入れ替え#

新 AMI を起動テンプレートの新バージョンに指定し、インスタンスリフレッシュでローリング置換する。AMI 作成は SSM Automation か EC2 Image Builder。Systems Manager

Lambda のパッケージングと公開#

API Gateway + Lambda で 504 が頻発し、29 秒が原因なら、関数 URL に切り替えるか非同期化する。

ECR#

フルマネージドのレジストリ。EC2 上に自前レジストリを立てない。ライフサイクルポリシー(「タグなしで 14 日経過」「最新 10 個以外」を自動削除)でストレージコストを抑え、イメージスキャンで既知の脆弱性を検出する。