7 decisions that make an Azure landing zone enterprise-ready

以下正文同步自 InfoWorld，版权归原站所有，已转换为易读排版。

As a designer of enterprise-scale Azure landing zones, I’ve found that drawing a landing zone is fairly easy. However, building one that engineering teams can use effectively is far more challenging.

When I started designing an enterprise Azure landing zone, the building blocks were familiar: management groups, subscriptions, virtual networks, policies, firewalls, monitoring and CI/CD. The difficult part was determining how they would interact without producing a platform that appeared secure on paper yet proved difficult to maintain.

Microsoft’s Cloud Adoption Framework provided an excellent starting point. However, a reference architecture can only go so far. Real-world environments have security standards, compliance requirements, deployment pipelines and application teams that need enough autonomy to build software without working around governance.

My design incorporated two Azure regions in an active-active configuration. Production traffic was routed across both regions via Azure Front Door, with health probes used to identify unhealthy origins and remove them from rotation when necessary. I selected Azure Virtual WAN over a traditional hub-and-spoke network, integrated Palo Alto Networks Cloud NGFW into the networking design, used Datadog for observability and used a dedicated cloud SIEM for security operations.

Lastly, I integrated GitHub larger runners with Azure VNets so deployment workflows could access private resources without exposing them publicly. The choices I made were not simply about enabling Azure services. They were about where control should reside, where teams require flexibility and how to make the secure option the easiest option.

1. Consider your landing zone as an operating model, not simply a network

I wanted to prevent the landing-zone project from becoming solely a networking exercise.

While networking is essential, a landing zone should also address other questions. Who can create resources? Where should workloads reside? How do policies propagate? Where are secrets stored? Where does telemetry get sent?

I separated platform resources from application workloads and placed production, non-production and sandbox environments within separate governance boundaries. This allowed tighter control in production while giving teams more freedom elsewhere.

I used management groups as my primary policy boundary. Subscriptions served as my operational boundary. Resource groups remained useful for ownership and lifecycle management, but I did not intend for them to carry the overall governance model.

2. Azure Virtual WAN was a better alternative to managing the hub myself

Hub-and-spoke is a well-established networking pattern in Azure. A central hub VNet hosts shared networking and security services, while application VNets connect to it as spokes.

For my platform, Azure Virtual WAN was a better alternative. I wanted the connectivity layer to extend across regions without turning custom transit routing, peering and route management into an ongoing platform responsibility.

I established Virtual WAN hubs in both regions and connected workload VNets through the fabric. This provided a cleaner basis for regional expansion, site-to-site connectivity and centralized routing.

Application teams were not required to understand every facet of transit routing. The platform provided connectivity as a service, while teams received governed VNets and consistent routes to the services they required.

A properly designed landing zone should eliminate repetitive infrastructure decisions that teams should not have to resolve.

3. Incorporate the security model into routing from day one

When I designed my landing zone, I wanted to avoid adding a firewall after I had designed the network.

I integrated Palo Alto Networks Cloud NGFW with Azure Virtual WAN, so traffic inspection was part of the routing model from the onset. This enabled a centralized security layer without excessive routing exceptions later.

The organization already had defined expectations around next-generation firewall capabilities. Moving workloads into Azure did not make those practices irrelevant.

My lesson was not that every landing zone requires Palo Alto. Azure Firewall might suit one organization, while a third-party NGFW might fit another because of existing standards, toolsets or team experience. The key is to make this decision while designing the network, not after everything else is complete.

4. Governance operates most efficiently when it establishes guardrails

A new cloud platform creates strong motivation to centralize control. This can be counterproductive.

Excessive deny policies turn everyday engineering activities into exception processes. Platform teams become ticket queues, and engineers eventually discover alternative ways to accomplish their tasks.

I opted for controls linked directly to risks, including approved regions, tagging, diagnostic settings, public exposure, identity, security posture and resource configuration. Policies safeguarding legitimate security or compliance boundaries could be enforced. Others could begin in audit mode until we understood their operational implications.

