Azure Functions Flex Consumption の 設定を Azure portal から変更すると、関連する App Service planのタグが意図せず消失する

Hi @伊藤 壮平 ,
こんにちは@伊藤壮平さん。 これを英語に翻訳するので、文法の誤りや不正確さがあればあらかじめお詫びします。

この行動を報告し、詳細な情報を提供してくださりありがとうございます。

あなたの説明からすると、Always Readyの設定を更新することで、基盤となるApp Service Planリソースへの更新がトリガーされているようです。更新操作で既存のタグが保持されない場合、明示的なエラーが報告されずにタグを削除してもよいでしょう。

これがAzureポータル経由で起きているのか、それとも他のデプロイメントプロセスを通じて起きているのかを判断するために、以下のチェックを行っていただけますか?

アプリサービスプランのアクティビティログを確認してください

App Service Planのリソース(Function Appではなく)にアクセスし、アクティビティログを開きます。

Always Ready設定が変更された時刻をフィルターし、操作を探します:

Microsoft.Web/serverfarms/write

ご確認ください:

操作を行ったのはユーザーアカウントかサービスプリンシパルかです。

リクエストの相関IDです。

これにより、アップデートがAzureポータルから発生したのか、別のデプロイメントプロセスから来たのかを判断するのに役立ちます。

テスト環境でその挙動を再現する

可能であれば、テスト用のFlex Consumption Functionアプリを作成し、以下を行ってください。

App Service Planにテストタグを追加してください。

Azureポータルの**「Always Ready**」設定を変更してください。

App Service Planタグがまだ残っているか確認してください。

例えば:

ヤムル

az tag update --resource-id <APP_SERVICE_PLAN_RESOURCE_ID> --operation Merge --tags TestTag=BeforeChange

az resource show --ids <APP_SERVICE_PLAN_RESOURCE_ID> --query tags

もしAlways Ready設定を変更しただけでタグが消えるなら、さらなる調査のための再現可能なシナリオが提供されます。

タグを復元してください

タグがすでに削除されている場合は、マージ操作で復元できます:

ヤムル

az tag update --resource-id <APP_SERVICE_PLAN_RESOURCE_ID> --operation Merge --tags CostCenter=00123 Owner=TeamA Environment=Production

マージを使うと、指定されたタグを追加・更新しながら既存のタグは保持されます。

もしApp Service PlanがInfrastructure as Codeで管理されている場合

ARM、Bicep、またはTerraformのデプロイにApp Service Planに必要なタグが含まれているか必ず確認してください。

既存のタグを含めずにリソースを更新する場合、Azure Resource Managerは更新時にタグコレクションを上書きできます。

参考になれば幸いです。上記の検査結果をお知らせいただければ、さらにお手伝いいたします。

Hi @Likhitha Sulake ,

Please excuse any lack of clarity in my English.

Thank you for your guidance. I performed the suggested reproduction tests and reviewed the Activity Log.

Validation in an Environment Without Azure Policy

In an existing Flex Consumption test environment, I configured test tags on the App Service plan and changed only the Function App's Always Ready setting through the Azure portal.

In this environment, the existing tags remained unchanged; no tags were removed or had their values changed.

Observed Behavior in an Environment Where Azure Policy Was Assigned

After comparing this environment with the environment where the issue occurred, I found that the built-in Azure Policy definition Inherit a tag from the resource group if missing (effect: modify) was assigned with the environment tag specified.

In this environment, I changed only Always Ready through the Azure portal while the following tags were configured on the App Service plan.

After this operation, the non-policy-targeted function tag was no longer present.

Additional Validation

1. I changed the App Service plan's environment tag to a value different from the resource group's value, and then changed Always Ready through the Azure portal. After the change, the environment tag value reverted to the resource group value (dev).
2. I also assigned the same Azure Policy definition for an additional tag. When I changed Always Ready through the Azure portal in this state, that tag remained and was not removed.

Additional Information

For Consumption and Elastic Premium plans, I could not reproduce the same tag loss by changing the scale-out settings through the Azure portal.

Activity Log

During the same validation period, Microsoft.Web/sites/write for the Function App was recorded first, followed by Microsoft.Web/serverfarms/write for the App Service plan.

