SLZ concepts
This article explains the various concepts associated with a Sovereign Landing Zone (SLZ).
Deployment and configuration methods for an SLZ
For organizations that want to streamline adoption, they can configure an SLZ from a singular parameter file and deploy it by running a singular script. The parameter file and its associated deployment orchestration provide consistency within the environment through steps such as using a common naming convention for resources and standardization within the environment. This design enables an organization to quickly get started with an SLZ without having to reference many manual deployment steps and various documentations.
When organizations need to demonstrate separation of duties and adherence to least privilege, they can configure an SLZ from one or more parameter files. Organizations can break deployment into individual steps based upon functional areas. For example, the team that provides subscriptions and configures management groups can do so as one deployment activity while still enabling a separate team to manage policies and compliance over these scopes. These individual deployment steps require coordination but enable a more granular deployment experience.
For more information on initially deploying the entire SLZ at once or using individual deployment steps, see Sovereign Landing Zone documentation on GitHub.
Advanced customizations to the SLZ
The SLZ parameter file helps an organization by fully configuring their deployment and ensuring consistency across all parts of the environment. Organizations should review the configuration options to determine the appropriate settings for their deployment.
However, the SLZ parameter file can't provide full configuration options for every possible setting a customer might desire to have. In the case where more capabilities are needed, we recommend the following options:
Request new configuration capabilities through a feature request. We recommend requesting these new capabilities when addressing general-purpose or common challenges.
Make customizations after SLZ deployment. Post-deployment steps are recommended when organizations need to place more controls or create additional resources before providing permissions for workload owners to use the environment.
Fork and maintain a local copy of the SLZ repository. We recommend using this option for organizations that need complete configuration control over their environment or require that their security controls are baked into the environment.
Use custom policies
Azure Policies are intended to provide appropriate visibility and technical guardrails to ensure a compliance posture is maintained. For many organizations, it's crucial that these policies are built into the environment prior to deploying workloads. The SLZ orchestration provides the ability for custom policy definitions and assignments to be created and deployed alongside an SLZ deployment and at specified scopes within the deployment. The orchestration provides organizations with the confidence that their unique compliance requirements are in place from the start. Organizations that don't need custom policies can also use the orchestration to assign built-in policy sets as well.
Our documentation on preview policy sets within the policy portfolio contains more information about how to use custom policies within an SLZ.
Minimize costs for pilots
When piloting or conducting a proof-of-concept, it's important to be conscientious of the cost implications. The default settings for the SLZ create a production-ready deployment, which could be cost-prohibitive for organizations that aren't yet ready for production. The SLZ orchestration provides toggles for many resources, and organizations should determine which ones are necessary for their deployment.
We recommend reviewing the following product offerings:
Azure DDoS Protection: We recommend the standard SKU due to its increased capabilities around traffic shaping, remediation, and visibility into DDoS events. However, you can use the basic SKU for nonproduction environments.
Azure Firewall: The Azure Firewall enables organizations to build strong network security around their SLZ deployment. However, organizations can find other Azure networking resources as suitable technologies for building security around nonproduction environments.
Azure VPN Gateway: The Azure VPN Gateway and ExpressRoute offerings enable an organization to connect their on-premises environments to Azure. However, organizations might not need nonproduction environments to have this type of network connectivity and can use Azure Bastion or other access technologies instead.