Azure Reference Architecture

Applies to: Argos Vault (desktop), Bailment Web (dealers), Bailment Web API

Executive Summary  

This document describes the recommended deployment pattern for running Argos in Microsoft Azure. This pattern maximises performance and simplifies operations while retaining strong security controls.

Deployment Pattern: A single Azure Virtual Desktop (AVD) host VM runs SQL Server, Bailment Web (IIS), Bailment Web API (IIS), and the Argos Vault client. Users connect to the VM via AVD (MFA via Microsoft Entra ID). External dealer access to Bailment Web is optionally fronted by a WAF/CDN. This pattern minimises network hops and offers the best real‑world performance with the fewest moving parts.

This architecture is deployed in a single Azure subscription for data isolation, with identity centralised in the customer's Entra ID tenant. All infrastructure, monitoring, and alerting are recommended to be provisioned via Bicep for repeatability.

Design Objectives & Principles  

• Identity‑first: Entra ID for interactive access; MFA required. No public RDP.
  

• Least privilege & zero plain‑text secrets: Prefer password‑less auth

• Data isolation by subscription: Separate Azure subscription for Argos deployment.

• Observability: Actionable alerts on VM, backup, and database health

• Resilience: Daily backup and tested restore; optional ASR to paired region.

• Infrastructure as Code: Everything deployable & drift‑detectable with Bicep.
  

Reference Architecture — Converged AVD  

Topology (high level)  

• Entra ID: Tenant for user accounts, groups, Conditional Access, MFA.

• AVD Host Pool: One session host VM (Windows 11/Server) joined to Entra ID.

• Session Host VM (single, sized to concurrent users):

• SQL Server (instance scoped to Argos database)

• Bailment Web (IIS)

• Bailment Web API (IIS)

• Argos Vault Client (installed for AVD users)

• Perimeter:

• Bailment Web: Publicly reachable. WAF recommended.

• Web API: Not public; restrict by NSG IP allow‑list to known consumers

• Admin access: Via AVD and/or Bastion as break‑glass; no public RDP/3389.

Why this pattern  

• Performance: DB + app + client on the same VM eliminates east‑west latency and chatty calls between client and DB.

• Security: AVD provides Entra‑based sign‑in with MFA; attack surface is reduced (no exposed RDP).

• Cost‑effective: One VM to size, patch, back up, and monitor.

• Operational simplicity: Fewer components, simpler DR, faster troubleshooting.

Identity, Authentication & Secrets  

Entra ID is the source of truth for users; Conditional Access enforces MFA for AVD.

• Use Windows Integrated authentication to SQL Server 2022 via the Microsoft ODBC Driver 18/19

• Use built-in NT AUTHORITY\Authenticated Users group and grant only minimal roles required (least‑privilege)

• Limit AVD access to this VM to Vault / Bailment users only

• No plain‑text credentials in ODBC/DSN files, shortcuts, etc.

• For Bailment Web and the Web API [in IIS], Use Windows Integrated Security and run the site under its Application Pool Identity.

• Grant that identity access in SQL and use Integrated Security=True in the connection string.

 Note: this provides coarse‑grained authorization (no per‑user or per‑group DB permissions) - see Future section below for using Entra for SQL Server authentication. 

Networking & Perimeter Controls  

• No public RDP. Access via AVD; optionally use Azure Bastion for admin.
  

• Bailment Web:
  

• Use a WAF in front of the public endpoint; restrict origin to provider IP ranges.

• Cloudflare is an option, or Azure WAF (higher cost)

• Web API: Private by default — allow only known consumer IPs (NSG) or expose via Private Link.

• Egress hardening: Limit outbound where practical; allow Windows Update, Defender signatures, and required vendor endpoints.

Monitoring, Alerting & Dashboards  

Core metrics & alerts:

• VM health: CPU > 80% (15m), RAM < 800 MB, free disk < 20 GB.

• Backup health: Unhealthy backup events; policy changes/deletes.

Implementation approach:

• Use Azure Monitor native metrics where available; add Log Analytics only for metrics not natively exposed (e.g., disk free).

• Alerts send to a specific Action Group (email/SMS/Chat integration).

• Set up workbook/dashboard and optional weekly/monthly health snapshots.

Recommendation: Focus on the minimal, high‑signal counters to keep ingestion costs low; avoid enabling full VM Insights unless specifically required.

Backup, DR & Resilience  

• Backups: Daily VM and SQL backups to a Recovery Services Vault with retention to match compliance; quarterly test restores.
  

• DR (optional): Azure Site Recovery to a secondary region; document RPO/RTO, failover runbooks, and network changes.

• Load balancing: Typically not required; consider only if dealer traffic to Bailment Web warrants it.
  

Security Baseline & Hardening  

• Defender for Cloud (Servers P1) for VM vulnerability assessment and threat detection.
  
• Secure configuration reviews via Defender recommendations before promoting infra changes.

• Local privileges: Admin rights limited

• Patch & AV: Windows Update must be configured; Microsoft Defender AV on; Defender for Cloud (Servers P1) enabled.
  

Deployment & Operations  

• IaC: Recommend using Bicep templates create Log Analytics workspaces, DCRs, Azure Monitor Agent, alert rules, action groups, RSVs, AVD, and VMs.
  

• Change management: Use a TEST database and TEST copies of Argos Vault, API etc. to manage Argos version upgrades.
  

Future

Note: The current version of Vault does not support Entra authentication to SQL Server. This will be addressed in a future version of Vault.  

Identity, Authentication & Secrets  

Alternative Architecture — Pooled AVD + Dedicated App/DB VM  

Topology (high level)  

• AVD host pool with N session hosts running Vault client.

• Separate App/DB VM in the same VNet hosting SQL Server, Bailment Web, and Web API.

• FSLogix user profile containers (recommended for multi‑session hosts).

• Perimeter identical to Pattern A (WAF for Bailment Web, IP‑restricted API).

When to choose this pattern  

• Higher concurrency and session isolation requirements.

• Operational separation between desktop sessions and server workloads.

• Need for horizontal scale of the Vault client (more session hosts).

Trade‑offs  

• Pros: Better fan‑out capacity; role isolation; rolling maintenance.

• Cons: More VMs to manage; additional latency between client and SQL (mitigated by same VNet/zone); higher cost.