Terraform azurerm Provider 実務＆Associate対策：Azureでのよくある設定集

azurerm Provider は Azure Resource Manager (ARM) API を呼び出す Terraform の拡張機能です。認証方式、サブスクリプションの切り替え、タグやリージョンの既定化など、現場でつまずきやすい箇所を試験観点と併せて解説します。

本稿は安定的な公式挙動を前提に書いています。バージョン依存の機能は注意書きを添えており、検証環境での確認を推奨します。

azurerm Provider の全体像とバージョン管理

azurerm Provider は Terraform から Azure Resource Manager (ARM) に対してリソースの作成・更新・削除を行うためのコンポーネントです。Terraform 本体は宣言・依存解決・差分計算を担い、実際の API 呼び出しは Provider が担当します。

実務では必ず required_providers でバージョンを固定し、provider ブロックに features {} を明示します。features は azurerm で必須の空ブロックで、消すと初期化時にエラーになります。また、デフォルトで Provider は ARM の Resource Provider (Microsoft.Compute 等) を自動登録します。組織のガードレールで自動登録が禁止されている場合は skip_provider_registration を使用します。

• Associate 試験では required_providers によるバージョンピン留めと features {} の必須性が頻出。
• skip_provider_registration は企業ポリシーや事前登録が済んでいる環境でのみ使用。
• プロキシ越しやクラウドシェル等の環境差で動作が変わるため、開発者ローカルと CI の両方で init/plan を検証する。

Terraform と azurerm Provider の関係と認証の流れ（概念図）

最小構成（バージョン固定と features、登録スキップの制御）

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.100"
    }
  }
}

provider "azurerm" {
  features {}
  # 事前にRP登録済みなら true を検討
  # skip_provider_registration = true
}

認証方式の比較と選び方（CLI / マネージドID / サービスプリンシパル / OIDC）

azurerm では複数の認証方式を選べます。ローカル開発は Azure CLI、Azure 上のランナーはマネージド ID、CI/CD はシークレット不要のフェデレーション（OIDC）やサービスプリンシパルなど、実行環境に合わせて使い分けます。

環境変数 (ARM_CLIENT_ID 等) を使うと provider ブロックの機密情報埋め込みを避けられます。OIDC によるフェデレーションはバージョン依存の設定が含まれるため、利用時は該当バージョンの公式ドキュメントでオプション名を確認してください。

• ローカル最小手順は az login 後に use_azure_cli = true。
• マネージド ID はサブスクリプションやリソースへの RBAC 付与を忘れない。
• CI ではシークレットレス運用（OIDC）が推奨傾向。非対応なら SP のクライアントシークレット/証明書を環境変数で渡す。

代表的な認証設定例

# 1) Azure CLI を利用
provider "azurerm" {
  features {}
  use_azure_cli = true
}

# 2) Managed Identity（システム割り当て）
provider "azurerm" {
  features {}
  use_msi         = true
  subscription_id = var.subscription_id
  tenant_id       = var.tenant_id
}

# 3) Service Principal（環境変数で供給）
# export ARM_CLIENT_ID=... ARM_CLIENT_SECRET=... ARM_TENANT_ID=... ARM_SUBSCRIPTION_ID=...
provider "azurerm" {
  features {}
}

# 4) OIDC（フェデレーション）
# バージョンによりオプション名が異なるため公式を要確認
# 例: use_oidc = true, oidc_token_file_path = var.oidc_token_file_path など

サブスクリプション／テナントの切り替えと alias の使い分け

複数サブスクリプションにまたがるデプロイでは、provider の alias を使います。各 alias に subscription_id／tenant_id／認証方式を分離し、リソース単位で provider を明示するのが安全です。

同一実行で Azure CLI のアカウントコンテキストを頻繁に切り替えるのは不安定化の原因になります。CI では alias を定義し、plan/apply 時に明示的に使い分けましょう。

• resource と data は provider = azurerm.alias で接続先を固定する。
• 同名リソースを複数サブに作る場合は key や名前規則で衝突を避ける。
• workspace で環境は分けつつ、subscription は alias で切り替えると管理しやすい。

alias によるマルチサブスクリプション配置

provider "azurerm" {
  alias           = "hub"
  features        {}
  subscription_id = var.hub_subscription_id
  tenant_id       = var.tenant_id
  use_azure_cli   = true
}

provider "azurerm" {
  alias           = "spoke"
  features        {}
  subscription_id = var.spoke_subscription_id
  tenant_id       = var.tenant_id
  use_azure_cli   = true
}