The Function App write and the App Service plan write had different correlation IDs. However, the Microsoft.Web/serverfarms/write operation for the App Service plan and the Microsoft.Authorization/policies/modify/action operation for Azure Policy were recorded with the same correlation ID.

The caller for the App Service plan write was a user account. The Always Ready change was made through the Azure portal. During that time, no updates were performed through Bicep, Terraform, Azure CLI, PowerShell, a service principal, or automated deployment.

Points to Confirm

My understanding is that Inherit a tag from the resource group if missing is an Azure Policy definition that inherits the resource group value when the target resource does not have the specified tag.

However, in this validation, changing Always Ready while existing tags were configured on the App Service plan changed the policy-targeted tag to the resource group value and removed the non-targeted tag.

Could you please confirm whether this result is expected when a Microsoft.Web/serverfarms/write operation occurs in an environment where the Azure Policy definition Inherit a tag from the resource group if missing is assigned?

@Likhitha Sulake

I apologize, but I accidentally posted my follow-up as an Answer instead of a Comment.

Please refer to that Answer for the requested validation results and Activity Log details. Sorry for the confusion.

Hi @伊藤 壮平 ,

追加検査を行い、結果を共有していただきありがとうございます。Azure Policyがある環境となし環境の比較は非常に参考になりました。

ご提供いただいた情報に基づいて、私たちが見つけた結果は以下の通りです:

1. **環境**タグがリソースグループの値に戻ることが予想されます

この動作は、組み込みの**「リソースグループからタグを継承する」**Azureポリシーを使用する際に予想されます。

このポリシーはaddOrRestitu演算でModify効果を利用しており、リソースが作成されたり更新されたりするたびに、リソースグループの値にマッチするよう指定されたタグを更新します—たとえリソースの値がすでに異なっていてもです。

これが、リソースが更新された後に手動で環境タグを変更すると必ず開発者に戻る理由が説明できます。

関数タグが削除されることは予想されていません

しかし、関数タグが消えるのは予想される動作ではありません。

ポリシーは環境タグのみを管理しているため、他の既存のタグを削除しないはずです。あなたのテストによると、Always Ready設定を保存すると、App Service Planの更新とAzureポリシーが相互作用し、ポリシー管理タグのみが保持され、他のタグは削除されるようです。

あなたの追加の承認はこれを強く裏付けています:

ポリシーで管理される環境タグのみの場合、関数タグは消えます。 関数タグにポリシーを割り当てた場合、更新後もそのまま残ります。

これは、ポリシーで書かれたタグのみが更新時に保持されていることを示しています。

正確な原因を特定するために、以下の情報を収集していただけませんか?

App Service Planの更新リクエストをキャプチャする アプリサービスプランのアクティビティログを開きます。 Microsoft.Web/serverfarms/write操作を確認し、リクエストにタグセクションが含まれているか確認してください。 また、関連するMicrosoft.Authorization/policies/modify/actionエントリを確認し、ポリシーの詳細もメモしてください。 変更履歴のレビュー App Service Planリソースを開きます。 履歴変更のページに行き、Always Readyアップデートの前後のタグを比較してください。 Azure Policy モードの検証 ポリシーがIndexedモードに設定されているか確認してください。これはリソースのタグポリシーに推奨されるモードです。 一時的な回避策

根本原因が確認されるまでは、以下のいずれかの回避策を利用できます。

保存が必要なタグごとにAzureポリシーを割り当ててください。あなたのテストによると、これによりタグの削除はうまく防がれています。 あるいは、異なるタグ値を維持する必要がある場合は、Always Readyの設定を変更した後に欠落タグを再適用する方法もあります。

参考になれば幸いです。上記の検査結果をお知らせいただければ、さらにお手伝いいたします。追加検査を行い、結果を共有していただきありがとうございます。Azure Policyがある環境となし環境の比較は非常に参考になりました。

ご提供いただいた情報に基づいて、私たちが見つけた結果は以下の通りです:

**環境**タグがリソースグループの値に戻ることが予想されます

この動作は、組み込みの**「リソースグループからタグを継承する」**Azureポリシーを使用する際に予想されます。

