Terraform完全ガイド：AWS IaC自動化

2026年8月30日2026年9月24日

この記事でわかること：TerraformでAWS構築を自動化する全体像

この記事では、Terraform完全マスターコース（Udemy）の実例を参考にしながら、、TerraformをAWSと組み合わせてインフラ構築を自動化するための知識と実践的な手順を体系的に解説します。Terraformの基本概念から始まり、実際のAWSリソース（VPC・EC2・S3・IAM）をコードで定義する方法まで、即実装できる実例を交えながら説明します。

Terraform × AWSで実現できること

TerraformをAWSと組み合わせることで、次のような運用が可能になります。

VPC・EC2・RDS・S3などのAWSリソースをコードとして宣言的に定義・管理できる
複数の環境（開発・ステージング・本番）を同一のコードベースから一貫して構築できる
Gitによるバージョン管理でインフラの変更履歴を追跡できる
CI/CDパイプラインに組み込み、インフラ変更を自動化・標準化できる
既存のAWS環境をコードにインポートして管理対象に加えられる

記事全体のロードマップ

この記事は以下の順序で構成されています。初めてTerraformに触れる方は最初から順番に読み進めることを推奨します。すでに基礎知識がある方は、目的のセクションから参照してください。

第1部（本記事）：Terraformの基礎概念とコアコンポーネントの理解、基本コマンドの使い方
第2部：VPC・EC2・S3・IAMの実践的な構築コード例と依存関係の管理
第3部：Terraformのモジュール化、tfstateの管理、チーム開発における運用ベストプラクティス

IaC導入で得られる具体的なメリット

Infrastructure as Code（IaC）を導入することで、インフラ運用における複数の課題を同時に解決できます。以下の数値は業界の複数事例をもとにした参考値であり、実際の効果は環境や運用体制によって異なります。

課題	IaC導入前	IaC導入後	改善効果（参考値）
環境構築にかかる工数	手動作業で数日〜数週間	コマンド実行で数分〜数十分	工数を最大80〜90%削減できたケースあり
設定ミス・環境差異	手作業による設定漏れが頻発	コードが仕様書となり差異が発生しにくい	設定ミスに起因するインシデントの大幅減少
再現性・一貫性	環境ごとに手順が異なる	同一コードから同一環境を何度でも再現	環境間の構成差異をほぼゼロに近づけられる
変更管理・監査	誰が何を変更したか追跡困難	Gitのコミット履歴で変更を完全追跡	変更の可視化により監査対応コストを削減

※上記の数値・効果は参考値です。実際の効果は組織規模や運用状況によって異なります。

Terraform基礎：IaCの仕組みとコアコンセプトを理解する

Terraformを実際に使い始める前に、IaCという考え方の本質と、Terraformがどのような仕組みで動作するかを理解することが重要です。概念を正しく理解することで、コードを書く際の判断軸が明確になります。

IaC（インフラストラクチャ・アズ・コード）とは

Infrastructure as Code（IaC）とは、サーバー・ネットワーク・ストレージなどのインフラ構成をコードとして記述し、プログラムによって自動的にプロビジョニング・管理する手法です。

従来のインフラ管理では、担当者がAWSマネジメントコンソールやCLIを操作して手動でリソースを作成・変更していました。この方法は直感的ですが、操作手順がドキュメントとして残りにくく、同じ構成を別の環境で再現しようとすると設定の抜け漏れが発生しやすいという問題があります。

IaCではインフラの「あるべき状態」をコードで表現します。このコードはGitなどのバージョン管理システムで管理でき、コードレビューやテストの対象にもなります。結果として、インフラの変更履歴の追跡、複数環境への一貫したデプロイ、チームでの共同作業がより安全かつ効率的になります。

TerraformがCloudFormationや他ツールと異なる理由

IaCを実現するツールは複数存在しますが、Terraformには他のツールにはない特徴があります。

比較項目	Terraform	AWS CloudFormation	AWS CDK
対応クラウド	マルチクラウド（AWS・GCP・Azureなど）	AWSのみ	AWSのみ
記述言語	HCL（独自DSL）	JSON / YAML	TypeScript・Python・Javaなど
実行計画の確認	terraform planで変更差分を事前確認できる	Change Setで確認可能	cdk diffで確認可能
状態管理	tfstateファイルで明示的に管理	CloudFormation側で自動管理	CloudFormation経由で管理
コミュニティ・エコシステム	非常に大きく、Terraform Registryにモジュールが豊富	AWSサポートが充実	成長中

