【AWS Fargate:第3回】Terraformパラメータ設計：設計と実装を繋ぐ架け橋

Last updated at 2026-01-23Posted at 2026-01-23

1. この記事について（6回シリーズ）

この記事は【AWS Fargate】実務的な設計フロー学習シリーズの第3弾です。

記事	タイトル	内容
第1弾	設計思考編	なぜ設計が先なのか
第2弾	図解編	構成図・フロー図・シーケンス図
第3弾	パラメータ設計編	Terraformパラメータ設計
第4弾	Terraform実装編	コード作成からplan成功まで
第5-1弾	実装編	apply〜アクセス確認
第5-2弾	運用・削除編	トラブルシューティング〜destroy

📁 完全なコードはGitHubで公開：GitHub: fargate-iac01

2. はじめに

2-1. この記事の位置づけ

第1弾で学んだ8ステップのうち、この記事ではSTEP 6-7を扱います。

STEP	工程	記事	状態
1	グランドデザイン	第1弾	✅ 完了
2-5	可視化（図の作成）	第2弾	✅ 完了
6	パラメータ設計	第3弾（この記事）	📝 今ここ
7	IaC設計	第3弾（この記事）	📝 今ここ
8	実装・テスト	第4弾〜第5-2弾	📋 次回以降

今回のゴール:

STEP 6: 全パラメータを表にまとめる
STEP 7: Terraformのファイル構成を決める

2-2. 前回までのおさらい

第1弾・第2弾で、設計の基礎を固めました。

記事	完了した内容	成果物
第1弾	グランドデザイン	要件表
第2弾	4種類の図	基本構成図、詳細構成図、フロー図、シーケンス図

ここまでで分かったこと:

何を作るか（Apache on Fargate）
どう繋がるか（VPC → Subnet → ECS → ECR）
データの流れ（HTTPリクエスト → IGW → Fargate → レスポンス）

次は、具体的なパラメータ（CIDR、CPU、Memory等）を決めていきます。

2-3. この記事で得られるもの

得られること	説明
✅ Terraform設計	ファイル構成とモジュール化の判断
✅ Terraformパラメータ表	variables.tf/terraform.tfvarsの設計
✅ 変数化の判断基準	何を変数にするか、何をハードコードするか
✅ 実務の考え方	パラメータ設計の思考プロセス

3. パラメータ表とは

3-1. パラメータ表の役割

パラメータ表は、設計と実装を繋ぐ架け橋だと思います。

フェーズ	成果物	パラメータ表の使い方
設計	構成図・フロー図	パラメータを整理
実装（IaC）	Terraformコード	variables.tfに変換

3-2. 料理で例えると

料理の工程	パラメータ表の例え
レシピを考える	設計（構成図）
材料の分量表を作る	パラメータ表
実際に調理	実装（Terraform）

3-3. なぜパラメータ表が必要？

3-3-1. 実務で必須とされる理由

理由	説明	具体例
✅ レビュー可能性	非エンジニアでもパラメータを確認できる	PM、セキュリティ担当がCIDRを確認
✅ 変更管理	コード変更前にパラメータ変更を承認	「CPU 256→512」を事前承認
✅ 証跡・監査	「なぜこの値を選んだか」を記録	セキュリティ監査で説明可能
✅ 引き継ぎ	退職・異動時にも設計意図が残る	「なぜこのCIDRか」が分かる
✅ 複数環境管理	dev/stg/prd の差分を一覧化	環境ごとのCPU差分を把握
✅ ミス防止	コードを書く前にパラメータを整理	CIDR重複を事前検知

3-3-2. 設計フロー

ステップ	成果物	レビュー対象
① 構成図を描く	Mermaid図	アーキテクト、PM
② パラメータ表を作る	パラメータ表	全メンバー（非エンジニア含む）
③ Terraform設計	variables.tf	エンジニア
④ 実装	Terraformコード	エンジニア

ポイント:

パラメータ表はコードではなく表なので、非エンジニアでもレビューできる
「いきなりコードを書かない」ことで、設計ミスを早期発見

4. Terraform用パラメータ表を考察してみる

何を変数化すべきかを考えることが重要だと思いました。

4-1. 変数化の判断基準

項目	変数化する？	理由
環境差分	✅ する	dev/stg/prdで変わる
リージョン	✅ する	デプロイ先が変わる可能性
CIDR	✅ する	ネットワーク設計で変わる
タグ	✅ する	プロジェクトごとに変わる
CPU/Memory	✅ する	負荷に応じて調整
ネットワークモード	❌ しない	Fargateでは awsvpc 固定
ポート番号	❌ しない	HTTP = 80 で仕様固定
インターネット向けルート	❌ しない	0.0.0.0/0 → IGW で固定

