Azure: exposure and health checks

Verified against primary documentation on 2026-10-11.

Exposure

Azure Load Balancer is public or internal, decided by whether its frontend IP is public or private; an internal load balancer "can't accept incoming traffic from the internet" (How Azure Load Balancer works). Application Gateway has a public frontend IP, a private one or both; Microsoft describes the private frontend as "useful for internal line-of-business applications that aren't exposed to the internet" (Frontend IP configuration).

On AKS, a LoadBalancer Service becomes internal with service.beta.kubernetes.io/azure-load-balancer-internal: "true" (Internal load balancer), and a private cluster keeps the API server on Private Link (Private clusters).

Container Apps ingress is external, shown as "Accepting traffic from anywhere", or internal, shown as "Limited to Container Apps Environment". Both are relative to the environment: an internal environment has no public endpoint, so an app with external ingress inside it is still not on the internet (Ingress; Networking). Internal ingress is not a complete boundary: "An app with internal ingress can still receive traffic from outside the environment if it's referenced as a target in an environment-level HTTP route configuration". The app declares its audience and the environment decides whether that audience includes the internet.

Azure is not consistent between the words: "internal" usually labels who can reach something, "private" usually labels an IP or Private Link, and no page defines them as distinct levels.

Identity

Microsoft's Zero Trust guidance moves access control "away from the perimeter and closer to applications and resources", based on identity and device rather than network location (Zero Trust overview). App Service authentication and managed identities provide that identity to users and workloads (Authentication and authorization; Managed identities).

Staff tools sit behind Entra Application Proxy, whose connector only makes outbound connections (Application Proxy), with Privileged Identity Management for just-in-time elevation (PIM).

Health checks

Container Apps supports startup, liveness and readiness probes over HTTP or TCP, and adds default probes when ingress is enabled and none are defined (Health probes).

App Service health check requests one configured path on every instance each minute and removes an instance from the load balancer after repeated failures (Health check).

Load Balancer probes come from 168.63.129.16, which network security groups must not block (Manage health probes). The Application Gateway Ingress Controller derives its probe from the Pod's readinessProbe or livenessProbe. Without either, it assumes the service answers at the backend-path-prefix annotation or the Ingress path, and it uses defaults, such as /, only for properties it cannot infer (Health probes with AGIC). It reads only httpGet probes, and "probing on a port other than the one exposed on the pod is currently not supported". A probe on another port is replaced by the appgw.ingress.kubernetes.io/health-probe-path and appgw.ingress.kubernetes.io/health-probe-port annotations on the Ingress, which default to / and 80 (AGIC annotations).

Microsoft documents the Health Endpoint Monitoring pattern but prescribes no path names (Health Endpoint Monitoring).