このポリシーはaddOrRestitu演算でModify効果を利用しており、リソースが作成されたり更新されたりするたびに、リソースグループの値にマッチするよう指定されたタグを更新します—たとえリソースの値がすでに異なっていてもです。

これが、リソースが更新された後に手動で環境タグを変更すると必ず開発者に戻る理由が説明できます。

関数タグが削除されることは予想されていません

しかし、関数タグが消えるのは予想される動作ではありません。

ポリシーは環境タグのみを管理しているため、他の既存のタグを削除しないはずです。あなたのテストによると、Always Ready設定を保存すると、App Service Planの更新とAzureポリシーが相互作用し、ポリシー管理タグのみが保持され、他のタグは削除されるようです。

あなたの追加の承認はこれを強く裏付けています:

ポリシーで管理される環境タグのみの場合、関数タグは消えます。

関数タグにポリシーを割り当てた場合、更新後もそのまま残ります。

これは、ポリシーで書かれたタグのみが更新時に保持されていることを示しています。

正確な原因を特定するために、以下の情報を収集していただけませんか?

App Service Planの更新リクエストをキャプチャする

アプリサービスプランのアクティビティログを開きます。

  **Microsoft.Web/serverfarms/write**操作を確認し、リクエストに**タグ**セクションが含まれているか確認してください。
  
     また、関連する**Microsoft.Authorization/policies/modify/action**エントリを確認し、ポリシーの詳細もメモしてください。
     
     **変更履歴のレビュー**
     
        **App Service Plan**リソースを開きます。
        
           **履歴変更**のページに行き、**Always Ready**アップデートの前後のタグを比較してください。
           
           **Azure Policy モードの検証**
           
              ポリシーが**Indexed**モードに設定されているか確認してください。これはリソースのタグポリシーに推奨されるモードです。
              
              一時的な回避策
              

根本原因が確認されるまでは、以下のいずれかの回避策を利用できます。

保存が必要なタグごとにAzureポリシーを割り当ててください。あなたのテストによると、これによりタグの削除はうまく防がれています。

あるいは、異なるタグ値を維持する必要がある場合は、Always Readyの設定を変更した後に欠落タグを再適用する方法もあります。

参考になれば幸いです。上記の検査結果をお知らせいただければ、さらにお手伝いいたします。

Hi @Likhitha Sulake ,

I also reviewed the Activity Log, the Azure Policy definition, and the Change History.

Azure Policy Definition Review

The built-in Azure Policy definition that is applied is Inherit a tag from the resource group if missing (not Inherit a tag from the resource group).

• Mode: Indexed (I confirmed that the mode is Indexed, as requested)
• Effect: modify
• Operation defined in the definition: add
• Condition: the target tag does not exist (exists: false)

The definition's description states that if the resource already has the tag with a different value, the existing value is left unchanged.

Activity Log Review

The Azure Policy record associated with the Microsoft.Web/serverfarms/write operation on the App Service plan was Microsoft.Authorization/policies/modify/action.

The recorded details are as follows:

• Policy definition: Inherit a tag from the resource group if missing
• Effect: modify
• Recorded field operation: Add tags[environment]

The Microsoft.Web/serverfarms/write operation and the Azure Policy modify/action were recorded under the same correlation ID and operation ID.

However, the Activity Log contains no recorded operation that removes the function tag. The Microsoft.Web/serverfarms/write entry reviewed in this case did not indicate whether the update request included a tags section or which tags it contained.

Change History Review

Immediately after the Always Ready change, the App Service plan's Change History contained a Resource Updated entry with Changed By: Unspecified and Client Type: Unspecified.

The diff for this change showed that the function tag, which had been present before the change, was no longer present afterward. No elements other than tags changed.

As a temporary workaround, we are currently reapplying the lost tags each time. However, because manual tag restoration is required after every Always Ready change, this places a significant ongoing operational burden on us.

We would appreciate your continued investigation into whether this difference is expected behavior for the combination of the Microsoft.Web/serverfarms/write operation associated with the Always Ready change and the Azure Policy definition Inherit a tag from the resource group if missing.