Azure Verified Modules: Support Statement & Target Response Times Update
We are announcing an update to the Azure Verified Modules (AVM) support statement. This change reflects our commitment to providing clarity alongside timely and effective support for our community and AVM module consumers. These changes are in preparation to allow us to enable AVM modules to be published as V1.X.X modules (future announcement on this soon đ„ł sign up to the next AVM Community Call on July 1st 2025 to learn more). What is the new support statement? You can find the support statement on the AVM website here: https://azure.github.io/Azure-Verified-Modules/help-support/module-support/#support-statements For bugs/security issues 5 business days for a triage, meaningful response, and ETA to be provided for fix/resolution by module owner (which could be past the 5 days) For issues that breach the 5 business days, the AVM core team will be notified and will attempt to respond to the issue within an additional 5 business days to assist in triage. For security issues, the Bicep or Terraform Product Groups may step in to resolve security issues, if unresolved, after a further additional 5 business days. For feature requests 15 business days for a meaningful response and initial triage to understand the feature request. An ETA may be provided by the module owner if possible. Key changes from the previous support statement In short its two items: Increasing response time targets from: 3 to 5 business days for issues And from 3 to 5 business days for AVM core team escalation Handling bugs/security issues separately from feature requests Feature requests now have a 15 business day target response time The previous support statement outlined a more rigid structure for issue triage and resolution. It required module owners/contributors to respond within 3 business days, with the AVM core team stepping in if there was no response within a further 24 hours. In the event of a security issue being unaddressed after 5 business days, escalation to the product group (Bicep/Terraform) would occur to assist the AVM core team. There was also no differentiation between bugs/security issues and feature requests, which there now is. You can view the git diff of the support statement here Why the changes? Being honest, we weren't meeting the previous support statement 100% of the time, which we are striving for, across all the AVM modules. And we heard from you that, that wasn't ideal and we agree whole heartedly. Therefore, we took a step back, reflected, looked at the data available and huddled together to redefine what the new AVM support statement and targets should be. "Yeah, but why can't you just meet the previous support statement and targets?" This is a very valid question that you may have or be wondering. And we want to be honest with you so here are the reasons why this isn't possible today: Module owners are not 100% dedicated to only supporting their AVM modules; they also have other daily roles and responsibilities in their jobs at Microsoft. Sometimes this also means conflicting priorities for module owners and they have to make a priority call. We underestimated the impact of holidays, annual leave, public holidays etc. The AVM core teams responsibility is not to resolve all module issues/requests as they are smaller team driving the AVM framework, specs, tooling and tests. They will of course step in when needed, as they have done so far today đ We don't get as many contributions from the open-source community as we expected and would still love to see đ For clarity we always love to see a Pull Request to help us add new features or resolve bugs and issues, even for simple things like typos. It really does help us go faster đââĄïž "How are you going to try and avoid changing (increasing) the support statement and targets in the future?" Again another very valid ask! And we reflected upon this when making these changes to the support statement we are announcing here. To avoid this potential risk we are also taking the following actions today: Building new internal tooling and dashboards for module owners to discover, track and monitor their issues and pull requests across various modules they may own, across multiple languages. (already complete and published đ) This tooling will also help the AVM core team track issues and report on them more easily to help module owners avoid non-compliance with the targets. Continue to push for, promote, and encourage open-source community contributions Prevent AVM modules being published as V1.X.X if they are unable to prove compliance with the new support statement and targets (sneak peek into V1.X.X requirements) Looking further into the future we are also investigating the following: Building a dedicated AVM team, separate from the AVM core team, that will triage, work on, and fix/resolve issues that are nearing or breaching the support statement and targets. Also they will look into feature requests as and where time allows or are popular/upvoted heavily where module owners are unable to prioritize in the near future due to other priorities. Seeing where AI and other automation tooling can assist with issue triage and resolution to reduce module owner workload. Summary We hope that this provides you with a clear understanding of the changes to the AVM support statement and targets and why we are making these. We also hope you appreciate our honesty on the situation and can see we are taking action to make things better while also reflecting and amending our support statements to be more realistic based on the past 2 years of launching and running AVM to date. Finally we just want to reassure everyone that we remain committed to AVM and have big plans for the rest of the calendar year and beyond! đ And with this in mind we want to remind you to sign up to the next AVM Community Call on July 1st 2025 to learn more and ask any questions on this topic or anything else AVM related with the rest of the community đ Thanks The AVM Core Team
Announcement of migrating to Azure Linux 3.0 for Azure CLI
Azure CLI 2.74.0 is the final version available on Azure Linux (Mariner) 2.0 and will not receive further updates. We recommend migrating to Azure Linux 3.0 to access newer versions of Azure CLI and continue receiving updates. A warning message will appear when using Azure CLI on Azure Linux 2.0. To suppress this message, set the AZURE_CLI_DISABLE_AZURELINUX2_WARNING environment variable to any value. We value the experiences of our Azure CLI users, especially when lifecycle changes might cause disruptions. Our goal is to provide clear communication and as much advance notice as possible. Quoting our internal partner, the Azure Linux team, as follows: Azure Linux 2.0 will reach its End of Life (EOL) on July 2025. After this date, it will no longer receive updates, security patches, or support, which may put your systems at risk. From today, we will not be entertaining package upgrade requests for Azure Linux 2.0. To ensure continued support, security, and performance, we strongly recommend upgrading to Azure Linux 3.0 by June 2025. Azure Linux 3.0 comes with enhanced features, better performance, and longer support, making it better choice for your infrastructure moving forward. Learn more about 3.0 here. We understand that migrations can take time, so we encourage you to begin planning your upgrade as soon as possible. Our Azure Linux team is available to assist with the transition, address any concerns, and help make the process as seamless as possible. Is this the same as Mariner? Yes, Mariner was rebranded to Azure Linux. We will slowly update our documentation and VM/container image tags to reflect this name change When did Azure Linux 3.0 GA? Azure Linux 3.0 became generally available in August 2024. When will Azure Linux 3.0 reach End of Life (EOL)? We currently support each major version for 3 years after it becomes generally available. Azure Linux 3.0 will reach EOL in Summer 2027. https://github.com/Azure/azure-cli/milestone/156 (scheduled for release on 2025-06-03) is the final version to support Azure Linux 2.0. We strongly recommend reviewing your scenarios and using this transition period to ensure a smooth migration. For AKS customers, Noting that Azure Linux team are still supporting Azure Linux 2.0 until November 2025 to align with AKS v1.31 support. This means Azure Linux 2.0 is getting regular patches until November 2025. If you encounter any issues related to Azure CLI on Azure Linux 3.0, please open an issue in our https://github.com/Azure/azure-cliAzure CLI and Azure PowerShell Build 2025 Announcement
The key investment areas for Azure CLI and Azure PowerShell in 2025 are quality and security. Weâve also made meaningful efforts to improve the overall user experience. In parallel, we've enhanced the quality and performance of Azure CLI and Azure PowerShell responses in Copilot, ensuring a more reliable user experience. We encourage you to try out the improved Azure CLI and Azure PowerShell in the Copilot experience and see how it can help streamline your Azure workflows. At Microsoft Build 2025, we're excited to announce several new capabilities aligned with these priorities: Improvements in quality and security. Enhancements to user experience. Ongoing improvements to Copilot's response quality and performance. Improvements in quality and security Azure CLI and Azure PowerShell Long Term Support (LTS) releases support In November 2024, Azure PowerShell became the first to introduce both Standard Term Support (STS) and Long-Term Support (LTS) versions, providing users with more flexibility in managing their tools. At Microsoft Build 2025, we are excited to announce that Azure CLI now also supports both STS and LTS release models. This allows users to choose the version that best fits their project needs, whether they prefer the stability of LTS releases or want to stay up to date with the latest features in STS releases. Users can continue using an LTS version until the next LTS becomes available or choose to upgrade more frequently with STS versions. To learn more about the definitions and support timelines for Azure CLI and Azure PowerShell STS and LTS versions, please refer to the following documentation: Azure CLI lifecycle and support | Microsoft Learn Azure PowerShell support lifecycle | Microsoft Learn Users can choose between the Long-Term Support (LTS) and Short-Term Support (STS) versions of Azure CLI based on their specific needs. It is important to understand the trade-offs: LTS versions provide a stable and predictable environment with a support cycle of up to 12 months, making them ideal for scenarios where stability and minimal maintenance are priorities. STS versions, on the other hand, offer access to the latest features and more frequent bug fixes. However, this comes with the potential need for more frequent script updates as changes are introduced with each release. It is also worth noting that platforms such as Azure DevOps and GitHub Actions typically default to using newer CLI versions. That said, users still have the option to pin to a specific version if greater consistency is required in their CI/CD pipelines. When using Azure CLI to deploy services like Azure Functions within CI/CD workflows, the actual CLI version in use will depend on the version selected by the pipeline environment (e.g., GitHub Actions or Azure DevOps), and it is recommended to verify or explicitly set the version to align with your deployment requirements. SecureString update for Azure PowerShell Our team is gradually transitioning to using SecureString for tokens, account keys, and secrets, replacing the traditional string types. In November 2024, we offered an opt-in method for the Get-AzAccessToken cmdlet. At the 2025 Build event, weâve made this option mandatory, which is a breaking change: Get-AzAccessToken Get-AzAccessToken Token : System.Security.SecureString ExpiresOn : 5/13/2025 1:09:15 AM +00:00 TenantId : 00000000-0000-0000-0000-000000000000 UserId : user@mail.com Type : Bearer In 2026, we plan to implement this secure method in more commands, converting all keys, tokens, and similar data from string types to SecureString. Please continue to pay attention to our upcoming breaking changes documentation. Install Azure PowerShell from Microsoft Artifact Registry (MAR) Installing Azure PowerShell from Microsoft Artifact Registry (MAR) brings several key advantages for enterprise users, particularly in terms of security, performance, and simplified artifact management. Stronger Security and Supply Chain Integrity Microsoft Artifact Registry (MAR) enhances security by ensuring only Microsoft can publish official packages, eliminating risks like name squatting. It also improves software supply chain integrity by offering greater transparency and control over artifact provenance. Faster and More Reliable Delivery By caching Az modules in your own ACR instances with MAR as an upstream source, customers benefit from faster downloads and higher reliability, especially within the Azure network. You can try installing Azure PowerShell from MAR using the following PowerShell command: $acrUrl = 'https://mcr.microsoft.com' Register-PSResourceRepository -Name MAR -Uri $acrUrl -ApiVersion ContainerRegistry Install-PSResource -Name Az -Repository MAR For detailed installation instructions and prerequisites, refer to the official documentation: Optimize the installation of Azure PowerShell | Microsoft Learn Enhancements to user experience Azure PowerShell Enhancements at Microsoft Build 2025 As part of the Microsoft Build 2025 announcements, Azure PowerShell has introduced several significant improvements to enhance usability, automation flexibility, and overall user experience. Real-Time Progress Bar for Long-Running Operations Cmdlets that perform long-running operations now display a real-time progress bar, offering users clear visual feedback during execution. Smarter Output Formatting Based on Result Count Output formatting is now dynamically adjusted based on the number of results returned: A detailed list view is shown when a single result is returned, helping users quickly understand the full details. A table view is presented when multiple results are returned, providing a concise summary that's easier to scan. JSON-Based Resource Creation for Improved Automation Azure PowerShell now supports creating resources using raw JSON input, making it easier to integrate with infrastructure-as-code (IaC) pipelines. When this feature is enabled (by default in Azure environments), applicable cmdlets accept: JSON strings directly via *ViaJsonString External JSON files via *ViaJsonFilePath This capability streamlines scripting and automation, especially for users managing complex configurations. We're always looking for feedback, so try the new features and let us know what you think. Improved for custom and disconnected clouds: Azure CLI now reads extended ARM metadata In disconnected environments like national clouds, air-gapped setups, or Azure Stack, customers often define their own cloud configurations, including custom dataplane endpoints. However, older versions of Azure CLI and its extensions relied heavily on hardcoded endpoint values based only on the cloud name, limiting functionality in these isolated environments. To address this, Azure CLI now supports reading richer cloud metadata from Azure Resource Manager (ARM) using API version 2022-09-01. This metadata includes extended data plane endpoints, such as those for Arc-enabled services and private registries previously unavailable in older API versions. When running az cloud register with the --endpoint-resource-manager flag, Azure CLI automatically parses and loads these custom endpoints into its runtime context. All extensions, like connectedk8s, k8s-configuration, and others, can now dynamically use accurate, environment-specific endpoints without needing hardcoded logic. Key Benefits: Improved Support for Custom Clouds: Enables more reliable automation and compatibility with Azure Local. Increased Security and Maintainability: Removes the need for manually hardcoding endpoints. Unified Extension Behavior: Ensures consistent behavior across CLI and its extensions using centrally managed metadata. Try it out: Register cloud az cloud register -n myCloud --endpoint-resource-manager https://management.azure.com/ Check cloud az cloud show -n myCloud For the original implementation, please refer to https://github.com/Azure/azure-cli/pull/30682. Azure PowerShell WAM authentication update Since Azure PowerShell 12.0.0, Azure PowerShell supports Web Authentication Manager (WAM) as the default authentication mechanism. Using Web Account Manager (WAM) for authentication in Azure enhances security through its built-in identity broker and default system browser integration. It also delivers a faster and more seamless sign-in experience. All major blockers have been resolved, and we are actively working on the pending issues. For detailed announcements on specific issues, please refer to the WAM issues and Workarounds issue. We encourage users to enable WAM functionality using the command: Update-AzConfig -EnableLoginByWam $true. under Windows operating systems to ensure security. If you encounter issues, please report them in Issues · Azure/azure-powershell. Improve Copilot's response quality and performance Azure CLI/PS enhancement with Copilot in Azure In the first half of 2025, we improved the knowledge of Azure CLI and Azure PowerShell commands for Azure Copilot end-to-end scenarios based on best practices to answer questions related to commands and scripts. In the past six months, we have optimized the following scenarios: Introduced Azure concept documents to RAG to provide more accurate and comprehensive answers. Improved the accuracy and relevance of knowledge retrieval query and chunking strategies Support more accurate rejection of the out-of-scope questions. AI Shell brings AI to the command line, enabling natural conversations with language models and customizable workflows. AI Shell is in public preview and allows you to access Copilot in Azure. All the optimizations apply to AI Shell. For more information about AI Shell releases, see: AI Shell To learn more about Microsoft Copilot for Azure and how it can help you, visit: Microsoft Copilot for Azure Breaking Changes⯠You can find the latest breaking change guidance documents at the links below. To learn more about the breaking changes, ensure your environment is ready to install the newest version of Azure CLI and Azure PowerShell, see the release notes and migration guides. Azure CLI: Release notes & updates â Azure CLI | Microsoft Learn Azure PowerShell: Migration guide for Az 14.0.0 | Microsoft Learn Milestone timelines: Azure CLI Milestones Azure PowerShell Milestones Thank you for using the Azure command-line tools. We look forward to continuing to improve your experience.âŻWe hope you enjoy Microsoft Build and all the great work released this week. We'd love to hear your feedback, so feel free to reach out anytime.âŻâŻ GitHub: o https://github.com/Azure/azure-cli o https://github.com/Azure/azure-powershell Let's stay in touch on X (Twitter) :âŻ@azureposh⯠âŻ@AzureCliâŻAn Update on Bicep Azure Verified Modules for Platform Landing Zone (ALZ)
But first some history and context As you may of heard in one of our Azure Landing Zone (ALZ) community calls over the past year, across ALZ we have been working hard to refactor both our Terraform and Bicep implementation options to be built upon Azure Verified Modules (AVM). Earlier this year we announced that the work for Terraform, which we started on first, was complete; and you can read more about that in the announcement blog post we posted here. But whilst this work was going on the ALZ Bicep team where already busy planning how they would go about doing the same and rebuilding ALZ Bicep from AVM modules. You can see the original plans and where we also asked for feedback in the GitHub issue (#791) . Enough history, what's the latest? Now to answer the question everyone has and rightly so đ Well, it's good news! We have been busy working away on getting a number of the AVM Bicep Resource Modules updated with missing bits and pieces that we need from an ALZ perspective. All fairly minor in most cases but some required some bigger updates than others, and some modules didn't exist at all so we have had to propose, create, and publish those of which we are pretty much done with đ We are still working towards an end of Q4 (June/July) target for a preview release of all the modules, accelerator and guidance on how to use the new version of ALZ Bicep, which will be called "Bicep Azure Verified Modules for Platform Landing Zone (ALZ)"; this is to align with Terraform and also to provide clear distinction between ALZ Bicep and the new AVM based version. Please note that the timeline shared above is an ETA and may move Announcing the preview release of `avm/ptn/alz/empty` AVM Pattern Module Before we get to a more complete release of all the required resources and modules to build the entire ALZ architecture with the new Bicep Azure Verified Modules for Platform Landing Zone (ALZ), we wanted to share an early look at the module that will be at the heart of all of your ALZ deployments. That module is called `avm/ptn/alz/empty` and is available in the Public Bicep Registry for you to try out today (currently version `0.1.0`)! Tip: Checkout the "max" test in the tests directory for advanced usage examples! module testMg 'br/public:avm/ptn/alz/empty:0.1.0' = { params: { managementGroupName: 'test-mg' // Other parameters here... } } This module is 1 of 11 modules that will all be based off the same code. The module optionally creates all of the below: The Management Group itself Can also target an existing Management Group Management Group Subscription Associations RBAC Custom Role Definitions RBAC Role Assignments Policy Assignments Custom Policy Definitions Custom Policy Set Definitions (Initiatives) There will also be 1 x Bicep Azure Verified Modules for Platform Landing Zone (ALZ) pattern module for each of the ALZ Architectures Management Groups, plus this empty one for custom and advanced scenarios. A reminder of those Management Groups and the associated modules that will be created for each of them: `avm/ptn/alz/int-root` `avm/ptn/alz/platform` `avm/ptn/alz/platform-management` `avm/ptn/alz/platform-identity` `avm/ptn/alz/platform-connectivity` `avm/ptn/alz/landing-zones` `avm/ptn/alz/landing-zones-corp` `avm/ptn/alz/landing-zones-online` `avm/ptn/alz/decommissioned` `avm/ptn/alz/sandbox` These Management Group aligned pattern modules will create the same resources as above, but will have the latest release of the ALZ Library baked in to each of the modules. Meaning that for the `avm/ptn/alz/int-root` pattern module, you won't have to declare all of the ALZ RBAC Custom Role Definitions, Custom Policy Definitions, Policy Assignments etc. via the input parameters as they'll be hardcoded in the module based off the latest release from the ALZ Library at the point the version of the module was released. This means that to build the ALZ Management Group hierarchy and make all of the default ALZ policy assignments, as documented here, you'd need a bicep file that would look something like this as a starting point: Important: None of these modules exist below today! module intRootMg 'br/public:avm/ptn/alz/int-root:0.1.0' = { params: { managementGroupName: 'int-root-mg' } } module platformMg 'br/public:avm/ptn/alz/platform:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: intRootMg.outputs.managementGroupId } } module platformConnectivityMg 'br/public:avm/ptn/alz/platform-connectivity:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: platformMg.outputs.managementGroupId } } This will make getting the ALZ Architecture out of the box really fast, and also really easy to upgrade and get the latest updates, by just bumping the version number as you desire when you are ready. Coupled with the `avm/ptn/alz/empty` module to add your own additional Policy Definitions and assignments, etc. at the same Management Groups scopes also helps you decouple the constant updates to the ALZ architecture and policies etc. from your own additional requirements. Helping you keep your code cleaner and our modules simple to maintain as we won't have to cater for handling additional custom definitions and assignments alongside the defaults from ALZ that are baked into the modules. Note: We are looking at suggesting that all of these are deployed via Deployment Stacks to help with lifecycle management of resources. e.g. help clean-up resources as well as deploy new ones; think policy assignments and definitions etc. We need to complete a lot more testing on this, but would love your feedback on experiences if you have any using Deployment Stacks to manage these kind of resources today. Open an issue/discussion on the ALZ Bicep GitHub repo đ Our asks to you đ«” Please go try out and test the new `avm/ptn/alz/empty` module and test it out for all the scenarios you can think of relating to Management Groups, RBAC, Policies etc. we want to make sure it's "match fit/ready" before we then build the Management Group aligned modules and bake in the ALZ defaults to them. So please go and put the module through its paces and test it out. Tip: Checkout the "max" test in the tests directory for advanced usage examples! If you find any issues, bugs, feature requests or just have a question on how to use it, please just raise them as GitHub issues here (make sure to select the `avm/ptn/alz/empty` module from the drop down đ) Thanks in advance for all your efforts and assistance and we look forward to hearing and getting your feedback on the module đ
Resilience Testing with Azure Chaos Studio: Compute Failures
Introduction Chaos Studio is an Azure service that helps you measure, understand, and build application and service resilience to real-world incidents, such as an unexpected infrastructure disruption or an application failure causing 100% CPU usage on a VM. In this new series of blog posts, weâll share best practices on performing resilience tests for common failure scenarios, provide step-by-step tutorials, and discuss how to leverage test results to improve the resilience of your cloud applications. Today, weâll focus on using Chaos Studio to simulate a compute failure. Resilience Testing Best Practices We recommend using a hypothesis-driven approach for resilience testing to ensure actionable results: Define a hypothesis: outline a specific failure scenario and predict how your infrastructure will perform if it occurs. Design a fault injection experiment that reflects the failure scenario you wish to test and set up proper telemetry to monitor performance over the course of the experiment. Run your experiment and analyze results to determine if your hypothesis was validated or invalidated. Make necessary improvements to your configurations based on your findings. As your cloud infrastructure changes and evolves, new dependency and configuration issues may arise â repeat this process over time to ensure continued reliability. Simulate a Compute Failure Scenario Today, weâll be performing an Availability Zone shutdown on a Virtual Machine Scale Set configured with instances across multiple Availability Zones. Remember to define a hypothesis before conducting your resilience test, for example: âIf one Availability Zone is shut down, the Virtual Machine Scale Setâs autoscale configuration will detect the drop in instance count and automatically provision additional instances in the remaining zones, maintaining overall capacity and performance.â Next, weâll create and run a fault injection experiment to test our scenario using Chaos Studio. Prerequisites A valid Azure subscription. If you donât have one, https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account?icid=azurefreeaccount. A Virtual Machine Scale Set configured with instances across multiple availability zones. Ensure that it is located in a https://learn.microsoft.com/en-us/azure/chaos-studio/chaos-studio-region-availability. If you donât have one, you can follow the https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/flexible-virtual-machine-scale-sets-portal to create one. If this is your first time using Chaos Studio, follow the instructions below to register the resource provider for your subscription Open the https://portal.azure.com/. Search for and select Subscriptions. Select the subscription youâd like to use. Select Settings > Resource providers from the left-side menu. Search for and select Microsoft.Chaos. Select Register. Create an Experiment and Set Up Monitoring To create an Availability Zone shutdown experiment on your Virtual Machine Scale set, do the following: Open the https://portal.azure.com/. Search for and select Chaos Studio. Select Targets from the left-side menu. Select the Virtual Machine Scale Set youâd like to test and select Enable targets > Enable service-direct targets (All resources) > Review + Enable > Enable. Navigate back to Chaos Studio and select Experiments from the left-side menu. Select Create > New experiment. On the Basics tab, select a subscription and resource group for your experiment. Give your experiment a name and select the region youâd like to store it in. On the Permissions tab, select whether youâd like to use a System or User-assigned https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview to manage your experiment permissions. If youâre unsure of which to choose, select the system-assigned identity option. Check the Enable custom role creation and assignment checkbox â this will allow Chaos Studio to automatically assign the necessary permissions to your managed identity based on your experiment configuration. On the Experiment designer tab, select Add action > Add fault. Choose the VMSS Shutdown (version 2.0) fault from the dropdown. Select Next: Target resources and select your Virtual Machine Scale Set. Select Next: Scope, choose the zone youâd like to shut down, and select Add. Select the Review + create button, review the experiment configuration, and select Create. The metrics you should monitor for your experiment run depend on the hypothesis you came up with for your scenario. Since our sample hypothesis predicted that our Virtual Machine Scale Set would provision additional instances in the event of a disruption based on its autoscale setting, weâll show you how to track the availability of your Virtual Machine Scale Setâs virtual machine instances: Search for your Virtual Machine Scale Set by name using the Azure portal search bar and select it to go to its overview page. Select Monitoring > Metrics from the left-side menu. Configure a metric with the following values: Scope: your Virtual Machine Scale Set Metric Namespace: Virtual Machine Host Metric: VM Availability Metric (Preview) Aggregation: Avg Select Add metric. You may select Save to dashboard and choose the Pin to dashboard, Pin to Grafana, or Send to workbook options to save your metric where youâd like. The VM Availability Metric will now display an average of the availability of your virtual machine instances within your Virtual Machine Scale Set over the course of your experiment run. Run the Experiment and Analyze Results To run your experiment, do the following: Within the Azure portal, navigate back to Chaos Studio and select Experiments from the left-side menu. Select your experiment and select Start experiment(s) > Yes from the bar at the top of the page. Select your experimentâs name to navigate to its overview page. Select the Details button under History to monitor its progress while running. While your experiment is running, navigate to your Virtual Machine Scale Set > Monitoring > Metrics, or the location where you saved your VM Availability Metric, and view the impact of the Availability Zone shutdown on your Virtual Machine Scale Setâs average instance availability: Recommendations to Improve Resiliency Did your Virtual Machine Scale Set perform as you expected it to during the Availability Zone shutdown? If not, here are some steps you can take to improve your resiliency for future tests and protect against real-world incidents: Configure or review the autoscale settings on your Virtual Machine Scale Set to ensure rapid provisioning of additional instances in unaffected zones during a failure. Maintain a balanced instance count across Availability Zones to minimize the impact of losing an entire zone. Set up load balancing or adjust configurations to seamlessly redistribute traffic when a zone becomes unavailable. After making improvements to your Virtual Machine Scale Set configuration, be sure to test and iterate on them by continuing to perform resilience testing regularly. Conclusion In this blog post, we have shown you how to use Chaos Studio to test your Virtual Machine Scale Sets against Availability Zone shutdowns. With the best practices laid out in this guide, you can conduct resilience tests on services across your cloud infrastructure using faults in Chaos Studioâs https://learn.microsoft.com/en-us/azure/chaos-studio/chaos-studio-fault-library. Be sure to look out for more blog posts covering other scenarios in the âResilience Testing with Azure Chaos Studioâ series soon. Feel free to add a comment below on which scenarios youâd like to see next. Happy resilience testing! Additional resources Chaos Studio Overview: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faka.ms%2FAzureChaosStudio&data=05%7C02%7Cprashabora%40microsoft.com%7C97b85263de9e45fec53208dcc261447e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638598970291980382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KXjm66iNnes%2Fi23UaLV6jQxB7CMUJ%2Bmb%2F2BKhOcJyqY%3D&reserved=0 Documentation: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fchaos-studio%2F&data=05%7C02%7Cprashabora%40microsoft.com%7C97b85263de9e45fec53208dcc261447e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638598970291987614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WeI29vxwtCJU%2Bt7m9gBFZePH2nCwH2X5fNo7S%2B1gEr0%3D&reserved=0 MS Build Session Recording: https://www.youtube.com/watch?v=lk1yxLMj-7A https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fazure.microsoft.com%2Fen-us%2Fblog%2Fadvancing-microsoft-azure-resilience-with-chaos-studio%2F&data=05%7C02%7Cprashabora%40microsoft.com%7C97b85263de9e45fec53208dcc261447e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638598970291994792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EuoO5oln%2BmznS%2B4d3pCERBGc28anm91TWpF3pinqczs%3D&reserved=0 https://learn.microsoft.com/en-us/azure/chaos-studio/chaos-studio-region-availabilityUnlocking the Best of Azure with AzureRM and AzAPI Providers
With the recent release of AzAPI 2.0, Azure offers two powerful Terraform providers to meet your infrastructure needs: AzureRM and AzAPI. The key question is, when should you use each one? This article offers a clear guide for Terraform users, particularly those familiar with the AzureRM provider, on some ideal scenarios for each. The recommendations provided within this post are jointly provided between HashiCorp and Microsoft; click here for HashiCorp's blogpost.Azure Landing Zones Accelerators for Bicep and Terraform. Announcing General Availability!
Azure Landing Zones Accelerators are designed to simplify the process of onboarding your Infrastructure as Code into a robust CI / CD pipeline with Azure DevOps or GitHub. Learn more about what the Accelerator can do for you and why you should be using it.
