Terraform×AWS入門｜IaCで学ぶインフラ自動構築の始め方

──そんな悩みを感じたことはありませんか？

AWSを使ったインフラ構築は柔軟で強力ですが、その反面、人の手による操作に頼ると“再現性の低さ”や“属人化”という壁にぶつかることも少なくありません。

環境差異による不具合、手順ミスによるトラブル、本番と開発の挙動のズレ…。こうした問題が、プロジェクト全体の品質やスピードに影響を及ぼしてしまいます。

Terraformを活用すれば、EC2やVPC、RDSといったAWSリソースの構成をコードで定義・管理でき、誰がいつ環境を構築しても、同じ設定を確実に再現できます。

さらに、構成の変更履歴を残したり、チームで共有・レビューしたりといった運用の標準化と自動化も実現可能です。

この記事では、Terraformを使ってAWS上にインフラを自動構築する方法を、基本の使い方から実践的な設計ポイントまでわかりやすく解説します。

TerraformやIaCの導入を進めたい企業様に向けて、Rabilooでは技術選定・PoC設計・運用支援まで一気通貫でご支援しています。

チーム開発やクラウド基盤の整備に課題を感じている方は、ぜひお気軽にご相談ください。

TerraformとAWSで実現するインフラ構築の自動化

クラウド環境で新しいシステムを立ち上げる際、多くの方が最初に使うのは AWS マネジメントコンソールなどのグラフィカルなUIでしょう。簡単にサービスを選び、ボタンをクリックするだけでリソースが作成されるため、最初は直感的で分かりやすい手段です。

しかし、構成が複雑になったり、複数の環境（開発・検証・本番）を使い分けたりするようになると、手作業による構築や管理には限界が出てきます。たとえば：

• 毎回手動で設定し直すのが面倒

• 少しの設定ミスが原因で障害が発生する

• 他のメンバーに構成内容を正確に共有できない

こうした課題を根本から解決する考え方が Infrastructure as Code（IaC） です。

Infrastructure as Code とは？

Infrastructure as Code（IaC）とは、サーバーやネットワークなどのインフラ構成をコードとして記述・管理する方法です。設定内容を .tf などのファイルで管理し、自動で構築・変更できるようになります。

IaC を導入すると、以下のようなメリットが得られます：

• 再現性のある構築：開発・本番など複数環境で同じ構成を再利用できる

• エラーの削減：手作業によるミスを防止できる

• 共有のしやすさ：コードをGitなどで管理すれば、チーム全体で内容を把握・修正できる

これにより、インフラの構築や管理は単なる「作業」ではなく、ソフトウェア開発と同じようにバージョン管理・自動化・共同作業が可能になります。

Terraformが選ばれる理由

IaCの実現手段としては、Terraform のほかにも CloudFormation（AWS公式）、Ansible、Chef などがありますが、Terraform は特に人気が高く、初心者でも扱いやすいという特徴があります。

Terraformを使えば、たとえば以下のような操作を数行のコードで定義できるようになります：

• AWSのEC2インスタンスの作成

• VPCやサブネットなどのネットワーク構成

• RDSなどのデータベースサービスの設定

Terraform と AWS を組み合わせることで、柔軟でスケーラブルなクラウドインフラの自動構築が可能になり、開発・運用の効率が大きく向上します。

IAC の Terraform と他のツールの比較表

TerraformとAWSの連携準備｜インストールと初期設定

Terraformを使ってAWSインフラをコードで構築するためには、最初にいくつかの準備が必要です。ここでは、Terraformのセットアップから、AWSとの接続設定までの基本手順を初心者向けにわかりやすく解説します。

Terraformのインストール方法（OS別）

Terraformは公式サイトからダウンロードできます。以下は代表的なOSごとのインストール手順です：

• macOS：Homebrewを使うのが簡単です。

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