判断のポイント:

「将来変わる可能性があるか？」
「環境ごとに違う値になるか？」

4-2. variables.tf vs terraform.tfvars

ファイル	役割	例
variables.tf	変数の定義・型・制約・デフォルト値	`type = string, validation, default`
terraform.tfvars	変数の実際の値	`region = "ap-northeast-1"`

ポイント:

variables.tfは「型定義」（コード管理対象）
terraform.tfvarsは「実際の値」（gitignore推奨）

料理で例えると:

variables.tf = 「砂糖：大さじ○杯」という記入欄の設計
terraform.tfvars = 「砂糖：大さじ2杯」という実際の分量

5. Terraform設計

Terraformでコード化する前に、ファイル構成を設計します。

5-1. 作業ディレクトリの準備

まず、Terraformファイルを配置する作業ディレクトリを作成します。

# ホームディレクトリに移動
$ cd ~

# 作業ディレクトリを作成
$ mkdir fargate-terraform
$ cd fargate-terraform

# 現在のディレクトリを確認
$ pwd
/home/username/fargate-terraform

重要: 以降、この記事のコマンドは全て ~/fargate-terraform/ ディレクトリで実行します。

5-2. ディレクトリ構成

~/fargate-terraform/          # ← 作業ディレクトリ
├── main.tf              # プロバイダー設定、共通タグ
├── vpc.tf               # VPC、Subnet、IGW、Route Table
├── security.tf          # Security Group
├── ecr.tf               # ECR Repository
├── ecs.tf               # Cluster、Task Definition、Service
├── iam.tf               # ECS Task Execution Role
├── variables.tf         # 変数定義
├── outputs.tf           # 出力値（Public IPなど）
├── terraform.tfvars     # 変数の値（gitignore対象）
└── .gitignore           # 除外ファイル設定

合計: 10ファイル

5-3. ファイル別の責務

ファイル	役割	具体的な内容	料理の例え
main.tf	プロバイダー設定	Terraformバージョン、AWS Provider、リージョン、default_tags	調理器具のセットアップ
vpc.tf	ネットワーク基盤	VPC、Subnet、IGW、Route Table	レストランの建物
security.tf	セキュリティ設定	Security Group（80/tcp許可）	防犯設備
ecr.tf	コンテナイメージ保管	ECR Repository（apache-repo）	レシピ本の本棚
ecs.tf	コンテナ実行環境	Cluster、Task Definition、Service	調理器具と調理ルール
iam.tf	権限設定	ECS Task Execution Role、Policy	スタッフの権限
variables.tf	変数定義	型定義、validation、default値	材料リスト（記入欄）
terraform.tfvars	変数の値	実際のパラメータ値	実際の分量
outputs.tf	出力値	Public IP、ECR URL	完成品の情報
.gitignore	Git除外設定	terraform.tfvars、.terraform/等	秘密のメモは保管庫へ

5-4. モジュール化しない理由

状況	モジュール化	理由
学習用・検証環境	❌ 不要	全体が見渡せる、学習しやすい
本番環境（複数環境）	✅ 推奨	dev/stg/prd で再利用

今回は学習用なので、シンプルな構成にしています。

5-5. outputs.tfの考え方

outputs.tfは、terraform apply後に確認したい値を出力します。

5-5-1. 何を出力すべきか？

出力すべきもの	理由	例
接続情報	手動で確認・アクセスする	ALB DNS名、Public IP
リソースID	後続処理で使用	VPC ID、Subnet ID
環境情報	デバッグ・確認用	ECR URL、Cluster名

5-5-2. 今回の構成で出力するもの

出力項目	用途
ECR Repository URL	Dockerイメージpush先を確認
ECS Cluster名	タスク確認コマンドで使用
ECS Service名	タスク確認コマンドで使用

5-5-3. variables.tf vs outputs.tf

項目	variables.tf	outputs.tf
目的	入力（パラメータ）	出力（結果）
設計タイミング	✅ 事前設計必須	△ 後から追加でもOK
使い方	リソース作成時に使用	apply後の確認・後続処理

ポイント:

学習用・単一環境: outputs.tfは後から「必要なもの」を追加でOK
複数環境・モジュール化: 事前設計が推奨
今回のシリーズ: 必要最小限の出力のみ（ECR URL、Cluster名、Service名）

