【第1回】Terraform × AWS インフラ自動化入門 — Terraformとは何か？インストールからHello AWS（EC2起動）まで

「インフラをコードで管理する」って言葉、最近よく聞くけど実際どうやるんだろう——そう思って調べたら、Terraformにたどり着きました。今回からシリーズで、TerraformとAWSを組み合わせたインフラ自動化を順番に追っていきます。

シリーズ全体の構成はこんな感じで考えています。

第1回（本記事）：Terraformとは？インストールからEC2起動まで
第2回：変数・outputs・tfstateの管理
第3回：モジュール化とファイル分割
第4回：GitHub Actions × Terraformで自動デプロイ

自分自身、これまでAWSはマネコンやBoto3（Python SDK）でなんとかしてきたんですが、構成が複雑になってくると「どこに何を作ったかわからなくなる問題」が慢性化してきたんですよね。Terraformはその辺を解決してくれそう、という期待込みで入門してみます。

この記事でわかること
Terraformとは何か
インストール（Mac / tfenv使用）
AWS側の準備（IAMとCLI設定）
初めてのtfファイルを書く
terraform init → plan → apply を実行する
まとめ

この記事でわかること

Infrastructure as Code（IaC）とTerraformの基本概念
Terraformのインストール方法（tfenvを使った管理）
AWS CLIの設定とIAM権限の設定
HCLでEC2インスタンスを定義するコード例
terraform init / plan / apply / destroy の実行フロー

Terraformとは何か

TerraformはHashiCorpが開発したInfrastructure as Code（IaC）ツールです。要は「インフラの構成をコードで書いて、コマンド一発で作ったり壊したりできるもの」です。

設定ファイルはHCL（HashiCorp Configuration Language）という独自言語で書きます。JSONに近い感じで、慣れると読み書きしやすいです。

似たポジションのツールとしてAWS CloudFormationがありますが、TerraformはAWSだけでなくAzureやGCP、GitHub、Datadogなど、複数のクラウドプロバイダーに対応しているため、マルチクラウド環境においても構築手段を統一できます。個人的にはAWSオンリーで当面は困らないんですが、「将来的にマルチクラウドになっても書き方を変えなくていい」というのは確かに魅力です。

大まかなワークフローはこの3ステップです。

terraform plan：「これから何を作る/変える/消す」を確認する
terraform apply：実際に適用する
terraform destroy：作ったリソースをまとめて削除する

この「applyする前にplanで確認できる」のが地味に安心感あります。マネコンでうっかりクリック連打して意図しないリソースを作るミスが自分は多いので……。

インストール（Mac / tfenv使用）

Terraformはバージョン管理が重要です。チームやプロジェクトごとにバージョンが違うことがよくあるので、最初からバージョン管理ツールのtfenvを使う習慣をつけておくのがおすすめです。

余談ですが、Pythonでいうpyenvみたいなものだと思えばイメージしやすいです。

# tfenvをインストール
brew install tfenv

# 利用可能なバージョン一覧を確認
tfenv list-remote

# 最新版をインストール（「最新」は変わるので、まずは list-remote で確認するのが安全です）
tfenv install latest

# 使用するバージョンを指定
tfenv use latest

# 確認
terraform version

Terraformを使う際、バージョンを固定管理することは重要です。チームで使う場合はプロジェクトルートに.terraform-versionというファイルを置いておくと、tfenvがそのバージョンを使う運用ができます。

macOSならbrew install terraformで直接インストールもできますが、後々バージョンを切り替えたくなるのでtfenv経由の方が無難だと思います。

AWS側の準備（IAMとCLI設定）

TerraformからAWSを操作するには、認証情報が必要です。AWS CLIがインストール済みであれば、以下で設定できます。

aws configure

アクセスキーIDとシークレットアクセスキー、デフォルトリージョン（今回はap-northeast-1）を入力すればOKです。

IAMユーザーに付与する権限については、本番環境では最小権限の原則に従い、必要最低限の権限のみを付与します。今回のハンズオンではEC2を触るのでAmazonEC2FullAccessがあれば動きます。本番では絶対にやらないですが、個人の練習用なら一旦これで。

アクセスキーの扱いには本当に気をつけてください。流出すると不正利用による高額請求のリスクがあります。絶対にGitHubに上げないように。.gitignoreに*.tfvarsや.terraform/を入れておくのは最低限やっておきましょう。

# .gitignore
.terraform/
*.tfstate
*.tfstate.*
*.tfvars

初めてのtfファイルを書く

Terraformの設定ファイルは拡張子.tfで作ります。今回は練習用のディレクトリを作って、シンプルにEC2を1台立ち上げるだけのコードを書いてみます。

mkdir hello-terraform && cd hello-terraform

ファイル構成はこんな感じです。

hello-terraform/
├── main.tf        # リソース定義
├── variables.tf   # 変数定義
└── outputs.tf     # 出力値

まずmain.tfから。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"  # 6系の最新マイナーバージョンを自動で使用
    }
  }
  required_version = ">= 1.14.0"
}

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

# Amazon Linux 2023のAMI（ap-northeast-1）
data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "hello" {
  ami           = data.aws_ami.amazon_linux_2023.id
  instance_type = var.instance_type

  tags = {
    Name = "hello-terraform"
  }
}

terraformブロックは、Terraformと使用するプロバイダー（AWS）のバージョンを指定しています。~> 6.0と書いておくと、AWS Providerの6系の中で自動的に新しいマイナーバージョンを利用します。

data "aws_ami"はデータソースで、既存のAWSリソース情報を参照するためのものです。ここではAmazon Linuxの最新AMIを自動検索しています。AMI IDをハードコーディングするのではなく、この方法で動的に取得する習慣をつけておくと、後々の保守が楽になります。

次にvariables.tf。

variable "instance_type" {
  description = "EC2インスタンスタイプ"
  type        = string
  default     = "t3.micro"
}

変数を定義しておくことで、同じコードを異なる値で何度も使える再利用性が生まれます。本記事ではt3.microをデフォルトにしていますが、これはAWS無料枠の対象インスタンスタイプです。

最後にoutputs.tf。

output "instance_id" {
  description = "作成されたEC2のインスタンスID"
  value       = aws_instance.hello.id
}

output "public_ip" {
  description = "パブリックIPアドレス"
  value       = aws_instance.hello.public_ip
}

outputsブロックはapply後に表示される値を定義します。インスタンスIDやパブリックIPなど、後で手動でコンソールに確認しなくても済むよう出力します。