• Ubuntu/Linux：apt経由でインストールできます。

  sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
  wget -O- <https://apt.releases.hashicorp.com/gpg> | gpg --dearmor > hashicorp.gpg
  sudo install -o root -g root -m 644 hashicorp.gpg /etc/apt/trusted.gpg.d/
  sudo apt-add-repository "deb [arch=amd64] <https://apt.releases.hashicorp.com> $(lsb_release -cs) main"
  sudo apt-get update && sudo apt-get install terraform
  
  

• Windows：zipファイルをダウンロードして、パスを通します。

  Chocolateyを使えば以下で簡単に導入可能です：

  choco install terraform
  
  

インストール後、以下のコマンドで確認します：

terraform -version

AWS CLIと認証情報の設定手順

TerraformはAWSと連携するために、AWS CLI（コマンドラインインターフェース）での認証情報が必要です。

1. AWS CLIの公式ページからCLIをインストール

2. 以下のコマンドでアクセスキーを設定（あらかじめIAMユーザーを作成しておく）

   aws configure
   
   

3. 入力例：

   AWS Access Key ID: <アクセスキー>
   AWS Secret Access Key: <シークレットキー>
   Default region name: ap-southeast-1
   Default output format: json
   
   

この操作により、設定は ~/.aws/credentials や ~/.aws/config に保存され、TerraformがAWSにアクセスできるようになります。

作業ディレクトリとmain.tfファイルの準備

準備が整ったら、実際のTerraform構成を記述するための作業ディレクトリを作成しましょう。

1. 任意のフォルダを作成

   mkdir my-terraform-project && cd my-terraform-project
   
   

2. main.tf ファイルを作成し、以下のような初期構成を記述します：

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }
  required_version = ">= 0.14.9"
}

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

この設定により、TerraformはAWSプロバイダーを使って東南アジアリージョン（例：シンガポール）にアクセスする準備が整います。

Terraformの基本構成と操作フローを理解する

Terraformを使ったAWSインフラ構築を行うには、基本的な構成要素と操作の流れをしっかりと理解しておく必要があります。ここでは、Terraformで重要となる「プロバイダー」「リソース」「ステート」の役割と、.tfファイルの記述ルール、実行コマンドの流れについて初心者向けに解説します。

プロバイダー、リソース、ステートの役割

Terraformの仕組みを理解するうえで重要なのが、以下の3つの概念です。

• プロバイダー（provider）

  TerraformがAWSなどのクラウドサービスと連携するためのプラグインです。たとえば、AWS環境を操作する場合は hashicorp/aws プロバイダーを使います。

• リソース（resource）

  Terraformで作成・管理するインフラの構成要素を指します（例：EC2インスタンス、VPC、RDSなど）。設定ファイル内で resource ブロックとして記述します。

• ステート（state）

  Terraformが現在のインフラの状態を追跡・管理するための情報ファイルです。.tfstate ファイルとして保存され、構築済みのリソースと設定ファイルとの差分を判断する際に使われます。

これら3つの要素が連携することで、Terraformは安全かつ効率的にInfrastructure as Codeを実現します。

.tfファイルの構成と書き方のルール

Terraformでは、設定はすべて .tf 拡張子のファイルに記述します。複数ファイルに分割して管理することも可能です。

基本的な構成は以下のようになります：

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

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

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t2.micro"
}

• terraform ブロック：Terraform自体のバージョンや依存関係を定義

• provider ブロック：使用するクラウド環境（ここではAWS）を指定

• resource ブロック：作成する具体的なリソースを定義

設定は HCL（HashiCorp Configuration Language） というシンプルな構文で記述され、初心者でも比較的理解しやすいのが特徴です。

terraform init / plan / apply の実行ステップとポイント

Terraformの構成ファイルを準備したら、以下のコマンドを順に実行することでリソースをデプロイできます：

1. terraform init（初期化）

   使用するプロバイダーのプラグインなどを取得し、プロジェクトを初期化します。

   ポイント：最初の1回だけでOK。設定変更後に再実行する場合もあり。

   terraform init
   
   

