Blog Post

Startups at Microsoft
7 MIN READ

Introducing the Startup-Scale Landing Zone: Get Azure right from day one

rmmartins's avatar
rmmartins
Icon for Microsoft rankMicrosoft
Mar 12, 2026

If you've been following this blog, you may recall the post From Zero to Hero with Azure Landing Zones, where we walked through the full Azure Landing Zone journey, from identity and RBAC to Platform and Application Landing Zones. That guide covered the what and the why. This post introduces the how, a deployable, open-source project that distills those principles into something a startup can actually ship in an afternoon.

The problem: Cloud foundations shouldn't take two months

Every startup building on Azure faces the same fork in the road:

Option A: Follow the Azure Landing Zone (ALZ) guidance. It's comprehensive, battle-tested, and designed for organizations with thousands of users. It's also 100+ modules, a multi-layered management group hierarchy, and months of work to understand, let alone implement. For a 10-person startup, it's like buying a commercial kitchen to make breakfast.

Option B: Skip governance entirely. One subscription, no policies, no budgets, no RBAC strategy. Ship fast now, deal with security debt later. This is what most startups actually do, and it works until the first security questionnaire from an enterprise customer, the first runaway cost incident, or the first az group delete that hits production.

Neither option is right. Startups need a third path: just enough governance to be secure and cost-aware from day one, without the operational overhead that slows them down.

That's exactly what the Startup-Scale Landing Zone (SSLZ) provides.

What is the Startup-Scale Landing Zone?

SSLZ is an opinionated, production-ready Azure infrastructure template that deploys in under one hour using Bicep or Terraform. It's built for teams of 5–50 engineers, typically pre-seed to Series A, who don't have a dedicated platform team but need to get Azure right from the start.

It takes the core principles from the Azure Landing Zone architecture and strips them to the essentials:

  • One management group, two subscriptions (prod + non-prod). That's it. No six-layer hierarchy.
  • Security built-in. Defender for Cloud, RBAC groups, NSG deny-all defaults, and policy enforcement, all automated.
  • Cost controls from day one. Budget alerts at 50%, 80%, and 100%, mandatory tagging, and reservation guidance.
  • An explicit graduation path. When you outgrow SSLZ, there's a step-by-step guide to migrate to the full ALZ architecture.

Important: SSLZ is not a replacement for Azure Landing Zones. It targets a different profile: very early-stage startups with a single workload, a single region, and no hybrid connectivity. For those teams, the realistic alternative isn't ALZ, it's usually no governance at all.

Architecture: Simplicity as a design principle

The architecture is deliberately minimal:

Tenant Root Group
└── mg-<yourcompany>              ← Policies applied here
    ├── sub-<yourcompany>-prod    ← Production workloads
    └── sub-<yourcompany>-nonprod ← Dev, staging, QA

Each subscription gets its own VNet with a standardized subnet layout:

vnet-<co>-prod (10.0.0.0/16)
├── snet-aks         10.0.0.0/20    (4,091 IPs — AKS nodes + pods)
├── snet-app         10.0.16.0/22   (1,019 IPs — App Service / Container Apps)
├── snet-data        10.0.20.0/22   (1,019 IPs — Private Endpoints)
└── snet-shared      10.0.24.0/24   (251 IPs — CI/CD agents, jump boxes)

No hub network. No Azure Firewall. No VNet peering. Each subscription is a self-contained island.

Why no hub?

A hub-spoke topology costs a minimum of ~$1,500/month. Azure Firewall alone runs $900+/month. For a startup with a single workload in a single region, that's cost and complexity with no return. NSGs provide L3/L4 filtering for free and handle 95% of startup networking use cases. When compliance or hybrid connectivity demands centralized egress control, the graduation guide walks you through adding a hub, without touching existing resources.

Why two subscriptions?

Two subscriptions give you isolation that resource groups can't:

  • Cost isolation for free: no tagging gymnastics to separate prod from dev spend.
  • RBAC without custom roles: developers get Contributor on non-prod and Reader on prod.
  • Blast radius containment: az group delete in dev can't touch production.
  • Quota isolation: non-prod experiments don't consume prod quotas.

This is a habit that's cheap to form early and expensive to retrofit later. One primary workload per subscription; when you deploy a second independent workload, create a new subscription.

What you get out of the box

ComponentWhat's deployed
Management GroupsSingle MG with two subscriptions
Azure PolicyMicrosoft Cloud Security Benchmark (audit mode), required tags (environment, team), allowed locations, diagnostic settings
NetworkingVNet + 4 subnets per subscription, NSGs with deny-all-inbound default
MonitoringLog Analytics workspace, Activity Log forwarding, 90-day retention
SecurityDefender for Cloud CSPM (free), Defender for Servers P2 (prod), security contact alerts
Cost ManagementBudget alerts at 50/80/100% thresholds, tag enforcement via policy
CI/CDGitHub Actions workflows for both Bicep and Terraform, Workload Identity Federation (no secrets)

Security without friction

The security model avoids compliance theater. Instead of buying Entra ID P2 "to check a box," SSLZ enables Security Defaults, free MFA that blocks 99.9% of identity attacks. Instead of enforcing MCSB in Deny mode on day one (which blocks legitimate deployments and frustrates developers), it starts in Audit mode so you can understand your posture first, then selectively move to Deny as your team matures.

