Terraformを使ったAWS構築法

INTRODUCTION

1. はじめに：なぜ今、TerraformとIaCが不可欠なのか

2026年現在、クラウドインフラの構築と運用は、ビジネスの成功に直結する重要な要素となっています。特に、変化の激しい現代において、手作業によるインフラ構築は、人的ミス、時間コスト、そしてセキュリティリスクの増大を招きかねません。そこで登場するのが、Infrastructure as Code（IaC）の概念であり、その代表的なツールがTerraformです。

Terraformは、HCL（HashiCorp Configuration Language）という宣言型の言語を用いて、インフラの状態をコードとして定義し、そのコードに基づいてクラウドプロバイダ（AWS, Azure, GCPなど）上のリソースを自動的にプロビジョニング、管理するツールです。これにより、インフラ構築のプロセスは劇的に効率化され、再現性、一貫性、そしてバージョン管理の恩恵を受けることができます。

本記事では、Terraformを使ってAWS上にインフラを自動構築するための実践的なガイドを提供します。初心者の方でも理解できるよう、Terraformの基本的な概念から丁寧に解説し、さらに中級者の方には、2026年現在のベストプラクティス、セキュリティ考慮事項、そしてチーム開発における課題解決策まで深く掘り下げていきます。具体的なコード例を交えながら、あなたのDevOps環境を強化し、運用を効率化するための一助となれば幸いです。

IaCがもたらす主要なメリット

これらのメリットは、現代のDevOpsチームにとって不可欠なものであり、Terraformはその実現を強力にサポートします。特にAWSのような広範なサービスを提供するクラウドプロバイダでは、Terraformのようなツールがなければ、手動での管理はほぼ不可能です。

CORE CONCEPTS

2. Terraformの基本概念とAWSプロバイダの設定

Terraformを効果的に利用するためには、いくつかの基本的な概念を理解することが重要です。ここでは、主要な構成要素と、AWSプロバイダを設定する方法について詳しく見ていきましょう。

Terraformの主要な構成要素

これらの要素を組み合わせることで、私たちは複雑なAWSインフラを宣言的に定義し、管理することができます。

AWSプロバイダの設定と認証方法

TerraformがAWSリソースを操作するためには、AWSプロバイダを定義し、適切な認証情報を設定する必要があります。最も一般的な認証方法は以下の通りです。

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0" # 2026年時点の推奨バージョン
    }
  }
}

provider "aws" {
  region = "ap-northeast-1" # 東京リージョン
  # profile = "my-aws-profile" # ~/.aws/credentials にプロファイルがある場合
  # access_key = "YOUR_ACCESS_KEY" # 環境変数またはIAMロールを推奨
  # secret_key = "YOUR_SECRET_KEY" # 環境変数またはIAMロールを推奨
}

上記のコードは、TerraformがAWSリソースを管理するために必要な最低限の設定です。特に本番環境では、セキュリティの観点からIAMロールを使用した認証を強く推奨します。これにより、認証情報をコードや環境変数に直接記述するリスクを排除し、一時的な認証情報によるアクセス制御が可能になります。

STATE MANAGEMENT

3. Terraform State管理の深掘り：S3とDynamoDB

Terraform State（状態ファイル）は、Terraformの最も重要な要素の一つです。Terraformは、このStateファイルを使って、実際にデプロイされているインフラリソースと、Terraformコードで定義されたインフラリソースとの対応関係を管理します。Stateファイルがなければ、Terraformはどのリソースを管理しているのか分からなくなり、インフラの変更や削除が適切に行えなくなります。

初期設定では、Stateファイルはローカルディレクトリに terraform.tfstate という名前で保存されます。しかし、このローカルStateは、チーム開発やCI/CDパイプラインでの利用には不向きです。複数の開発者が同時に作業する場合、Stateファイルの競合や上書きが発生するリスクがあるため、リモートState管理が必須となります。

AWS S3とDynamoDBによるリモートState管理

AWS環境でTerraformを利用する際、リモートStateの保存先として最も一般的で推奨されるのが、S3バケットとDynamoDBテーブルの組み合わせです。

