user-guides

Multi-Tenant Application Architecture on Azure VMs

Scope:
This document defines the complete multi-tenant architecture for a web and API-based solution hosted on Azure Virtual Machines.
It covers all layers except the SQL Server database, focusing on the application, API, infrastructure, and operations components for both Active–Active and Active–Passive designs.

1. Architecture Overview

Current Setup

Goals

2. High-Level Architecture Summary

Active–Passive Mode

Active–Active Mode

3. Multi-Tenancy at the Application Layer

Advantages

Challenges

Option B: Tenant-Scoped Application Instances

Advantages

Challenges

Option C: Dedicated Environments (VIP Clients)

Advantages

Challenges

4. Multi-Tenancy at the API Layer

Core Design Principles

image

Tenant Context Middleware Example

public class TenantMiddleware {
    public async Task Invoke(HttpContext context) {
        var tenantId = context.User.FindFirst("tenant_id")?.Value 
                        ?? context.Request.Headers["X-Tenant-ID"];
        context.Items["TenantId"] = tenantId;
        await _next(context);
    }
}

API Deployment Models

  1. Single Shared API VMSS – All tenants share the same API backend.
  2. Per-Tenant API Pools – Isolated APIs for high-volume or VIP tenants.

5. Infrastructure and Networking Design

Hub–Spoke Model per Region

Example

EastUS-Hub
│
├─ Spoke-Shared
│   ├─ Web VMSS
│   ├─ API VMSS
│   ├─ Redis / Cache
│
├─ Spoke-TenantA (optional)
│   ├─ Custom VMSS
│
└─ Spoke-TenantB (optional)

Isolation Controls

6. Tenant Lifecycle Management

Stage Mechanism
Provisioning CI/CD pipeline deploys app, config, and registers tenant
Configuration Adds tenant metadata to registry or Key Vault
Isolation Controls Creates storage, folders, secrets, and RBAC roles
Monitoring TenantId tagging for observability
Deprovisioning Automated cleanup of tenant resources and keys

Automation ensures consistent onboarding and safe removal of tenants with no manual intervention.

7. Request Flow (End-to-End)

Client (tenantA.example.com)
   ↓
Azure Front Door (Global WAF)
   ↓
Regional App Gateway (East/West)
   ↓
Web VMSS (Tenant-Aware App)
   ↓
API VMSS (Tenant Context Middleware)
   ↓
SQL AG Listener (Tenant-Scoped Query)
   ↓
Redis Cache (Key Prefix = TenantId)
   ↓
Telemetry (App Insights Tagged by Tenant)

8. Security and Governance

9. Monitoring and Observability

Component Function
Azure Monitor VM and app performance metrics
Log Analytics Centralized logging, tagged with TenantId
Application Insights Telemetry, request traces, dependency maps
Defender for Cloud Security and compliance posture
Sentinel (Optional) Advanced SIEM and threat detection

Use custom dimensions such as TenantId, Region, and Environment in telemetry to isolate tenant metrics.

10. CI/CD and Deployment Automation

11. High Availability (HA) and Disaster Recovery (DR)

Model Description Active Region(s) Failover Mechanism
Active–Active Both regions serve live traffic East + West Front Door rerouting
Active–Passive Primary handles load; secondary standby East Traffic Manager or manual trigger

Key Considerations:

12. Summary and Recommendations

Multi-Tenancy Strategy

| Layer | Approach | Isolation | Scaling | |——-|———–|————|———-| | Web App | Shared, tenant-aware logic | Logical | Autoscale VMSS | | API | Shared or per-tenant | Logical / Medium | Autoscale VMSS | | Infrastructure | Hub-Spoke VNets | Network | Per spoke | | Storage | Shared SMB with ACLs | Logical | Per folder/share | | Monitoring | Tenant-tagged logs | Logical | Centralized | | CI/CD | Parameterized templates | Config-based | Automated |

Recommendations