resource "azurerm_resource_group" "rg_hub" {
  name     = "rg-hub-shared"
  location = var.location
  provider = azurerm.hub
}

resource "azurerm_resource_group" "rg_spoke" {
  name     = "rg-spoke-app"
  location = var.location
  provider = azurerm.spoke
}

リージョン・命名規則・タグの既定化

リージョンは variables で一元管理し、命名は locals で規則化するのが定石です。これにより review しやすく、試験でも再現性・可読性の観点が評価されます。

azurerm は provider レベルの default_tags をサポートします。default_tags とリソース個別の tags はマージされ、キーが重複した場合はリソース側の値が優先されます。タグの横展開やガバナンスに有効です。

features.resource_group.prevent_deletion_if_contains_resources を使うと、リソースを抱えた RG の誤削除を防げます（デフォルト値はバージョンで異なる可能性があるため、意図を持って明示設定を推奨）。

• ストレージアカウント名は小文字・英数字のみ、長さ制限あり。命名はリソース種別ごとにローカルで分岐させる。
• タグは environment, owner, cost-center などを最小セットとしてプロジェクト共通化。
• location は可能な限り単一変数から参照。マルチリージョン時は可読な map を利用。

location/命名/デフォルトタグのパターン

variable "location" {
  type    = string
  default = "japaneast"
}

variable "env" { type = string }
variable "owner" { type = string }

locals {
  name_prefix = lower(join("-", [var.env, "app01"]))
  rg_name     = "rg-${local.name_prefix}"
}

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = true
    }
  }
  default_tags {
    tags = {
      environment = var.env
      owner       = var.owner
    }
  }
}

resource "azurerm_resource_group" "main" {
  name     = local.rg_name
  location = var.location
  tags = {
    # 同じキーがある場合はこの値が優先される
    owner = var.owner
  }
}

よくある落とし穴とデバッグの勘所

Resource Provider の自動登録が抑止されていると、特定のリソース作成で 404/AuthorizationFailed が発生します。この場合は skip_provider_registration を true にしても根本解決にならないことがあるため、運用設計として事前登録 or 自動登録許可のいずれかを明確化します。

Service Principal 利用時は期限切れ・権限不足が典型。Contributor では足りないケース（Key Vault のデータプレーン等）に注意。Azure CLI 認証は現在の az account set のサブスクリプションに依存するため、CI では非推奨です。

障害切り分けは Terraform のデバッグログと ARM のエラーメッセージを突き合わせます。まず plan で再現し、再試行時は -parallelism の調整で一時的なスロットリングを回避することもできます。

• az account show / az account list --refresh で CLI の現在コンテキストを確認。
• 環境変数 ARM_CLIENT_ID/SECRET/TENANT_ID/SUBSCRIPTION_ID を明示して CLI 依存を排除。
• 長時間実行の CI はトークン期限切れを起点に失敗することがあるため、ステップを分割。

デバッグのための環境変数とログ

# Service Principal（シークレット）の例
export ARM_CLIENT_ID=00000000-0000-0000-0000-000000000000
export ARM_CLIENT_SECRET=********
export ARM_TENANT_ID=11111111-1111-1111-1111-111111111111
export ARM_SUBSCRIPTION_ID=22222222-2222-2222-2222-222222222222

# 詳細ログ（必要な時だけ）
export TF_LOG=TRACE
export TF_LOG_PATH=./terraform.trace.log

# Azure CLI の現在サブスクリプションを明示
az account set --subscription $ARM_SUBSCRIPTION_ID

リモートステート（Azure Storage backend）とロック

バックエンドの azurerm は Provider とは別物で、terraform ブロックの backend で宣言します。State は Azure Storage の Blob に保存され、ロックは Blob のリースで実現されます。

CI では Backend 用のリソースグループ／ストレージアカウント／コンテナを事前に IaC で用意し、アクセスは Azure AD（推奨）か SAS で与えます。バケット相当のコンテナには バージョニング／ソフトデリート を有効化すると復旧が容易です。

• State 用ストレージは運用と権限を分離し、汎用の prod/tfstate 等の命名に統一する。
• key は workspace ごとに分けると衝突を防げる。
• 認証は Azure CLI／Managed Identity／Service Principal のいずれでも可。

azurerm Backend の例（provider ではなく terraform ブロックに記述）

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "sttfstate1234"
    container_name       = "tfstate"
    key                  = "${terraform.workspace}.tfstate"
  }
}

# 認証は実行環境に依存（例：az login、Managed Identity、ARM_* 環境変数）

問題で確認

よくある質問