# backend.tf (または main.tf)
terraform {
  backend "s3" {
    bucket         = "my-kwonteki-terraform-state-2026" # ユニークなS3バケット名
    key            = "dev/network/terraform.tfstate"     # Stateファイルのパス
    region         = "ap-northeast-1"                   # S3バケットのリージョン
    encrypt        = true                               # Stateファイルを暗号化
    dynamodb_table = "my-kwonteki-terraform-lock-2026"  # DynamoDBテーブル名
  }
}

上記のバックエンド設定を適用する前に、まずはS3バケットとDynamoDBテーブルを手動で（または別のTerraform設定で）作成しておく必要があります。

# infrastructure-foundation/main.tf (例)
resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-kwonteki-terraform-state-2026"
  tags = {
    Name        = "Terraform State Bucket"
    Environment = "Shared"
  }
}

resource "aws_s3_bucket_versioning" "terraform_state_versioning" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled" # バージョニングを有効にする
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state_encryption" {
  bucket = aws_s3_bucket.terraform_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "AES256" # 暗号化を有効にする
    }
  }
}

resource "aws_dynamodb_table" "terraform_lock" {
  name           = "my-kwonteki-terraform-lock-2026"
  hash_key       = "LockID"
  read_capacity  = 5
  write_capacity = 5

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

  tags = {
    Name        = "Terraform State Lock Table"
    Environment = "Shared"
  }
}

PRACTICAL APPLICATION

4. 実践！AWS環境構築ステップバイステップ

それでは、具体的なTerraformコードを使って、AWS上にシンプルなWebサーバー環境を構築する手順を見ていきましょう。ここでは、VPC、サブネット、インターネットゲートウェイ、ルートテーブル、セキュリティグループ、そしてEC2インスタンスを作成します。

プロジェクト構造

まず、プロジェクトのディレクトリ構造を以下のように設定します。

ステップ1: backend.tf の設定

前述の通り、リモートState管理は必須です。まずはS3とDynamoDBを利用する設定を記述します。

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-kwonteki-terraform-state-2026"
    key            = "webserver-env/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "my-kwonteki-terraform-lock-2026"
  }
}

ステップ2: variables.tf の定義

環境によって異なる値や、頻繁に変更される可能性のある値を変数として定義します。これにより、コードの再利用性が高まり、管理が容易になります。

# variables.tf
variable "aws_region" {
  description = "AWS Region"
  type        = string
  default     = "ap-northeast-1"
}

variable "project_name" {
  description = "Project name for tagging resources"
  type        = string
  default     = "KwontekiWebserver"
}

variable "vpc_cidr_block" {
  description = "CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "public_subnet_cidr_block" {
  description = "CIDR block for the public subnet"
  type        = string
  default     = "10.0.1.0/24"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "ami_id" {
  description = "AMI ID for the EC2 instance (Amazon Linux 2023)"
  type        = string
  default     = "ami-0b3273397d3967817" # ap-northeast-1 の Amazon Linux 2023 AMI ID (2026年3月時点の一例)
}

variable "key_pair_name" {
  description = "Name of the EC2 Key Pair to use"
  type        = string
  default     = "kwonteki-keypair" # 既存のキーペア名を指定
}

ステップ3: main.tf の作成

いよいよメインのTerraformコードです。AWSプロバイダの定義から、VPC、サブネット、インターネットゲートウェイ、ルートテーブル、セキュリティグループ、EC2インスタンスまでを順に作成します。

# main.tf
provider "aws" {
  region = var.aws_region
}

# ----------------------------------------------------
# VPC
# ----------------------------------------------------
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "${var.project_name}-VPC"
    Environment = "Development"
  }
}

# ----------------------------------------------------
# Subnet
# ----------------------------------------------------
resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.public_subnet_cidr_block
  availability_zone = "${var.aws_region}a" # 例えば ap-northeast-1a
  map_public_ip_on_launch = true # パブリックIPを自動割り当て

  tags = {
    Name        = "${var.project_name}-PublicSubnet"
    Environment = "Development"
  }
}

# ----------------------------------------------------
# Internet Gateway
# ----------------------------------------------------
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.project_name}-IGW"
    Environment = "Development"
  }
}

# ----------------------------------------------------
# Route Table
# ----------------------------------------------------
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name        = "${var.project_name}-PublicRouteTable"
    Environment = "Development"
  }
}

resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

