Satish Sunker and Heinrich Wewers explain why Azure Deployment Stacks are a smart next step toward greater governance and confidence in the cloud.
As cloud environments evolve and scale, managing infrastructure across multiple subscriptions, environments, and teams has become one of the most persistent challenges for IT professionals and managed service providers (MSPs) alike. The need for speed, consistency, and governance has never been more pressing and yet achieving all three simultaneously can often feel impossible.
Azure Deployment Stacks, one of Microsoft’s recent enhancements to the Azure Resource Manager (ARM) and Bicep ecosystem, aims to solve precisely that. By treating groups of Azure resources as cohesive, managed units, Deployment Stacks simplify lifecycle management and governance across complex environments without sacrificing flexibility or control.
To explore how Deployment Stacks can transform infrastructure management in Azure, we asked Cloud Solutions Architect Satish Sunker and Senior Cloud Consultant Heinrich Wewers to share their insights on what Deployment Stacks can do, why they matter, and how enterprises and MSPs can start benefiting from them.
The growing complexity of cloud infrastructure
Today’s cloud teams operate under immense pressure, says Satish Sunker. “Scaling infrastructure is no longer a nice-to-have… It’s actually an expectation from the business,” he explains. “Teams are required to provision and expand environments quickly, without compromising reliability or performance.”
With this pressure comes complexity. Maintaining consistency across environments, subscriptions, and regions can become a full-time job in itself. Each team may interpret organisational standards slightly differently or make ad hoc changes that cause divergence in the long run. “Over time, manual changes and one-off fixes can cause configuration drift from the original deployment templates,” adds Sunker. “Technical teams spend a lot of time remediating resources that are not compliant or do not meet security requirements.”
This challenge is compounded by concerns about cost management. “Teams are being squeezed to optimise spend while maintaining availability,” notes Sunker. “That often means implementing automation to dynamically scale resources up or down, which can add another layer of complexity.”
Before Deployment Stacks, many organisations relied solely on ARM or Bicep templates to deploy Azure resources declaratively. While effective for provisioning, they lacked robust lifecycle management capabilities. Once resources were deployed, keeping them in sync and cleaning them up safely was largely a manual or script-driven process.
“Enterprises want their cloud teams to be agile and manage their own infrastructure, but that can lead to inconsistencies in governance, security, and compliance. Technical debt tends to build up over time, as it becomes harder to maintain control and consistency across large environments,” says Sunker.
This is where Azure Deployment Stacks come into play.
What is an Azure Deployment Stack?
At its core, an Azure Deployment Stack is a resource that acts as a container for multiple deployed resources, allowing them to be treated as a single, unified entity, explains Heinrich Wewers.
“Unlike a traditional ARM or Bicep deployment, which simply provisions resources, a Deployment Stack establishes a managed relationship between Azure and the resources it deploys,” says Wewers. “Azure keeps track of those resources as part of the stack, allowing for more controlled updates and cleanups.”
Behind the scenes, when a Deployment Stack is created, Azure registers a management relationship between the stack and each deployed resource. “This relationship allows Azure to track, update and clean up those resources as a single managed identity,” adds Wewers. “It ensures consistency throughout the resource lifecycle.”
The main components that make up a Deployment Stack include:
- A Bicep or ARM deployment template and parameters
- A deployment scope (such as subscription, management group, or resource group)
- Deny settings that control who can modify managed resources
- Exclusions for specific identities or service principals that require access
The introduction of Deployment Stacks marks an important shift in how Azure environments can be managed at scale.
“They help eliminate operational risks and reduce technical debt caused by limited control, poor lifecycle management, and lack of visibility over deployed resources,” says Wewers. “By keeping related resources grouped and tracked together, they reduce compliance gaps and ensure consistent configuration across subscriptions.”
Deployment Stacks also reduce the risk of human error. “They bring structure and predictability to how resources are deployed, updated, and cleaned up,” notes Wewers. “That’s critical for large teams working across shared environments.”
By embedding management and governance directly into the deployment process, Deployment Stacks effectively extend Infrastructure-as-Code (IaC) capabilities into the operational lifecycle. “Traditional ARM and Bicep templates are great for provisioning, but they offer limited visibility and lifecycle control once resources are deployed. Deployment Stacks enhance that process with additional management capabilities.”
How do Azure Deployment Stacks work?
The workflow for building and managing an Azure Deployment Stack follows a structured, repeatable pattern. “The first step is to identify which resource groups should be managed together as part of the same stack. This helps define clear boundaries for ownership and lifecycle management. Once the scope is set, you can use existing ARM or Bicep templates to define the resources that make up the stack. From there, Azure establishes the management relationship with each deployed resource,” explains Wewers.
When templates are changed later, Azure automatically manages updates intelligently. “When changes are made to the templates, one of two things can happen: any new resources added to the template are automatically brought under management by the Deployment Stack, and any resources removed from the template become unmanaged. Azure also allows you to define what should happen to those unmanaged resources… For example, whether they should be retained or automatically deleted.”
This makes ongoing lifecycle control more predictable and less error-prone.
Tools, integrations, and limitations
Sunker highlights that Deployment Stacks integrate seamlessly into existing workflows. “You can use Azure CLI or Azure PowerShell to create and update Deployment Stacks,” he says. “In most cases, current resource deployment processes using ARM or Bicep can be seamlessly adapted to deploy and manage resources through Azure Deployment Stacks, without significant changes to existing templates or pipelines.”
However, there are a few limitations to bear in mind when working with Deployment Stacks:
- There’s a limit of 800 deployment stacks within a single scope.
- You can’t directly add existing Azure resources under the management of a stack if they were not originally deployed through that stack.
- Deny settings cannot be configured at the management group scope.
These constraints are likely to evolve as the feature matures, notes Sunker, so it’s worth checking the Microsoft documentation regularly for updates.
Business and operational advantages
Sunker points out that, beyond the technical capabilities, Azure Deployment Stacks deliver measurable business benefits. “From a business and operational standpoint, the biggest advantage is the increased efficiency in managing Azure resources. This efficiency translates directly into cost savings and reduced management overhead, easing the burden on cloud teams. By simplifying resource lifecycle management and improving consistency, organisations can focus more on innovation and less on maintenance,” he says.
Deployment Stacks also play a significant role in strengthening governance, consistency, and compliance across environments by reducing the need for manual actions and therefore lowering the risk of human error or oversight. “Deny settings can enforce policy and prevent engineers from making unapproved configuration changes or quick fixes that could drift from organisational standards. Because all resources in a Deployment Stack share the same lifecycle, orphaned resources are minimised, ensuring cleaner environments and easier compliance reporting.”
By combining lifecycle management with governance controls, Deployment Stacks help enterprises achieve a more secure, predictable, and compliant cloud operating model, without slowing down delivery.
Sunker also notes that Azure Deployment Stacks naturally reinforce key pillars of the Azure Well-Architected Framework, including:
- Operational excellence: Deployment Stacks support efficient, repeatable operations.
- Reliability: Deployment Stacks reduce configuration drift and improve system stability.
- Security: Deny settings and managed relationships help enforce access boundaries and prevent unauthorised changes.
- Cost optimisation: Streamlined lifecycle management reduces resource sprawl and orphaned assets.
- Performance efficiency: Deployment Stacks ensure consistent, optimised deployments as business requirements evolve.
This alignment makes Deployment Stacks an attractive option for enterprises pursuing well-architected cloud environments.
Real-world scenarios
BUI has started adopting Azure Deployment Stacks in customer projects to address challenges observed in previous IaC implementations, particularly around configuration drift and lifecycle management, Wewers shares.
“Azure Deployment Stacks don’t replace IaC, they enhance it. By adding structured lifecycle management and governance capabilities on top of existing ARM or Bicep deployments, Azure Deployment Stacks make it easier for enterprises to adopt and scale IaC with greater confidence and control.”
Wewers gives an example: “A common scenario where Deployment Stacks deliver real value is managing proof-of-concept projects. These environments are typically short-lived, and manually tracking every deployed resource can lead to forgotten assets and unnecessary costs. With Deployment Stacks, all resources deployed during the POC are managed together. When the stack is deleted, every associated resource is automatically cleaned up.”
Deployment Stacks can also improve environment management across the development, testing and production stages, notes Wewers. “Each environment can be deployed as its own stack. This ensures environment isolation, consistent deployment, simplified lifecycle management, and clear auditability, all of which align with DevOps and governance best practices.”
Deployment Stacks are especially valuable during workload migrations or customer onboarding scenarios, he continues. “During migrations, Deployment Stacks allow you to replicate environments easily across subscriptions or regions using the same ARM or Bicep template. Temporary or transitional resources can be managed as a unit and once the migration is complete, deleting the stack safely removes all associated resources, preventing leftover costs or configuration drift. This capability helps MSPs, like us, to streamline transitions and maintain consistency from the first deployment.”
Common pitfalls to avoid
Sunker cautions that there are nuances to understand when it comes to Azure Deployment Stacks and highlights two common pitfalls.
“Mistake number one is assuming that stacks manage everything in a scope,” he warns. “Deployment Stacks only manage the resources they deploy. Any additional resources created outside the stack won’t be managed or removed when the stack is updated or deleted. Cloud teams must communicate and document which resources are under stack management and which are not.”
The second issue is overly strict Deny settings. “If Deny assignments are too restrictive, even the original deployment identity may lose the ability to manage the stack. It’s important to exclude the right service principals or admin accounts.”
Sunker’s advice? “Start small and focus on how resource management behaves before scaling to larger environments. Document your stack design and clearly define scopes to avoid confusion.”
Wewers has a similar outlook. For cloud teams ready to explore, he recommends a simple, hands-on approach: “You can use your existing ARM or Bicep templates and deploy them as a stack using Azure CLI or Azure PowerShell. Go slowly… Deploy a basic stack that includes just a few resources. Then experiment with Deny settings and the actionOnUnmanage parameters to see how Azure enforces governance and resource cleanup in practice.”
By experimenting early on, cloud teams can build familiarity and confidence before rolling out Azure Deployment Stacks across production environments.
Looking ahead
As a Microsoft Azure Expert MSP, BUI is already helping customers identify workloads that are ideal candidates for Azure Deployment Stacks. “Our approach focuses on planning the right configuration from the start and aligning governance, lifecycle management and team workflows to leverage the benefits fully,” says Sunker.
For enterprises looking to reduce operational overhead, enhance automation maturity, and improve governance, Deployment Stacks represent a significant evolution in how Azure environments can be deployed and managed, he continues. “By turning groups of resources into manageable, lifecycle-bound entities, Deployment Stacks bring order, visibility, and control to environments that were once sprawling and difficult to standardise.”
Wewers concurs. “The benefits extend beyond the technical: Deployment Stacks simplify operations, strengthen compliance, and support a more consistent, cost-effective cloud strategy. For enterprises that depend on Azure, Deployment Stacks are a smart next step toward greater governance and confidence in the cloud,” he concludes.
As a Microsoft Azure Expert MSP, we’re here to support every stage of your cloud journey, from design and deployment to automation, security, and optimisation. Our certified architects and engineers can help you leverage innovations like Azure Deployment Stacks to streamline your infrastructure now, while laying the foundation for future growth and resilience. Contact our team to get started.
