Securing Azure Container App Endpoints Used by Azure Communication Services (Call Automation + Media Streaming)

Hi @Balar, Nishilkuma

Thank you for reaching us regarding the issue.
At this time, Azure Communication Services (ACS) Call Automation – including webhook delivery and bidirectional media streaming (WSS) – requires publicly reachable endpoints. There is no supported way today to have ACS initiate calls, callbacks, or media streaming into a private‑only (VNet‑internal) Azure Container App with no public ingress.

1. Is there an official Azure-supported way to restrict inbound access to a Container App to ACS only at the network level?
   No. ACS requires publicly reachable HTTPS/WebSocket endpoints. You can use VNet integration + internal ingress on Container Apps, but ACS cannot reach a fully private endpoint. Network-level restriction to “ACS only” is not supported.
2. Does ACS Call Automation support connecting to a private endpoint or VNet-integrated backend for media streaming (WSS)? Is Private Link on the roadmap?
   No. ACS does not support private endpoints or Private Link for callbacks or bidirectional media streaming (WSS). The callback URI and media Transport URI must be public with a valid HTTPS certificate. No Private Link roadmap is documented.
3. Is AzureCommunicationServices available as an NSG Service Tag for inbound rules?
   It appears in the downloadable IP ranges JSON, but it is not available as a selectable service tag in the Azure Portal NSG rule builder. Do not rely on it for inbound restrictions.
4. Is there any recommended architecture pattern from Microsoft for securing Container Apps as ACS Call Automation backends (webhooks + WSS)?
   Yes, Use internal ingress + VNet integration for the Container App, then front it with Azure Application Gateway (with WAF) or Azure Front Door. Route only your required paths (/api/incomingCall, /api/callbacks/{contextId}, /ws). Keep strong app-level validation (JWT, secrets, HMAC). This is the recommended layered pattern.

Reference:
https://dori-uw-1.kuma-moon.com/en-us/azure/communication-services/how-tos/call-automation/secure-webhook-endpoint?pivots=programming-language-javascript
https://dori-uw-1.kuma-moon.com/en-us/azure/container-apps/waf-app-gateway?tabs=default-domain
https://dori-uw-1.kuma-moon.com/en-us/azure/application-gateway/application-gateway-websocket

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

1. There’s no documented, Azure-supported way in the provided material to restrict Azure Container Apps ingress “to ACS only” at the network layer. The available guidance for Container Apps focuses on:
   • Using internal ingress and VNet integration, plus NSGs and firewalls, to restrict access in general.
   • Fronting web-facing workloads with a WAF-capable entry point when external ingress is required.
   The material explicitly notes that when using built-in external ingress, the ingress point can’t be fully placed behind a WAF or DDoS plan, and recommends “Front all web-facing workloads with a web application firewall” instead of a service-tag-only restriction.
2. The provided ACS Call Automation documentation requires that:
   • IncomingCall events are delivered via Event Grid to a webhook endpoint.
   • Mid-call Call Automation events are delivered via HTTPS webhooks to a callback URI that “must be a public endpoint with a valid HTTPS certificate, DNS name, and IP address with the correct firewall ports open.”
   • For WebSocket media, ACS initiates the WebSocket connection to the application’s WSS endpoint, and security is handled by:
     • Validating a JWT token in the WebSocket headers.
     • Optionally restricting connections by IP ranges/FQDNs for “Call Automation media” and “Call Automation callback URLs.”
   There’s no mention in the context of ACS Call Automation supporting:
   • Private endpoints / Private Link to reach a backend.
   • Direct connectivity to a VNet-only or private-ingress-only Container App.
   Instead, the guidance is to secure the public endpoint with:
   • HTTPS and certificate validation.
   • JWT validation for WebSocket connections.
   • IP allowlisting using the documented ACS media and callback IP ranges and FQDNs.
3. The context lists IP ranges and FQDNs for ACS media and callback traffic, but does not state that an AzureCommunicationServices NSG service tag is available or supported for inbound rules. The recommended network-level control in the ACS docs is IP/FQDN allowlisting, not a service tag.
4. For an architecture pattern, the relevant guidance from the context is:
   • For Container Apps:
     • Use internal ingress and VNet integration plus NSGs when workloads must not be broadly exposed, but when external ingress is used, front it with a WAF (for example, Application Gateway or Azure Front Door) and other network security features such as NSGs, UDRs, and private endpoints for downstream services.
     • Avoid storing state in the Container Apps environment; use external state stores.
   • For ACS Call Automation:
     • Webhook callback URIs and WebSocket endpoints must be public HTTPS endpoints.
     • Secure them with:
       • Event Grid’s support for Microsoft Entra–protected endpoints for IncomingCall events.
       • JWT validation on WebSocket connections.
       • IP/FQDN allowlisting for ACS media and callback traffic.
   Combining these, the pattern implied by the documentation is:
   • Keep a public HTTPS/WebSocket surface that ACS can reach (for webhooks and media), but harden it:
     • Front with WAF (Application Gateway or Azure Front Door) as the only public entry point.
     • Use Container Apps network security features (NSGs, rule-based routing, custom domains, firewall integration) behind that entry point.
     • Use JWT validation and IP/FQDN allowlisting for ACS media and callbacks.
   • Use internal networking and private endpoints only for downstream dependencies (databases, caches, etc.), not for the ACS-facing endpoints themselves.
   The context does not describe a fully private, no-public-IP Container App being directly reachable by ACS Call Automation for webhooks and WebSocket media.

References:

• Deploy Microservices to Azure Container Apps
• Security overview in Azure Container Apps
• Secure webhook endpoints and WebSocket connections (programming-language-csharp)
• Secure webhook endpoints and WebSocket connections (programming-language-python)
• Secure webhook endpoints and WebSocket connections (programming-language-java)
• Call Automation Overview
• Control mid-call media actions with Call Automation