☁️ AWS移行時にAWSコンソールではなくTerraformを学ぶべき理由とは？

“AWS移行ツールは引っ越し業者だ。Terraformは家の設計図だ。引っ越しだけで済むなら引っ越し業者を呼べばいい。しかし、引っ越し後も家を改修して住み続ける必要があるなら話は別だ。”

🎯 この記事で扱うこと

AWS移行専用サービス（MGN、DMSなど）の限界
Terraformとは何か、なぜ今学ぶべきなのか
ベンダーロックイン問題と脱出戦略
実際のTerraformコード例で見るAWSインフラの宣言
移行後の運用観点から見たTerraformの価値

📌 導入 / 背景

AWS移行を控えた組織が最初に探すのは、AWS Migration Hub、Application Migration Service(MGN)、Database Migration Service(DMS)のようなAWS専用の移行サービスです。

これは十分に理解できる選択です。AWSが直接作ったツールなので、最もよく機能しそうに見え、公式ドキュメントも豊富で、AWSコンソールで数回クリックするだけで動作するように見えるからです。

しかし、ちょっと待ってください。まず一つの質問をしてみる必要があります。

“移行が終わった後、どうするつもりですか？”

移行は目的地ではなく出発点です。オンプレミスからAWSへ移行するその瞬間が終わりではなく、その後も何年にもわたってAWS上でインフラを運用し、拡張し、時には別のクラウドへ再度移行する必要があるかもしれません。

この観点から見ると、今Terraformを学ぶべき理由が明確になります。

🔍 AWS移行サービスだけでは不十分な理由

AWS専用サービスが得意なことと苦手なこと

AWSが提供する移行ツールは「引っ越しトラック」です。荷物を新しい家に素早く運ぶことに特化しています。


サービス	役割	限界
MGN (Application Migration Service)	サーバーをそのまま複製しEC2に変換	移行完了後の役割なし
DMS (Database Migration Service)	DBをAWS RDS/Auroraへ移行	AWS DBサービスに依存
Migration Hub	移行の進捗状況を追跡	モニタリングツール、インフラ管理不可
SCT (Schema Conversion Tool)	DBスキーマ変換	変換後の運用は別の問題

これらのツールの共通点は「一回限り」であることです。オンプレミスからAWSへの移行という特定のイベントに最適化されているだけで、移行後のインフラ運用、変更管理、複数環境（dev/staging/prod）の構成には適していません。

🚨 本当の問題：クリックで作成されたインフラは記録されない

多くの組織がAWSコンソールでクリックしてインフラを構成しています。VPCを作成し、サブネットを作成し、EC2を立ち上げ、RDSを接続し…

しかし6ヶ月後、このような状況が訪れます。

👨‍💼 「このVPCはなぜこのように設定されているのですか？」
😰 「ええと… 移行担当者が退職してしまって。」
👨‍💼 「ステージングにも同じ環境を作成できますか？」
😰 「…コンソールを見ながら一つずつ作り直すしかないかと。」

開発チーム：「ステージング環境をもう一つ作成してください。」
セキュリティチーム：「昨日誰かがセキュリティグループのルールを変更しましたが、誰が、なぜ変更したのか分かりません。」
経営陣：「コストが急増しましたが、どのリソースが問題なのか把握できません。」
災害復旧担当者：「ソウルリージョンで障害が発生した場合、他のリージョンで同じ環境をどれだけ早く再現できますか？」

これがクリックベースのインフラ管理の現実です。再現不可能、追跡不可能、共同作業不可能…

🧩 Terraformとは何か

TerraformはHashiCorpが作成したInfrastructure as Code(IaC)ツールです。簡単に言えば、インフラをコードで宣言する方法です。

「EC2インスタンスを一つ作成して」をコンソールでクリックする代わりに、このように記述します：

