Azure Landing Zones (ALZ) Library

repository·main·Indexed 40 days ago

https://github.com/azure/azure-landing-zones-library

A collection of resources and implementations for establishing scalable, secure, and well-architected Azure environments. It includes the ALZ Terraform provider, management group architectures, and a comprehensive set of archetypes with Azure Policy definitions, set definitions, and assignments. Additionally, it provides the AMBA (Azure Monitor Baseline Alerts for Azure Landing Zones) library for implementing baseline monitoring, alerting, and notification configurations across the landing zone hierarchy.

Tokens
18.4K
Snippets
40
Records
65
Agent score
100%

What's inside Azure Landing Zones Library

  1. Access Azure Landing Zones Library documentation

    main

    The complete documentation for the Azure Landing Zones Library is hosted on GitHub Pages. For detailed guides, technical specifications, and usage instructions, visit the official site.

    https://azure.github.io/Azure-Landing-Zones-Library/
  2. Understand the Azure Landing Zones Library components

    main

    The Azure Landing Zones Library is a collection of resources designed to assist in building and managing Azure governance. It consists of two primary components:

    1. Azure Policy assets: Governance rules and definitions.
    2. Constructs: A series of components that combine to form a deployable architecture.

    A concrete implementation example can be found in the platform/alz directory of the repository.

  3. Understand the purpose of the Schemas directory

    main
    The schemas/ directory contains JSON schemas for data types used within the Azure Landing Zones Library. These schemas are specifically provided for data structures that are not already defined by standard Azure resource schemas. Developers can use these schemas to validate custom configuration data or internal project objects used during the deployment or management processes.
  4. What is an archetype and how is it defined?

    main

    An archetype is a collection of assets that can be deployed to an Azure management group. To support extensibility, multiple archetypes can be deployed to the same management group.

    An archetype definition must include a unique name and can reference associated assets such as policy definitions, policy set definitions, policy assignments, and role definitions. These assets are referenced by their exact name (the JSON .name property).

    Archetype definition files must follow these filename patterns:

    • *.alz_archetype_definition.json
    • *.alz_archetype_definition.yaml
    • *.alz_archetype_definition.yml
    name: "landing_zones"
    policy_assignments:
      - "Audit-AppGW-WAF"
      - "Deny-IP-forwarding"
    policy_definitions: []
    policy_set_definitions: []
    role_definitions: []
  5. Use Archetype Overrides to customize archetypes

    main

    An archetype override is a delta applied to an existing archetype. It allows you to modify the behavior of an archetype (adding or removing policy definitions, policy sets, assignments, or role definitions) without modifying the original archetype itself.

    Best Practices:

    • Use overrides in local libraries as the final step of customization.
    • Do not store archetype overrides in a central library.
    • Ensure the name of the override is unique across all archetypes and override archetypes.
    • All assets being added or removed must be referenced by their exact name (the JSON .name property).
    name: "landing_zones_override"
    base_archetype: "landing_zones"
    policy_assignments_to_add: []
    policy_assignments_to_remove:
      - "Deny-IP-forwarding"
    policy_definitions_to_add: []
    policy_definitions_to_remove: []
    policy_set_definitions_to_add: []
    policy_set_definitions_to_remove: []
    role_definitions_to_add: []
    role_definitions_to_remove: []
  6. Understand SLZ Archetypes and Policy Assignments

    main

    The Sovereign Landing Zone (SLZ) uses Archetypes to group related Azure Policy assignments. Each archetype represents a specific functional area or environment type (e.g., connectivity, corp, landing_zones, platform) and carries a set of guardrails to enforce security, compliance, and operational standards.

    When deploying or managing an SLZ, you select archetypes to apply the corresponding policy assignments to your environment. For example, the landing_zones archetype provides extensive guardrails for various Azure services, while the connectivity archetype focuses on network-level protections like DDoS enablement.

  7. Configure resource IDs in policy definitions for deployment

    main
    Policy definition files contain values specific to the scope of the deployed resource that must be modified during deployment within an architecture. Specifically, the resource id must be updated. Clients responsible for deploying these resources must ensure that these scoped values are correctly set to match the target environment.
  8. Understand SLZ (Sovereign Landing Zone) architectures

    main

    The SLZ library provides two primary management group architectures. Both architectures are deployed as children of the user-supplied root management group.

    architecture alz

    This architecture follows a standard hierarchy including:

    • Azure Landing Zones (root)
      • Decommissioned (archetype: decommissioned)
      • Landing zones (archetype: landing_zones)
        • Corp (archetype: corp)
        • Local
        • Online
      • Platform (archetype: platform)
        • Connectivity (archetype: connectivity)
        • Identity (archetype: identity)
        • Management
        • Security
      • Sandbox (archetype: sandbox)

    architecture slz

    This architecture is designed for sovereign requirements and includes specific control archetypes applied to management groups:

    • Sovereign Landing Zone (root) (archetype: sovereign_l1_controls)
      • Decommissioned (archetype: decommissioned)
      • Landing zones (archetype: landing_zones)
        • Confidential Corp (archetypes: corp, sovereign_l2_controls, sovereign_l3_controls)
        • Confidential Online (archetypes: online, sovereign_l2_controls, sovereign_l3_controls)
        • Corp (archetypes: corp, sovereign_l2_controls)
        • Local
        • Online (archetypes: online, sovereign_l2_controls)
        • Public
      • Platform (archetype: platform)
        • Connectivity (archetypes: connectivity, sovereign_l2_controls)
        • Identity (archetypes: identity, sovereign_l2_controls)
        • Management (archetypes: management, sovereign_l2_controls)
        • Security (archetypes: security, sovereign_l2_controls)
      • Sandbox (archetype: sandbox)
  9. Manage library dependencies and asset conflicts

    main

    When hosting your own version of the library, you can manage dependencies and naming conflicts using the following methods:

    Defining Dependencies

    • In your library: Create an alz_library_metadata.json file in the root of your library directory to provide metadata and list any dependencies. Dependencies are transitive; you only need to list direct dependencies.
    • In the Terraform provider: Supply dependent libraries directly in the library_references field of the provider configuration.

    Handling Naming Conflicts

    By default, clients prevent adding assets that already exist in the library (e.g., creating an architecture named alz when using the platform/alz library). To resolve this:

    • Best Practice: Use unique naming for your assets to avoid conflicts.
    • Override Assets: If you must use conflicting names, enable the override setting in the ALZ Terraform provider by setting library_overwrite_enabled to true.
  10. Understand the ALZ management group architecture

    main

    The alz architecture organizes management groups into a specific hierarchy. The root management group (Azure Landing Zones) contains several top-level branches:

    • Decommissioned: For resources being phased out (decommissioned archetype).
    • Landing Zones: The primary container for workloads, containing:
      • Corp: Corporate workloads (corp archetype).
      • Local: Local workloads (local archetype).
      • Online: (Note: listed in diagram, archetype not explicitly detailed in this segment).
    • Platform: Core infrastructure services (platform archetype), which includes sub-branches for:
      • Connectivity (connectivity archetype)
      • Identity (identity archetype)
      • Management
      • Security
    • Sandbox: Isolated environments for testing (sandbox archetype).
  11. Understand the CalVer versioning strategy

    main

    The Azure Landing Zones Library uses a Calendar Versioning (CalVer) strategy for all library members. Versions follow the pattern library/path/YYYY.0M.P-modifier.

    • YYYY: The year of the release.
    • 0M: The zero-padded month of the release.
    • P: The patch number, starting at 0.
    • modifier: An optional suffix for pre-releases (e.g., alpha, beta, or rc).

    Breaking Changes Policy:

    • Breaking changes may occur between year and month releases (e.g., moving from 2024.01.x to 2024.02.x).
    • Patch releases (e.g., 2024.01.0 to 2024.01.1) are expected to be non-breaking.
    library/path/YYYY.0M.P-modifier
  12. How library assets are identified and referenced

    main

    Assets in the library are identified by filename patterns and read from library member directories. While you can organize files into directories for clarity, the directory structure is not considered during processing; assets are processed based on their names.

    Key constraints and behaviors:

    • Uniqueness: The name (the .name JSON property) of an asset must be unique for any given asset type. For example, you cannot have two policy definitions with the same name.
    • Referencing: Assets are keyed by name. During the creation of a deployable architecture, assets are modified to update references such as resource IDs.
    • Client Responsibility: When building with these assets, clients should look up referenced resources by name and ensure values are correctly updated before deploying the resource.