Deploy a CAF Foundation blueprint in Azure
The Azure landing zones Implementation options section of the Cloud Adoption Framework is undergoing a freshness update.
As part of this update, we will be revising the table of contents and article content, which will include a combination of refactoring and consolidation of several articles. An update will be posted on this page once the work is completed.
Visit the new "Deployment options" section of the Azure Architecture Center for the latest Azure landing zone implementation content, including platform and application landing zones.
The CAF Foundation blueprint doesn't deploy a landing zone. Instead, it deploys the tools required to establish a governance MVP (minimum viable product) to begin developing your governance disciplines. This blueprint is designed to be additive to an existing landing zone and can be applied to the CAF Migration landing zone blueprint with a single action.
Deploy the blueprint
Before you use the CAF Foundation blueprint in the Cloud Adoption Framework, review the following design principles, assumptions, decisions, and implementation guidance. If this guidance aligns with the desired cloud adoption plan, the CAF Foundation blueprint can be deployed using the deployment steps.
This implementation option deploys a minimum viable product (MVP) to serve as the foundation for your governance disciplines. The team follows a modular refactoring-based approach to mature the governance disciplines using the Govern methodology.
This implementation option provides an opinionated approach to the common design areas shared by all Azure landing zones. For technical details, see the Assumptions section.
Azure billing and Active Directory tenant
This implementation option doesn't take an inherent position on enterprise enrollment. This approach is designed to be applicable to customers regardless of contractual agreements with Microsoft or Microsoft partners. Prior to deployment of this implementation option, it's assumed that the customer has already created a target subscription.
Identity and access management
This implementation option assumes that the target subscription is already associated with a Microsoft Entra instance in accordance with identity management best practices.
Network topology and connectivity
This implementation option assumes the landing zone already has a defined network topology in accordance with network security best practices.
This implementation option demonstrates how Azure Policy can add some elements of resource organization through the application of tags. Specifically, a
CostCenter tag is appended to resources using Azure Policy.
The governance team should compare and contrast the elements of resource organization to be addressed by tagging versus those that should be addressed through subscription design. These fundamental decisions inform resource organization as your cloud adoption plans progress.
To aid in this comparison early in adoption cycles, the following articles should be considered:
- Initial Azure subscriptions: At this stage of adoption scale, does your operating model require two, three, or four subscriptions?
- Scale subscriptions: As adoption scales, what criteria is used to drive subscription scaling?
- Organize subscriptions: How will you organize subscriptions as you scale?
- Tagging standards: What other criteria need to be consistently captured in tags to augment your subscription design?
To aid in this comparison when teams are further along with cloud adoption, see the governance patterns section of the governance guide: prescriptive guidance article. This section of the prescriptive guidance demonstrates a set of patterns based on a specific narrative and operating model. That guidance also includes links to other patterns that should be considered.
This implementation option doesn't implement controls for the primary purpose of security. In the absence of defined security controls, you shouldn't use this landing zone for mission critical workloads or sensitive data. It's assumed you're using this landing zone for limited production deployment. This deployment starts your learning, iteration, and development of the operating model in parallel with these early migration efforts.
To accelerate parallel development of security disciplines, review the Secure methodology. Consider deploying the Cloud Adoption Framework Foundation blueprint along with the Cloud Adoption Framework Migration landing zone blueprint.
This implementation option doesn't implement key aspects of the operations baseline. In the absence of a defined operations baseline, this landing zone shouldn't be used for mission critical workloads or sensitive data. It's assumed that this landing zone is being used for limited production deployment to initiate learning, iteration, and development of the overall operating model in parallel to these early stage migration efforts.
As the operations baseline is developed, refactoring may be required. Specifically, resources may later need to be moved to a new subscription or resource group.
This implementation option doesn't have affordances for business continuity and disaster recovery (BCDR). It's assumed that the solution for protection and recovery will be addressed by the development of the operations baseline.
This implementation demonstrates one approach to maturity in the Cost Management discipline of the Govern methodology. Specifically, it demonstrates how Azure Policy can be used to create an allowlist of specific SKUs. Limiting the types and sizes of resources that can be deployed into a landing zone reduces the risk of overspending.
To accelerate parallel development of the other governance disciplines, review the Govern methodology. To continue maturing the Cost Management discipline of governance, see the Cost Management discipline guidance.
As the governance disciplines mature, refactoring may be required. Refactoring may be required. Specifically, resources may later need to be moved to a new subscription or resource group.
Platform automation and DevOps
This implementation option doesn't implement automated Azure Pipelines in DevOps. In the absence of defined automation, you shouldn't use this landing zone for mission critical workloads or sensitive data. It's assumed you're using this landing zone for limited production deployment. This deployment starts your learning, iteration, and development of the operating model in parallel with these early migration efforts.
To accelerate parallel development, review the Ready methodology. Consider deploying the Cloud Adoption Framework Foundation blueprint along with the Cloud Adoption Framework Migration landing zone blueprint.
This initial blueprint assumes that the team is committed to maturing governance capabilities in parallel to the initial cloud migration efforts. If these assumptions align with your constraints, you can use the blueprint to begin the process of developing governance maturity.
- Compliance: No third-party compliance requirements are needed in this landing zone.
- Limited production scope: This landing zone could potentially host production workloads. It isn't a suitable environment for sensitive data or mission-critical workloads.
If these assumptions align with your current adoption needs, then this blueprint might be a starting point for building your landing zone.
Learn more and download a reference sample of the CAF Foundation blueprint for deployment or customization from the Azure blueprint samples.
When you're ready to expand this foundation into your first landing zone, see Transition existing Azure environments to the Azure landing zone conceptual architecture.