Terraform Importの「闇」を暴く：手動リソースをコード化し、インフラの秩序を取り戻す完全攻略ガイド
現場で「とりあえずコンソールでポチポチ作った」リソースが、いつの間にか制御不能なレガシーと化している――。これは、Terraformを導入した多くのチームが直面する「技術的負債の第一段階」です。
今日は、その行き場のないリソースをTerraformの管理下に引き戻し、「宣言的なインフラ」へと昇華させるための極意を伝授します。単なるマニュアルの焼き直しではなく、実戦で血を流してきたエンジニアだけが知る「安全なインポート戦略」を共有します。
—
1. インポートの哲学：なぜ「闇雲にコマンドを打つ」のが失敗の元か
`terraform import`は、現在のクラウド状態をStateファイルに強引に書き込む行為です。しかし、Stateファイルだけを更新しても、コード（HCL）は空のまま。このギャップこそが、次回の`plan`で発生する「大規模なドリフト（構成乖離）」の正体です。
鉄則：
1. Stateへの反映（import）
2. コードへの落とし込み（generate）
3. ドリフト解消（plan/apply）
この3ステップを機械的に踏めるかどうかが、あなたの生産性を左右します。
—
2. 現場で震えるほど役立つ「インポート高速化」テクニック
A. terraform-provider-sfc （Importを自動化する魔法）
コマンドを一つずつ叩くのは時間の無駄です。既存のAWSリソースを一括で読み込み、HCLファイルを生成してくれるツール群を活用しましょう。
- [Terraformer](https://github.com/GoogleCloudPlatform/terraformer): AWSリソースをスキャンし、HCLとStateを自動生成します。「大規模な既存環境」をインポートする際の初手として、これに勝るものはありません。
B. VS Code 必須設定：Terraform管理の神プラグイン
- HashiCorp Terraform (公式): 必須。LSPによる補完とドキュメント参照はこれ一択。
- Terraform Doc Snippets: 定型文を瞬時に生成。
- Settings Sync: チーム全員で同じ拡張機能とフォーマッター設定を共有すること。`settings.json`をリポジトリの `.vscode/` 配下に含め、プロジェクトごとのルールを強制しましょう。
// .vscode/settings.json – チーム開発の最低限の作法
{
“terraform.languageServer”: {
“args”: [“serve”]
},
“editor.formatOnSave”: true, // 保存時にterraform fmtを走らせる
“editor.codeActionsOnSave”: {
“source.fixAll”: “explicit”
}
}
—
3. 実践：安全なインポート・ワークフロー
ステップ1：リソースの特定とImportブロックの活用
Terraform 1.5以降、`import` ブロックが導入されました。これにより、コマンド操作なしで宣言的にインポートが可能です。
main.tf にインポート定義を記述する
import {
to = aws_s3_bucket.my_bucket
id = “my-existing-bucket-name”
}
ステップ2：構成の生成と検証
`terraform plan` を実行し、Terraformが「どの属性が不足しているか」を教えてくれるのを待ちます。
ここで重要なのは、`terraform plan` の出力を精査し、既存リソースのパラメータとコードの差分をゼロにすることです。 焦って `apply` してはいけません。
ステップ3：ドリフトの排除
以下のような構成管理を推奨します。
modules/s3_bucket/main.tf
resource “aws_s3_bucket” “this” {
bucket = var.bucket_name
# 既存リソースのパラメータをここに完全に一致させる
# 差分が出る場合は、ここでHCL側を修正して一致させる
tags = {
ManagedBy = “Terraform”
}
}
—
4. チーム生産性を最大化する「構造化」のルール
インフラをコード化する際、単一の巨大な`main.tf`は「悪」です。以下の階層構造を徹底してください。
/infrastructure
/modules
/s3
- main.tf # リソース定義
- variables.tf
- outputs.tf
/environments
/prod
- main.tf # モジュールを呼び出すだけ
- backend.tf # S3/DynamoDBを用いたState共有設定
プロの心得：
- Backendの共有: `terraform.tfstate` をローカルに置くのは禁止です。S3 + DynamoDBによるStateロックは、チーム開発の「酸素」です。
- `.tfvars` の管理: 環境ごとの変数は `prod.tfvars` などのファイルに分離し、Git管理下で変更履歴を追えるようにします。
—
5. テックリードからのメッセージ
インポート作業は「過去の自分（あるいは前任者）との対話」です。
「なぜこの設定値になっているのか？」というクラウド上の設定の意図を汲み取り、それをコードとしてドキュメント化する作業こそが、インフラエンジニアの真価です。
ツールはあくまで補助輪です。重要なのは、「クラウド上のリソースが常にコードの写し鏡である」という状態を維持し続ける規律です。
今日から、手動リソースに怯えるのはやめましょう。コマンドを叩く前に、まずは `import` ブロックを書き、計画を立てる。その「慎重かつ大胆なアプローチ」こそが、堅牢なインフラを構築する唯一の道です。
さあ、ターミナルを開いて、あなたのインフラを「コード」という名の秩序の下へ連れ戻しましょう。