【第1回】Terraform × AWS インフラ自動化入門 — Terraformとは何か？インストールからAWSリソース作成まで

最近、Lambdaの設定をコンソールでポチポチ変えていたら、「あれ、ステージング環境ってどんな設定だったっけ？」ってなる場面が増えてきた。そろそろちゃんとTerraformを使えるようになりたいと思い、ゼロから学んでみることにした。

この記事は「Terraform × AWS インフラ自動化入門」全5回シリーズの第1回です。シリーズ全体の流れはざっくりこんな感じ：

第1回（今回）: Terraformとは？インストールからAWSリソース作成まで
第2回: tfstateの管理とS3バックエンド設定
第3回: GitHub Actions × Terraform でCI/CDパイプラインを構築する
第4回: モジュール化と環境分離（dev / prod）
第5回: セキュリティとベストプラクティスの整理

今回は第1回なので、まずTerraform自体の概念とインストール、そしてAWSリソースを実際にコードで作るところまでをやっていきます。

この記事でわかること
Terraformとは何か、素直に説明すると
インストール
1. Homebrew でインストール（Mac）
2. tfenv を使う場合（バージョン管理したいとき）
AWSプロバイダーの設定と最初の .tf ファイル
1. AWSの認証情報
実際にS3バケットを作ってみる
tfstateファイルについて知っておくべきこと
基本コマンドの整理
まとめ

この記事でわかること

Terraform（Infrastructure as Code）の基本概念
MacでのTerraformインストール方法（Homebrew と tfenv）
AWSプロバイダーの設定方法
Terraformで実際にS3バケットを作成する手順
tfstateファイルの役割と次ステップ
よく使うTerraformコマンドの一覧

Terraformとは何か、素直に説明すると

TerraformはHashiCorpが開発したInfrastructure as Code（IaC）ツール。インフラをコードで定義して管理できるから、AWSのマネジメントコンソールでポチポチ作っていたリソースを、.tfファイルに書いておくイメージ。

特徴として「宣言的」という言葉がよく出てくる。「このEC2インスタンスを作れ」という命令を書くのではなく、「この状態であってほしい」という最終形を書く感じ。差分はTerraformが計算してくれる。

そういえば、TerraformはHashiCorpがライセンス変更をして一時期ざわついた。「企業利用が全部NGになった」みたいに聞こえるけど、実際にはHashiCorpと競合する形での提供など特定の条件が制限されるという趣旨らしい。普通のプロダクト開発やチーム内での利用なら問題ないケースがほとんどだけど、公式のFAQで確認しておくと安心。

インストール

MacならHomebrewかtfenvでインストールするのが楽。両方紹介しておきます。

Homebrew でインストール（Mac）

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

terraform version

tfenv を使う場合（バージョン管理したいとき）

複数プロジェクトをまたぐとTerraformのバージョンが混在しがちなので、個人的にはtfenvを使っておくと後が楽かなと思う。

brew install tfenv
tfenv install 1.12.1
tfenv use 1.12.1

プロジェクトルートに .terraform-version ファイルを置いておけば、そのディレクトリで自動的にバージョンが切り替わる。チームで使うときはこれが便利。

AWSプロバイダーの設定と最初の .tf ファイル

Terraformにとっての「プロバイダー」は、各クラウドやサービスとの橋渡し役。AWSを使うなら hashicorp/aws プロバイダーを指定する。

まずディレクトリを作って、main.tf を書いてみる。

mkdir tf-practice && cd tf-practice

# main.tf

terraform {
  required_version = ">= 1.11.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

required_version はそこそこ新しいバージョンを指定しておくのが無難。古いバージョンだと新しい機能（例えばS3 Native State Lockingなど）が使えなくなる。

AWSの認証情報

ローカルで試すなら ~/.aws/credentials に設定しておくのが一番シンプル。

aws configure
# AWS Access Key ID: xxxxxxxx
# AWS Secret Access Key: xxxxxxxx
# Default region name: ap-northeast-1

ただしCI/CDに組み込む場合は、長期クレデンシャルをそのまま使うのはNG。GitHub ActionsではOIDCを使った認証を設定することで、長期的なアクセスキーを使用するよりも安全にAWSへアクセスできる。CI/CDの標準的な方法はこちら。

実際にS3バケットを作ってみる

概念の話ばかりだと眠くなるので、シンプルにS3バケットを作ってみる。

# main.tf（続き）

resource "aws_s3_bucket" "practice" {
  bucket = "my-terraform-practice-20260700"  # バケット名はグローバルでユニークにすること

  tags = {
    Name        = "practice"
    Environment = "dev"
    ManagedBy   = "terraform"
  }
}

書いたらまず初期化。

terraform init

初回は .terraform ディレクトリが作られて、プロバイダーのプラグインがダウンロードされる。このフォルダは .gitignore に入れておく。

terraform plan

plan は「これから何が起きるか」の確認。コンソールに + create と出ていれば問題ない。ここで思ってもみない変更が出てくることがたまにあるので、applyの前には必ず確認する習慣をつけたい。

terraform apply

確認プロンプトが出るので yes を入力すると実際にリソースが作られる。自動承認したい場合は -auto-approve オプションをつける（CI/CDでは使うけどローカルでは注意）。

削除するときは：

terraform destroy

ここが手動管理との大きな違いで、どのリソースがTerraformで管理されているか追跡されているので、まとめて安全に削除できる。

tfstateファイルについて知っておくべきこと

terraform apply すると terraform.tfstate というファイルが生成される。これはTerraformが「現在のインフラの状態」を記録しているファイルで、これがないとTerraformは何も判断できない。

ローカルで学習している分にはそのままで問題ないけど、チームで使ったりCI/CDに組み込む場合は絶対にS3などのリモートバックエンドで管理する必要がある。これは次回（第2回）で詳しくやる予定。

ちなみに最近のTerraformでは、S3バックエンドで S3 Native State Locking がサポートされている。この機能は、S3バックエンド上のStateファイルが破損しないように保護するもので、複数人が同時に terraform apply を実行するなどしてStateファイルを同時更新しようとする際のファイル破損を防ぐ。以前はDynamoDBを別途用意してロックをかけていたんだけど、S3 Native State Lockingを使えば use_lockfile = true でロックできるようになって、追加で用意する必要のあるリソースがなくなった。これは地味にうれしいアップデート。