5-6. Terraformとプロバイダーのバージョン指定

# Terraformのバージョン指定
terraform {
  # Terraform本体のバージョン（1.0以上を要求）
  required_version = ">= 1.0"
  
  # 使用するプロバイダーとそのバージョン
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"  # AWS Provider 5.x系を使用
    }
  }
}

# AWSプロバイダーの設定
provider "aws" {
  region = var.aws_region  # デプロイ先のリージョン
  
  # 全リソースに自動適用される共通タグ
  default_tags {
    tags = {
      Project     = var.project_name  # プロジェクト名
      Environment = "learning"         # 環境（学習用）
      ManagedBy   = "terraform"        # 管理方法
    }
  }
}

ポイント:

required_version: Terraform本体のバージョンを指定
required_providers: 使用するプロバイダーとバージョンを明示
~> 5.0: 5.x系の最新を使用（5.0以上、6.0未満）

5-7. `default_tags`のメリット

各リソースで Name タグだけ設定すればOK
Project、Environment、ManagedBy は自動付与
タグの付け忘れを防止

6. Terraformパラメータ表(`variables.tf`の設計準備)

構成図のパラメータを、variables.tfで使用する変数します。

6-1. ネットワーク設定

パラメータ	設定値	Terraform変数名	terraform.tfvars値	変数化判断
VPC
名前タグ	fargate-vpc	`project_name` + "-vpc"	-	動的生成
IPv4 CIDR	10.0.0.0/16	`vpc_cidr`	"10.0.0.0/16"	✅ 変数化
DNS解決	有効	（ハードコード: true）	-	❌ 固定値
DNSホスト名	有効	（ハードコード: true）	-	❌ 固定値
Subnet
名前タグ	fargate-public-subnet	`project_name` + "-public-subnet"	-	動的生成
IPv4 CIDR	10.0.1.0/24	`subnet_cidr`	"10.0.1.0/24"	✅ 変数化
AZ	ap-northeast-1a	`availability_zone`	"ap-northeast-1a"	✅ 変数化
Public IP自動割当	有効	（ハードコード: true）	-	❌ 固定値
Internet Gateway
名前タグ	fargate-igw	`project_name` + "-igw"	-	動的生成
Route Table
送信先	0.0.0.0/0	（ハードコード）	-	❌ 固定値
ターゲット	IGW	`aws_internet_gateway.main.id`	-	リソース参照

6-2. セキュリティグループ設定

パラメータ	設定値	Terraform変数名	terraform.tfvars値	変数化判断
名前タグ	fargate-sg	`project_name` + "-sg"	-	動的生成
インバウンド
ポート	80	（ハードコード: 80）	-	❌ HTTP固定
ソース	0.0.0.0/0	（ハードコード）	-	❌ インターネット公開
アウトバウンド
全て許可	有効	（ハードコード）	-	❌ デフォルト設定

6-3. ECS設定

パラメータ	設定値	Terraform変数名	terraform.tfvars値	変数化判断
Cluster
名前	fargate-cluster	`project_name` + "-cluster"	-	動的生成
Task Definition
CPU	.25 vCPU	`cpu`	256	✅ 負荷調整
Memory	.5 GB	`memory`	512	✅ 負荷調整
Network Mode	awsvpc	（ハードコード: "awsvpc"）	-	❌ Fargate必須
Container
Image	httpd:2.4	`container_image`	"httpd:2.4"	✅ バージョン管理
Port	80	（ハードコード: 80）	-	❌ HTTP固定
Service
Desired Count	1	`desired_count`	1	✅ スケール調整
Public IP	有効	（ハードコード: "ENABLED"）	-	❌ 必須設定

6-4. ECR設定

パラメータ	設定値	Terraform変数名	terraform.tfvars値	変数化判断
Repository名	apache-repo	`ecr_repository_name`	"apache-repo"	✅ プロジェクト依存
Image Tag Mutability	MUTABLE	（ハードコード）	-	❌ 開発環境推奨

7. variables.tf の設計

7-1. 共通設定

# ファイル: variables.tf（共通設定部分）

# AWSリージョンの設定
variable "aws_region" {
  description = "リソースを作成するAWSリージョン"
  type        = string
  default     = "ap-northeast-1"  # 東京リージョン
}