Terraformの最大の特徴はマルチクラウド対応と宣言的な構文にあります。AWSだけでなく、GCPやAzure、さらにはDatadog・GitHub・PagerDutyなどのSaaSサービスも同じTerraformコードで管理できます。将来的にクラウドプロバイダーを追加・変更する可能性があるチームにとって、ベンダーロックインを避けられる点は大きなメリットです。

また、Terraformは宣言型のアプローチを採用しています。手順（「EC2インスタンスを作成するコマンドを実行する」）ではなく、状態（「このEC2インスタンスが存在すべきだ」）を記述します。Terraformエンジンが現在の状態と目標状態を比較し、差分を埋めるために必要な操作を自動的に決定・実行します。

宣言的構文HCLの特徴と書き方の基本

Terraformの設定ファイルはHCL（HashiCorp Configuration Language）で記述します。HCLはJSONをベースにした人間が読みやすい構文を持ち、コメントの記述やネストした構造の表現がJSONよりも直感的です。

以下はHCLの基本的な構文例です。


# リソースブロックの基本構文
resource "リソースタイプ" "リソース名" {
  属性名 = 値
}

# 実際のS3バケット定義の例
resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket-20240101"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

HCLの主な特徴を以下に整理します。

可読性：JSONのような厳密な記法よりも記述がシンプルで、設定ファイルとしての可読性が高い
コメント記述：#または//で行コメント、/* */でブロックコメントを記述できる
式と関数：文字列補間（${var.region}）や組み込み関数（length()、toset()など）を使用できる
ブロック構造：設定要素をブロック単位で論理的に整理でき、ファイル分割も自由に行える

Terraformの主要コンポーネント：Provider・Resource・Variable・Output

Terraformのコードは複数のブロックタイプから構成されます。それぞれの役割と相互関係を理解することが、正しいコードを書くための基礎になります。

主要なブロックの関係を整理すると以下のようになります。

Provider：どのクラウドやサービスを操作するかを指定する。AWSやGCPなどのAPIとの接続設定を担う
Resource：作成・管理したいインフラリソースを定義する。Terraformの中核となるブロック
Variable：コードを再利用可能にするための入力値。環境ごとに変わる値を外部から注入できる
Output：作成したリソースの情報（IPアドレスやARNなど）を外部から参照可能にする。モジュール間のデータ受け渡しにも使用する
Data Source：Terraformが管理していない既存のリソース情報を参照する。最新のAMI IDの取得などに活用する
Local：コード内で繰り返し使用する計算結果や文字列を変数として定義する

AWS Providerの設定例

AWS Providerを設定する際は、使用するAWSリージョンとバージョン制約を明示することが推奨されます。


# terraform.tf（またはversions.tf）
terraform {
  required_version = ">= 1.5.0"

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

# main.tf（またはprovider.tf）
provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      ManagedBy   = "terraform"
      Environment = var.environment
    }
  }
}

認証情報の設定方法はいくつかありますが、セキュリティの観点から推奨される方法を優先順に示します。

推奨①：IAMロール（EC2インスタンスプロファイル、ECS TaskRole、GitHub ActionsのOIDCなど）：シークレットキーを直接扱わないため最も安全
推奨②：AWS SSOまたはaws-vault：ローカル開発環境での一時的な認証情報の利用
非推奨：access_key・secret_key

State管理の完全理解：tfstateファイルの仕組みとチーム運用

Terraformを実運用するうえで、最も理解を深めておくべき概念のひとつがStateファイル（tfstate）です。Terraformはインフラの現在の状態をこのファイルに記録し、次回のplanやapply実行時に「理想の状態（コード）」と「実際の状態（State）」を比較して差分を計算します。

Stateファイルがなぜ重要か・破損・競合リスクの説明

tfstateファイルは単なるキャッシュではなく、Terraformがリソースを管理するための唯一の正確な情報源です。このファイルが存在しない・破損している・古い状態のままになっている場合、Terraformは既存のリソースを認識できず、意図しないリソースの重複作成や削除が起きるリスクがあります。

特にチーム開発では次のような問題が生じやすくなります。

競合（Race Condition）：複数人が同時にapplyを実行すると、Stateが互いに上書きされ、どちらかの変更が消えてしまう
ローカル保存のリスク：開発者のマシンにtfstateが存在すると、他のメンバーが同じ環境を操作できない
機密情報の漏洩：tfstateにはパスワードやアクセスキーなどの機密情報が平文で含まれる場合があり、GitリポジトリへのコミットはNG

これらのリスクを回避するために、チーム開発ではリモートStateへの移行が強く推奨されます。

