Azure Cloud Engineering Patterns

Azure Cloud Engineering & Secure Network Architecture

When to Use This Skill

Triggers — load this skill when:

• Subscription, management-group, or network topology must be designed on Azure
• PaaS services need private-only access via Private Endpoints and DNS
• Governance must be codified with Azure Policy and RBAC

Route elsewhere when:

• AKS-specific cluster design -> azure-aks-enterprise-landing-zones
• Cross-cloud posture auditing -> cloud-security-posture-cspm-cis
• Cost governance -> finops-framework-inform-optimize-operate

1. Hub-and-Spoke with Azure Private Endpoints & Virtual WAN

resource "azurerm_private_endpoint" "sql_private_endpoint" {
  name                = "pe-sqldb-prod"
  location            = "eastus2"
  resource_group_name = "rg-networking-prod"
  subnet_id           = azurerm_subnet.private_endpoints_subnet.id

  private_service_connection {
    name                           = "psc-sqldb-prod"
    private_connection_resource_id = azurerm_mssql_server.sql_server.id
    subresource_names              = ["sqlServer"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "pdzg-sqldb"
    private_dns_zone_ids = [azurerm_private_dns_zone.privatelink_database.id]
  }
}

2. Best Practices & Anti-Patterns

• Do: Enforce Private Endpoints for all PaaS services (Azure SQL, Cosmos DB, Key Vault, Storage Accounts).
• Do: Use Azure Policy definitions to deny resources without required tags or deployed in unauthorized regions.
• Don't: Never expose database management or RDP/SSH ports directly to public IP addresses without Azure Bastion.

3. Management Group Hierarchy & Private DNS

Tenant Root Group
└── acme (top-level; all policy that must apply everywhere lands here)
    ├── platform
    │   ├── connectivity   # hub VNets, Virtual WAN, firewall, DNS resolver
    │   ├── identity       # domain controllers, Entra tooling
    │   └── management     # Log Analytics, automation, backup vaults
    ├── landing-zones
    │   ├── corp           # internal, private-only workloads
    │   └── online         # internet-facing workloads
    ├── sandbox            # loose policy, hard spend cap, no connectivity peering
    └── decommissioned     # deny-all-create policy, retained for audit

Assign policy at the management group, never per subscription: subscriptions move between groups as workloads change, and inherited assignments follow automatically. Keep the hierarchy shallow (three or four levels) — depth makes effective-policy debugging painful.

Private DNS is where Private Endpoints actually fail. The endpoint gets a private IP, but callers keep resolving the public name unless every resolving VNet links the right zone:

Centralise these zones in the connectivity subscription, link them to every spoke VNet, and enforce automatic registration with the Deploy-Private-DNS-Zones policy initiative so a developer creating a Private Endpoint cannot forget the DNS half. Diagnose with nslookup <resource>.blob.core.windows.net from inside the spoke: a public IP in the answer means the zone link, not the endpoint, is missing.

4. Cloud Adoption Framework Alignment

The hierarchy above is the Cloud Adoption Framework (CAF) enterprise-scale landing zone applied concretely. CAF's value here is the separation it forces:

Application teams own resources inside their subscription; they never own connectivity, policy, or logging destinations. Deploy the baseline with the Azure Landing Zones Terraform/Bicep modules rather than hand-built resource groups, so the hierarchy is reproducible and reviewable.