# プロジェクト名の設定
variable "project_name" {
  description = "リソース命名とタグ付けに使用するプロジェクト名"
  type        = string
  default     = "fargate-terraform"
  
  # プロジェクト名の妥当性チェック（1文字以上32文字以下）
  validation {
    condition     = length(var.project_name) > 0 && length(var.project_name) <= 32
    error_message = "project_nameは1文字以上32文字以下で指定してください。"
  }
}

7-2. ネットワーク設定

# ファイル: variables.tf（ネットワーク設定部分）

# VPCのCIDRブロック
variable "vpc_cidr" {
  description = "VPCのCIDRブロック（IPアドレス範囲）"
  type        = string
  default     = "10.0.0.0/16" 
}

# Public SubnetのCIDRブロック
variable "subnet_cidr" {
  description = "Public SubnetのCIDRブロック（IPアドレス範囲）"
  type        = string
  default     = "10.0.1.0/24"
}

# サブネットを配置するアベイラビリティゾーン
variable "availability_zone" {
  description = "サブネットを配置するアベイラビリティゾーン"
  type        = string
  default     = "ap-northeast-1a"  # 東京リージョンのAZ-A
}

7-3. ECS設定

# ファイル: variables.tf（ECS設定部分）

# Fargateタスクに割り当てるCPU
variable "cpu" {
  description = "FargateタスクのCPUユニット（256, 512, 1024など）"
  type        = number
  default     = 256  # 0.25 vCPU
  
  # CPUは特定の値のみ許可（Fargateの制約）
  validation {
    condition     = contains([256, 512, 1024, 2048, 4096], var.cpu)
    error_message = "cpuは次のいずれかを指定してください: 256, 512, 1024, 2048, 4096"
  }
}

# Fargateタスクに割り当てるメモリ
variable "memory" {
  description = "FargateタスクのメモリサイズMB（512, 1024, 2048など）"
  type        = number
  default     = 512  # 512MB
}

# 起動するタスクの数
variable "desired_count" {
  description = "起動するタスクの希望数"
  type        = number
  default     = 1  # 学習用のため1タスクのみ
}

# コンテナイメージの指定
variable "container_image" {
  description = "使用するコンテナイメージ（例: httpd:2.4）"
  type        = string
  default     = "httpd:2.4"  # Apache HTTPサーバー
}

# ECRリポジトリ名
variable "ecr_repository_name" {
  description = "Dockerイメージを保管するECRリポジトリの名前"
  type        = string
  default     = "apache-repo"
}

# Dockerイメージのタグ
variable "image_tag" {
  description = "Docker image tag"
  type        = string
  default     = "latest"
}

ポイント:

CPUは選択肢が限られているためvalidationで制約
その他は学習の焦点を保つため、シンプルな定義に

7-4. コラム：validationについて

本記事では学習の焦点を明確にするため、validationを最小限にしています。
実務では、入力値の妥当性チェックとして以下のようなvalidationを追加することも検討：

例1: CIDR形式のチェック

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
  
  validation {
    condition     = can(regex("^([0-9]{1,3}\\.){3}[0-9]{1,3}/[0-9]{1,2}$", var.vpc_cidr))
    error_message = "vpc_cidr must be a valid CIDR block."
  }
}

例2: 範囲のチェック

variable "memory" {
  description = "Memory for Fargate Task"
  type        = number
  default     = 512
  
  validation {
    condition     = var.memory >= 512 && var.memory <= 30720
    error_message = "memory must be between 512 and 30720."
  }
}

参考元URL: Terraform - Variable Validation

8. terraform.tfvars の設計

# 共通設定
aws_region   = "ap-northeast-1"
project_name = "fargate-terraform"

# ネットワーク設定
vpc_cidr          = "10.0.0.0/16"
subnet_cidr       = "10.0.1.0/24"
availability_zone = "ap-northeast-1a"

# ECS設定
cpu                  = 256
memory               = 512
desired_count        = 1
container_image      = "httpd:2.4"
ecr_repository_name  = "apache-repo"
image_tag            = "latest"

ポイント:

環境ごとに別ファイル（dev.tfvars、stg.tfvars）を用意できるが、
今回は自動読み込みができるファイル名。
terraform.tfvarsは .gitignore に追加（秘密情報を含む場合）

9. 変数化 vs ハードコードの実例

9-1. ケース1: VPC CIDR（変数化）

理由: プロジェクトごとにCIDRが変わる可能性

# variables.tf
variable "vpc_cidr" {
  type    = string
  default = "10.0.0.0/16"
}

# vpc.tf
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
}

9-2. ケース2: ネットワークモード（ハードコード）

