最近の記事

出力ブロックで変数ブロックを参照しない

ルール

Do not reference variable blocks as values in output blocks.

(出力ブロックで変数ブロックを参照しない)

解説

AWSの推奨に従っています。

出力ブロックに変数をそのまま格納するのは無駄ですから普通しないと思いますが、念のため残しています。

サンプルコード(悪い例)

variable "name" {
  description = "Resource name"
  type = string
}

output "name" {
  description = "Name of Resource"
  value       = var.name
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards

他モジュールの呼び出しはmain.tfに定義する

ルール

Define calls to other modules in main.tf.

(他モジュールの呼び出しはmain.tfに定義する)

解説

AWSの推奨に従っています。

モジュール呼び出しは必ずmain.tfにある、とわかっていれば、モジュールの呼び出し部分を迷わず見つけることが可能です。

サンプルコード

# main.tf
module "networking" {
  source = "./modules/networking"
  vpc_cidr = var.vpc_cidr
}

module "database" {
  source = "./modules/database"
  vpc_id = module.networking.vpc_id
  db_subnet_ids = module.networking.private_subnet_ids
}

module "application" {
  source = "./modules/application"
  vpc_id = module.networking.vpc_id
  db_endpoint = module.database.endpoint
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards

localsブロックの使用を最小限にする

ルール

Minimize the use of locals blocks. If used, define them in locals.tf.

localsブロックの使用を最小限にする。使用する場合はlocals.tfに定義する)

解説

AWSの推奨に従っています。

使用する際はlocals.tfに集約することで、ローカル変数の定義場所を一元化し可読性を維持します。

サンプルコード

# locals.tf
locals {
  # 複数の変数を組み合わせた共通タグ
  common_tags = {
    Environment = var.environment
    Project     = var.project
  }

  # 計算が必要な値
  common_prefix = "${var.environment}-${var.project}-"
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards

固定値はリソース定義に直接記述してよい

ルール

Fixed values may be coded directly in resource definitions. (e.g., t4g.micro)

(固定値はリソース定義に直接記述してよい(例:t4g.micro))

解説

生成AIはむやみやたらとvariablesを使いたがる傾向があります。そこで明示的にそれを抑制しています。

サンプルコード

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t4g.micro"  # 固定値を直接記述

  tags = {
    Name = "web-server"
  }
}

Infrastructure 開発ガイドライン Coding Standards

dataブロックの使用を最小限にする

ルール

Minimize the use of data blocks. If used, place them immediately above the resource block that references them.

dataブロックの使用を最小限にする。使用する場合は、参照するリソースブロックの直前に配置する)

解説

dataブロックは便利なのですが、AWS APIへの問い合わせが行われるため、多用するとTerraformの実行が遅くなります。 そのため使わなくてもよい場面ではDataブロックではなくvariablesを利用します。

ただし禁止ではないため、使用することもあります。その場合はなるべく読みやすいよう参照するリソースの直前に配置します。

サンプルコード

# 使用するリソースの直前にdataブロックを配置
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]  # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards

コードから明らかな内容をコメントに書かない

ルール

Do not add comments describing what is already clear from the code.

(コードから明らかな内容を説明するコメントを追加しない)

解説

コードを見れば分かる内容を繰り返すコメントは害のほうが大きいため禁止しています。

サンプルコード

# 良い例
resource "aws_s3_bucket_lifecycle_configuration" "logs" {
  bucket = aws_s3_bucket.logs.id

  rule {
    id     = "delete_old_logs"
    status = "Enabled"

    # 監査要件により90日間保持
    expiration {
      days = 90
    }
  }
}

# 悪い例(参考)
# resource "aws_s3_bucket" "logs" {  # <- S3バケットを作成
#   bucket = "${var.environment}-${var.project}-logs"  # <- バケット名を設定
# }

Infrastructure 開発ガイドライン Coding Standards

*.tfファイルのコメントを最小限に保つ

ルール

*Keep comments in .tf files to a minimum. Avoid adding header blocks or documentation-level specifications in comments.

(*.tfファイルのコメントを最小限に保つ。ヘッダーブロックの追加禁止。またドキュメントに記載すべき仕様も書いてはならない)

解説

生成AIはしばしば大量のコメントやヘッダーブロックをコード内に埋め込もうとします。しかし過剰なコメントは可読性を落とし、コメントの保守の手間を増やし、トークン効率を悪化させます。そのため禁止しています。

サンプルコード

# 良い例: 最小限のコメント、自己文書化されたコード
variable "instance_type" {
  type        = string
  description = "EC2インスタンスタイプ。本番環境ではt3.mediumを推奨"
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  # セキュリティ要件により、IMDSv2を強制
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
  }
}

Infrastructure 開発ガイドライン Coding Standards

略語を避け、完全な名前を使用する

ルール

Avoid abbreviations, use full names (e.g., cgcoding_guidelines). However, abbreviations used as proper nouns (e.g., RDS, id) may be used.

(略語を避け、完全な名前を使用する(例: cgcoding_guidelines)。ただし、固有名詞として使用される略語(例: RDS, id)は使用可能)

解説

独自の略語は外部の人員や将来の担当者が意図を理解しにくくなるため極力利用を控えます。

ただし、RDSやidのような固有名詞に近いものは利用してかまいません。

サンプルコード

# 完全な名前を使用。ただしidのように半ば固有名詞として使われているものは可
variable "security_group_id" {
  type        = string
  description = "Security Group ID"
}

# このような略し方はNG
variable "sg_id" {
  type        = string
  description = "Security Group ID"
}

Infrastructure 開発ガイドライン Coding Standards

実装はAWS Well-Architected Frameworkを考慮する

ルール

Implementation should consider the AWS Well-Architected Framework, though strict compliance is not required.

(実装はAWS Well-Architected Frameworkを考慮する。ただし厳格な準拠は要求しない)

解説

AWS Well-Architected Frameworkは大変優れた設計原則であり、何をおいてもこの考え方が設計の基本となります。 ただしその方針を具体化したルールの中には準拠が難しいものも含まれるため、参考に止めればよいとしています。

Infrastructure 開発ガイドライン Coding Standards

ストレージ単位にはMiB/GiBを使用し、その他にはMB/GBを使用する

ルール

Use MiB/GiB for storage units, and MB/GB (decimal units) for others.

(ストレージ単位にはMiB/GiBを使用し、その他にはMB/GBを使用する)

解説

ストレージ容量(ディスク/ボリューム/スナップショット等)はバイナリ単位を使用します。それ以外のメトリクス(ネットワーク転送量、帯域など)は10進数の単位を使用します。単位の微妙な違いによる勘違いを防止します。

サンプルコード

# ストレージには2進数(GiB/MiB)を使用
variable "ebs_volume_size_gib" {
  type        = number
  description = "EBS volume size in GiB"
}

# それ以外は10進単位を使用
variable "cw_alarm_network_out_threshold_mb" {
  type        = number
  description = "CloudWatch Alarm threshold for NetworkOut in MB"
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards