CloudFormationで作ったリソースをコンソールから変更すると、テンプレートと実際の設定に差が生じることがあります。この差がドリフトです。手動変更が正しい設定だった場合は、実環境を維持したまま、CloudFormation側の定義も合わせたいところです。
まず「手動変更を元へ戻す」のか、「現在の設定を正式な構成として採用する」のかを決めます。この記事では後者を目的に、Retainと再インポートを使う方法を整理します。
ドリフト検出は、差分を自動でテンプレートへ反映する操作ではない
検出結果は、想定と実際の違いを確認するための情報です。検出を実行しただけでテンプレートが書き換わるわけではありません。また、すべてのリソース・プロパティが検出対象になるとは限りません。
現在の設定を採用する場合でも、常に再インポートが必要とは限りません。通常のテンプレート更新や、ドリフトを考慮した変更セットで対応できる場合があります。特にドリフト対応の変更セットでは、実際の状態を含めて変更内容を確認できます。対象リソースの対応状況と、提案される変更を見て選びます。
再インポートを検討する場面
通常の更新ではリソースの置換が発生するなど、既存リソースを保持したまま管理上の定義を整えたい場合に、リソースインポートを検討できます。ただし、対象のリソースタイプがインポートをサポートしている必要があります。
| 判断すること | 確認する内容 |
|---|---|
| どちらを正しい設定とするか | テンプレートの値へ戻すか、実環境の値を採用するか |
| 通常更新で対応できるか | 変更セットの更新・置換内容 |
| 再インポートできるか | 対象タイプの対応、識別子、必要なプロパティ |
| 他リソースとの依存関係 | Ref、GetAtt、Outputs、別スタックからの参照 |
基本の流れは「保持して管理対象から外し、同じ実体を戻す」
再インポートによる方法では、次の3段階で進めます。スタック全体を削除する手順ではありません。対象のリソース定義だけを一時的に外して、スタックを更新します。
- 対象リソースへ
DeletionPolicy: Retainを追加し、スタック更新を完了する。 - 対象リソースの記述をテンプレートから外し、再びスタックを更新する。
- 実環境と一致する定義をテンプレートへ戻し、既存リソースとしてインポートする。
具体的な操作はインポートでドリフトを解消する公式手順に沿って確認してください。以下では、各段階の意味を説明します。
1. Retainを設定した更新を、先に完了する
DeletionPolicy は、CloudFormationのテンプレートに記載する属性です。対象リソースをスタックから外した際に、実体をどう扱うかを指定します。Retainなら、その実体を保持します。
記載位置は Properties の内側ではなく、Type と同じ階層です。
Resources:
ManagedBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain
Properties:
BucketName: example-existing-bucket-nameこれは記載位置を示す抜粋です。実際の更新には現在のスタック全体のテンプレートを使い、既存プロパティを維持します。Retainの追加と、対象定義を外す変更を一度に済ませようとせず、先に保持方針を設定した更新が成功したことを確認します。属性の詳細はDeletionPolicyの仕様を参照してください。
2. 対象の定義を外して、スタックを更新する
たとえば2つのバケットを管理するスタックで、片方だけを再インポートしたい場合、外すのはそのバケットの定義です。もう片方の定義は残します。Retainが設定済みであれば、外したバケットは保持され、CloudFormationの管理対象から離れます。
この段階では、対象を参照するOutputsなども整合させる必要があります。参照だけを残すとテンプレートが成立しません。別スタックへエクスポートしている値やリソース間の依存がある場合は、単純な削除・再追加として進めず、参照を維持できる手順を先に設計します。
更新後は、イベントの DELETE_SKIPPED などを確認し、対象の実体が残っていることを確認します。管理から外れている間は、CloudFormationでそのリソースを更新できない期間になる点も考慮します。
3. 現在の設定を記述して、既存リソースをインポートする
対象の定義を実環境の設定に合わせて戻し、「スタックへのリソースのインポート」を行います。このとき、新規作成の通常更新として戻すのではなく、既存リソースの識別子を指定して、同じ実体を管理下へ戻します。
対象タイプによって、バケット名などの識別子を使います。インポートにはDeletionPolicyの指定が必要で、他のリソースへの変更を同じ操作に混ぜないようにします。要件は既存スタックへのインポート手順で確認できます。
インポートが成功しただけで、記載したすべての値と実環境の一致まで保証されたと判断しません。改めてドリフト検出を実行し、対象プロパティやサービス側の実際の設定も確認します。
タグ変更だけでも、毎回この手順が必要？
タグのような変更では、テンプレートを実際の設定へ合わせ、通常更新やドリフト対応の変更セットで処理できるかを先に確認します。再インポートは、既存リソースを保持して構成を取り込むための選択肢の一つです。
手動変更を残す理由、テンプレートの修正内容、変更セットの結果を記録しておくと、その後の更新で意図せず元へ戻すことを防ぎやすくなります。
