Security and strong operational controls are paramount for integration platforms. Without them, organisations risk data breaches, downtime, and loss of trust. This post demonstrates, step by step, how to build a secure, enterprise-grade landing zone for Azure API Management (APIM) using private networking, observability, and automation. This post features a real scenario from a hands-on deployment and discusses why this approach is essential for regulated, high-security, or internal API platforms.
As a Senior Consultant, over the years I’ve seen organisations succeed—or struggle—based on how intentionally they approach their API management foundation. This post is for architects and decision-makers who want to get APIM right from the start, with a focus on infrastructure, security, and operational excellence.
This blog post mainly focuses on securing the baseline, deploying APIM with secure configuration and no backends. If there is interest, I will extend this into another part covering scenarios such as adding a private Azure Function backend or a GenAI backend.
Understanding the Landing Zone for API Platform
A landing zone is a pre-configured, governed environment in Azure that provides a secure and scalable foundation for workloads. For API Platforms, it brings together networking, identity, monitoring, security controls, and automation – ensuring APIs are not just deployed, but deployed right.
By establishing a landing zone:
- You accelerate time-to-value with ready-to-use, best-practice infrastructure
- Risk is reduced through enforced security and operational standards from day one
- Teams gain the ability to scale and move fast, without reinventing the wheel or bypassing controls
Landing zones are built using Infrastructure as Code (Bicep, Terraform or ARM), integrated with Azure Policy, RBAC, and monitoring for governance and visibility. Modularity is key: networking, identity, security, and API management are composable building blocks. Skipping this foundation leads to security vulnerabilities (public endpoints, weak identity, lack of observability), compliance gaps, operational chaos, and slower innovation due to rework and firefighting.
For API strategy, a landing zone ensures your platform is a first-class, secure, and scalable foundation – optimising for both agility and control, and supporting rapid delivery with enterprise control.
Why a Secure Baseline Matters
Before exposing APIs to partners, customers, or internal teams, your API gateway must be secure by default. A secure baseline reduces the attack surface, enforces organisational standards, and sets the stage for future enhancements – enabling safe integration of new backends, policies, and features. This is achieved by using private networking to restrict access, applying least-privilege identity and access controls, integrating monitoring and alerting from day one, and automating deployment to avoid configuration drift.
Neglecting a secure baseline can result in APIs being exposed to the public internet by accident, inconsistent security posture across environments, and increased risk of data breaches or downtime.
What Makes a Secure Baseline for Azure API Management?
A secure baseline for Azure APIM is a deployment that incorporates best practices for security, networking, identity, and operational readiness. It is the “minimum viable security and governance” for your API platform.
Key elements include:
- APIM deployed in internal mode (private networking)
- A dedicated management subnet (Mgmt Subnet) with a management VM (jumpbox) for secure, internal administration and troubleshooting. This subnet is assumed to exist as part of the landing zone and is not shown in the deployment steps in this blog.
- No backends connected by default – reducing initial risk
- A sample API for validation and demonstration
- Managed identities enabled for secure resource access
- Monitoring and diagnostics integrated for visibility
Key Features and Best Practices
Private Networking: Deploy APIM in internal mode, placing it in a dedicated subnet within a virtual network. This prevents unauthorised access from the public internet; only trusted networks can reach your APIs. Skipping this step may expose APIs to external threats, increasing the risk of attacks.
Management Subnet and Jumpbox: Use a dedicated management subnet (Mgmt Subnet) with a management VM (jumpbox) for secure, internal administration and troubleshooting. This enables safe access to APIM resources without exposing them to the public internet.
No Backends by Default: Start with no backend services connected to APIM. This reduces initial risk and allows you to validate the platform’s security posture before onboarding real workloads.
Sample API: Deploy a placeholder API to validate the platform and test policies. This provides a safe way to test and demonstrate the platform before onboarding production APIs.
Managed Identities: Enable system-assigned managed identity for APIM. This allows APIM to securely access Azure resources (Key Vault, Storage, etc.) without hardcoded secrets. Without managed identities, you risk credential leaks and operational complexity. Note: This blog does not cover managed identity configuration in detail.
Monitoring: Integrate APIM with Azure Monitor and Log Analytics. This enables proactive detection of issues, performance bottlenecks, and security events. Without this, you’ll have blind spots in API usage, delayed incident response, and compliance gaps. (Optionally, you can integrate with Microsoft Sentinel for advanced security analytics and threat detection.)
Infrastructure as Code: Use Bicep, Terraform or ARM to define and deploy all resources. This ensures repeatability, auditability, and rapid recovery from failures. Manual deployments or changes can lead to errors, configuration drift, and slow recovery from incidents.
Sample API: Deploy a placeholder API to validate the platform and test policies. This provides a safe way to test and demonstrate the platform before onboarding real workloads. Skipping this step can delay validation and increase the risk of misconfiguration when onboarding production APIs.
Network Diagram
Below is a very high-level network diagram of a secure, enterprise-ready Azure API Management landing zone, including Network Security Groups (NSGs), Log Analytics, a management subnet, and private endpoints:

