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
| Component | What's deployed |
|---|---|
| Management Groups | Single MG with two subscriptions |
| Azure Policy | Microsoft Cloud Security Benchmark (audit mode), required tags (environment, team), allowed locations, diagnostic settings |
| Networking | VNet + 4 subnets per subscription, NSGs with deny-all-inbound default |
| Monitoring | Log Analytics workspace, Activity Log forwarding, 90-day retention |
| Security | Defender for Cloud CSPM (free), Defender for Servers P2 (prod), security contact alerts |
| Cost Management | Budget alerts at 50/80/100% thresholds, tag enforcement via policy |
| CI/CD | GitHub 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:
- Never assign roles to individuals: always use security groups.
- Developers don't get Contributor on prod: deployments go through CI/CD.
- 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:
| Signal | Why it matters |
|---|---|
| Second independent workload | Each workload gets its own subscription |
| Engineering team > 50 people | Different teams need different permissions and cost boundaries |
| Regulatory compliance (SOC2, HIPAA, PCI) | Requires specific controls SSLZ doesn't cover |
| Multi-region deployment | Needs centralized network management |
| Hybrid connectivity (VPN, ExpressRoute) | Requires a Connectivity subscription with gateways |
| 5+ subscriptions | Policy 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:
- 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.
- 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.
- 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.
- GitHub: github.com/ricmmartins/sslz
- Documentation site: startupscalelanding.zone
- Previous post: From Zero to Hero with Azure Landing Zones
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.