Azure Defense in Depth

A Rebuttal: Why Simplicity Shouldn’t Come at the Cost of Security Depth

A response to “A Simplified Azure Landing Zones Alternative” by Rasmus Lystrøm

The blog post “A Simplified Azure Landing Zones Alternative” makes compelling points about the overwhelming complexity of Microsoft’s official Azure Landing Zone implementations. The frustration with 800,000+ lines of code is understandable. However, the proposed simplifications introduce significant security and operational risks that warrant careful consideration before adoption—particularly when evaluated against established principles like defense in depth and mature operational disciplines.

1. Defense in Depth: Identity Is Necessary but Not Sufficient

The author’s core security thesis is that “identity and encryption trumps and often replaces Network Security.” This conflates Zero Trust with a single-layer security model.

The problem: Zero Trust does not mean “identity only.” The actual Zero Trust principle, as defined by NIST SP 800-207, explicitly calls for multiple enforcement points:

• Identity verification
• Device health validation
• Network segmentation
• Micro-segmentation
• Continuous monitoring

By allowing “Public Network Access: Enabled” across services and discouraging Azure Private Link, the simplified architecture eliminates an entire layer of defense. If an Entra ID token is compromised (through phishing, token theft, or misconfigured service principals), there is no network boundary preventing lateral movement or data exfiltration.

Defense in depth requires: Even when identity controls are strong, network controls provide a compensating layer. A storage account with Private Link enabled can only be accessed from approved networks—even if credentials are compromised, the attack surface is dramatically reduced.

2. Centralized Logging and Monitoring: The Missing Operational Backbone

Notably absent from the simplified architecture is any discussion of:

• Centralized log aggregation
• Security Information and Event Management (SIEM) integration
• Network flow logging
• Diagnostic settings at scale
• Alerting and incident response workflows

The official Azure Landing Zones, and particularly Azure Monitor Baseline Alerts (AMBA), exist precisely because security requires visibility. The author dismisses AMBA as complexity for complexity’s sake, but operational security depends on:

• Log Analytics Workspaces collecting activity logs, diagnostic logs, and security events across all subscriptions
• Microsoft Sentinel or equivalent SIEM for correlation and threat detection
• Network Watcher flow logs to detect anomalous traffic patterns
• Azure Policy ensuring diagnostic settings are deployed consistently

The simplified approach leaves platform teams without the telemetry necessary to detect, investigate, or respond to incidents. When a storage account is accessed by an unexpected principal, how would you know? When a web app experiences suspicious authentication patterns, where is that visibility?

Operational discipline requires: Logging is not optional infrastructure—it is the foundation of security operations. Complexity in monitoring infrastructure is complexity that directly serves incident detection and response.

3. Network Segmentation Serves More Than Security

The blog states: “We do not want to manage network from a centralized perspective. All applications will be deployed as islands with no inter-network connectivity.”

While this reduces management overhead, it also eliminates:

• Blast radius containment: If one “island” is compromised, without network boundaries, the attacker can pivot using identity rather than being constrained by network topology
• Egress filtering: Controlling what data leaves your environment requires network-level controls; identity cannot prevent a compromised workload from exfiltrating data to an attacker-controlled endpoint
• Compliance requirements: Many regulatory frameworks (PCI-DSS, HIPAA, government standards) explicitly require network segmentation as a control, regardless of identity posture

The simplified model’s assumption that identity controls alone satisfy compliance is often incorrect for regulated industries.

4. The Lines-of-Code Metric Is Misleading

Using cloc to compare implementations is a surface-level analysis. The question isn’t “how many lines of code exist” but rather “what capabilities do those lines provide?”

The official implementations include:

• Multi-region deployment patterns
• Hybrid connectivity options
• Management group hierarchies with policy inheritance
• Role-based access control blueprints
• Diagnostic settings deployment
• Defender for Cloud integration
• Cost management frameworks

The simplified version achieves its 3,819 lines by removing these capabilities. This is not equivalent functionality at lower complexity—it’s reduced functionality.

Organizations should ask: “Do we need these capabilities?” For many enterprises, the answer is yes. For startups or small teams, perhaps not. But the comparison should be honest about what is traded away.

5. The “YAGNI” Argument Doesn’t Apply to Security Controls

The author invokes YAGNI (You Aren’t Gonna Need It) to dismiss capabilities in Azure Verified Modules. However, security controls are fundamentally different from feature code:

• You don’t know you need intrusion detection until you’re breached
• You don’t know you need network flow logs until you’re investigating an incident
• You don’t know you need Private Link until credentials are leaked

Security controls are proactive investments against uncertain threats. The YAGNI principle applies to product features where user demand is uncertain—not to defensive controls where the cost of being wrong is measured in breach impact.

6. Azure Relay and Service Bus Are Not Zero Trust Alternatives to Network Security

The blog suggests Azure Relay and Service Bus as alternatives to VPN/ExpressRoute for hybrid connectivity. These are excellent tools for specific patterns (pub/sub messaging, hybrid application integration), but they are not network security controls.

They provide:

• Message brokering
• Asynchronous communication patterns
• Protocol bridging

They do not provide:

• Network isolation
• Micro-segmentation
• Flow-level visibility
• Egress control

Recommending these as replacements for network architecture conflates application integration patterns with security architecture.

Conclusion: Complexity Should Be Managed, Not Eliminated

The frustration driving the simplified Azure Landing Zone is legitimate: Microsoft’s reference implementations have become unwieldy. The solution, however, is not to remove defense-in-depth controls, eliminate centralized logging, and rely solely on identity.

A more measured approach would be:

1. Start with a minimal viable landing zone that includes identity, network, and monitoring foundations
2. Adopt Azure Policy for guardrails (the blog does this well)
3. Ensure centralized logging is non-negotiable infrastructure
4. Use Private Link for data services, even if it adds complexity
5. Grow complexity incrementally based on organizational needs

The official implementations may be over-engineered for some scenarios, but the simplified alternative swings too far in the opposite direction—sacrificing operational visibility and layered security for the sake of reduced line counts.

Security architecture is not a domain where “less is more” applies unconditionally. Defense in depth exists because no single control is infallible. Centralized monitoring exists because incidents require investigation. The complexity of enterprise landing zones reflects the complexity of enterprise security requirements.