Skip to content
eSHARS Operations

INFRA-0001: VNet Integration for App Service → SSRS Connectivity

Status

Accepted

Date

2026-03-25

Context

The eSHARS web app (wa-eshars-nonprod, wa-eshars-prod) renders SSRS reports via the MvcReportViewer NuGet package. The package makes server-side HTTP calls from the App Service to the SSRS server. Until March 2026, this worked via the SSRS VM’s public IP address.

When the public IP was removed from vm-sql16-np (nonprod) to improve security posture, all report viewing broke with “Service unavailable — unable to connect to remote server.” The App Service had no route to the VM’s private IP (10.1.0.4).

The same situation applies to production (vm-ssrs16-prod, private IP 10.0.0.5, public IP 23.99.180.223 still present at time of writing).

Decision

Use Azure App Service VNet Integration to give the App Service outbound access to the VNet, routing traffic to the SSRS VM via private IP.

  • Create a dedicated subnet per environment for App Service delegation
  • Add VNet integration on each App Service slot pointing to that subnet
  • Update app settings to use private IP instead of public IP

Alternatives Considered

Alternative 1: Restore the public IP

Re-add the public IP to the SSRS VM and keep routing traffic over the internet.

Pros: Zero configuration change. Restores previous state immediately.

Cons: Public IP is a security exposure on a VM running Windows Server 2012 R2 (EOL) and SQL Server 2016. Keeping it contradicts the goal of reducing attack surface. Fragile — if IP changes again, everything breaks.

Alternative 2: App Gateway as reverse proxy

Route App Service → App Gateway → SSRS VM (private IP). The App Gateway already fronts nonprodreports.myeshars.com.

Pros: No new Azure networking primitives. App Gateway is already in place.

Cons: Unnecessary hop — App Gateway is designed for inbound HTTP, not as a generic TCP proxy. Adds latency. App Gateway health probes would target SSRS endpoints. The training slot actually uses this pattern (see INFRA-0003) and it works, but it’s the exception not the rule.

Alternative 3: Private Endpoint on the SSRS VM

Expose the SSRS VM via an Azure Private Endpoint.

Cons: Private Endpoints are for Azure PaaS services (SQL, Storage, Key Vault, etc.) — not for IaaS VMs. VMs are reachable via VNet integration natively once the App Service is on the same VNet.

Consequences

Positive

  • App Service → SSRS traffic stays entirely within the Azure VNet
  • Public IP can be removed from SSRS VMs (reduces attack surface)
  • Pattern is consistent across all environments once applied to prod

Negative

  • VNet integration is configured per slot, not inherited from the App Service Plan. Each slot (dev, qa, regression, uat, trn, prod) must be configured individually.
  • Requires a dedicated subnet per environment (see INFRA-0002)

Neutral

  • App setting updates required — both the dot-notation and camelCase keys must be updated (see INFRA-0004)

Implementation

EnvironmentSubnetSSRS Private IPStatus
nonprod (all slots)sn-webapp-eshars-np (10.1.3.0/24)10.1.0.4✅ Complete (2026-03-25)
prodsn-webapp-eshars-prod (10.0.3.0/24)10.0.0.5Scheduled — see Change Record