既存AWS環境へTerraformを導入する現実的手順

「先週まで動いていたAPIが急に502を返すようになった。原因を調べたら、誰かがセキュリティグループの設定をマネジメントコンソールから直接変えていた」——こうした相談は珍しくありません。犯人探しをしたいわけではなく、「誰が・いつ・何を変えたか」が誰にも分からない状態そのものが問題です。AWSのマネジメントコンソールは便利な反面、変更履歴が体系的に残らず、担当者の記憶とスクリーンショットだけが頼りという運用になりがちです。

この記事では、そうした「手作業で育ってきたAWS環境」に、いきなり全部を作り直すのではなく現実的にIaC(Infrastructure as Code、具体的にはTerraform)を導入していく手順を、発注者・経営者向けに整理します。

手作業運用が引き起こしているリスク

まず、なぜ「動いているから問題ない」と放置できないのかを整理します。

• 変更履歴が残らない: マネジメントコンソールでの変更はCloudTrailに操作ログこそ残りますが、「なぜその設定にしたか」という意図までは残らない。数ヶ月後に見返しても、変更理由が分からず触れない設定が積み上がっていく
• 属人化: 「AWSの設定は〇〇さんしか分からない」状態になりやすく、その担当者が退職・異動すると環境全体がブラックボックス化する。過去に相談を受けた案件でも、退職者しか把握していないセキュリティグループやIAMロールが放置され、誰も安全に変更できない状態になっていました
• 環境間の差分が発生する: 本番・ステージング・検証環境をそれぞれ手作業で構築すると、微妙な設定差(タイムアウト値、インスタンスサイズ、セキュリティグループのルール等)が積み重なり、「ステージングでは動くのに本番で動かない」原因になる
• 災害復旧が困難: リージョン障害やアカウント誤操作で環境が壊れた場合、手作業で構築した環境を同じ状態に復元する手順が文書化されていないことが多い。「復元できるはず」という期待だけが残り、実際に試したことがないケースがほとんど
• 変更の影響範囲が見えない: あるセキュリティグループのルールを消したら、他のどのリソースに影響するのか。手作業運用では、変更前に影響範囲を機械的に確認する手段がない

これらは平時には表面化しませんが、障害対応・監査・引き継ぎといった「いざという時」に一気に牙を剥く性質のリスクです。障害が多いWebサービスを改善する優先順位でも触れていますが、原因不明の障害の背景に「誰が何を変えたか分からない」インフラの状態が隠れていることは少なくありません。

Terraform導入で得られるもの

TerraformはAWSのリソース構成をコード(HCLというテキスト形式)で定義し、そのコードを適用することでインフラを構築・変更するツールです。導入によって得られる価値は主に3つです。

1. 変更履歴がGitに残る: 誰が・いつ・何を・なぜ変えたかがPull Requestとコミットログとして残る。レビューを挟めば「変更前にもう一人の目が入る」プロセスも自然に作れる
2. 環境の再現性: コードから同じ構成を何度でも再現できる。検証環境を本番と同じ構成で作る、リージョン障害時に別リージョンで再構築する、といったことが手順書ではなくコード実行で完結する
3. 変更の影響を事前に確認できる: terraform plan を実行すると、実際に適用する前に「何が追加・変更・削除されるか」を差分として確認できる。手作業では見えなかった「このルールを消すとこのリソースにも影響する」が事前に分かる

一方で誤解しておきたくないのは、Terraform導入は銀の弾丸ではないということです。コード化すればするほど、コードの品質(状態管理の設計、モジュール分割の粒度)が運用のしやすさを左右します。導入すること自体が目的化すると、「動いているシステムを一度壊しかねない大工事」になってしまいます。

いきなり全部やらない: 段階導入という考え方

既存のAWS環境を持つ企業からよく聞かれるのが「全リソースを一気にコード化すべきか」という質問です。答えは明確にノーです。理由は2つあります。

• 既存リソースのimport作業はリスクを伴う: 手作業で作られたリソースをTerraformの管理下に置く(import)には、実際の設定とコードの記述を一致させる必要があります。ここに差分があると、次の terraform apply で意図しない変更が本番に適用される事故につながります
• 全体を一度に切り替えると切り戻しが困難: 一気に移行して問題が起きた場合、どこまで手作業運用に戻せばよいか判断できなくなります

そのため、私たちが既存環境にTerraformを導入する際は、次のような段階を踏みます。

ステップ1: 影響範囲が小さいリソースから始める

いきなり本番のVPCやRDSから着手せず、新規に作るリソース、あるいは変更頻度は高いが壊れても影響が小さいもの(例: 開発環境のS3バケット、CloudWatchのアラーム設定、IAMポリシーの一部)からTerraform管理に置きます。ここでチームがHCLの書き方・レビューフロー・applyの運用に慣れることを優先します。

