Review the database boundary in an Azure-hosted RDS design

Source facts

Microsoft documents RDS deployment architectures for hosting Windows desktops and applications in Azure. The basic Azure example operates in one region and uses an external load balancer for incoming internet connections. The highly available example replaces a traditional SQL Server virtual machine with Azure SQL Database for RDS configuration and session data, introducing a managed-platform dependency. Microsoft documentation.

Applicability

Use this review when comparing the documented Azure deployment patterns. Identify the proposed RDS roles, database service, region, and network entry points. Validate current service and platform requirements for the selected design.

DSE recommendation

Draw the database boundary separately from the session-host and gateway roles. Ask the RDS and Azure owners to assign responsibility for database connectivity, service configuration, and incident investigation. Record which operational tasks change with the managed database choice. Keep the architecture decision distinct from component-version support and from the sequence of a later upgrade.

Verification

Exercise the intended session and connection workflows in an approved test deployment. Inspect the actual database endpoint used and record the associated configuration. Include the agreed connectivity-failure scenario and its observable effect on RDS operations. Compare results with the design objectives before treating a diagram’s highly available label as evidence for the deployed service.

Official references

Microsoft Learn: Remote Desktop Services Architecture in Azure – Deployment Patterns and Best Practices. Source reviewed September 8, 2026.