ある企業は CloudFormation で本番環境の Amazon RDS インスタンス（Multi-AZ 設定・本番データ保存）と EC2 Auto Scaling グループを同一スタックで管理しています。開発チーム

Question

ある企業は CloudFormation で本番環境の Amazon RDS インスタンス（Multi-AZ 設定・本番データ保存）と EC2 Auto Scaling グループを同一スタックで管理しています。開発チームは EC2 の起動テンプレート変更などで頻繁にスタックを更新しますが、RDS インスタンスの設定（ストレージ容量・エンジンバージョン・インスタンスクラス）は誤って変更・置換されないよう技術的に保護する必要があります。IAM ポリシーで CloudFormation UpdateStack アクション全体を制限することはビジネス要件上できません。最小限の変更で最も確実に RDS リソースへの誤変更を防ぐ方法はどれですか？

Accepted Answer

正解: CloudFormation スタックポリシー（Stack Policy）で、RDS の論理 ID への Update 系アクション（Modify・Replace・Delete）を Deny するポリシーを適用する。CloudFormation スタックポリシーは、スタック内の特定リソースへの更新アクション（Update:Modify、Update:Replace、Update:Delete）を IAM ポリシーに似た JSON 形式で制限する機能です。論理 ID やリソースタイプでリソースを指定し Deny を設定することで、CloudFormation スタック更新時に対象リソースへの変更を技術的に防ぎます。緊急時は一時的ポリシーで上書き可能です。

選択肢AのRDS リソースに DeletionPolicy: Retain および UpdateReplacePolicy: Retain を設定する方法は、スタック削除時のリソース保持と置換時の旧リソース保持に使われますが、Update:Modify（インプレース更新、例えばインスタンスクラス変更）は防げません。

選択肢CのCloudFormation スタックを RDS 専用スタックとその他リソーススタックに分割する方法は、設計として有効ですが「RDS スタックへの更新を手動で制御する」という運用依存であり、誤操作を技術的に防ぐ保護にはなりません。

選択肢DのAWS Config ルールで RDS の設定変更を検出し、Systems Manager Automation で変更前の設定に自動ロールバックする方法は、変更後の検出と修復（事後対応）であり、変更自体を事前に防ぐ予防的制御にはなりません。変更が一時的に適用される期間が生じます。

Answer

RDS リソースに DeletionPolicy: Retain および UpdateReplacePolicy: Retain を設定し、スタック削除時のリソース保持と置換をともなう更新時の旧リソース保持によってデータ損失を防止する — RDS リソースに DeletionPolicy: Retain および UpdateReplacePolicy: Retain を設定する方法は、スタック削除時のリソース保持と置換時の旧リソース保持に使われますが、Update:Modify（インプレース更新、例えばインスタンスクラス変更）は防げません。

Answer

CloudFormation スタックを RDS 専用スタックとその他のリソーススタックに分割し、RDS スタックはクロススタック参照（Outputs と Fn::ImportValue）経由でのみ参照して更新の影響範囲を切り離す — CloudFormation スタックを RDS 専用スタックとその他リソーススタックに分割する方法は、設計として有効ですが「RDS スタックへの更新を手動で制御する」という運用依存であり、誤操作を技術的に防ぐ保護にはなりません。

Answer

AWS Config のカスタムルールで RDS の設定変更（ストレージ容量・インスタンスクラス・エンジンバージョン等）を検出し、Systems Manager Automation で変更前の設定へ自動的にロールバックする — AWS Config ルールで RDS の設定変更を検出し、Systems Manager Automation で変更前の設定に自動ロールバックする方法は、変更後の検出と修復（事後対応）であり、変更自体を事前に防ぐ予防的制御にはなりません。変更が一時的に適用される期間が生じます。

解説

解説