最近の記事

AWS Well-Architected Framework に従って実装する

ルール

Implementation follows AWS Well-Architected Framework

(AWS Well-Architected Framework に従って実装する)

解説

AWS Well-Architected Framework は、AWSでインフラを構築する際の基本となる設計原則です。 考慮すべき事項の抜け漏れ防止、あるいは関心事の深堀りなどその効用は多岐にわたります。生成AIに活用させるには若干漠然としすぎていますが、それでも指摘せぬわけにいかない重要事項です。

サンプルコード

参考リンク

Infrastructure 開発ガイドライン Design

サービスの監視とアラート機構を準備する

ルール

Prepare service monitoring and alerting mechanisms

(サービスの監視とアラート機構を準備する)

解説

サービスの安定運用には、問題の早期発見と迅速な対応が不可欠です。 CloudWatchやDatadog等を使用して監視・発報の仕組みを用意しておきます。

サンプルコード

参考リンク

Infrastructure 開発ガイドライン Design

埋め込み属性をできるだけ使用しない

ルール

Do not use embedded attributes as much as possible. (e.g., ingress/egress within security groups)

(埋め込み属性をできるだけ使用しない(例: セキュリティグループ内の ingress/egress))

解説

埋め込み属性は可読性が悪い・ループなどの操作がしづらい・更新時に一時的に削除されることがあるなど、使いづらさが目立つため、極力使わないようにします。

サンプルコード

resource "aws_security_group" "web" {
  name        = "${var.environment}-${var.project}-web-sg"
  description = "Webサーバー用セキュリティグループ"
  vpc_id      = var.vpc_id
}

resource "aws_security_group_rule" "web_https_ingress" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.web.id
}

resource "aws_security_group_rule" "web_egress" {
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.web.id
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards

すべての.tfファイルにterraform fmtを適用する

ルール

Apply terraform fmt to all .tf files.

(すべての.tfファイルにterraform fmtを適用する)

解説

「フォーマッタが正しい」これをプロジェクトのルールにします。

個人のスタイルの違いが出ないよう、ツールにすべて任せます。

サンプルコード

# terraform fmt 実行前
resource "aws_instance" "web" {
instance_type="t3.micro"
  ami=data.aws_ami.ubuntu.id
    tags={
  Name="web-server"
    }
}

# terraform fmt 実行後
resource "aws_instance" "web" {
  instance_type = "t3.micro"
  ami           = data.aws_ami.ubuntu.id

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

参考リンク

Infrastructure 開発ガイドライン Coding Standards

重要なリソースとデータは常にバックアップする。DR戦略はバックアップ&リストアレベル

ルール

Always backup important resources and data. DR strategy is at backup & restore level

(重要なリソースとデータは常にバックアップする。DR戦略はバックアップ&リストアレベルとする)

解説

重要なリソースとは自社保有の暗号鍵など、データとはデータベース上のレコードなどです。 これらの消失はサービス存続にも関わる大損害をもたらすため、必ずバックアップします。

ここではコスト面を重視しDR(災害対策)はバックアップ&リストア方式を採用していますが、プロジェクトの性格次第でそれ以外の戦略を取ってももちろんかまいません。

サンプルコード

なし

参考リンク

Infrastructure 開発ガイドライン Design

TFLintを導入してAWSベストプラクティス違反と未使用宣言を検出する

ルール

Introduce TFLint to detect AWS best practice violations and unused declarations.

(TFLintを導入してAWSベストプラクティス違反と未使用宣言を検出する)

解説

人間のレビューを受ける前に機械的なチェックで済ませられることを極力済ませておきます。

これは人間のレビュー負荷軽減に貢献します。

サンプルコード

$ tflint

参考リンク

Infrastructure 開発ガイドライン Coding Standards

terraform validateで構文検証を実行する

ルール

Perform syntax validation with terraform validate.

terraform validateで構文検証を実行する)

解説

生成AIが最初に出したコードには時折構文エラーが含まれます。 これらを自動的に検出し、自動で修正させるため、ツールによるバリデーションを行います。

人間のレビュー負荷軽減のための施策の一つです。

サンプルコード

# 構文検証の実行
$ terraform validate

参考リンク

Infrastructure 開発ガイドライン Coding Standards

terraform.tfvars.jsonはルートモジュールに配置する

ルール

Place terraform.tfvars.json in the root module (the module where terraform apply is executed) instead of submodules.

terraform.tfvars.jsonはルートモジュールに配置し、サブモジュールには配置しない)

解説

混乱防止のため、terraform.tfvars.jsonは必ずルートモジュールに置くルールです。

サンプルコード

# ディレクトリ構造
#
# terraform/
#   production/
#     main.tf
#     variables.tf
#     terraform.tfvars.json    # ← ここに配置
#   modules/
#     networking/
#       main.tf
#       variables.tf
#       # terraform.tfvars.json は配置しない

Infrastructure 開発ガイドライン Coding Standards

terraform.tfvars.jsonには再利用値と機密情報を格納する

ルール

In the root module, ensure terraform.tfvars.json stores: 1) values that other modules might also reuse, 2) sensitive information that must never be hard-coded (e.g., private keys).

(ルートモジュールのterraform.tfvars.jsonには、1) 他のモジュールでも再利用する値、2) ハードコードしてはならない機密情報を格納する)

解説

平文の機密情報はなるべくTerraformを通さずに利用したいところですが、利用せざるを得ないケースもあります。その場合はコード内にハードコーディングせず、terraform.tfvars.jsonに記述してsopsで暗号化します。

なおこのアプローチをとる場合、そのリポジトリでCursorやClaudeCodeなどクラウドタイプのAIを利用してはいけません。

サンプルコード

# terraform.tfvars.json(良い例)
{
  "environment": "production",
  "project": "myapp",
  "region": "ap-northeast-1",
  "db_password": "encrypted_password_here",
  "ssl_certificate_private_key": "encrypted_key_here"
}

# variables.tf
variable "environment" {
  type        = string
  description = "Environment name"
}

variable "project" {
  type        = string
  description = "Project name"
}

variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password"
}

# main.tf
module "database" {
  source = "../modules/database"

  environment = var.environment
  project     = var.project
  password    = var.db_password
}

module "networking" {
  source = "../modules/networking"

  environment = var.environment
  project     = var.project
}

Infrastructure 開発ガイドライン Coding Standards

Nameタグを識別子として使用するリソースには必ずNameタグを設定する

ルール

Always set Name tags for resources that use Name tags as identifiers.

(Nameタグを識別子として使用するリソースには必ずNameタグを設定する)

解説

EC2インスタンスなど、Nameタグが事実上のリソース名として用いられるリソースがいくつかあります。

これらはNameタグが適切につけられていないと管理運用が難しくなるため、必ずセットします。

サンプルコード

resource "aws_instance" "api" {
  tags = {
    Name = "${var.environment}-${var.project}-api"
  }
}

参考リンク

Infrastructure 開発ガイドライン Coding Standards