Reference Architecture for Modern Cloud Apps in Azure

A reference architecture is a vetted, opinionated blueprint that demonstrates how to assemble Azure services into a production system. This page describes a reference architecture for a modern cloud application — a web API with a frontend, serving external users, with a managed data tier, complete observability, and a fully automated CI/CD pipeline. Each design choice is explained so you can understand the reasoning and adapt it to your specific requirements.

Architecture overview

The architecture has five main layers, each with a clear responsibility:

  1. Edge layer: Azure Front Door with WAF — global anycast entry point, DDoS protection, SSL termination, caching, and geographic traffic routing.
  2. API gateway layer: Azure API Management — authentication enforcement, rate limiting, API versioning, developer portal, and backend routing.
  3. Compute layer: Azure Container Apps or AKS — application services, autoscaling, managed identity, health probes.
  4. Data layer: Azure Cosmos DB (document data), Azure SQL Database (relational data), Azure Cache for Redis (sessions and caching), Azure Blob Storage (files and static assets).
  5. Platform layer: Azure Key Vault (secrets), Azure Monitor + Application Insights (observability), Azure Service Bus (async messaging), Virtual Network with Private Endpoints (network isolation).

All layers connect through managed identities and Private Endpoints. No credentials are stored in code or environment variables. All traffic between compute and data services travels on the private VNet backbone, never over the public internet.

Edge and ingress

Azure Front Door (Standard or Premium tier) serves as the global entry point. It provides anycast routing, meaning every user’s request enters Microsoft’s network at the geographically nearest Point of Presence (PoP) — currently 200+ locations globally. Front Door terminates TLS at the PoP, reducing connection latency for geographically distributed users.

Front Door’s integrated Web Application Firewall (WAF) operates in Prevention mode with the Microsoft Default Rule Set (OWASP Core Rule Set equivalent) enabled. Custom WAF rules block known bot patterns, specific geographic regions (if required by compliance), and high-volume single-IP sources. Front Door’s rate limiting rule protects against credential stuffing and API scraping.

Front Door routes to API Management as the backend. The API Management instance has a private frontend IP in the VNet; Front Door reaches it via Private Link. No other traffic can reach APIM directly — any attempt to access the APIM IP from the internet is rejected at the network layer.

API Management layer

Azure API Management handles the concerns that are common to every API endpoint but should not be implemented in each service individually:

  • JWT validation: APIM validates the Authorization: Bearer token on every request using the validate-jwt policy. Invalid or expired tokens return 401 before the request reaches backend services.
  • Rate limiting: Per-subscription and per-IP rate limits prevent any single caller from consuming excessive capacity.
  • API versioning: APIM exposes versioned API paths (/v1, /v2) and routes each version to the appropriate backend implementation. Old versions can be deprecated and sunsetted without impacting new clients.
  • Response caching: APIM caches GET responses for configurable TTLs, reducing backend load for frequently requested, infrequently changed data.
  • Transformation: Response header stripping removes internal headers (X-Powered-By, Server) that expose implementation details. Request transformation normalises input formats before backends receive them.

Compute tier

Application services run on Azure Container Apps (for most scenarios) or AKS (for scenarios requiring custom Kubernetes configurations, GPU nodes, or deep control over networking). Container Apps is recommended for new workloads because it eliminates node pool management while still providing Kubernetes-based scaling and Dapr integration.

Each service runs with a minimum of three replicas spread across availability zones. Managed identity is assigned at the Container App or pod level, not the cluster level, so each service has only the permissions it needs. Resource limits and requests are set for every container to prevent noisy-neighbour effects.

# Container App definition (ARM/Bicep equivalent shown as conceptual YAML)
# Minimum viable Container App configuration for production
name: order-service
identity:
  type: UserAssigned
  userAssignedIdentities:
    - /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/order-service-identity
properties:
  environmentId: /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.App/managedEnvironments/myContainerEnv
  configuration:
    ingress:
      external: false
      targetPort: 8080
    secrets:
      - name: db-connection
        keyVaultUrl: https://mykeyvault.vault.azure.net/secrets/order-db-connection
        identity: /subscriptions/.../order-service-identity
  template:
    containers:
      - name: order-service
        image: myregistry.azurecr.io/order-service:2.1.4
        resources:
          cpu: 0.5
          memory: 1Gi
        probes:
          - type: Readiness
            httpGet:
              path: /health/ready
              port: 8080
    scale:
      minReplicas: 3
      maxReplicas: 20

Data layer

The data layer is split by access pattern. Use the right tool for each data type rather than a single database for everything.

Azure Cosmos DB (API for NoSQL) stores document data with variable schemas — product catalogs, user profiles, order line items. Provisioned in serverless mode for variable traffic, or with autoscale RUs for predictable workloads. Zone-redundant and geo-replicated to the paired region with multi-region writes enabled for Tier 1 workloads.

Azure SQL Database Business Critical stores relational data requiring ACID transactions — financial transactions, inventory ledgers, audit records. Zone-redundant with failover group to secondary region. Read replicas serve analytical queries.