ローカルStateからリモートStateへの移行手順

ローカルに存在するtfstateをリモートバックエンド（例：S3）へ移行する手順は以下のとおりです。

Step1：S3バケットおよびDynamoDBテーブルを事前に作成する（後述のセットアップ参照）
Step2：backend "s3" {}ブロックをmain.tfまたはbackend.tfに追記する
Step3：terraform initを実行すると「Do you want to copy existing state to the new backend?」と確認プロンプトが表示されるので「yes」を入力する
Step4：移行後、ローカルのterraform.tfstateは削除またはバックアップとして保管する

State操作コマンド（import・mv・rm）の使いどころ

Stateを手動で操作する必要が生じた場合に使うコマンドを整理します。

コマンド	用途	使用シーン例
terraform import	既存リソースをStateに取り込む	手動作成したEC2インスタンスをTerraform管理下に置く
terraform state mv	State内のリソースを別の名前に移動	リソース名のリファクタリング時にdestroyを避ける
terraform state rm	StateからリソースをTerraform管理外に除外	Terraformの管理を外したいが実リソースは残したい場合

これらのコマンドは誤実行がリスクになるため、実行前に必ずterraform state listで現状を確認し、操作対象を特定してから行うことを推奨します。

S3＋DynamoDBによるリモートStateのセットアップ

AWSでTerraformのリモートStateを管理する場合、S3バケットをStateの保存先、DynamoDBテーブルを状態ロックに使うパターンが標準的な構成です。以下にその詳細を解説します。

backendブロックの設定コードを完全掲載

以下はTerraformのbackend設定の記述例です。backend.tfとして分離するか、main.tfに記述します。

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "envs/prod/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

各パラメータの意味は次のとおりです。

bucket：tfstateを保存するS3バケット名
key：バケット内のオブジェクトパス。環境ごとにパスを変えることで複数環境を管理可能
region：S3バケットが存在するAWSリージョン
encrypt：サーバーサイド暗号化（SSE）を有効化
dynamodb_table：State Lockに使用するDynamoDBテーブル名

DynamoDBによる状態ロック（State Lock）の仕組みと設定

State Lockとは、複数ユーザーが同時にapplyを実行することを防ぐ排他制御の仕組みです。Terraformはapply開始時にDynamoDBテーブルへロックレコードを書き込み、他のプロセスが同テーブルを確認することで二重実行を防ぎます。

DynamoDBテーブルの作成例（Terraformコード）：

resource "aws_dynamodb_table" "terraform_lock" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

ロックが残存している場合（applyが異常終了した場合など）は、terraform force-unlock <LOCK_ID>で手動解除できますが、別プロセスが実行中でないことを必ず確認してから行ってください。

S3バケットの暗号化・バージョニング設定で安全性を高める

tfstateには機密情報が含まれる可能性があるため、S3バケットには以下の設定を必ず適用することを推奨します。

サーバーサイド暗号化（SSE-S3またはSSE-KMS）：保存データを暗号化し、不正アクセス時のリスクを軽減する
バージョニング（Versioning）：tfstateが誤って上書きされた場合に旧バージョンへロールバックできる
パブリックアクセスのブロック：バケットポリシーでパブリックアクセスを完全に遮断する
アクセスログの有効化：誰がいつStateを操作したかを追跡できるようにする

※本記事執筆時点の情報です。最新情報は公式サイトでご確認ください。

Workspaceと環境分離：dev・staging・prodを安全に管理する

TerraformにはWorkspaceという機能があり、同一のコードベースから複数の独立したStateを管理できます。ただし、Workspaceは万能ではなく、ユースケースによってはディレクトリ分離の方が適切な場面もあります。

terraform workspaceコマンドの使い方と注意点

基本的なWorkspace操作コマンドは以下のとおりです。

terraform workspace list：現在のWorkspace一覧を表示
terraform workspace new dev：「dev」という名前の新しいWorkspaceを作成
terraform workspace select prod：「prod」Workspaceに切り替える
terraform workspace show：現在のWorkspace名を表示

注意点として、WorkspaceはStateを分離しますが、使用するコード（tfファイル）は共通です。そのため、環境ごとに大きく構成が異なる場合は、コードの条件分岐が増えてメンテナンスが複雑になるリスクがあります。

Workspaceとディレクトリ分離の使い分け基準

方式	適したケース	注意点
Workspace分離	環境間の構成差が小さく、変数の値のみ異なる場合	コード共有のため、環境差が大きくなると管理が煩雑
ディレクトリ分離	環境ごとにリソース構成が大きく異なる場合	コードの重複が生じやすいためモジュール化が必要

