Azure Resource Manager / Bicep

解決する課題

クラウド インフラを手作業のポータル操作で構築すると、環境差異・設定漏れ・再現性の欠如が避けられません。Azure Resource Manager（ARM）と Bicep は、インフラをコードとして宣言的に記述し、繰り返し同じ結果で展開できるようにします。

• 開発・検証・本番で同一構成を再現したい（環境ドリフトの排除）
• リソース作成を手順書ではなくコードで残し、レビュー・履歴管理したい
• 複数リソースの依存関係と作成順序を自動で解決したい
• 権限・タグ・ポリシーを統一の制御プレーンから一貫して適用したい

主要概念と用語

• Azure Resource Manager（ARM）: ポータル・CLI・PowerShell・SDK からのあらゆるリソース操作を受け付ける統一の制御プレーン。認証・認可・課金タグ付け・依存解決を担う（AWS の CloudFormation ＋ コントロール プレーンに相当）
• ARM テンプレート: リソースを宣言する JSON ファイル。ARM がネイティブに解釈する原形式
• Bicep: ARM テンプレートを簡潔に書くためのドメイン固有言語（DSL）。デプロイ時に ARM テンプレート（JSON）へ変換（トランスパイル）される。JSON より可読性が高く、AWS の CloudFormation に対する CDK に近い立ち位置だが、命令的言語ではなく宣言的
• リソース プロバイダー: Microsoft.Compute や Microsoft.Storage など、リソース種別ごとの操作を実装する名前空間。利用には登録が必要
• デプロイ（Deployment）: テンプレートを適用する操作。同じ入力なら結果が同じになるべき等性を持つ
• スコープ: デプロイの適用範囲。リソース グループ／サブスクリプション／管理グループ／テナントの4階層
• モジュール（Bicep module）: 再利用可能な Bicep の部品。テンプレートを分割・共有する単位
• パラメーター／変数／出力: 入力値・中間値・他テンプレートへ渡す戻り値を表す要素
• What-if 操作: 適用前に変更内容（作成・変更・削除）を事前確認する機能（CloudFormation の変更セットに相当）

仕様・制限・クォータ

• 宣言的かつべき等: テンプレートは「あるべき状態」を記述し、ARM が現状との差分を適用します。同じテンプレートを再実行しても結果は変わりません
• デプロイ モード: **増分（Incremental）**は既存リソースを保持しテンプレート記載分を追加・更新。完全（Complete）はテンプレートに無いリソースをスコープ内から削除します。既定は増分で、完全モードは意図しない削除に注意します
• 依存関係: ARM はリソース間参照から依存を自動推論し、可能なものは並列に展開します。明示指定も可能です
• スコープ単位の上限: 1 回のデプロイで扱えるリソース数や、テンプレートのサイズ・パラメーター数などに上限があります。大規模構成はモジュール分割やネスト デプロイで回避します
• Bicep は JSON のスーパーセット的役割: Bicep で書けるものは ARM テンプレートに変換可能で、既存 JSON からの逆変換（decompile）も可能です
• 具体的な上限値は時期やリソース種別で変わり得るため、設計時は最新の公式ドキュメントで確認します

内部の仕組み

ARM は Azure のすべてのリソース操作の入口です。ポータル・az CLI・PowerShell・REST いずれの操作も、最終的に ARM の REST API を通り、ARM が認証・RBAC による認可・ポリシー評価・タグ付けを行ったうえで、各リソース プロバイダーへ処理を委譲します。

Bicep ファイルはデプロイ時にまず ARM テンプレート（JSON）へトランスパイルされ、テンプレートとパラメーターがデプロイとして ARM に投入されます。ARM はテンプレート内のリソース間参照から依存グラフを構築し、依存のないリソースは並列に、依存のあるものは順序を守って各プロバイダーに展開を指示します。各リソースの作成・更新はべき等で、既に望ましい状態にあるものは再作成されません。

