Terraform の removed ブロック徹底解説: 宣言的に管理対象から外す

Terraform では、コードからリソース定義を削除すると通常は destroy が計画されます。運用上「作った実物は残したいが、Terraform の管理からは外したい」場面では、それでは困ります。

removed ブロックは、このギャップを埋めるための宣言的な state 操作です。CLI での terraform state rm のような単発操作をコードに置き換え、レビュー/再現可能な形で“忘れる”ことを実現します。

removed ブロックの目的と使いどころ

removed ブロックは、既存の管理対象リソースを破壊せずに Terraform の状態管理から外すための宣言です。適用時にプロバイダへ destroy は依頼されず、対応する state エントリが削除されます。実インフラ上のリソースはそのまま残ります。

想定ユースケースは、ログ保管用バケット等を別ツールや手動運用に引き渡す、検証中のみ Terraform 管理していた一時的リソースを管理外に戻す、チーム内のレビュー可能な形で state からの削除を行いたい、などです。

• 宣言的に “忘れる” を表現し、レビューや差分管理に乗せられる
• destroy を伴わないため、クリティカルなリソースを安全に管理外へ
• 再実行しても副作用がない（idempotent）

構文と評価タイミング

removed はトップレベルブロックで記述し、from に“これまで管理していたオブジェクトのアドレス”を指定します。count/for_each のインスタンスにもインデックス/キー指定で対応できます。プラン時に Terraform は、該当の state エントリを destroy ではなく “state からの削除”として解釈します。

適用順序としては、通常の差分解決の一環で removed の処理が行われます。対象が state に存在しなければ何も起きません。適用後は、removed ブロック自体をコードから削除して構いません（移行のための一時的な宣言です）。

• 書式: removed { from = "<アドレス>" }
• 対象: 管理対象リソースのインスタンス（例: aws_s3_bucket.logs や aws_instance.web[0]）
• 効果: destroy せずに state エントリのみ削除

removed による計画と適用の流れ

removed と他手段の使い分け

removed は “管理外にする” ための手段です。名前変更やアドレスの変更は moved、即時に手元だけで state をいじるなら terraform state rm、実インフラを削除したいなら destroy を使います。試験でもこの区別が頻出です。

特に、コードからリソース定義を消すだけでは destroy が計画される点に注意が必要です。destroy を抑止して state から忘れたいときに removed を併用します。

• moved: アドレスの変更を宣言（from→to）。実物は維持、state 内の関連付けだけ更新
• removed: 管理対象からの除外を宣言。実物は維持、state から削除
• terraform state rm: CLI による単発の state 操作（宣言的でなく、レビューに載せづらい）
• terraform destroy/-target: 実物を削除。管理外にはならない

実務シナリオ: S3 ログバケットを Terraform 管理から外す

例として、監査ログ用の aws_s3_bucket.logs を今後はセキュリティチームが直接管理することになり、Terraform の対象からは外したいが、実物は消さない要件を考えます。コードから単に削除すると destroy が計画されるため、removed を使います。

適用後は state から該当バケットが消え、以降の plan で Terraform はこのバケットを参照しなくなります。他リソースが参照している場合は、参照の差し替え（データソース、外部入力、変数化など）を先に済ませてから実行してください。

• count/for_each を使っている場合は特定インスタンスをピンポイントに除外可能（例: aws_iam_user.legacy["temp"])
• 適用が完了し no-op を確認したら、removed ブロック自体は削除してよい（一時的な宣言）
• Terraform 1.6 以降での利用を想定（実案件では利用バージョンのドキュメントを確認）

HCL 例: S3 バケットを管理外にする

# Terraform >= 1.6 を想定
# 既存: aws_s3_bucket.logs が state に存在

terraform {
  required_version = ">= 1.6.0"
}

# 以前はここに aws_s3_bucket.logs の定義があったが削除済み

# 破壊せずに state から外したい
removed {
  from = "aws_s3_bucket.logs"
}

# count/for_each の特定インスタンスを外す例
# removed {
#   from = "aws_iam_user.legacy[\"temp\"]"
# }

設計・運用上の注意点

依存関係の解決順序に注意します。removed の対象を他リソースが参照していると、参照切れで plan が失敗します。先に参照元を置き換える（データソース化、外部入力に切替、ハードコード回避）か、分割して適用します。

状態の整合性を保つため、PR に removed を含めてレビューを通し、適用後に no-op を確認してから removed ブロックを削除する運用が安全です。CLI の state rm を混在させる場合は、誰がいつ実施したかの監査ログと手順書を残します。

• removed はプロバイダ API を呼ばない（destroy しない）
• state に対象が無ければ no-op（安全に再適用可能）
• Terraform Cloud/Enterprise のリモート実行でも同様に機能（ワークスペース単位で評価）

資格試験対策（Pro 向け）

removed と moved の違い、destroy の挙動の違いを正確に説明できることが求められます。シナリオ問題では「実物は残す」「管理から外す」「アドレスを変える」をキーワードとして読み取り、最適なブロックまたはコマンドを選択します。

また、count/for_each の個別インスタンス指定、適用後に removed をコードから削除できる一時的宣言である点、チーム運用では宣言的アプローチ（removed/moved）を優先する、などが問われやすいです。

• 実物を残す＋管理外にする → removed
• 実物を残す＋アドレス変更 → moved
• 実物を削除する → destroy
• 単発の state 操作 → terraform state rm（宣言的ではない）

問題で確認

よくある質問