Image 1: A very high-level architecture diagram
Step-by-Step: Deploying a Secure Baseline for Azure API Management
Below are detailed (somewhat advanced-level) steps to deploy Azure API Management (APIM) as part of a secure landing zone, with context for each decision.
Note: The Azure CLI examples provided here are for demonstration and learning purposes. In enterprise environments, resource provisioning and configuration should be automated using Infrastructure as Code (IaC) tools such as Bicep, Terraform, or ARM templates, integrated with CI/CD pipelines. This ensures consistency, repeatability, compliance, and auditability across environments.
1. Create a Resource Group
az group create --name rg-vishal-demo --location australiaeast
2. Create a Virtual Network and Subnet
This step creates the foundational network elements required to isolate APIM from the public internet.
az network vnet create --resource-group rg-vishal-demo --name vnet-vishal-demo --address-prefix 1.0.0/16 --subnet-name apim-subnet --subnet-prefix 10.1.1.0/24
az network nsg create --resource-group rg-vishal-demo --name nsg-vishal-demo
az network vnet subnet update --resource-group rg-vishal-demo --vnet-name vnet-vishal-demo --name apim-subnet --network-security-group nsg-vishal-demo
If you skip this, APIM may be exposed to the public internet, increasing risk.
3. Deploy APIM in Internal Mode (Bicep Example)
Internal mode ensures APIM is only accessible from trusted networks.
Create a file named `apim-secure-baseline.bicep`:
Note: The Developer tier is for non-production use only. For production workloads, use higher tiers like Standard or Premium.
resource apim 'Microsoft.ApiManagement/service@2022-08-01' = {
name: 'apim-vishal-demo'
location: resourceGroup().location
sku: {
name: 'Developer'
capacity: 1
}
identity: {
type: 'SystemAssigned'
}
properties: {
publisherEmail: 'vishal.makwana@contoso.com'
publisherName: 'Vishal Makwana'
virtualNetworkType: 'Internal'
virtualNetworkConfiguration: {
subnetResourceId: resourceId('Microsoft.Network/virtualNetworks/subnets', 'vnet-vishal-demo', 'apim-subnet')
}
}
}
Deploy the Bicep file:
az deployment group create --resource-group rg-vishal-demo --template-file apim-secure-baseline.bicep
If you skip this, APIs may be reachable from untrusted networks, violating security policy.

Image 2: AZ resources after successful deployment
4. Enable Monitoring
Monitoring provides visibility into API usage, performance, and security events.
az monitor log-analytics workspace create --resource-group rg-vishal-demo --workspace-name logws-vishal-demo --location australiaeast
az monitor diagnostic-settings create --resource "/subscriptions/{subscription id}/resourceGroups/rg-vishal-demo/providers/Microsoft.ApiManagement/service/apim-vishal-demo" --name apim-monitoring --workspace /subscriptions/{subscription id}/resourceGroups/rg-vishal-demo/providers/Microsoft.OperationalInsights/workspaces/logws-vishal-demo --logs "[{\"category\": \"GatewayLogs\", \"enabled\": true}]"
Without Log Analytics and diagnostics, you’ll lack observability, have delayed incident response, and face compliance risks.
5. Validate the Deployment
To ensure your secure baseline is effective, perform both positive and negative testing:
Positive Testing (Expected Access):
- From a VM inside the Mgmt Subnet (or another trusted subnet in your VNet), access the APIM gateway and management endpoints. Confirm you can reach the APIM instance and perform management operations as intended. You can find the APIM private IP address in the Azure Portal under the APIM resource’s ‘Network’ settings. Use this address from your management VM to test connectivity
- Validate that diagnostic logs are being sent to Log Analytics – In the Azure Portal, navigate to your Log Analytics workspace, select ‘Logs,’ and query for APIM diagnostic entries (e.g., using the ‘AzureDiagnostics’ table).
Negative Testing (Blocked Access):
- Attempt to access the APIM gateway or management endpoints from outside the VNet (e.g., your local machine or an untrusted subnet). Confirm that access is denied and endpoints are not reachable.
- Try to access APIM from a subnet that is not explicitly allowed by your NSG rules and verify that traffic is blocked.
Lessons Learned and Recommendations
- Start with a secure landing zone: Retrofitting security and governance is costly and risky. Invest up front.
- Automate everything: Manual deployments lead to drift, errors, and slow recovery. Use IaC and CI/CD.
- Integrate monitoring and alerting: Visibility is non-negotiable for security, compliance, and operations.
- Design for scale and change: Use modular, composable patterns so you can evolve your API platform without rework.
- Document and enforce standards: Make it easy for teams to do the right thing by default.
- Review and iterate: Azure and business requirements evolve—so should your landing zone and API platform.
Conclusion
A secure, well-architected API management foundation is not just a technical requirement—it’s a business enabler. By investing in a landing zone and a secure baseline for Azure API Management, you set the stage for innovation, agility, and resilience. The “how” and “why” behind each architectural choice matter: they determine your ability to scale, govern, and protect your digital assets.
Don’t wait for an incident or audit to reveal gaps. Build your API platform on a strong, secure, and automated foundation—your future self (and your business) will thank you.

