多くの実運用チームでは、environments/dev/・environments/staging/・environments/prod/のようにディレクトリを分離し、各環境が独立したStateを持つ構成を採用しています。

環境ごとにtfvarsファイルを切り替えるパターン

環境ごとの変数値の切り替えには、tfvarsファイルを活用するのが一般的です。

dev.tfvars・staging.tfvars・prod.tfvarsを作成し、環境ごとの値を定義する
実行時にterraform apply -var-file="prod.tfvars"のように指定する
CI/CDパイプラインでブランチや環境変数に応じてtfvarsファイルを自動選択するよう設定することで、誤った環境へのapplyを防げる

モジュール設計とコード品質：スケールするTerraformの書き方

Terraformのコードが増えてくると、再利用性・可読性・テスト容易性を意識した設計が重要になります。適切なモジュール設計とコード品質管理により、大規模なインフラ管理でも安全性を保てます。

再利用可能なモジュールの設計原則

モジュール設計では次の原則を意識することで、長期的なメンテナンス性が向上します。

単一責任の原則：1つのモジュールは1つの責務（例：VPCの作成、RDSの作成）だけを担当する
インターフェース設計：variablesで入力、outputsで出力を明確に定義し、モジュール内部の実装詳細を隠蔽する
デフォルト値の活用：頻繁に変わらない値にはデフォルト値を設定し、呼び出し側の記述量を減らす
バージョン管理：社内モジュールにはGitタグを付けてバージョン管理し、破壊的変更を安全に導入する

Terraform Registryの公式AWSモジュールの活用法

Terraform Registryには、HashiCorpや各コミュニティが公開する品質の高いモジュールが多数存在します。特にAWS向けではterraform-aws-modulesが広く利用されており、VPC・EKS・RDS・S3などの主要リソースをベストプラクティスに沿って構築できます。

利用例：VPCモジュールの実装パターン

Terraformを実際に使う際の代表的なユースケースとして、VPCモジュールの作成と再利用があります。VPCモジュールを使うことで、VPC・サブネット・ルートテーブル・セキュリティグループなどの設定を再利用可能なパッケージとして管理できます。
開発環境と本番環境で同じモジュールを使い、変数で環境ごとの設定を切り替えるパターンが一般的です。これにより、環境間の構成差異を最小化し、デプロイエラーを防ぐことができます。

モジュール構造の例


  modules/
    ├── vpc/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── ec2/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

まとめ

この記事では、Terraform完全マスターコース（Udemy）の実例を参考にしながら、、TerraformをAWSと組み合わせたInfrastructure as Codeの基礎から実践までを体系的に解説しました。Terraformのコアコンポーネント（Provider・Resource・Variable・Output）の役割を理解し、VPC・EC2・S3・IAMといった主要なAWSリソースをコードで宣言的に定義・管理する方法を学ぶことで、手動によるコンソール操作に依存しない再現性の高いインフラ構築が実現できます。複数環境への展開やGitによる変更履歴の追跡など、IaC導入で得られる運用上のメリットは多岐にわたります。

また、チーム開発において特に注意が必要なStateファイル（tfstate）の管理についても取り上げました。tfstateはTerraformがリソースを認識・管理するための唯一の正確な情報源であり、ローカル保存のままにすることは競合リスクや機密情報漏洩の原因となります。S3バックエンドとDynamoDBによるステートロックを組み合わせたリモートState管理への移行は、チーム運用を安全に進めるうえで優先度の高い対応事項です。

Terraformを実運用に近い形で活用するためには、本記事で解説した基礎知識に加え、モジュール化による再利用性の向上や、CI/CDパイプラインへの組み込みによる自動化・標準化が重要なステップとなります。以下に、次のアクションとして取り組むべき事項を整理します。

ローカル環境にTerraformおよびAWS CLIをセットアップし、本記事のコード例を実際に動かして動作を確認する
既存のAWSアカウントでS3バックエンドとDynamoDBを用いたリモートState管理を構成し、チーム開発の基盤を整える
繰り返し使うリソース定義をモジュール化し、開発・ステージング・本番の各環境へ一貫したコードで展開できる構造を作る
terraform planをCI/CDパイプラインに組み込み、プルリクエスト時に差分を自動で可視化できる運用フローを検討する

なお、本記事で言及したAWSサービスの料金・仕様、およびTerraformの各バージョンにおける機能の詳細は変更される場合があります。本記事執筆時点の情報です。最新情報はTerraform公式ドキュメントおよびAWS公式サイトでご確認ください。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！