Using Azure Application Change Analysis to discover configuration changes in Azure services
Have you ever wondered why a service or asset stopped working, or what could have caused a different behavior in your applications, although you didn't deploy any new code? I know I have. Use the Azure Application Change Analysis to learn all about it!
Have you ever wondered why a service or asset stopped working, or what could have caused a different behavior in your applications, although you didn't deploy any new code? I know I have.
With the Azure Application Change Analysis capability, we can drill down into changes for resources we have in our subscriptions.
- Learn what has changed for resources in Azure.
- See the change details and compare them with previous configurations.
- Identify why something changed. Was it a user, was it automation, or was it something else?
I previously talked about the Azure Resource Graph, which is an excellent way to stay on top of your Azure Governance game. Today we're talking specifically about change management and auditing on resources you have.
Azure Application Change Analysis
In the Azure Portal, if you go to the Search bar and type in "Change", you'll find something called "Application Change Analysis". We will look at this now.
Enable Change Analysis
When I have opened the Azure Application Change Analysis tool and am listing and filtering my resources, I can now opt-in to enable change analysis on individual resources.
For example, with App Services, we can make granular configurations to enable this service:
Use case: Discover changes for specific resources
Often I find myself looking for why something changed. Sometimes I know that something changed, but I'm not sure exactly what.
There is a wild variety of things that can change resources and services—applications with permissions to modify something, users in your organization, deployment pipelines, and more.
I have a set of resources targeted for DEV, STAGING, and PRODUCTION, for example. I now want to know why the STAGING environment no longer behaves the same way as DEV and PROD - you get the point.
As displayed in the picture, I can see all the resources in my selected resource groups, and I can see that quite some changes have occurred over the last few days.
Clicking one of them brings up the details, where I can now learn what changed. This capability is amazingly helpful - especially if you manage a considerable amount of resources across many types of services and subscriptions.
I'll drill down into one of my resources that have changes:
Do you know how I mentioned at the beginning of the post that you could see if the change was by a user or not? Here we can see that I have personally triggered quite some changes due to my changes in configuration. However, I can also see some unplanned changes, for example, when the avalabilityState changed for one of my resources.
Further, I can now select any change from the list of changes, and I can compare it to the previous configuration. This comparison is interesting if something stopped working, and I now need to figure out why.
Let's take an example with a recent change in how Functions behaved in one of my deployments. The difference, I figured out, came from code - but without knowing that this changed, I would have to start to troubleshoot why the behavior was different.
For example, I learned that the bindings changed the timer trigger schedule in my Azure Function. It also discovers changes in Application Configuration (app settings), and everything else you can think of - extremely useful, at least in my daily operations when I need to ensure the cloud stays alive and healthy.
This post was a small tip - make use of the Azure Application Change Analysis capabilities to stay on top of the game and enforce your business continuity! Good luck out there in the clouds.
Thanks for reading. Don't forget to leave a comment!