設計パターン / ベストプラクティス

• モジュール化: ネットワーク・ストレージ・アプリ層などを Bicep モジュールに分割し、環境ごとにパラメーターで差し替える
• 環境分離: 同一テンプレート＋環境別パラメーター ファイル（dev／staging／prod）で構成差異をパラメーターに閉じ込める
• What-if で事前確認: 本番適用前に必ず what-if を実行し、想定外の削除・変更を検出する
• CI/CD 連携: テンプレートを Git で管理し、GitHub Actions や Azure Pipelines から自動デプロイ（PR レビュー → what-if → 適用）
• 完全モードは慎重に: 既定の増分モードを基本とし、完全モードは影響範囲を理解したうえで限定的に使う
• タグとネーミング規約を変数・モジュールで一元化し、コスト配賦と運用を容易にする

運用・監視

• デプロイ履歴: リソース グループ単位でデプロイ履歴と各操作の成否・エラー詳細が記録され、失敗時の原因追跡に使える
• アクティビティ ログ: ARM 経由のすべてのコントロール プレーン操作（作成・変更・削除）が証跡として残る（AWS の CloudTrail 相当）
• 失敗の切り分け: プロバイダー未登録、クォータ超過、RBAC 権限不足、依存関係の記述漏れが典型的な失敗要因
• ドリフト対策: ポータルでの手動変更がテンプレートと乖離する「ドリフト」を、what-if や定期的な再デプロイで検出・是正する
• Azure Policy 連携: 命名・リージョン・SKU 制限などをポリシーで強制し、テンプレート外の逸脱も防ぐ

コスト

ARM と Bicep によるデプロイ操作自体は無償です。課金が発生するのは、テンプレートが作成した個々のリソース（仮想マシン・ストレージなど）であり、IaC レイヤーには直接の利用料金はありません。コスト最適化の観点では、テンプレートで SKU・サイズ・冗長性をパラメーター化し、環境ごとに過剰なリソースを作らないことが重要です。

セキュリティ

• 認可は RBAC: ARM は操作ごとに Microsoft Entra ID ＋ Azure RBAC で認可します。デプロイ実行者やパイプラインのサービス プリンシパルには最小権限を割り当てます
• シークレットを直書きしない: 接続文字列やパスワードはテンプレートにハードコードせず、Azure Key Vault 参照でデプロイ時に注入します
• マネージド ID をパイプラインに使い、長期資格情報の保存を避けます
• Azure Policy で許可リージョン・SKU・命名規約などを強制し、テンプレートの逸脱や手動変更を防ぎます
• 完全モードによる削除は権限とともに破壊的影響を持つため、誰がどのスコープに適用できるかを RBAC で厳格に制御します

Well-Architected の観点

• 運用上の優秀性（operational）: インフラをコード化し、レビュー・バージョン管理・自動デプロイの対象にできます。手作業を排し、再現性と監査性を高めます
• 信頼性（reliability）: べき等なデプロイと環境別パラメーターにより、本番と同一構成を確実に再現でき、災害復旧時の再構築も自動化できます。what-if による事前検証で変更リスクを下げます

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソース グループを作成
az group create --name demo-rg --location japaneast

# Bicep ファイルの適用前に変更内容を事前確認（what-if）
az deployment group what-if \
  --resource-group demo-rg \
  --template-file main.bicep \
  --parameters env=dev

# Bicep ファイルをリソース グループ スコープにデプロイ（既定は増分モード）
az deployment group create \
  --resource-group demo-rg \
  --name infra-deploy \
  --template-file main.bicep \
  --parameters @dev.parameters.json

# デプロイ結果（出力値）を確認
az deployment group show \
  --resource-group demo-rg \
  --name infra-deploy \
  --query properties.outputs

# 既存 ARM テンプレート（JSON）を Bicep へ逆変換
az bicep decompile --file azuredeploy.json