理由: Fargateでは awsvpc 固定

# ecs.tf
resource "aws_ecs_task_definition" "main" {
  network_mode = "awsvpc"  # ハードコード
}

9-3. ケース3: Security Group ポート（ハードコード）

理由: HTTPアプリなので80番固定

# security.tf
resource "aws_security_group_rule" "ingress" {
  from_port = 80  # ハードコード
  to_port   = 80  # ハードコード
}

10. まとめ

10-1. この記事で学んだこと

項目	内容
✅ Terraform設計	ファイル構成（10ファイル）
✅ 変数化の判断	環境差分がある項目を変数化
✅ variables.tf	型定義・validation・デフォルト値
✅ terraform.tfvars	実際の値を記載

10-2. 8ステップの進捗

この記事で、8ステップのうちSTEP 6-7が完了しました！

STEP	工程	記事	状態
1	グランドデザイン	第1弾	✅ 完了
2-5	可視化（図の作成）	第2弾	✅ 完了
6	パラメータ設計	第3弾	✅ 完了
7	IaC設計	第3弾	✅ 完了
8	実装・テスト	第4弾〜第5-2弾	📋 次回

達成したこと:

✅ 全パラメータを表にまとめた
✅ 変数化の判断基準を理解した
✅ Terraformのファイル構成を決めた

次は、ついにSTEP 8: 実装に進みます！

10-3. パラメータ設計のポイント

ポイント	説明
✅ 変数化の基準	「将来変わる可能性」で判断
✅ validation	不正な値を事前にチェック
✅ default値	一般的な値をデフォルトに
✅ ファイル分割	責務ごとにファイルを分ける

11. 実務で活きる場面

このパラメータ設計は、以下のような場面で活きます：

シーン	活用方法
新規プロジェクト	variables.tfをテンプレート化
複数環境	dev.tfvars、stg.tfvars、prd.tfvars
レビュー	パラメータ表でパラメータを確認
引き継ぎ	variables.tfを見れば設計意図が分かる

12. 次の記事へ

次の第4弾では、Terraform実装編に進みます。
このパラメータ表をもとに、実際のTerraformコードを作成します。

12-1. 次回の内容

内容	説明
10ファイルの実装	main.tf、vpc.tf等の詳細解説
terraform init	プロバイダーの初期化
terraform validate	構文チェック
terraform plan	実行計画の確認

設計が完了したので、いよいよコードを書いていきましょう！

13. 参考リンク

（次回へ続く）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【AWS Fargate:第3回】Terraformパラメータ設計：設計と実装を繋ぐ架け橋

1. この記事について（6回シリーズ）

2. はじめに

2-1. この記事の位置づけ

2-2. 前回までのおさらい

2-3. この記事で得られるもの

3. パラメータ表とは

3-1. パラメータ表の役割

3-2. 料理で例えると

3-3. なぜパラメータ表が必要？

3-3-1. 実務で必須とされる理由

3-3-2. 設計フロー

4. Terraform用パラメータ表を考察してみる

4-1. 変数化の判断基準

4-2. variables.tf vs terraform.tfvars

5. Terraform設計

5-1. 作業ディレクトリの準備

5-2. ディレクトリ構成

5-3. ファイル別の責務

5-4. モジュール化しない理由

5-5. outputs.tfの考え方

5-5-1. 何を出力すべきか？

5-5-2. 今回の構成で出力するもの

5-5-3. variables.tf vs outputs.tf

5-6. Terraformとプロバイダーのバージョン指定

5-7. default_tagsのメリット

6. Terraformパラメータ表(variables.tfの設計準備)

6-1. ネットワーク設定

6-2. セキュリティグループ設定

6-3. ECS設定

6-4. ECR設定

7. variables.tf の設計

7-1. 共通設定

7-2. ネットワーク設定

7-3. ECS設定

7-4. コラム：validationについて

8. terraform.tfvars の設計

9. 変数化 vs ハードコードの実例

9-1. ケース1: VPC CIDR（変数化）

9-2. ケース2: ネットワークモード（ハードコード）

9-3. ケース3: Security Group ポート（ハードコード）

10. まとめ

10-1. この記事で学んだこと

10-2. 8ステップの進捗

10-3. パラメータ設計のポイント

11. 実務で活きる場面

12. 次の記事へ

12-1. 次回の内容

13. 参考リンク

5-7. `default_tags`のメリット

6. Terraformパラメータ表(`variables.tf`の設計準備)