Azure Front Door Standard／Premiumで複数ルールをTerraformから安全に更新するなら、新しいRule SetをBatch Modeで作成し、ルール全体を1つの望ましい状態として管理するのが有効です。追加・変更・削除・並べ替えのいずれかに失敗すると変更は全件不適用となるため、一部のルールだけが先に反映される「部分反映」を防げます。
ただし、既存のRule Setが自動的にBatch Modeへ切り替わるわけではありません。既存環境は後方互換性のためClassicのまま維持され、移行する場合はBatch ModeのRule Setを新規作成して、Routeとの関連付けを差し替える必要があります。MicrosoftはAzure Front DoorのBatch rule updatesを2026年8月に一般提供しました。
Terraformでは、従来のazurerm_cdn_frontdoor_rule_setと個別ルールリソースを使うのではなく、専用のazurerm_cdn_frontdoor_batch_rule_setを使用します。この記事では、設定例、Classicとの違い、既存環境からの移行手順、失敗しやすいポイントまで具体的に解説します。
Azure Front Doorの部分反映を防ぐBatch Rule Updateとは
従来のClassic方式では、Azure Front Doorの各ルールを個別の作成、更新、削除リクエストとして処理します。
例えば、Terraformで次の変更を同時に行うとします。
- リダイレクトルールを1件追加する
- キャッシュルールを2件変更する
- 不要なヘッダー書き換えルールを1件削除する
- 実行順序を入れ替える
Classicでは、それぞれの処理が独立しています。途中の更新でエラーが起きると、それ以前に成功した変更だけが残る可能性があります。その結果、ルールの順序が一時的に崩れたり、Terraformの再実行やロールバックが複雑になったりします。
Batch Modeでは、Rule Set内のルール一覧全体を最終状態として送信します。Azure Front Doorはその一覧をRule Set単位で評価し、すべて適用できる場合にまとめて反映します。1件でも適用できなければ、Rule Setへの変更全体が失敗します。(Microsoft Learn)
原子的に更新される範囲はRule Set内に限られる
Batch Modeの原子性が保証する範囲は、1つのRule Setに含まれるルール群です。
同じTerraform applyで次のリソースも変更した場合、これらすべてがAzure上で1つのトランザクションになるわけではありません。
- Front Door Route
- Origin Group
- Origin
- Endpoint
- WAFポリシー
- 別のRule Set
例えば、Batch Rule Setの更新に成功した後、Routeの更新でエラーになる可能性はあります。したがって、既存環境から移行するときは「Batch Rule Setの作成」と「Routeの付け替え」を段階的に実施する方が安全です。
ClassicとBatch Modeの違い
| 比較項目 | Classic | Batch Mode |
|---|---|---|
| 更新単位 | ルール単位 | Rule Set内のルール全体 |
| 追加・変更・削除 | 個別リクエスト | まとめて処理 |
| 並べ替え | 個別更新となり原子的ではない | 最終的な順序を一括反映 |
| 途中で失敗した場合 | 一部だけ反映される可能性がある | すべて成功またはすべて不適用 |
| Terraformで使う主なリソース | azurerm_cdn_frontdoor_rule_setとazurerm_cdn_frontdoor_rule | azurerm_cdn_frontdoor_batch_rule_set |
| 既存Rule Set | 既定でClassicを継続 | 新規作成時に明示的な選択が必要 |
| 適した環境 | ルールが少なく、変更頻度も低い | ルールが多い、並べ替えが多い、IaC中心 |
| モード変更 | Batchへ直接変更できない | Classicへ直接戻せない |
Microsoftは、少数のルールをたまに変更する環境ではClassic、大規模なRule Set、頻繁な並べ替え、TerraformなどのIaC運用ではBatch Modeを推奨しています。Batch Modeは作成後に変更できず、モードを切り替えるには新しいRule Setの作成とRouteの再関連付けが必要です。(Microsoft Learn)
Terraformでは専用のBatch Rule Setリソースを使う
AzureRM Providerでは、Rule Setの管理方式によって使用するリソースが異なります。
Classicで使用するリソース
resource "azurerm_cdn_frontdoor_rule_set" "classic" {
name = "ClassicRuleSet"
cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id
}
resource "azurerm_cdn_frontdoor_rule" "example" {
name = "ExampleRule"
cdn_frontdoor_rule_set_id = azurerm_cdn_frontdoor_rule_set.classic.id
order = 1
# actions、conditionsなどを定義
}azurerm_cdn_frontdoor_rule_setで作成されるRule Setは非Batch Modeです。各ルールはazurerm_cdn_frontdoor_ruleで個別に管理します。
Batch Modeで使用するリソース
Batch Modeでは、次の専用リソースを使用します。
azurerm_cdn_frontdoor_batch_rule_setルールは別リソースとして作成せず、azurerm_cdn_frontdoor_batch_rule_set内にruleブロックとしてまとめて定義します。ruleブロックを変更すると、Providerは最終的なルール一覧を1回のリクエストとしてAzureへ送信します。
batch_mode属性を追加する方式ではない
AzureRM Providerの専用リソースでは、次のような属性を記述するわけではありません。
batch_mode = trueazurerm_cdn_frontdoor_batch_rule_setを選択すること自体が、TerraformにおけるBatch Modeの明示的な選択です。
一方、ARM、Bicep、REST API、AzAPI Providerなど、Azure Resource Managerのリソース構造を直接扱う場合は、Rule Set作成時に次のプロパティを指定します。
properties = {
batchMode = true
rules = local.frontdoor_rules
}Microsoft.Cdn/profiles/ruleSetsの2025-12-01 APIでは、properties.batchModeと完全なrules配列を指定できるようになっています。AzureRM Providerが要件を満たす場合は、スキーマ検証や状態管理がしやすい専用リソースを優先するとよいでしょう。(Microsoft Learn)
TerraformでBatch Rule Setを作成する設定例
次の例では、既存のAzure Front Doorプロファイルに、2つのルールを持つBatch Rule Setを作成します。
/legacyで始まるパスを/newへリダイレクト/appで始まるレスポンスにセキュリティヘッダーを追加
認証情報やSubscription IDは、環境変数やCI/CDのWorkload Identityなど、利用環境に合わせて設定してください。
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 5.3"
}
}
}
provider "azurerm" {
features {}
}
resource "azurerm_cdn_frontdoor_batch_rule_set" "web" {
name = "WebBatchRules"
cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id
rule {
name = "RedirectLegacy"
order = 10
behaviour_on_match = "Stop"
conditions {
request_path {
operator = "BeginsWith"
values = ["legacy"]
transforms = ["Lowercase"]
}
}
actions {
url_redirect {
redirect_type = "PermanentRedirect"
redirect_protocol = "Https"
destination_path = "/new"
}
}
}
rule {
name = "AddNosniffHeader"
order = 20
behaviour_on_match = "Continue"
conditions {
request_path {
operator = "BeginsWith"
values = ["app"]
}
}
actions {
modify_response_header {
header_name = "X-Content-Type-Options"
operator = "Overwrite"
header_value = "nosniff"
}
}
}
}作成したRule SetをRouteに関連付けるには、既存のazurerm_cdn_frontdoor_route内で次のIDを指定します。
cdn_frontdoor_rule_set_ids = [
azurerm_cdn_frontdoor_batch_rule_set.web.id
]専用リソースでは、すべてのruleブロックが完全なRule Setを表します。1件のルールを変更した場合でも、Providerは最終的な順序を含むルール一覧全体をAzureへ送信します。
orderは10刻みなど間隔を空ける
Batch Rule Setでは、ruleブロックをorderの昇順で記述する必要があります。ただし、値を連番にする必要はなく、間隔を空けられます。
10
20
3010刻みにしておけば、後から10と20の間にルールを追加するときにorder = 15を指定できます。既存ルールをすべて採番し直す必要がなく、Terraform planの差分も読みやすくなります。
各ルールのnameとorderは重複できません。ルール名は英字で始め、英数字だけで構成する必要があります。
request_pathの値には通常スラッシュを付けない
request_path条件では、ルートパスそのものを表す/を除き、値の先頭にスラッシュを付けません。
values = ["legacy"]次のように記述すると、意図した一致条件にならない可能性があります。
values = ["/legacy"]一方、リダイレクト先を指定するdestination_pathには先頭のスラッシュが必要です。条件とアクションで書式が異なるため、移行時に間違えやすいポイントです。
追加・変更・削除・並べ替えはどう記述するか
Batch Modeでは「今回変更するルール」ではなく、「適用後に存在してほしい全ルール」を宣言します。
| 実施したい変更 | Terraformでの操作 |
|---|---|
| ルールを追加する | 新しいruleブロックを昇順になる位置へ追加する |
| ルールを変更する | 対象のruleブロック内の条件やアクションを変更する |
| ルールを削除する | 対象のruleブロックを構成から取り除く |
| 順序を変更する | orderを変更し、ブロックの記述順も昇順に並べ直す |
| 全ルールを置き換える | 最終状態となるruleブロック群へ書き換える |
構成から削除したルールは「変更対象外」ではなく、「最終状態には存在しないルール」として扱われます。
特にAzAPIやREST APIを直接使う場合、変更する1件だけをrules配列へ入れて送信してはいけません。省略したルールが削除対象になる可能性があるため、常にRule Set全体の最終状態を組み立てる必要があります。(Microsoft Learn)
既存のClassic Rule SetをBatch Modeへ移行する手順
既存Rule SetのbatchModeは後から変更できません。安全に移行するには、既存リソースを直接書き換えるのではなく、新旧Rule Setを一時的に並存させます。
現在のルールを棚卸しする
最初に、Classic Rule Setに含まれる次の情報を一覧化します。
- ルール名
- 実行順序
- 条件
- アクション
ContinueまたはStop- Route OverrideとOrigin Groupの参照
- キャッシュ設定
- Routeとの関連付け
- Terraform外で加えられた変更
Terraformコードだけでなく、Azure上の実構成も確認してください。ポータルで手動変更された内容がTerraformへ反映されていないと、新しいBatch Rule Setへ移行した際に設定が欠落します。
新しいBatch Rule Setを別名で作成する
既存Rule Setとは異なる名前で、azurerm_cdn_frontdoor_batch_rule_setを作成します。
resource "azurerm_cdn_frontdoor_batch_rule_set" "web_v2" {
name = "WebBatchRulesV2"
cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id
# 現在のルールをすべてruleブロックとして移行
}この段階では、可能であれば本番Routeへ関連付けません。まずBatch Rule Set単体を作成し、ルール数、順序、条件、アクションを確認します。
Routeの参照先を差し替える
Batch Rule Setの作成を確認したら、別のapplyでRouteの関連付けを変更します。
変更前：
cdn_frontdoor_rule_set_ids = [
azurerm_cdn_frontdoor_rule_set.classic.id
]変更後：
cdn_frontdoor_rule_set_ids = [
azurerm_cdn_frontdoor_batch_rule_set.web_v2.id
]原則として、同じ目的の新旧Rule Setを同時にRouteへ関連付けるのは避けます。リダイレクト、ヘッダー操作、Route Overrideなどが重複すると、想定外の結果になる可能性があるためです。
実際のエンドポイントで動作確認する
Routeの切り替え後は、代表的なURLだけでなく、条件の境界もテストします。
curl -I https://www.example.com/legacy/test
curl -I https://www.example.com/app/
curl -I https://www.example.com/少なくとも次の項目を確認します。
- HTTPステータスコード
Locationヘッダー- リクエスト／レスポンスヘッダー
- Origin Groupの切り替え
- キャッシュ対象と非対象
- クエリ文字列の扱い
- 大文字・小文字の違い
- GET以外のHTTPメソッド
- 条件に一致しないURL
旧Rule Setは確認後に削除する
切り替え直後に旧Rule Setを削除せず、Routeから外した状態で一定期間保持すると、問題発生時に参照先を戻しやすくなります。
安定稼働を確認した後、旧Rule Setと個別のazurerm_cdn_frontdoor_ruleをTerraformから削除します。
state mvやimportだけではモードを変換できない
次のようなterraform state mvを実行しても、Azure上のRule SetがBatch Modeへ変わるわけではありません。
terraform state mv \
azurerm_cdn_frontdoor_rule_set.classic \
azurerm_cdn_frontdoor_batch_rule_set.webstate mvが変更するのはTerraform State内のアドレスです。Azureリソースの作成時プロパティは変更しません。
また、Classicとして作成されたRule Setをazurerm_cdn_frontdoor_batch_rule_setへimportするとエラーになります。Batch専用リソースで管理できるのは、最初からBatch Modeとして作成されたRule Setだけです。
最大100ルールとキャッシュ設定の数え方に注意する
Batch Rule Setでは、1つのRule Setに最大100ルールを定義できます。ただし、Route Overrideでキャッシュを有効にしたルールは、上限計算上2ルール分として扱われます。(Microsoft Learn)
実効的なルール数は、次のように計算できます。
実効ルール数
= キャッシュなしルール数
+ キャッシュありルール数 × 2例えば、99件のルールのうち2件でキャッシュを有効にしている場合は、次の計算になります。
97 + 2 × 2 = 101見かけ上は99件でも上限を超えるため、更新に失敗します。
キャッシュルールを大量に置き換える場合
キャッシュを有効にしたルールが50件ある場合、実効ルール数は100です。この50件を一度にすべて置き換えようとすると、処理中の一時的な上限超過によって失敗する場合があります。
Microsoftは、このケースでは25件ずつ2段階に分ける方法を推奨しています。Terraformでは次のように進めます。
- 既存50件のうち25件だけを新しい内容へ変更してapplyする
- 動作を確認する
- 残り25件を変更して再度applyする
各applyでは完全なRule Setが送信されますが、1回の操作で置き換えるルール数を抑えられます。なお、2回のapply全体が原子的になるわけではありません。途中状態でも正しく動作する順序で変更内容を設計してください。(Microsoft Learn)
Terraform運用で失敗しやすいポイント
| 失敗例 | 問題 | 対策 |
|---|---|---|
| 既存Rule SetにBatch Modeを後付けする | モードは作成後に変更できない | 新しいBatch Rule Setを作成する |
azurerm_cdn_frontdoor_ruleを併用する | Batch Rule Setの個別ルールは管理できない | すべてのルールを専用リソース内へ入れる |
| 変更したルールだけを送信する | 省略したルールが最終状態から消える | 常に完全なルール一覧を宣言する |
ruleブロックの記述順がバラバラ | Providerが期待する昇順と一致しない | orderの昇順にコードを並べる |
同じorderを複数回使う | 実行順序を一意に決められない | nameとorderを重複させない |
request_pathに常に/を付ける | 条件が想定どおり一致しない | ルートパス以外は先頭の/を外す |
| キャッシュルールを1件として数える | 実効ルール数が100を超える | キャッシュ有効ルールは2件分として計算する |
| ポータルとTerraformの両方で編集する | Driftが発生し、次のapplyで上書きされる | Rule Setの変更経路をTerraformへ一本化する |
| apply全体が原子的だと考える | Routeなど別リソースの失敗を見落とす | 作成、Route切り替え、削除を段階的に実施する |
| Classicをstate mvで変換する | Azure上のモードは変わらない | 新規作成とRouteの付け替えを行う |
azurerm_cdn_frontdoor_ruleは、Batch Modeとして作成されたRule Setのルール管理には使用できません。ClassicとBatchのリソースを明確に分けることが重要です。
CI/CDではRule Set全体の変更としてレビューする
Batch Modeでは、1件の修正でもRule Set全体が更新単位になります。そのため、Terraform planも「1ルールだけ変わった」と考えず、ルール一覧全体の最終状態を確認します。
基本的な実行手順は次のとおりです。
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform show tfplan
terraform apply tfplanレビューでは、少なくとも次を確認します。
- 意図しないルール削除が含まれていないか
orderが正しい順序になっているかStopによって後続ルールが実行されなくならないか- Route OverrideとURL Redirectを同一ルールに入れていないか
- URL RewriteとURL Redirectを同一ルールに入れていないか
- キャッシュを有効にしたルールの実効数が上限内か
- Routeが正しいRule Set IDを参照しているか
- ポータルで追加された未管理ルールが消えないか
1つのactionsブロックには少なくとも1つ、最大5つのアクションを定義できます。ただし、Route OverrideとURL Redirect、URL RewriteとURL Redirectは同一ルール内で併用できません。
同時実行を防ぐ
Batch Mode自体はRule Setの部分反映を防ぎますが、複数のTerraformパイプラインが同じRule Setを同時に更新する運用は避けるべきです。
実務では次の対策を行います。
- Remote Stateのロックを有効にする
- 本番環境へのapplyを直列化する
- 同じRule Setを複数のStateで管理しない
- apply対象のplanファイルをレビュー後にそのまま使用する
- ポータルからの手動編集を原則禁止する
- 緊急変更を行った場合は直ちにTerraformへ反映する
Batch Modeは更新処理を安全にしますが、複数の管理元が互いの変更を上書きする問題までは解決しません。Rule Setごとに管理主体を1つに決めることが重要です。
Azure Front Doorルールを安全に一括更新するための実施順序
Azure Front DoorのBatch Rule UpdateをTerraformで導入するときは、次の順序で進めると安全です。
- AzureRM Providerの対応バージョンを固定する
- 既存Rule Setのルール、順序、Route参照を棚卸しする
azurerm_cdn_frontdoor_batch_rule_setで新しいRule Setを作成する- すべてのルールをネストした
ruleブロックとして移行する terraform planで削除、順序、条件、アクションを確認する- Batch Rule Setだけを先に作成する
- 別のapplyでRouteの参照先を切り替える
- 実際のFront Doorエンドポイントで動作確認する
- 問題がなければ旧Classic Rule Setを削除する
重要なのは、Batch Modeを単なる「複数ルールの高速更新機能」と捉えないことです。これは、Rule Set全体を1つの構成単位として宣言し、部分反映を防ぐための管理方式です。
TerraformをAzure Front Doorルールの唯一の管理元とし、完全なルール一覧、明確な実行順序、段階的なRoute切り替えを徹底することで、ルール数が多い環境でも予測可能なデプロイを実現できます。
コメント