An application can run successfully in Azure before anyone has settled who can change production, how private data is accessed, or who responds when something fails.
Those questions become harder to resolve once people depend on the system. Before launch, the application and the Azure environment around it both need attention.
For teams building or expanding in Azure, a landing zone provides a structure for making those decisions.
Where an Azure landing zone fits
Microsoft's Azure landing zone guidance describes an architecture for governing, securing, and scaling Azure environments across subscriptions. It separates the foundation into two parts:
- The platform landing zone provides shared governance and services, such as connectivity, security, and management.
- Workload landing zones are the environments where teams deploy and operate their applications, data, and supporting resources within those shared rules.
That distinction matters. A platform team might manage network connectivity and subscription policies, while an application team manages releases, application health, and data recovery. Both need to understand where their responsibilities meet.
The scope should reflect what you run. A small application and a business with dozens of connected systems have different needs. Start with the requirements, then choose the structure and services needed to meet them.
Five decisions to make before launch
1. Who can access and change the environment?
Use Microsoft Entra ID and Azure role-based access control (RBAC) to give people the permissions they need at an appropriate scope. Separate routine development access from privileged production access.
For elevated roles, consider time-limited activation through Privileged Identity Management, subject to licensing. Where supported, use managed identities for applications accessing Azure services to reduce the need to store and rotate credentials.
Microsoft's landing zone identity guidance covers these choices. Before launch, confirm who can deploy, change permissions, and handle an emergency.
2. How will subscriptions and policies be organized?
Subscriptions help separate workloads and environments. Management groups let you apply policies across subscriptions with similar requirements.
Keep the hierarchy understandable. Microsoft advises against copying the company organization chart into a deeply nested management group structure. Group subscriptions around shared governance needs, with appropriate separation between production and nonproduction. See its management group recommendations.
Be precise about what policies do. Azure Policy can audit configurations, block certain changes, or support remediation, depending on the policy effect. Assigning a policy does not automatically fix every existing resource or establish regulatory compliance. Test the impact and plan remediation before enforcing new restrictions. Microsoft's Azure Policy overview explains the differences.
3. What can connect to what?
Decide which services need public access, which require private connectivity, and how the application reaches existing business systems.
Private endpoints can provide private access to supported Azure services, but they also require correct DNS and network configuration. Creating an endpoint alone does not settle every service's public-access settings. Review those settings separately and test connectivity from the places that actually need access, including deployment tools and support staff. Microsoft's private endpoint DNS guidance explains common configurations.
Document the intended connections. A network diagram should help someone understand how the application operates and troubleshoot a failed connection.
4. Who will know when something goes wrong?
Configure useful logs, alerts, and notification routes. Azure Monitor can support platform and application monitoring; Microsoft Defender for Cloud can surface security recommendations and alerts according to the enabled capabilities.
Assign an owner to each operational response. Decide what warrants an immediate call, what can wait, and how long logs need to be retained.
Microsoft provides monitoring guidance for landing zone components, but application-specific checks still need attention. A healthy server does not prove that orders are processing correctly. Agree on recovery requirements and test the application's restore procedure before relying on it.
5. What will the environment cost to operate?
Estimate the application and its supporting services together. Networking, security services, backups, and log ingestion or retention can all contribute to the bill.
Use ownership tags, budgets, and a regular cost review. Remember that Azure budgets provide alerts; they do not stop consumption by themselves.
Include the people needed to operate the environment in the support plan. Someone must review alerts, manage changes, and keep the configuration current.
Make the foundation repeatable
Microsoft's recommended platform deployment approach uses the Azure landing zone infrastructure-as-code accelerator with Azure Verified Modules for Terraform or Bicep.
Infrastructure as code makes configuration easier to review, version, and deploy consistently. It also gives the team a record of intended changes.
The accelerator is a starting point. Review its configuration against your requirements, use a controlled deployment process, and test changes before applying them to production. The team maintaining the environment needs to understand what has been deployed.
If you already have applications in Azure
You can improve an existing environment incrementally. Start by mapping resources, access, dependencies, policies, and ownership. Identify the gaps that present the greatest operational risk.
Take care when reorganizing subscriptions. Moving a subscription under a different management group can change the policies and permissions it inherits, affecting later deployments and updates. Microsoft's transition guidance covers these considerations.
Getting ready with Canviz
Canviz works across Azure and the Microsoft ecosystem. We can help you review the application and the environment it will depend on, identify what needs attention before launch, and agree on who will support it afterward.
The useful outcome is a foundation your team understands, can operate, and can extend as the application grows.
