既存の野良リソースをIaC管理下に完全移行する秘訣：CloudFormation `ImportExistingResources` 徹底活用ガイド
こんにちは。テックリードの私だ。
開発スピードを優先するあまり、コンソール（GUI）やAWS CLIで直接作成された「野良リソース（Unmanaged Resources）」が、本番環境の片隅でひっそりと息を潜めている――。この光景に心当たりがないチームはないはずだ。
「このS3バケット、誰が作ったんだっけ？」
「セキュリティ監査が入るから、すべてのリソースをIaC（Infrastructure as Code）管理下に強制移行しろ」
こんな無茶振りに直面した時、あなたはどうする？ 全てのリソースを一度破壊して作り直す？ 本番環境でそんな真似をすれば、翌日にはあなたの机の上には私物がまとめられたダンボール箱が置かれていることだろう。
AWS CloudFormationのリソースインポート機能（`ImportExistingResources`）を使えば、既存の本番リソースを無停止で、かつ安全にCloudFormationスタックの管理下に組み込むことができる。今回は、この機能を現場の最前線で安全に使い倒すための実践的知見を授けよう。
—
1. 開発スピードを劇的に高めるツールチェーンと環境構築
IaCの移行作業において、手作業によるミスは致命傷となる。特にJSON/YAMLのインデントミスや、AWSリソースの物理IDのタイポは、デプロイのたびに数分間の絶望的な待ち時間（ROLLBACK待ち）を生み出す。以下のツール群を導入し、環境を強制的に最適化せよ。
圧倒的な生産性を誇るキーボードショートカット（VSCode前提）
- `Ctrl + Space` (Windows/Linux) / `Cmd + Space` (Mac):
AWS CloudFormation Linterと連携させ、リソースプロパティの補完を強制発動させる。
- `Shift + Alt + F` (Windows) / `Shift + Option + F` (Mac):
YAMLのフォーマットを瞬時に整える。インデントのズレによる構文エラーを物理的に根絶する。
- `Ctrl + Shift + V` (Windows) / `Cmd + Shift + V` (Mac):
テンプレートの全体構造をMarkdownプレビュー的に視覚化する（拡張機能利用）。
絶対に入れるべき神プラグイン
1. AWS CloudFormation Linter (cfn-lint):
テンプレートの静的解析ツール。リソースのプロパティ誤りや、不適切な依存関係をコーディング段階で検知する。
2. YAML:
Red Hat製。CloudFormationのYAML記述における構文ハイライトと自動インデントの精度が段違い。
3. AWS Toolkit for Visual Studio Code:
VSCode上から直接CloudFormationスタックの状態を確認し、テンプレートのバリデーションを実行できる。
チーム開発で共有すべき設定ファイル（`.vscode/settings.json`）
チームメンバー全員が同一の品質でコードを書くため、プロジェクトルートに以下の設定を強制配置しろ。
{
“editor.tabSize”: 2,
“editor.insertSpaces”: true,
“editor.formatOnSave”: true,
“files.associations”: {
“.yaml”: “yaml”,
“.yml”: “yaml”
},
“yaml.schemas”: {
“https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.json”: “.yaml”
}
}
—
2. 実践：野良リソースインポートの4ステップ
既存のリソース（例：すでに稼働中のS3バケット `my-legacy-bucket-2023`）をCloudFormation管理下に移行する手順を、ステップバイステップで解説する。
ステップ1：既存リソースの正確な識別子の特定
インポートには、AWSリソースを一意に特定する物理IDが必要だ。S3ならバケット名、DynamoDBならテーブル名、RDSならDBインスタンス識別子となる。
AWS CLIを使って、現在のプロパティを正確に抽出しておけ。
aws s3api get-bucket-tagging –bucket my-legacy-bucket-2023
aws s3api get-bucket-encryption –bucket my-legacy-bucket-2023
ステップ2：テンプレートの作成と論理IDの付与
CloudFormationテンプレートに、インポート対象のリソースを定義する。ここでのポイントは、既存の設定と完全に一致させることだ。設定が乖離していると、インポート直後の変更セット適用時に意図しないリソースの更新（または置換）が発生する。
ベストプラクティス構成例（`import-stack.yaml`）
AWSTemplateFormatVersion: ‘2010-09-09’
Description: ‘Production S3 Bucket Import Template’
Resources:
# 論理ID: テンプレート内でリソースを識別するID
LegacyBucket:
Type: ‘AWS::S3::Bucket’
Properties:
BucketName: ‘my-legacy-bucket-2023’
# 既存リソースに付与されているタグを完全に再現すること
# タグの不一致は、次回のスタック更新時に意図しない差分を生む
Tags:
- Key: ‘Environment’
Value: ‘Production’
- Key: ‘ManagedBy’
Value: ‘Manual’ # 移行後に ‘CloudFormation’ に書き換える
VersioningConfiguration:
Status: ‘Enabled’
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: ‘AES256’
Outputs:
BucketArn:
Description: ‘The ARN of the imported S3 bucket’
Value: !GetAtt LegacyBucket.Arn
ステップ3：リソースマッピングファイル（変更ファイル）の作成
インポート操作では、CloudFormationの「どの論理ID」が「どの物理ID」に対応するのかを記述したリソース映射ファイル（JSON）を別途用意する必要がある。
`import-resources.json`
[
{
“ResourceType”: “AWS::S3::Bucket”,
“LogicalResourceId”: “LegacyBucket”,
“ResourceIdentifier”: {
“BucketName”: “my-legacy-bucket-2023”
}
}
]
> ⚠️ 致命的な罠（エラー回避策）:
> `ResourceIdentifier` のキー名はリソースタイプによって厳密に決まっている（S3なら `BucketName`、DynamoDBなら `TableName` 等）。ここを間違えると `ValidationError` が即座に発生する。AWS公式ドキュメントの「リソースタイプ識別子のリファレンス」を必ず確認しろ。
ステップ4：インポート実行と整合性の確保
AWS CLIを使用して、変更セットの作成時にインポートを指定する。
aws cloudformation create-change-set \
–stack-name ProductionStorageStack \
–template-body file://import-stack.yaml \
–resources-to-import file://import-resources.json \
–change-set-type IMPORT \
–capabilities CAPABILITY_IAM
変更セットのステータスが `CREATE_COMPLETE` になったら、内容を目視で確認し、実行する。
aws cloudformation execute-change-set –stack-name ProductionStorageStack
これで、野良リソースは無事にCloudFormationの強力なガバナンス下に保護された。
—
3. 現場で生き残るためのプロの知見（Tips & トラブルシューティング）
1. 既存タグの整合性確保：ドリフトの防止
移行直後、テンプレート内の `Tags` 定義と、既存リソースに付いていたタグの大文字・小文字、あるいは順序が微妙に異なっていると、CloudFormationは「ドリフト（乖離）」と検知する。
移行完了後は、速やかにテンプレート側を正（Single Source of Truth）として更新し、`ManagedBy: CloudFormation` などのガバナンス用タグに書き換えるコミットを打て。
2. 依存関係の錯覚に気をつけろ
すでに存在するリソースをインポートする場合、他の新規作成リソースがそのインポートリソースに依存（`DependsOn` や `!Ref`）していると、インポート処理自体が失敗することがある。
鉄則: まずは「インポートのみ」を行うスタックをデプロイし、成功したあとに別のスタック、あるいは同一スタック内で依存リソースを追加・接続する（段階的デプロイの原則）。
3. 削除ポリシー（DeletionPolicy）の強制
インポートしたリソースは、万が一のスタック削除時に物理リソースまで消し飛ぶリスクがある。これを防ぐため、移行直後のリソースには必ず `Retain` を付与しておけ。
Resources:
LegacyBucket:
Type: ‘AWS::S3::Bucket’
DeletionPolicy: Retain # スタックが削除されてもS3バケットを死守する
Properties:
# …
—
結びにかえて
インフラストラクチャのIaC化は、単なる「コード化の趣味」ではない。それは、システム障害時の復旧時間を短縮し、監査要件をクリアし、チーム全体の精神的負荷を劇的に下げるための防衛策だ。
「昔からそこにあるから触れない」というエンジニアリングの負債を、今日、この瞬間で断ち切れ。あなたの手で、すべての野良リソースをコードの光のもとに導き出すのだ。