ステップ2: 既存リソースをimportする

terraform import コマンド(または terraform plan -generate-config-out によるコード自動生成)を使い、既存リソースをTerraformの管理下に取り込みます。重要なのは、import直後に terraform plan を実行して差分がゼロであることを確認する工程です。差分が出るということは、コードの記述が実際の設定とズレている証拠であり、そのまま apply すると意図しない変更が発生します。この確認を1リソースずつ丁寧に行うのが、地味ですが最も事故を防ぐ工程です。

ステップ3: 対象を広げながらモジュール化する

importが安定して回るようになったら、VPC・セキュリティグループ・RDS・ECS/EC2といった主要リソースへ対象を広げます。同じパターンが繰り返し出てくる部分(環境ごとのVPC構成等)はモジュール化し、環境間の差分を変数として明示的に管理できるようにします。ここまで来ると、「ステージングと本番で設定が微妙に違う」問題が構造的に解消されます。

ステップ4: 手作業変更を禁止するルールを運用に組み込む

コード化が完了しても、誰かがマネジメントコンソールから直接変更してしまうと、コードと実態がまたズレます(いわゆるdrift)。IAM権限を絞る、CI/CDでの terraform plan 差分チェックを必須にする、といった運用ルールとセットで初めて「コードが実態を正しく表す」状態を維持できます。

state管理という落とし穴

Terraformを運用する上で見落とされがちなのが「state(状態)ファイル」の扱いです。stateはTerraformが管理しているリソースの現在の状態を記録したファイルで、これが壊れる・ロストする・複数人が同時に触って競合するといった事故が起きると、コードとインフラの対応関係そのものが失われます。

最低限、次の2点は導入初期から整えておく必要があります。

• リモートバックエンドの利用: stateをローカルファイルのままにせず、S3 + DynamoDB(ロック用)などのリモートバックエンドに置く。チームで運用する以上、ローカルstateはほぼ確実に事故の原因になります
• state分割の設計: 全リソースを1つのstateに詰め込むと、1箇所のミスが全体に波及するリスクと、apply実行時間の肥大化を招きます。環境単位・レイヤー単位(ネットワーク層/アプリケーション層等)である程度分割しておくのが安全です

この設計は後から変更するコストが高いため、段階導入の初期段階で決めておくべき事項です。

外注する場合の進め方

社内にTerraformの実務経験者がいない状態でこれを内製だけで進めようとすると、import時の差分確認やstate設計といった「経験がないとハマりやすい」工程で時間がかかりすぎたり、事故につながったりするケースを多く見てきました。外部に依頼する場合、現実的な進め方は次の二段階です。

1. 現状棚卸しと段階導入計画の策定(数週間): 既存のAWSリソースをCloudTrailやマネジメントコンソールから棚卸しし、どのリソースからimportするか、state分割はどう設計するかの計画を作ります。この段階で「何が動いていて、何が使われていないか」も可視化されるため、AWSコストを診断する観点と合わせて実施すると、コード化と同時にコスト削減の余地も見えてきます
2. 段階的な実装と運用への引き継ぎ: 計画に沿ってimport・モジュール化を進め、並行してチームがHCLを読み書きできるようレビューを重ねながら引き継ぎます。「作って終わり」ではなく、内製チームが自走できる状態まで伴走するのが現実的なゴールです

急いで全部を一気に任せてしまうと、依頼元がTerraformの中身を理解しないまま「ブラックボックスなコード」が新たに生まれるだけになります。それでは手作業運用の属人化と同じ問題を、形を変えて繰り返すことになります。

まとめ

• 手作業でのAWS運用は、平時は問題が見えなくても「変更履歴が残らない」「属人化する」「環境間に差分が生まれる」というリスクを静かに積み上げており、障害対応や引き継ぎの局面で表面化する
• Terraform導入は全リソースを一気に置き換えるのではなく、影響が小さいリソースから始めてimport・plan差分ゼロの確認を丁寧に重ね、state管理(リモートバックエンド化・分割設計)を初期段階で固めるのが事故を防ぐ現実的な手順
• 外部に依頼する場合も「作って終わり」ではなく、内製チームがHCLを読み書きし自走できる状態まで引き継ぐことを前提に進めるべき

torcheees では、既存AWS環境の棚卸しから始める開発診断、Terraform導入を含む継続的な継続的な改善支援円を提供しています。まずは現状のAWS構成がどこまでコード化可能かを一緒に確認するところから始められます。既存プロダクトの改善全般については既存プロダクトの改善、外部チームが最初に見る観点もあわせてご覧ください。インフラの技術領域や改善・モダナイゼーション支援の詳細もご参照のうえ、お問い合わせフォームからお気軽にご相談ください。