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. 参考リンク

（次回へ続く）