# main.tf — EC2インスタンスの宣言
provider "aws" {
  region = "ap-northeast-2"  # ソウルリージョン
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c9c942bd7bf113a2"  # Amazon Linux 2023
  instance_type = "t3.medium"

  tags = {
    Name        = "web-server"
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

このファイルをGitにコミットし、`terraform apply`を実行すると、AWSにEC2が作成されます。

重要なのは、このファイルが残ることです。誰が作成したのか、どのような設定なのか、いつ変更されたのか — すべてがコードとして記録されます。

💡 移行時にTerraformを学ぶべき5つの理由

1️⃣ 移行 = インフラをゼロから設計する機会

オンプレミスからAWSへの移行プロセスは、単にサーバーをコピーするだけではありません。VPC、サブネット、セキュリティグループ、IAM、ロードバランサー、データベース… 新しいインフラをゼロから設計する機会です。

この時点でTerraformで設計すれば、最初からコードで管理されるインフラを持つことになります。後でレガシーなコンソール設定をコードに変換する手間を省くことができます。

2️⃣ マルチ環境の構成がコピー＆ペーストレベルで簡単になる

ほとんどの組織では、開発(dev)、ステージング(staging)、本番(production)環境を個別に運用しています。これをコンソールでそれぞれ構成すると、3倍の作業が必要になり、環境間で設定の差異が生じやすくなります。

Terraformは変数(Variables)とワークスペース(Workspace)を通じて、環境ごとの構成をきれいに分離します：

# variables.tf — 環境別変数の定義
variable "environment" {
  description = "배포 환경 (dev, staging, prod)"
  type        = string
}

variable "instance_type" {
  description = "EC2 인스턴스 타입"
  type        = string
  default     = "t3.micro"
}

# terraform.tfvars (本番環境用)
environment   = "prod"
instance_type = "t3.large"

dev環境とprod環境は変数値が異なるだけで、インフラ構造自体は同じコードで管理されます。一貫性が保証されます。

3️⃣ ベンダーロックインを最初から防ぐ

AWS移行サービスだけを学べば、あなたのチームはAWSコンソール操作能力を身につけることになります。しかし、もし3年後にコスト問題でAzureやGCPの一部サービスを導入したり、マルチクラウド戦略を検討したりすることになったらどうでしょうか？

TerraformはAWS、Azure、GCP、NCPなど数百のクラウド/サービスを同じ構文で管理します。AWS EC2を宣言する方法とAzure VMを宣言する方法の構造は同じです。学んだ考え方がそのまま通用します。

# AWS EC2
resource "aws_instance" "web" { ... }

# Azure VM — 構文構造は同じ
resource "azurerm_virtual_machine" "web" { ... }

# GCP Compute Engine
resource "google_compute_instance" "web" { ... }

AWSに依存しないクラウド不可知論的(Cloud Agnostic)な能力を培うことができます。

4️⃣ 変更履歴がGitに残り、監査と共同作業が可能になる

セキュリティコンプライアンスを重視する組織にとって、インフラの変更履歴は必須です。「誰が、いつ、何を、なぜ変更したのか」が追跡可能である必要があります。

コンソールでのクリックはCloudTrailログに残りますが、これを人間が読みやすい形で追跡するのは困難です。TerraformコードをGitで管理すれば、PR(Pull Request)ベースのインフラ変更プロセスになります。

# インフラ変更ワークフロー
git checkout -b feature/add-rds-replica
# terraformコードの修正
git commit -m "feat: RDS 읽기 복제본 추가 (트래픽 분산 목적)"
git push origin feature/add-rds-replica
# PR作成 → チームレビュー → 承認 → マージ → terraform apply

これにより、インフラの変更もコードレビューの対象となります。

5️⃣ 移行後の運用自動化のための必須基盤

移行が完了すると、本当の運用が始まります。新しいサービスの追加、スケールアップ/ダウン、災害復旧(DR)環境の構築、コスト最適化のためのインスタンスタイプ変更…

これらのすべての作業は、Terraformで管理されている環境ではコード一行の修正 + applyで完了します。コンソールベースの環境では、何十回ものクリックとミスのリスクが伴います。

💻 実践例 — Terraformで基本的なAWSネットワークを構成する

移行時に最初に必要となるVPCの基本構成をTerraformで作成してみます。

# vpc.tf — 移行対象環境のネットワーク基盤構成

# VPC作成
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "migration-vpc"
  }
}

# パブリックサブネット (Webサーバー、ALB用)
resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet-${count.index + 1}"
    Tier = "public"
  }
}

# プライベートサブネット (DB、バックエンドサーバー用)
resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "private-subnet-${count.index + 1}"
    Tier = "private"
  }
}

# アベイラビリティゾーンデータソース
data "aws_availability_zones" "available" {
  state = "available"
}

このコードを実行すると：

`terraform init` — プロバイダープラグインをダウンロード
`terraform plan` — 変更内容を事前に確認（実際の適用前にレビュー）
`terraform apply` — 実際にAWSにインフラを作成

# terraform plan 出力例
Plan: 5 to add, 0 to change, 0 to destroy.

# + aws_vpc.main
# + aws_subnet.public[0]
# + aws_subnet.public[1]
# + aws_subnet.private[0]
# + aws_subnet.private[1]

`plan`段階で何が作成/変更/削除されるかを事前に表示してくれる点がTerraformの大きな強みです。コンソールではクリックしてからでないと結果が分かりません。

⚠️ 注意事項 / よくある間違い

❌ 「移行が終わってからTerraformを導入すればいい」

最もよくある間違いです。コンソールで構成したインフラを後からTerraformコードに逆変換（`terraform import`）する作業は非常に面倒でエラーが多く発生します。最初からTerraformで構成する方が圧倒的に効率的です。

❌ 状態ファイル（terraform.tfstate）をローカルに保管する

Terraformは現在のインフラの状態を`.tfstate`ファイルに記録します。このファイルをローカルに置くとチームでの共同作業が不可能になり、紛失時には大きな問題となります。S3 + DynamoDBを利用したリモートバックエンド設定が必須です。

# backend.tf — 状態ファイルをS3に保存
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "migration/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-state-lock"  # 同時修正防止ロック
    encrypt        = true
  }
}

❌ AWS認証情報をTerraformコードにハードコーディングする

# 絶対にしないこと
provider "aws" {
  access_key = "AKIAIOSFODNN7EXAMPLE"  # ❌ 危険
  secret_key = "wJalrXUtnFEMI/K7MDENG"  # ❌ 危険
}

AWS CLIプロファイルや環境変数、IAMロールを通じて認証してください。

✅ まとめ / 締めくくり

AWS移行サービス（MGN、DMSなど）は引っ越しトラックです。荷物を運ぶのには役立ちますが、新しい家での生活には別の能力が必要です。

Terraformは新しい家を管理する方法です。


比較項目	AWS移行サービスのみ	Terraformベースのアプローチ
移行速度	速い	初期学習コストあり
その後の運用	コンソールクリックに依存	コードで自動化
環境再現性	不安定	完全に再現可能
ベンダーロックイン	高い	低い
監査/追跡	限定的	Git履歴で完全に追跡
チーム共同作業	困難	PRベースの共同作業

移行という機会を単なる「引っ越し」で終わらせないでください。最初から正しい方法でインフラをコード化する出発点と捉えれば、その後の運用、セキュリティ、コスト最適化のすべてがはるかにスムーズになります。

次の学習ステップ：

Terraform公式チュートリアル (registry.terraform.io)
AWS Providerドキュメントの熟知
Terragruntによる大規模モジュールの管理
CI/CDパイプラインへの`terraform plan/apply`の統合 (GitHub Actions, GitLab CI)