Writing in InfoWorld, architect Sachin Suryawanshi describes a platform spanning two active Azure regions, with Azure Front Door distributing production traffic, Azure Virtual WAN providing connectivity, Palo Alto Networks Cloud NGFW providing network inspection, and Datadog handling operational observability. A separate cloud security information and event management system, or SIEM, supports security operations. GitHub-hosted larger runners connect through Azure virtual networks to reach private resources.
Those products are his implementation choices, not an enterprise-readiness checklist that every organization must purchase. His deployment account is not independently corroborated in the available reporting, and it includes no measured cost savings, failover times, or developer-productivity results. Its value is the design reasoning, which can be compared with Microsoft’s documented landing-zone model.
Microsoft’s Cloud Adoption Framework asks organizations to evaluate landing-zone design areas before deployment and use those decisions to assess implementation choices. That is a useful starting point here: select the controls and responsibilities the organization needs before treating a reference diagram as a finished platform.
Azure landing-zone boundaries should follow governance and ownership
Suryawanshi’s first decision is to define the landing zone as an operating model. Alongside networking, it must establish who can create resources, where workloads belong, how policies propagate, where secrets are kept, and where telemetry goes. His design separates shared platform resources from application workloads, while giving production, non-production, and sandbox environments different governance boundaries. The intended result is stronger production control without making every experimental deployment follow the same constraints.
Microsoft’s landing-zone documentation supplies a precise distinction that helps turn this idea into responsibilities. A platform landing zone provides the centralized foundation: governance, security, and shared capabilities. An application landing zone contains the resources a workload team deploys and operates. Microsoft describes each application landing zone as encompassing the workload’s environments, such as development, test, and production, with each environment using one or more subscriptions according to its requirements. Separating platform ownership from workload ownership therefore does not mean creating an entirely independent platform for every application or environment.
Suryawanshi uses management groups as his primary policy boundary, subscriptions as operational boundaries, and resource groups for ownership and lifecycle management. That division gives each part of the hierarchy a purpose. Management groups collect subscriptions that need common controls; subscriptions provide a manageable scope for workload operations; resource groups organize resources whose ownership or lifecycle belongs together. These roles should not be read as exclusive Azure capabilities. Microsoft documents policy enforcement at both management-group and subscription scopes, for example.
An important qualification emerges when this account is compared with Microsoft’s management-group guidance: separate environment governance does not require separate production, test, and development management groups. Microsoft explicitly recommends against creating management groups simply to represent those environments. Where separation is needed, it recommends different subscriptions within the same management group. It also recommends grouping workloads according to their security, compliance, connectivity, and feature requirements. Suryawanshi does not publish a complete hierarchy, so his environmental separation should not be interpreted as contradicting—or replacing—that guidance.
Microsoft recommends keeping the management-group hierarchy reasonably flat, ideally no more than three or four levels, rather than reproducing a corporate organizational chart. It also advises assigning application-team permissions at the subscription or resource-group scopes they need, rather than broadly at management-group scope. Platform teams may need broader access, but Microsoft recommends controlling such access through privileged identity management so permissions are granted when needed. The practical distinction is between distributing policies widely and distributing operating permissions widely: the former does not justify the latter.
For an enterprise administrator, the first useful deliverable is consequently a responsibility map alongside the resource hierarchy. A workload team should be able to identify the subscription it operates, the controls it inherits, and the shared capabilities another team maintains. Microsoft also calls for a repeatable process to request, create, and distribute application landing zones. Automating that process becomes more important as demand grows, but automation should reproduce an agreed ownership model rather than conceal an unresolved one.
Azure Virtual WAN and firewall routing belong in the same decision
Suryawanshi’s second and third decisions are closely connected: select a connectivity model that the platform team can operate, and incorporate traffic inspection while designing its routes. He chose Azure Virtual WAN instead of managing a traditional hub-and-spoke arrangement himself. In the traditional pattern he describes, a central hub virtual network hosts shared networking and security services, while application networks connect as spokes. His reason for choosing Virtual WAN was to avoid making custom transit routing, peering, and route management a continuing platform burden.
According to his InfoWorld account, the implementation places Virtual WAN hubs in both Azure regions and connects workload virtual networks through that fabric. This provides the basis for regional expansion, site-to-site connectivity, and centralized routing. Application teams receive governed networks with consistent routes to required services, rather than being expected to design transit connectivity for each workload. The important operating-model choice is that the platform team supplies connectivity as a shared capability.
Microsoft’s landing-zone reference architecture supports both hub-and-spoke and Virtual WAN networking. The presence of both patterns is significant: Suryawanshi’s preference is a response to his operational requirements, not a declaration that hub-and-spoke has become obsolete. His account does not include a comparative cost model, measured administrative effort, or performance benchmarks. An organization evaluating the same choice should therefore use the account to frame responsibility questions, not as evidence that Virtual WAN will necessarily be cheaper or faster in its own environment.
The security decision follows from that network choice. Suryawanshi reports integrating Palo Alto Networks Cloud NGFW with Virtual WAN so traffic inspection was included in the routing design from the outset. His organization already had expectations for next-generation firewall capabilities, and he wanted those expectations reflected in Azure without creating excessive routing exceptions later. He explicitly allows for Azure Firewall or another approved alternative where an organization’s standards, tooling, and operating experience point elsewhere.
The transferable lesson is to decide where inspection belongs before distributing workload networks. Connectivity and inspection need to describe the same intended traffic paths. Otherwise, the network design can promise application teams a route to a service while the security design assumes a different route or enforcement point. That is an architectural implication of the account, rather than a reported fault in Azure Virtual WAN or any firewall product. It is also why a firewall selection cannot be evaluated only as a list of inspection features.
For an existing landing zone, the useful review is to compare the connectivity service offered to workload teams with the inspection requirements security teams expect it to enforce. Identify which team owns shared routing, which owns firewall policy, and how a new workload receives an approved path. Suryawanshi does not provide route tables, inspection coverage, or product configuration steps, so his design cannot safely be converted into a universal deployment recipe. It does establish the decision order: settle topology and inspection together, then make the resulting network pattern repeatable.
Azure Policy should enforce known risks without making every deployment exceptional
Suryawanshi’s fourth decision addresses the temptation to equate central control with maximum restriction. He argues that excessive deny policies can turn ordinary engineering work into exception requests, leaving platform teams to process tickets while application teams search for alternative paths. His response is to connect controls to explicit risks: approved deployment regions, resource tagging, diagnostic settings, public exposure, identity, security posture, and resource configuration. The objective is a predictable set of constraints that teams can work within.
The distinction between enforcement and observation matters. In his approach, controls protecting established security or compliance boundaries can be enforced, while other controls can begin in audit mode until their operational implications are understood. Audit mode is an observation stage, not a substitute for a required prohibition. Equally, making a policy deny a deployment does not demonstrate that the platform has supplied a workable compliant alternative. Those are separate design obligations.
Consider the relationship between public-exposure policy and deployment access. The account describes private resources that deployment workflows still need to reach. A rule that prevents public access can serve a legitimate security boundary, but the platform also needs to offer a deployment path compatible with that rule. If governance is designed independently of CI/CD networking, the same organization can require private access and then routinely approve public exceptions so software can ship. Connecting those two decisions is more useful than adding another restriction to the policy inventory.
Sandbox treatment follows the same reasoning. Suryawanshi retains cost controls and basic security boundaries while allowing more flexibility than production. Microsoft’s management-group guidance likewise describes sandbox subscriptions as isolated environments with less restrictive policies for testing and exploration. A sandbox is therefore a deliberately different governance environment, not an ungoverned subscription. Its purpose is to provide room for experimentation without forcing experimental activity into production environments.
Microsoft adds a further caution about where policies are assigned: limit assignments at the root management-group scope to reduce the difficulty of debugging inherited controls lower in the hierarchy. Combined with its recommendation to group workloads by common requirements, this suggests a more maintainable model than applying every possible restriction at the broadest scope. Shared controls should be genuinely shared. Workload-specific requirements should remain identifiable rather than disappearing into a long chain of inherited exceptions.
A practical policy review can therefore ask three questions of each consequential control: what risk it addresses, which workloads need it, and how those workloads complete legitimate operations under it. This is a review framework derived from the two sources, not a Microsoft-mandated approval procedure. Its value is that it connects policy intent to engineering behavior. A control that repeatedly needs exceptions may require better workload placement, a better platform capability, or a more appropriately scoped policy; the existence of exceptions alone does not establish which change is correct.
Datadog and a security SIEM need distinct jobs, not indiscriminate log duplication
The fifth decision separates operational observability from security monitoring. Suryawanshi uses Datadog for application performance, infrastructure telemetry, logs, distributed traces, service health, dashboards, and engineering alerts. His separate cloud SIEM supports security analytics, identity events, threat detection, investigations, incidents, and security operations center workflows. He does not name the SIEM product, so the architecture should not be described as a documented Datadog–Microsoft Sentinel deployment.
The distinction is easiest to understand through the events he identifies. An API failure that requires an engineer to diagnose application behavior belongs primarily in the observability platform. A suspicious sign-in, privileged identity activity, firewall threat alert, or security-policy violation is more directly relevant to the SIEM. Some events can support both operational diagnosis and security investigation. The design task is to determine which consumers need each category, rather than assuming every destination needs every record.
| Telemetry described in the account | Primary purpose in the design |
|---|---|
| Application failures, performance data, and distributed traces | Help engineers understand application behavior and diagnose service problems. |
| Infrastructure telemetry and service-health information | Support operational visibility, dashboards, and engineering alerts. |
| Suspicious sign-ins and privileged identity activity | Support security analysis and investigation. |
| Firewall threat alerts and security-policy violations | Support threat detection and security operations workflows. |
| Events relevant to both operations and security | Serve both teams where the shared investigative need justifies distribution. |
Suryawanshi warns that sending all logs to both platforms can add cost and noise without necessarily improving visibility. The account provides no ingestion volumes, retention settings, or pricing comparison, so it cannot support a numerical savings claim. Nor does it establish that a particular event must always have only one destination. The useful principle is that telemetry routing should follow investigative purpose and ownership, with duplication justified by an actual need.
Microsoft’s reference architecture corroborates the broader need for centralized management and security capabilities. It includes components such as Log Analytics, Microsoft Sentinel, dashboards, alerts, diagnostic settings, and Defender for Cloud. That does not make Suryawanshi’s particular vendor combination a requirement, or imply that separate operational and security responsibilities always demand separate commercial platforms. The documented distinction concerns the jobs the organization needs performed; tooling selection follows those jobs.
For platform teams, this makes telemetry part of workload onboarding. A new application environment should arrive with an established operational destination, an established security destination where required, and a clear division of responsibility for the resulting signals. Suryawanshi’s conclusion is that teams should not have to decide afresh where logs go every time they deploy a workload. The practical improvement is consistency in who receives actionable information, rather than simply increasing the amount of information collected.
GitHub deployment runners must fit Azure’s private-access model
The sixth decision exposes a dependency that can be missed when networking and software delivery are planned separately. When Azure resources are no longer publicly accessible, deployment workflows still need an approved way to reach them. Suryawanshi identifies storage accounts, Key Vaults, and databases as examples. Opening public exceptions can unblock a deployment, but it also works against the private-network design the organization has chosen.
According to InfoWorld, his solution uses GitHub larger runners with private networking through Azure virtual networks. The runners remain GitHub-hosted, while their network interfaces are deployed into the Azure virtual network. This distinction is important: the account describes a GitHub-hosted execution model with private network connectivity, not a fleet of runner machines that the organization necessarily hosts and maintains itself. It also describes a particular larger-runner arrangement, not a property that can be assumed for every GitHub-hosted runner.
The mechanism addresses reachability. Deployment jobs obtain a controlled network path to private resources rather than depending on those resources being exposed publicly. Suryawanshi separately identifies identity controls, network controls, logging, and clear ownership as deployment-infrastructure requirements. Private connectivity therefore does not replace decisions about what a workflow is permitted to do. Both the path to the resource and the authority exercised over it remain part of the platform design.
He extends that responsibility to Terraform modules, GitHub workflows, environment protections, identities, and private connectivity. Those components should support the landing-zone model rather than establish a second route around it. The architectural implication is straightforward: the same platform that distributes application environments should account for how approved software changes reach them. A private production environment with no workable deployment path is an incomplete service to its application team.
There is a material implementation limit here. The account does not establish GitHub plan eligibility, supported runner operating systems, available regions, network prerequisites, or the setup procedure for this arrangement. It should not be used to promise that an organization can enable the same capability on its current subscription without further verification. For a purchasing or implementation decision, those details must be established from the applicable GitHub and Azure product requirements; they cannot be reconstructed safely from the architectural description.
Even without a configuration walkthrough, the account supports a concrete review. Identify the private resources a deployment workflow must reach, the runner arrangement intended to reach them, and the team responsible for its network access, identities, and logs. Check whether the normal deployment path requires exceptions to the intended exposure policy. That review does not presume a particular remedy, but it reveals whether CI/CD is actually integrated into the landing zone or remains an unresolved dependency.
Azure Front Door cannot make two regions operationally equivalent
Suryawanshi’s seventh decision is to make both Azure regions genuinely production-ready. His active-active architecture sends production traffic to both regions rather than leaving a second environment idle. According to his account, Azure Front Door sits in front of the regional application endpoints and distributes requests across healthy origins. Health probes identify unhealthy origins so Front Door can stop routing requests to them.
The important distinction is between traffic routing and the ability to operate the surviving workload. Routing away from an unhealthy region answers where incoming requests should go. Suryawanshi’s requirement goes further: either region should be able to absorb the other’s failure without changing the operating model. That means adequate capacity, telemetry, security visibility, and deployment access must already be available in the region expected to continue serving production.
His regional pattern repeats Virtual WAN hubs, network addressing, firewall integration, policies, diagnostic settings, Datadog and SIEM integration, Terraform modules, and deployment pipelines. These repetitions connect resilience to the previous six decisions. If one region has a working application endpoint but lacks the expected monitoring or deployment path, the two regions do not offer the same operational capability. The inference is that regional readiness should be assessed across platform services, not only by checking whether each endpoint accepts traffic.
Microsoft’s management-group guidance also helps avoid a misleading way of representing this design. It recommends retaining the standard landing-zone management-group structure for multiregion deployments rather than creating management groups solely to model Azure regions. Location-based regulatory requirements, such as data residency or sovereignty, can justify a location-based structure. Simply deploying in two regions does not, by itself, establish that requirement. Regional resource organization and policy organization need not be identical.
The evidence does not establish a recovery-time objective, recovery-point objective, measured failover result, or workload data-replication design. Those omissions materially limit the conclusion: the account supports a repeatable two-region platform pattern, but it does not prove application-level continuity or a particular data-loss outcome. Front Door health-based routing cannot be treated as evidence for requirements the account does not document. Likewise, there is no basis here for describing failover as instantaneous or uninterrupted.
The practical decision is therefore broader than whether to switch on traffic in a second region. An organization adopting this pattern needs to decide whether both regional environments can provide the operating capabilities the workload requires during disruption. Suryawanshi’s account makes those capabilities visible, particularly deployment access and security monitoring, which are easy to overlook in a diagram focused on request routing. It does not establish that active-active is the right or most economical choice for every Azure workload.
Review Azure landing-zone handoffs before changing products
Start by reviewing the handoffs among teams and services rather than replacing a working network or observability product. The account’s most useful diagnostic is whether each new workload receives a predictable environment or triggers another round of architecture negotiations. A platform that repeatedly requires bespoke routing, monitoring setup, policy exceptions, and deployment work has not yet made those capabilities reliably reusable.
A supported review sequence is to begin with ownership and governance boundaries, then trace the workload through connectivity, inspection, telemetry, deployment, and regional operation. This is an architectural review, not a live migration procedure: the evidence provides no basis for moving subscriptions, changing inherited policies, or altering production routes without environment-specific planning. The objective is to identify incomplete responsibilities before making consequential changes.
The most concrete takeaways are these:
- Keep management groups focused on shared governance requirements, and use subscription or resource-group scopes for the application-team permissions Microsoft recommends.
- Evaluate Azure Virtual WAN and hub-and-spoke against operating responsibilities, while deciding traffic inspection as part of the same network design.
- Tie Azure Policy controls to explicit risks, preserve isolated sandbox flexibility, and ensure legitimate deployment paths can satisfy enforced restrictions.
- Give operational observability and security monitoring clear purposes, routing shared telemetry to both only where the investigative need warrants it.
- Include private deployment connectivity and regional operating capabilities in the platform’s readiness review, rather than treating them as follow-up work.
For an organization whose existing landing zone already provides those capabilities consistently, this account offers review criteria rather than a reason to rebuild. For a platform still being designed, it establishes a useful order of decisions: define responsibility, make shared services coherent, and provide a repeatable workload onboarding process. Microsoft’s accelerators can implement recommended patterns, but an accelerator cannot determine which team should own an unresolved operational responsibility.
An enterprise-ready Azure landing zone gives application teams an environment they can govern, deploy to, observe, and operate without renegotiating the foundation for every workload. Suryawanshi’s seven decisions are useful because they expose where those promises depend on one another. The next workload onboarded is a practical opportunity to apply that reasoning: its normal deployment and operating paths should use the platform’s approved capabilities, including in the region expected to keep serving when another is unavailable.