I also maintained separation between sandbox environments. A sandbox still requires cost controls and fundamental security boundaries. However, if it performs identically to production, teams lose opportunities to experiment safely.

Governance should reduce risky choices without unnecessarily impeding normal engineering activities.

5. Observability and SIEM serve distinct functions

Another choice was differentiating between operational observability and security monitoring.

I employed Datadog as my primary observability platform for application performance, infrastructure telemetry, logs, distributed traces, service health, dashboards and engineering alerts. A dedicated cloud SIEM had a different role. I utilized it for security analytics, identity-related events, threat detection, investigations, incidents and SOC workflows.

This distinction dictated where telemetry was sent. If an API call fails and an engineer needs to determine why, that information belongs primarily within the observability platform. If an event represents a suspicious sign-in, privileged identity activity, a firewall threat alert or security policy violation, the SIEM becomes more pertinent.

Some events are relevant to both teams. However, sending all logs to both platforms adds cost and noise without necessarily improving visibility.

6. CI/CD networking is a component of the platform

Private endpoints create an immediate deployment issue. Once Azure resources are no longer publicly accessible, how does the CI/CD pipeline access them?

One alternative is to create public exceptions for storage accounts, Key Vaults or databases so deployment jobs can connect. This resolves the pipeline problem, but it diminishes the private network design.

I utilized GitHub larger runners with private networking via Azure VNets. The runners remained GitHub-hosted while their network interfaces were deployed into the Azure VNet. This permitted deployment workflows to access private resources through controlled paths.

This altered my perspective regarding CI/CD infrastructure. Deployment paths require identity controls, network controls, logging and clear ownership.

Terraform modules, GitHub workflows, environment protections, identities and private connectivity should support the landing-zone model rather than create a second pathway around it.

7. Active-active models work only when both regions are fully production-ready

My architecture employed an active-active model instead of maintaining the second region in an idle state. Both regions were operational and processing production traffic.

Azure Front Door was positioned in front of the regional application endpoints and distributed requests across healthy origins. Health probes verified origin health so that if one region became unavailable, Front Door could stop sending traffic to it and continue routing requests to the healthy region.

This changed my perspective regarding disaster recovery. I was no longer asking how rapidly I could activate a passive environment. Each region needed to absorb the failure of the other without altering the operating model.

To make this practical, the platform had to be repeatable across regions. Virtual WAN hubs, network addressing, firewall integration, policies, diagnostic settings, Datadog integration, SIEM integration, Terraform modules and deployment pipelines followed the same regional pattern.

If one region failed, the remaining region needed adequate capacity, telemetry, security visibility and deployment access to function normally.

Active-active models reduce recovery time only when both regions are genuinely active. A region that receives traffic but cannot independently support the workload is not sufficient for a resiliency strategy.

The architect’s responsibility begins where the reference architecture stops

After considering these decisions, my view of a successful landing zone became straightforward.

Workload teams should receive environments where networking, identity, security, observability, governance and deployment paths have already been established while maintaining enough flexibility to develop and manage applications.

If each new workload requires the architecture team to rethink networking, negotiate firewall rules again, manually configure monitoring, determine where logs should be directed and devise another deployment strategy, then the landing zone has not become a true platform.

Microsoft’s reference architecture provides a valuable foundation. However, it remains the architect’s responsibility to convert that foundation into something that operates effectively for the organization.

In my case, Azure Front Door, Azure Virtual WAN, Palo Alto Cloud NGFW, governance boundaries, Datadog, a dedicated cloud SIEM, private GitHub runner connectivity and a repeatable active-active regional design collectively formed a single platform.

The real advantage came from enabling these components to work together so that connectivity, security, observability, governance, deployment and resiliency supported one another instead of being solved independently.

That represents, for me, where an Azure landing zone develops beyond a reference diagram.

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。