コンソールを一度クリックして作成したサーバーは、誰が作ったのか誰も知らない。
コードとして残さなければ、そのインフラはすぐに幽霊となる。
>
>
一枚のコードで同じインフラを繰り返しデプロイするIaCの一貫性と統制感を、「設計図によって同時に建設される都市」として表現
>
🎯 この記事で扱うこと
- AWSとは何か、なぜクラウドの標準となったのか
- Terraformとは何か、なぜIaC（Infrastructure as Code）が必要なのか
- AWS + Terraformの組み合わせが生み出す自動化の力
- Terraformの主要な5段階ワークフロー（init → plan → apply → destroy）
- 実務でチームがインフラを共同管理する方法
📌 導入 / 背景
AWSコンソールでEC2インスタンスを手動で作成したと想像してみてください。
リージョンはap-northeast-2、インスタンスタイプはt3.medium、セキュリティグループ設定でポート22を開放…一つ一つクリックして完成。満足です。しかし6ヶ月後、同じ環境をステージングサーバーとしてもう一つ作成する必要があるとしたら？その時の設定は何だったっけ？
これが手動インフラ管理の落とし穴です。
- 設定記録がない
- 誰が何を変更したか追跡できない
- 環境ごとに微妙に異なる
- 新しいチームメンバーが来たら最初から説明し直す必要がある
この問題を解決するために登場したのが、IaC（Infrastructure as Code）、そしてその代表的なツールであるTerraformです。
🔍 AWSとは何か？
AWS（Amazon Web Services）は、Amazonが運営するグローバルなクラウドコンピューティングプラットフォームです。世界中の数十のリージョンにデータセンターを保有し、企業がサーバーを直接購入しなくても、インターネットを通じてコンピューティングリソースを借りて利用できるようにします。
AWSの主要サービス
| カテゴリ | サービス | 一言説明 |
| コンピューティング | EC2 | 仮想サーバー (VM) |
| ストレージ | S3 | オブジェクトストレージ (ファイル保存) |
| サーバーレス | Lambda | サーバーなしでコード実行 |
| ネットワーク | VPC | 仮想プライベートネットワーク |
| セキュリティ/アクセス制御 | IAM | 権限管理 |
| データベース | RDS | マネージド型リレーショナルDB |
AWSの最大の特徴は、使用した分だけ費用を支払う構造です。使用しないリソースは停止でき、トラフィックが急増しても数分で拡張できます。
🔍 Terraformとは何か？
TerraformはHashiCorpが作成したIaCツールです。インフラをコードとして定義し管理できるツールで、AWSだけでなくAzure、GCP、オンプレミス環境まで一つの言語で管理できます。
HCL — Terraformの言語
TerraformはHCL（HashiCorp Configuration Language）という専用言語を使用します。JSONのように見えますが、はるかに読みやすいです。
# AWSプロバイダー設定
provider "aws" {
region = "ap-northeast-2"
}
# EC2インスタンス作成
resource "aws_instance" "web_server" {
ami = "ami-0c9c942bd7bf113a2" # Amazon Linux 2
instance_type = "t2.micro"
tags = {
Name = "MyWebServer"
}
}このコードファイル一つで、AWSコンソールで10回クリックする作業を代行します。
プロバイダー(Provider)の概念
TerraformがAWSと対話するにはプロバイダーが必要です。プロバイダーはTerraformと特定のクラウドサービスを接続するプラグインです。
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}AWS以外にも、azurerm（Azure）、google（GCP）など数百のプロバイダーが存在します。
🔍 AWS + Terraform、なぜ一緒に使うべきか？
企業環境でAWSを使用していると、すぐにこのような状況が発生します。
- 開発チーム → 開発環境VPCが必要
- QAチーム → テスト環境VPCが必要
- 運用チーム → プロダクション環境VPCが必要
3つの環境は構造は同じですが、設定値が少し異なります。手作業でそれぞれ作成するとどうなるでしょうか？
- ミスが発生します
- 後で3つの環境が少しずつ異なり、「私の環境では動いたのに、なぜプロダクションでは動かないのか？」という問題が発生します
Terraformでコード化すれば、変数一つを変更するだけで3つの環境を同じようにデプロイできます。
# variables.tf
variable "environment" {
description = "배포 환경"
type = string
default = "dev"
}
variable "instance_type" {
description = "EC2 인스턴스 타입"
type = string
default = "t2.micro"
}💻 Terraform 基本ワークフロー 5段階
TerraformでAWSインフラを管理する主要なワークフローです。
1段階: コード作成 (Write)
.tfファイルにインフラを定義します。これは前述のHCLコード作成ステップです。
my-terraform-project/
├── main.tf # 主要リソース定義
├── variables.tf # 変数宣言
├── outputs.tf # 出力値定義
└── provider.tf # プロバイダー設定2段階: terraform init — 初期化
terraform initこのコマンドは、プロジェクトを初めて開始する際に必ず実行する必要があります。実行すると、以下のようになります。
- .terraform/フォルダが作成される
- 必要なプロバイダープラグインが自動ダウンロードされる
- 外部モジュールが初期化される
Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Installing hashicorp/aws v5.31.0...
- Installed hashicorp/aws v5.31.0 (signed by HashiCorp)💡 ヒント: .terraform/フォルダは必ず.gitignoreに追加してください。サイズが大きく、各環境で直接ダウンロードする必要があります。
3段階: terraform plan — 計画確認
terraform plan実際には何も変更せず、変更予定の内容のみを出力します。デプロイ前の必須レビュー段階です。
Terraform will perform the following actions:
# aws_instance.web_server will be created
+ resource "aws_instance" "web_server" {
+ ami = "ami-0c9c942bd7bf113a2"
+ instance_type = "t2.micro"
...
}
Plan: 1 to add, 0 to change, 0 to destroy.+は作成、~は変更、-は削除を意味します。-が表示された場合は、必ず意図した削除であるか確認してください。
4段階: terraform apply — 実際のデプロイ
terraform applyplanで確認した内容を実際のAWSに適用します。実行前にもう一度確認を求めます。
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yesデプロイが完了すると、terraform.tfstateファイルが作成/更新されます。このファイルが現在のインフラ状態を記録する主要なファイルです。
⚠️ 注意: terraform apply -auto-approveで確認を省略できますが、プロダクション環境では絶対に使用しないでください。
5段階: terraform destroy — インフラ削除
terraform destroy作成したすべてのリソースを削除します。テスト環境の整理や開発完了後のリソース削除に活用します。AWSコスト削減に非常に効果的です。
🔍 実務ワークフロー — チームと共同管理
モジュール化で再利用性を高める
共通の構成要素はモジュールとして作成し、再利用します。
# VPCモジュール再利用例
module "dev_vpc" {
source = "./modules/vpc"
environment = "dev"
cidr_block = "10.0.0.0/16"
}
module "prod_vpc" {
source = "./modules/vpc"
environment = "prod"
cidr_block = "10.1.0.0/16"
}同じVPCモジュールを開発/プロダクション環境で再利用。コードの重複なく一貫性を維持します。
リモート状態管理 — S3 + DynamoDB
複数のチームメンバーが同時にterraform applyを実行すると、状態ファイルの競合が発生します。これを防ぐためにリモート状態管理を設定します。
terraform {
backend "s3" {
bucket = "my-terraform-state-bucket"
key = "prod/terraform.tfstate"
region = "ap-northeast-2"
dynamodb_table = "terraform-lock" # 同時実行防止 (ロック)
encrypt = true
}
}- S3: 状態ファイルを中央で保存
- DynamoDB: 複数人が同時にapplyできないようにロック管理
Git + CI/CDとの連携
実務では、TerraformをGitブランチ戦略と組み合わせて使用します。
feature 브랜치 → PR 생성 → terraform plan 자동 실행 → 코드 리뷰 → main 병합 → terraform apply 자동 실행GitHub ActionsやGitLab CIを活用すれば、このプロセスを完全に自動化できます。
⚠️ 注意事項 / よくある間違い
🔴 状態ファイルをGitにコミットしないでください
terraform.tfstateには、リソースID、IP、さらにはパスワードが平文で含まれる可能性があります。必ず.gitignoreに追加し、S3のようなリモートバックエンドを使用してください。
# .gitignore
*.tfstate
*.tfstate.backup
.terraform/🔴 terraform destroyは慎重に
プロダクション環境で誤って実行すると、すべてのリソースが削除されます。重要なリソースにはprevent_destroy設定を追加する習慣をつけましょう。
resource "aws_db_instance" "production" {
lifecycle {
prevent_destroy = true # destroyコマンド実行時にエラー発生
}
}🔴 アクセスキーをコードにハードコーディングしないでください
# ❌ 絶対にこのようにしないでください
provider "aws" {
access_key = "AKIAXXXXXXXXXXXXXXXX"
secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
# ✅ 環境変数またはIAMロールを使用
provider "aws" {
region = "ap-northeast-2"
# AWS CLI環境変数またはIAMロールで自動認証
}✅ まとめ / 締めくくり
AWSとTerraformの組み合わせをまとめるとこうなります。
| 区分 | 内容 |
| AWS | クラウドのリソースを提供するプラットフォーム |
| Terraform | そのリソースをコードとして管理するツール |
| 主要ワークフロー | init → plan → apply → destroy |
| チームコラボレーションの鍵 | S3リモート状態 + DynamoDBロック + Gitブランチ戦略 |
| 最大の強み | 一貫性、再利用性、変更追跡、自動化 |
クラウドインフラが複雑になるにつれて、手動管理の限界はすぐに明らかになります。Terraformでインフラをコードとして管理する習慣を身につければ、環境が増えても自信を持ってデプロイし、保守することができます。
次の学習ステップとして推奨するもの:
- Terraform Module Registryの活用 (registry.terraform.io)
- Terraform Cloud / Atlantisを利用したGitOpsパイプラインの構築
- terraform importで既存の手動作成リソースをコードに取り込む
コメントを残す