今更はじめてですみませんが今はいないだれかが作った既存リソースから乖離した塩漬けテンプレートを再び使えるようにすることになったので忘れないようにかいときます。（ブラックベルトは読んだことがあったし他人が書いたテンプレみたことはありました）
管理対象の対象リソースを手動で消して別の識別子で作り直した形跡があり、
管理するリソースを挿げ替えるというchangesetを作れるかというと、
Parametersに切り出してないと無理そうに見えた。（たぶん）
なので、、消せなかった対象の識別子を管理対象の内容に合わせてから削除して、直したテンプレート（Mapping、Parametersのあたりを色々）によって再作成しました。
（リリース前で許可でたので）
追記：いないリソース作ってからでないと消せない問題、RDSで確認したところスキップしてとっとくにチェックをいれるとスタック消せるという回避方法があったので書いておきます。
SecurityGroupがあとから複数つけるとインスタンス変わるので接続確認時にアレだったりなどしてたけども、作り直すことに問題は出なかったです。（作成後の変更がほかにあり管理が要る範囲だとテンプレに反映する必要が）
RDSのパラメータグループ修正したかっただけだったのが大げさになって少し驚きました。
（社内の環境でテンプレの修正とテストをがっつりしました）
あまり細かいことは、参考リンク先みればいいかなと思いますが、個人的に遭遇したエラーとしては、
サブネットリソースが枯渇してるとか、
SnapshotつかうならDBUser指定できない（どっちか）とか、
シンタックス違うとか、
DeletationPolicyはクラスタにしか定義できない
拡張モニタリングはDBインスタンス側に設定する
など。
サブネットリソースは、アカウントAだとAZ-aのものがアカウントCからみるとAZ-cなどになってたりすることがあるようで、
新規のアカウントだと枯渇してないゾーンから選ばれるらしいと同僚の人にききました。
参考
https://github.com/tmiki/cloud-formation-templates/blob/master/cfn-32-rds.yml
https://qiita.com/tmiki/items/19cc4fc71949eaafbc3a
https://dev.classmethod.jp/cloud/aws/cloudformation_auroramysql56_57_cloudwatchlogs_export/
https://dev.classmethod.jp/cloud/aws/aws-cloudformation-support-dynamic-references-securestring/
https://dev.classmethod.jp/cloud/aws/blackbelt-cloudformation-2018/
https://dev.classmethod.jp/cloud/aws/awscli-cfn-validate/
ざっくり大枠だけ備忘録、
Parameters パラメータを画面から手入力（デフォルト値かける）ここでかいたやつをRefとかで呼び出してリソース定義につかう
Mappings 辞書、マップ、というたぐいの環境ごとのハッシュ変数をかいといてリソース定義で呼んでつかう
Conditions 条件定義してIf分岐するためのやつ
Resources リソース定義するところ
まあ、どういう動きするか何がしたいかわかると多少なんとか。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbcluster.html
シンタックスがアレなのを防ぐバリデーションは以下の感じでいけました。
# cat /tmp/hoge.yml | xargs -0 aws cloudformation validate-template --template-body
リソースに関連するパラメータが定義できないものだったりするとそういうメッセージが親切に出るようでした。
https://dev.classmethod.jp/cloud/aws/awscli-cfn-validate/
パスワード等はSystemManagerから引っ張ってこれる（gitリポジトリにかかない）
https://dev.classmethod.jp/cloud/aws/aws-cloudformation-support-dynamic-references-securestring/
DBMasterUserPassword:
Description: from system manater parameter.
Default: "{{resolve:ssm-secure:DB_PASSWORD:1}}"
Type: String
NoEcho: true
数が多い場合ディレクトリっぽく表現してまとめてとってくるとかも可能なようです。
/project/env/db/とかを上にくっつけて登録しとくような。
ParameterStoreとの比較
https://qiita.com/tomoya_oka/items/a3dd44879eea0d1e3ef5
管理された状態に戻ったあとはパラメータ変えるくらいならchangesetでいけるはず。たぶん。
拡張モニタリング有効化もDBインスタンスの再起動はマニュアルに書かれたとおり起きなかったです。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html
ただ拡張モニタリング(RDSのOSインスタンス情報をとるとI/O等のリソースが見られる）を
Datadogと連携さすのにデータがCloudwatchLogsに吐かれる関係でLambda連携が要りました。
https://aws.amazon.com/jp/blogs/aws/using-enhanced-rds-monitoring-with-datadog/
ちなみに、DatadogをCloudformationでVMに入れる方法はこれ↓なんだけど、マニュアル見る前にuserdataでS3から落としてきたスクリプトで入れるとかしてしまってました。まあ入ればいいか。
https://www.datadoghq.com/blog/deploying-datadog-with-cloudformation/
このあとECSとかAutoScalingとかEC2のテンプレートも更新したりしました。
変更セットでなんか意図しない更新箇所が出てきたら、そのリソースを念入りにじっと見てテンプレートの差分を埋める必要があるならテンプレート更新するのと、パラメータが知りたいなーと思ったらtypeのとこに書いてあるコロンでつながれた文字列をググるとマニュアル出てくるかんじでした。
マニュアルにそれぞれのパラメータの更新に伴う挙動について書いてありました。
ECSのタスクのスケジュール戦略が手動でかわってたりすると消して作り直すしかなかったなーというところでした。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html