2. terraform plan（プレビュー）

   構成ファイルの内容を元に、どのリソースが作成・更新・削除されるのかを事前に確認します。

   ポイント：「何が変わるのか」を安全に確認できる重要なステップ。

   terraform plan
   
   

3. terraform apply（適用）

   plan で確認した変更内容を実際に反映してリソースを構築します。

   ポイント：「yes」の入力を求められるので、内容に問題がなければ確定。

   terraform apply
   
   

この3つのコマンドがTerraformの基本操作です。毎回この流れで作業を進めることで、安全かつ一貫性のあるインフラ構築が実現できます。

Terraform apply時に表示される変更プランと「yes」の意味

Terraformを実行するときに使う terraform apply は、単純な「即時実行」ではなく、まず「何が変更されるか」を確認できるステップがあります。

bash
コピーする編集する
terraform apply

このコマンドを実行すると、以下のような変更内容が表示されます：

• 追加されるリソース（+）

• 変更されるリソース（~）

• 削除されるリソース（）

たとえば、EC2インスタンスを新規作成する場合、次のように出力されます：

csharp
コピーする編集する
Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami           = "ami-830c94e3"
      + instance_type = "t2.micro"
      ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

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 と入力することで、実際にインフラ構築が始まります。

AMI IDはリージョンによって異なる点に注意

TerraformでEC2を作成する際、使用するAMI（Amazon Machine Image）のIDはAWSリージョンごとに異なります。

例えば、東京リージョン（ap-northeast-1）で使えるAmazon Linux 2のAMIは、オレゴン（us-west-2）とは異なるIDになります。

• 東京リージョン：

  コピーする編集する
  ami-0c3fd0f5d33134a76
  
  

• オレゴンリージョン：

  コピーする編集する
  ami-830c94e3
  
  

間違ったリージョンにAMIを指定すると、Error: InvalidAMIID.NotFound などのエラーになります。

EC2・VPC・RDSなど主要AWSリソースの構築例

Terraformを使うと、AWSの主要なリソース――EC2、VPC、RDSなど――をコードだけで自動的に構築・管理できます。ここでは、各リソースの代表的な使い方をコードとともに紹介します。

EC2インスタンスの作成（コード付き）

もっとも基本的な構築例のひとつが、EC2（仮想サーバー）の作成です。以下のコードで、t2.micro タイプのEC2インスタンスを1台起動できます。

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t2.micro"

  tags = {
    Name = "TerraformEC2Example"
  }
}

このコードを .tf ファイルに保存し、terraform init → terraform apply を実行することで、インスタンスがAWS上に自動作成されます。

VPCとサブネット構成の自動化

ネットワーク環境の構築もTerraformで自動化できます。以下は、カスタムVPCとパブリックサブネットを1つ作成する基本構成です。

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "TerraformVPC"
  }
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-southeast-1a"

  tags = {
    Name = "PublicSubnet"
  }
}

このように、Terraformではリソース間の依存関係も自動的に処理されます。手動では面倒なネットワーク構成も、再利用可能なコードとして整備できる点が魅力です。

RDSインスタンスの定義と管理

次に、データベースとしてよく使われるRDS（リレーショナル・データベース・サービス）の構築例を見てみましょう。

resource "aws_db_instance" "example" {
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  name                 = "mydb"
  username             = "admin"
  password             = "yourpassword"
  skip_final_snapshot  = true

  tags = {
    Name = "TerraformRDS"
  }
}

この設定により、MySQLベースのRDSインスタンスが自動的に作成されます。

Terraformを使えば、これらのリソースを一貫性のある方法で繰り返し構築できます。実際のプロジェクトでは、これらを組み合わせてVPC内にEC2とRDSを配置する構成なども簡単に実現可能です。

次は、Terraformをより安全かつ効率的に運用するための「設計と管理のコツ」について解説していきます。

Terraformを安全かつ効率的に使うための運用設計

TerraformでAWSインフラを構築できるようになったら、次に考えるべきは本番環境での運用を見据えた使い方です。小規模な個人開発やテスト環境とは異なり、チーム開発や長期的な運用では、安全性・再利用性・保守性が重要になります。

