Cloud Adoption Framework (CAF) guides you to implement your cloud workloads in Azure with best practices. We encounter the concept of Landing Zones at the latter part of CAF.
I will briefly describe the concept of Landing Zones in this article. You can access the official documentation via this link
Landing Zones
Landing Zones allow us to implement resources within subscriptions declaratively. It will commission the foundation of our cloud tenant with best practices and guidelines.
Why do we need landing zones? What is the problem with GUI/Wizard based provisioning via the beloved portal?
Landing zones are built with code to provision workloads in our tenant. Since it is written in code, we can version our cloud infrastructure in a source code repository. As we have the code, we can scale our cloud environment as we wish and we can repeatedly execute this in many environments.
Furthermore, landing zones are built in declarative manner where our resources are idempotent. Landing zones are structured in a modular manner where we can execute another landing zone in our environment on top of an existing zone.
Following are the key takeaways :)
- Version control
- Scalable
- Repeatable
- Declarative
- Idempotent
- Modular
There are mainly two ways that we can implement the our landing zones
1. Small Scale (Forever small or starting small)
Let's assume that we have only a single subscription or we want to start very small and gradually progress to enterprise level. Then the small scale landing zone model would be the preferred design choice.
We can develop small scale landing zone with ARM templates, Azure Policy and Azure Blueprint.
Azure provides kick-start packages where we can start our small scale landing zone journey.
Since landing zones are modular in nature, we can first apply the foundation blueprint and later add the migration blueprint to the same subscription.
2. Enterprise Scale
This is where you design and build your tenant at enterprise level. The tenant might contain multiple subscriptions with their own dedicated workloads.
Why do we need multiple subscriptions in my tenant? can't I use a single subscription to house all my workloads?
Yes you can. But that's not the best practice. The idea is to separate and contain interests within specific boundaries.
For an example you can have a subscription to contain specific application and relevant components. You can secure and govern it with firewalls and policies. You should not mix this with unrelated Virtual Machine workloads that cater a separate business function. Ideally those workloads should reside in a separate subscription.
We can develop enterprise scale landing zones with ARM templates and Azure policies.
Azure provides following kick-start packages for enterprise