RBAC follows three rules:

  1. Never assign roles to individuals: always use security groups.
  2. Developers don't get Contributor on prod: deployments go through CI/CD.
  3. No Owner at subscription level for non-admins: a compromised account with Owner can grant itself anything.

For CI/CD, SSLZ uses Workload Identity Federation (WIF) instead of client secrets. No credentials to store, rotate, or accidentally commit. Short-lived OIDC tokens scoped to specific repos and branches.

Cost transparency

Every recommendation includes real numbers:

  • "Azure Firewall: $900+/month. Skip until compliance or hybrid demands it."
  • "DDoS Protection Standard: $2,944/month. Azure's free basic DDoS + Front Door WAF handles most cases."
  • "Defender for App Service: ~$15/month. Limited value compared to other plans. Revisit later."
  • "Standard_D4s_v5 VM: $140/month on-demand → $90/month with 1-year RI. 36% savings."

The documentation also covers the six most common cost mistakes startups make: forgotten dev VMs, over-provisioned databases, ignoring Reserved Instances, premium storage where standard works, not using Spot VMs, and missing Dev/Test pricing. Each mistake comes with a concrete fix and code example.

Starter examples: Three startup archetypes

SSLZ ships with three production-grade example architectures, each with Bicep + Terraform implementations, deployment instructions, and realistic cost estimates:

SaaS Startup (~$330–440/month)

Container Apps + Azure SQL Elastic Pool + Redis + Key Vault. Multi-tenant with shared schema and tenant_id column. Container Apps scale to zero in non-prod. Elastic pools are 50–70% cheaper than individual databases.

AI Startup (~$1,150–1,250/month)

AKS with GPU Spot node pools (60–90% savings) + Azure OpenAI + Blob Storage + Redis for inference caching. Covers model serving framework choices (vLLM vs Triton vs TGI) and GPU node management with taints and KEDA autoscaling.

API-First Startup (~$163–345/month)

App Service with deployment slots (zero-downtime swaps) + API Management (Consumption tier, pay-per-call) + Cosmos DB + Application Insights. Includes API versioning strategy, rate limiting tiers, and Cosmos DB partitioning guidance.

When to graduate

SSLZ is explicit about its limits. You'll outgrow it when 2–3 of these signals appear simultaneously:

SignalWhy it matters
Second independent workloadEach workload gets its own subscription
Engineering team > 50 peopleDifferent teams need different permissions and cost boundaries
Regulatory compliance (SOC2, HIPAA, PCI)Requires specific controls SSLZ doesn't cover
Multi-region deploymentNeeds centralized network management
Hybrid connectivity (VPN, ExpressRoute)Requires a Connectivity subscription with gateways
5+ subscriptionsPolicy and RBAC at scale needs MG hierarchy

The Graduation Guide provides a five-phase migration path to full ALZ: management group hierarchy, hub network + firewall, management subscription, policy hardening, and identity hardening with risk assessments for each phase. It also includes the cost of the full platform layer ($1,500–3,000/month), so you can make an informed decision about when the investment makes sense.

Quick start: From zero to production-ready in under 1 hour

Prerequisites (5 min)

  • Azure CLI installed
  • Two Azure subscriptions (prod + non-prod)
  • Owner permissions on both subscriptions
git clone https://github.com/ricmmartins/sslz.git
cd sslz
az login
./scripts/validate-prerequisites.sh

Deploy with Bicep (20 min)

cd infra/bicep
cp parameters/prod.bicepparam parameters/prod.local.bicepparam
# Edit prod.local.bicepparam with your values

az deployment sub create \
  --location eastus2 \
  --template-file main.bicep \
  --parameters parameters/prod.local.bicepparam

Or Deploy with Terraform (20 min)

cd infra/terraform
cp terraform.tfvars.example terraform.tfvars
# Edit terraform.tfvars with your values

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Verify (5 min)

az group list --query "[?contains(name, 'yourcompany')].name" -o tsv
az policy assignment list --query "[].displayName" -o tsv
az security pricing list --query "value[?pricingTier=='Standard'].{Name:name, Tier:pricingTier}" -o table

Design philosophy

Three principles guided every decision in SSLZ:

  1. Opinionated over flexible. "It depends" isn't helpful when you have five engineers and no platform team. SSLZ makes the call: two subscriptions, no hub, deny-all NSGs, MCSB in audit mode and tells you when to revisit.
  2. Reversible over perfect. Every architectural decision is designed to be easy to change later. Moving subscriptions between management groups is a 10-second operation. Adding a hub VNet requires only a new deployment, not changes to existing resources. Policies can move from Audit to Deny on a schedule. Multi-region is a future add-on, not a prerequisite.
  3. Honest about trade-offs. Instead of claiming "enterprise-grade," SSLZ says:"You'll outgrow this when..." and "Here's exactly what it costs to add the next layer." That transparency is what separates it from frameworks that are either overkill for startups or under-engineered for production.

Get involved

SSLZ is open source under the MIT license. The project welcomes contributions, especially real-world configurations from startup CTOs and platform engineers who've battle-tested the patterns.

If you're a startup building on Azure, give SSLZ a try. Deploy it, break it, and tell us what your real infrastructure looks like, so the next team doesn't have to figure it out from scratch.

Updated Mar 12, 2026
Version 2.0
No CommentsBe the first to comment