Terraform Importの深淵：手動リソースを「コードの支配下」に屈服させる極意
インフラエンジニアのキャリアにおいて、避けて通れない「罪」がある。それが「コンソールでの手動構築」だ。
プロジェクトが急拡大し、技術的負債が山積する中で、誰かが深夜にポチポチと作成したAWSリソースが、今もあなたの監視をすり抜け、ドリフト（乖離）を起こしているのではないか？
今日は、Terraformの`import`コマンドを単なる作業として終わらせるのではなく、「既存インフラを宣言的コードの完全支配下に置き、二度とドリフトを許さないためのエンジニアリング」について語る。
—
1. importは「コマンド」ではなく「儀式」である
多くのエンジニアが犯す最大の過ちは、`terraform import`を打った直後に「終わった」と勘違いすることだ。
`import`は単にAWS上のリソースをTerraformの状態ファイル（`terraform.tfstate`）に紐付けるだけの「接続作業」に過ぎない。重要なのは、その後に続く「コードとの整合性検証」である。
極限のワークフロー：失敗しないための鉄則
1. Stateの隔離とバックアップ: 事故は常に起きる。`tfstate`のバックアップは必須。
2. 型定義の先行記述: コード側にHCL（HashiCorp Configuration Language）を書き、その型がリソースと一致しているか確認する。
3. `terraform plan`による執念の突き合わせ: コードと実際のリソースの差分がゼロになるまで、コードを修正し続ける。
—
2. 大規模環境での自動化ハック：`terracognita`と`terraformer`の境界線
数千のリソースを手動でインポートするなど正気の沙汰ではない。ここで、我々のような上級エンジニアはツールを「使い分ける」。
- `terraformer` (Google): AWSの既存環境をコードに落とし込む際の最強の相棒。ただし、出力されるHCLは往々にして人間が読めないコードの墓場になる。
- 戦略的アプローチ:
1. `terraformer`で全体構造を自動生成する。
2. 生成されたコードをモジュール化し、責務を分離する（ネットワーク、IAM、計算資源など）。
3. ここが重要: 全てをインポートせず、「変更頻度の高いリソース」だけを厳選して管理下に置く。
—
3. 完全自動化の解：独自スクリプトによる「インポート・パイプライン」
複雑な依存関係を持つリソース（例：RDSとセキュリティグループの複雑な絡み合い）をインポートする場合、CLIの叩き込みでは限界がある。私は以下のPythonスクリプトによるラッパーを推奨する。
import subprocess
import json
TerraformのPlanをJSONで解析し、ドリフトを検知する独自ロジック
def verify_drift(resource_address):
cmd = [“terraform”, “plan”, “-json”]
result = subprocess.run(cmd, capture_output=True, text=True)
# JSON出力を解析し、意図しない変更が含まれていないかチェックする
plan_data = json.loads(result.stdout)
# ここに独自のCI/CD検証ロジックを注入する
print(f”Verifying {resource_address}…”)
インポートの自動化実行
def perform_import(resource_type, resource_name, resource_id):
address = f”{resource_type}.{resource_name}”
cmd = [“terraform”, “import”, address, resource_id]
subprocess.run(cmd, check=True)
print(f”Successfully imported: {address}”)
実行例：一度の実行で関連リソースを連鎖的にインポートし、検証まで行う
if __name__ == “__main__”:
perform_import(“aws_s3_bucket”, “my_app_bucket”, “my-unique-bucket-name”)
—
4. パフォーマンスと内部アーキテクチャの最適化
インポート作業において、メモリ消費が問題になるほどの巨大な`tfstate`ファイルを抱えている場合、`terraform state mv`を使ってStateファイルを分割することをお勧めする。
- State分割の極意:
- `terraform state rm`で不要なリソースを切り離し、新しい`terraform.tfstate`へ移動させる。
- これにより、`terraform plan`の計算量（メモリ消費）を劇的に削減でき、CI/CDパイプラインの高速化が可能になる。
- 設計哲学: 巨大なモノリスなStateファイルは「悪」である。ドメインごとにStateを分割せよ。
—
5. 最後に：インフラの「真の管理」とは
`terraform import`が完了した瞬間、そのリソースはあなたの「所有物」となる。
一度管理下に入れたら、二度とコンソールから手動で変更させてはならない。私はチームに対し、以下のポリシーを徹底させている。
- IAMポリシーの制限: 開発者のAWSコンソールへの書き込み権限を剥奪する。
- ドリフト検知の自動化: 1時間に1回、`terraform plan`を回し、差分が出た瞬間にSlackへアラートを飛ばす（もちろん、修正はコード経由で行う）。
インフラ管理とは、単なるツールの操作ではない。「システムの状態をコードとして定義し、その定義が現実を強制的に支配する」という思想の実践である。
あなたがインポートするそのリソースは、単なるAWSのオブジェクトではない。あなたのコードという「論理」によって、物理的な世界の混沌を鎮圧するための第一歩なのだ。
さあ、コンソールを閉じ、`main.tf`を開こう。エンジニアリングの真髄は、そこにある。