Azure Cache for Redis Enterprise (zone-redundant) stores sessions, API response caches, and distributed locks. Active geo-replication for multi-region deployments. Configured with eviction policy allkeys-lru so that the cache degrades gracefully under memory pressure.

Azure Blob Storage (ZRS, Hot tier) stores user-uploaded files, static web assets, and exported reports. Static website hosting serves the frontend directly from Blob Storage via CDN. Private Endpoints restrict access to the compute VNet only.

Note

All data services are deployed with Private Endpoints. The public network access setting is disabled on every data service. Any connection attempt from outside the VNet is rejected at the network layer before authentication is even considered.

Observability

The observability stack is built on Azure Monitor with Application Insights for application telemetry and Log Analytics for infrastructure and platform logs. All services send telemetry to the same Log Analytics workspace, enabling cross-service correlation in a single query interface.

Every service is instrumented with OpenTelemetry, emitting traces, metrics, and structured logs. The trace context (traceparent header) is propagated across all service calls including Service Bus messages. A single request from browser to API can be traced across Front Door, APIM, all microservices, and every database call in a single Application Insights End-to-End Transaction view.

Alerting uses a three-tier model: availability monitor pings the front door endpoint every minute from multiple global locations; error rate alerts fire when 5xx responses exceed 1% of traffic for 5 minutes; latency alerts fire when P99 response time exceeds 2 seconds for 5 minutes. Alerts route to PagerDuty via Action Groups for on-call paging.

CI/CD pipeline

Every service has its own CI/CD pipeline in GitHub Actions or Azure DevOps. The pipeline structure is standardised across all services: build → unit test → container image build → push to Azure Container Registry → security scan (Trivy/Defender for Containers) → deploy to staging → integration test → deploy to production (canary, then full).

Container images are tagged with the commit SHA and semantic version. Image tags are immutable — once an image is pushed to ACR with a given tag, that tag cannot be overwritten. Vulnerability scanning runs on every image build and blocks promotion to production if a critical CVE is found.

# Example: tag and push a production image
SERVICE=order-service
VERSION=2.1.4
COMMIT_SHA=$(git rev-parse --short HEAD)
ACR=myregistry.azurecr.io

docker build -t $ACR/$SERVICE:$VERSION-$COMMIT_SHA .
docker tag $ACR/$SERVICE:$VERSION-$COMMIT_SHA $ACR/$SERVICE:$VERSION
az acr login --name myregistry
docker push $ACR/$SERVICE:$VERSION-$COMMIT_SHA
docker push $ACR/$SERVICE:$VERSION

# Scan the image for vulnerabilities before deployment
az acr task run \
  --registry myregistry \
  --name vulnerability-scan \
  --set IMAGE=$ACR/$SERVICE:$VERSION

Common mistakes

  1. Deploying the full reference architecture for a simple application. This architecture is designed for a production application serving many users with strict reliability and security requirements. Applying it to a low-traffic internal tool adds cost and operational complexity with no benefit. Match the architecture’s complexity to the workload’s requirements.
  2. Treating the reference architecture as static. Azure services evolve rapidly. Patterns that were best practice two years ago may have been superseded. Review your architecture against current Azure Well-Architected Framework guidance annually and adopt improvements to security, reliability, and cost efficiency as they become available.
  3. Implementing observability as an afterthought. Instrumentation code is much easier to add before a service is deployed than after it is running in production under load. Require Application Insights instrumentation as a non-optional part of the service template. A service without distributed tracing cannot be diagnosed effectively when it misbehaves in production.

Related topics to read next

These pages build on what you just learned.

Frequently asked questions

Is this reference architecture suitable for every Azure application?

This architecture targets production workloads serving external users at meaningful scale. It is intentionally comprehensive to demonstrate the full range of Azure best practices. A smaller internal tool or a prototype does not need every component shown here. Use this as a menu: adopt the patterns that match your scale, criticality, and team maturity. The identity, secrets management, and monitoring patterns apply to every workload regardless of scale.

How do I adapt this architecture for a microservices application vs a monolith?

The frontend, API Management, and networking layers are identical. For a monolith, replace the AKS microservices tier with a single App Service or Container App deployment. For microservices, each service is a separate Container App or AKS workload with its own database. The observability, security, and CI/CD patterns apply to both. The main difference is that microservices require a service bus for inter-service communication, while a monolith communicates internally.

What does this architecture cost to run at minimum viable production scale?

At minimum viable scale (2-region active-passive, single AKS node pool with 3 nodes, Azure SQL Business Critical S3, Redis C1, Standard API Management, Standard Front Door), you should expect $2,000–$4,000 per month. The largest cost drivers are AKS node VMs, Azure SQL Business Critical, and API Management Standard tier. For cost-constrained scenarios, replace Azure SQL Business Critical with General Purpose (lower cost, longer failover), use App Service instead of AKS, and use API Management Consumption tier.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.