# Review the database boundary in an Azure-hosted RDS design

> What changes when an Azure RDS architecture uses Azure SQL Database instead of a SQL Server VM?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-051-review-the-database-boundary-in-an-azure-hosted-rds-design/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-08T18:16:20+00:00
- Modified: 2026-09-08T18:20:21+00:00
- Last reviewed by DSE: 2026-09-08
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

What changes when an Azure RDS architecture uses Azure SQL Database instead of a SQL Server VM?

## Potentially affected

Use this review when comparing the documented Azure deployment patterns.

## DSE recommendation

Draw the database boundary separately from the session-host and gateway roles.

## Article

## 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](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture).

## 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](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture). Source reviewed September 8, 2026.

## Primary reference

- Name: Remote Desktop Services Architecture in Azure - Deployment Patterns and Best Practices
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Review the database boundary in an Azure-hosted RDS design,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-051-review-the-database-boundary-in-an-azure-hosted-rds-design/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.