# ----------------------------------------------------
# Security Group (for Web Server)
# ----------------------------------------------------
resource "aws_security_group" "web_sg" {
  vpc_id      = aws_vpc.main.id
  name        = "${var.project_name}-WebSecurityGroup"
  description = "Allow HTTP/HTTPS and SSH access"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # HTTP (Webアクセス)
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # HTTPS (Webアクセス)
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # SSH (管理アクセス)
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"] # 全ての outbound を許可
  }

  tags = {
    Name        = "${var.project_name}-WebSecurityGroup"
    Environment = "Development"
  }
}

# ----------------------------------------------------
# EC2 Instance (Web Server)
# ----------------------------------------------------
resource "aws_instance" "web_server" {
  ami           = var.ami_id
  instance_type = var.instance_type
  subnet_id     = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.web_sg.id]
  key_name      = var.key_pair_name
  associate_public_ip_address = true # パブリックIPを割り当て

  user_data = <<-EOF
              #!/bin/bash
              sudo yum update -y
              sudo yum install -y httpd
              sudo systemctl start httpd
              sudo systemctl enable httpd
              echo "<h1>Hello from Kwonteki Terraform!</h1>" | sudo tee /var/www/html/index.html
              EOF

  tags = {
    Name        = "${var.project_name}-WebServer"
    Environment = "Development"
  }
}

ステップ4: outputs.tf の定義

デプロイ後に必要な情報（例: EC2のパブリックIPアドレス）をTerraformの出力として定義します。

# outputs.tf
output "web_server_public_ip" {
  description = "The public IP address of the web server"
  value       = aws_instance.web_server.public_ip
}

output "web_server_public_dns" {
  description = "The public DNS name of the web server"
  value       = aws_instance.web_server.public_dns
}

ステップ5: Terraformコマンドの実行

全てのファイルが準備できたら、以下のコマンドを順に実行してインフラをデプロイします。

terraform init

terraform plan

terraform apply

環境を削除したい場合は、以下のコマンドを実行します。

terraform destroy

BEST PRACTICES

5. Terraformベストプラクティス：モジュール化とセキュリティ

Terraformを本番環境で運用するには、単にコードを記述するだけでなく、保守性、再利用性、そしてセキュリティを考慮したベストプラクティスに従うことが重要です。ここでは、特にモジュール化とセキュリティに焦点を当てて解説します。

モジュール化によるコードの再利用と整理

モジュールは、関連するリソースをまとめたTerraformの設定のコンテナです。これにより、コードの再利用、整理、抽象化が可能になります。

例えば、前述のWebサーバー環境をモジュール化する場合、以下のような構造になります。

# root/main.tf (親モジュール)
module "web_app_environment" {
  source = "./modules/webserver-stack" # ローカルモジュールへのパス

  project_name          = "ProductionWebApp"
  aws_region            = "ap-northeast-1"
  vpc_cidr_block        = "10.10.0.0/16"
  public_subnet_cidr_block = "10.10.1.0/24"
  instance_type         = "t3.medium"
  ami_id                = "ami-0b3273397d3967817" # Amazon Linux 2023
  key_pair_name         = "prod-keypair"
}

output "prod_web_server_ip" {
  value = module.web_app_environment.web_server_public_ip
}

そして、modules/webserver-stack ディレクトリ内には、先ほどの main.tf と同じ内容のファイルが配置され、変数や出力が適切に定義されます。

Terraformにおけるセキュリティベストプラクティス

IaCはインフラのセキュリティをコードとして管理できるため、非常に強力なツールとなりますが、同時に誤った設定が大規模なセキュリティリスクを招く可能性も秘めています。

以下の点は、Terraformコードを記述・運用する上で常に意識すべきセキュリティプラクティスです。

これらのプラクティスを実践することで、Terraformを使ったインフラ管理のセキュリティレベルを大幅に向上させることができます。セキュリティは一度設定すれば終わりではなく、継続的な見直しと改善が必要です。

TROUBLESHOOTING

6. よくある課題と解決策

Terraformは非常に強力なツールですが、実際の運用ではいくつかの課題に直面することがあります。ここでは、特によく遭遇する問題とその解決策について解説します。

# Stateファイルを現在のインフラ状態に合わせて更新
terraform refresh

# 変更計画を確認 (refresh後、driftが検出されると差分が表示される)
terraform plan

# 計画に基づいて修正を適用 (手動変更をコードの状態に戻すか、コードをインフラの状態に合わせる)
terraform apply