このセクションでは、Terraformを実務で活用する際に押さえておきたい4つの設計ポイントを紹介します。

1.ステートファイルの管理戦略（local vs remote）

Terraformは、実行結果を .tfstate ファイルという「状態ファイル」に保存します。これにより、次回以降の変更点を正確に判断できます。

• Local backend（ローカル管理）

  初期導入時に手軽だが、チームでの共有には不向き。バックアップも自己管理。

• Remote backend（例：S3 + DynamoDB）

  ステートファイルを安全に保管し、ロック機能を使って同時編集の競合を防止できます。

2.モジュール化によるコードの再利用と分割管理

本番環境では、同じ構成を複数回使うケースが多くあります。たとえば、各環境（dev/stg/prod）に同じVPC構成を用意する場合、コードをコピーするのではなく**「モジュール化」**することで再利用が可能になります。

module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

こうすることで、保守性と可読性が大幅に向上し、大規模チームでの開発にも対応しやすくなります。

3.CI/CDとの統合・自動化（GitHub Actions, CodePipelineなど）

Terraformの実行を手動で行うだけでなく、CI/CDツールと連携することで自動化も実現できます。たとえば以下のようなパターンがあります：

• GitHub Actions で terraform plan を自動実行

• CodePipeline を使って terraform apply を本番環境へ自動デプロイ

• PRベースでplan結果をレビュー → 承認後にapply実行

このようなフローを構築すれば、人手によるミスを防ぎ、構成変更の透明性も高めることができます。

4.セキュリティ管理とIAMポリシーの設計

Terraformを使ってAWSリソースを操作するには、適切なアクセス権限が必要です。以下の点に注意してください：

• 最小権限の原則（Least Privilege）

  実行ユーザーには必要最小限のIAMロールを付与する

• クレデンシャルの管理

  aws configure で設定されたキー情報は外部に漏れないように注意

  CI/CD環境では Secrets Manager や GitHub Secrets などを活用

• リソースの意図しない変更を防ぐ

  terraform plan で事前確認し、Apply前にレビューを通す文化をつくる

本番環境でTerraformを使うには、単にコードを書く以上に「どう安全に、どう継続的に使うか」が問われます。以上のポイントを参考に、より実践的なTerraform運用を目指してみてください。

ありがとうございます。現状のまとめ部分は「情報の締めくくり」としては良くできていますが、B2Bでのリード獲得や問い合わせにつなげる力（コンバージョン）がやや弱い印象です。

以下に、専門性・安心感・行動喚起を高めるよう改善したリライト案をご提案します。

まとめ｜TerraformでAWSインフラの自動化をはじめよう

Terraformは、AWSインフラをコードで管理・自動構築できる強力なツールです。この記事では、Terraformの基本概念から、EC2/VPC/RDSの構築例、運用設計のポイントまでを順を追って解説してきました。

振り返ると、Terraform + AWS の組み合わせには、以下のようなメリットがあります：

• リソース構成を .tf ファイルで定義することで、再現性の高いインフラ構築が可能になる

• init / plan / apply の3ステップで、作業の自動化と標準化が実現できる

• EC2・VPC・RDS などの主要リソースも、数十行のコードで管理可能

• 本番環境では、ステート管理・モジュール化・CI/CD連携によって、安全で持続可能な運用が可能になる

Terraformを導入することで、属人化を防ぎ、トラブルの予防や開発効率の向上、チームでのスムーズな連携が期待できます。

Terraformを導入検討中の方へ

Terraformの導入は、最初の設計や運用ルールの定義が重要です。
Rabiloo（ラビロー）では、TerraformやIaCの導入支援から、CI/CD統合・セキュリティ設計・運用フローの整備まで、企業の実情にあわせた支援を行っています。

「何から始めたらいいかわからない」「チームにIaCを浸透させたい」「安全に本番運用まで持っていきたい」
――そんな方は、まずは下記のフォームよりお気軽にご相談ください。初回ヒアリングは無料です。