Network Endpoint Groups, or NEGs, are how Cloud Load Balancing reaches backends that aren't Compute Engine VMs. If you've worked with Cloud Run behind an HTTPS load balancer, you've already used a NEG even if you didn't think of it that way. For the Professional Cloud Architect exam, you need to recognize when a NEG is the right answer and which flavor fits the backend type.
A managed instance group sends traffic to VMs. That works for the classic case, but a lot of modern architectures don't run on VMs. Cloud Run, App Engine, Cloud Functions, container-native pods inside GKE, services running on-premises, and external internet endpoints all sit outside the MIG model. NEGs fill that gap. They give the load balancer a structured way to address those backends as if they were a normal pool, so the same load balancer that routes to a VM group can also route to a serverless service or an external host.
NEGs are most commonly used with the HTTPS Load Balancer because that load balancer runs at Layer 7 and has the routing intelligence to make path-based and host-based decisions across these mixed backend types. You can have one URL map send /api/* to a Cloud Run service through a serverless NEG and /static/* to a Cloud Storage bucket, all behind a single anycast IP.
For the Professional Cloud Architect exam, the NEG types worth knowing are:
Serverless NEGs connect a load balancer to Cloud Run, App Engine, or Cloud Functions. This is the integration that lets you put a custom domain and Google-managed SSL cert in front of a serverless service, and it's also how you fit a serverless backend into a multi-region or multi-service URL map.
GKE NEGs are used for container-native load balancing. GKE doesn't strictly require a NEG, since it can also use instance group backends, but the container-native path lets the load balancer send traffic directly to pod IPs instead of bouncing through a node and kube-proxy. Fewer hops, better health checks, and more accurate load distribution.
Internet NEGs point at endpoints outside Google Cloud. That can be an on-premises system, a service in another cloud, or any internet-facing host. The load balancer treats it as a backend and you can layer Google's edge network and Cloud Armor in front of it.
Zonal NEGs are the underlying primitive for pointing at specific IP and port combinations inside a zone. You'll see these come up with GKE container-native load balancing and with hybrid scenarios.
When a Professional Cloud Architect question mentions a load balancer in front of Cloud Run, App Engine, or Cloud Functions, the answer involves a serverless NEG. When the question describes routing to an on-premises system or an external endpoint behind a Google-managed load balancer, the answer is an internet NEG. When it describes container-native load balancing in GKE, you're looking at a NEG, not a basic instance group backend.
The mental model is simple. Cloud Load Balancing wants a uniform abstraction for "where to send traffic." NEGs are that abstraction for everything that isn't a Compute Engine instance group.
My Professional Cloud Architect course covers Network Endpoint Groups alongside the rest of the networking material.
