Network Security
Customer-controlled deployments should use private connectivity for data, search, secret, registry, and other managed services wherever the target Azure services and customer architecture support it.
Reference Pattern
- Route public application traffic through an approved ingress layer with TLS and web-application protection.
- Keep application and function workloads in delegated subnets appropriate to their Azure service.
- Place private endpoints in a dedicated subnet where the customer standard requires it.
- Use private DNS zones and documented DNS links for private endpoint resolution.
- Disable public network access for sensitive managed services after private connectivity is verified.
- Apply deny-by-default network rules with explicit, reviewed service and destination allowances.
- Separate ingress, application, private endpoint, and management paths.
- Monitor denied traffic and failed DNS resolution during rollout.
Validation
Before go-live, test from every required runtime and administrative path:
- ingress reaches only the intended frontend or API endpoint,
- private names resolve to private addresses,
- workloads can reach required managed services,
- unauthorized public paths are blocked,
- required provider and integration egress succeeds,
- blocked egress produces useful operational evidence,
- deployment and emergency-access paths still work as designed.
Do not publish actual subnet ranges, internal hostnames, private endpoint identifiers, or customer firewall rules in public documentation. Maintain those values in the controlled deployment record.