Understanding Network Endpoint Groups (NEGs) in Google Cloud Load Balancing

Introduction

Google Cloud Load Balancing is a powerful and flexible solution for distributing traffic across multiple backend instances. In this blog, we will explore Network Endpoint Groups (NEGs), their role in load balancing, and how we configured them in our recent lab experiment.

What are Network Endpoint Groups (NEGs)?

Network Endpoint Groups (NEGs) are a crucial component in Google Cloud that allow load balancers to route traffic to specific endpoints, such as Cloud Run services, Cloud Functions, or App Engine instances. Unlike traditional backend instance groups, NEGs enable granular traffic routing and better integration with serverless computing.

Types of NEGs:

1. Zonal NEGs – Used for VM instances with specific network interfaces.
2. Internet NEGs – Used for backend services hosted outside Google Cloud.
3. Serverless NEGs – Used for Cloud Run, App Engine, and Cloud Functions.

Why Use NEGs?

• Fine-grained traffic control: NEGs allow routing traffic to individual services rather than entire instance groups.
• Multi-region support: NEGs enable distribution of traffic across multiple regions for better availability.
• Serverless integration: They seamlessly integrate with Cloud Run, App Engine, and Cloud Functions.
• Optimized performance: Load balancing decisions can be made closer to the request origin, reducing latency.

Lab Exercise: Configuring a Load Balancer with NEGs

Objective

To create an external HTTP Load Balancer with serverless NEGs as backends for routing traffic to multiple Cloud Run services.

Steps Performed

1. Create Cloud Run Services

We deployed two Cloud Run services in different regions:

# Deploy service in us-central1

# Deploy service in asia-south1

2. Create Serverless NEGs

# Create NEG for us-central1

# Create NEG for asia-south1

3. Create Backend Services and Attach NEGs

# Create backend service for us-central1

# Create backend service for asia-south1

4. Create URL Map and HTTP Proxy

# Create URL map

# Create HTTP proxy

5. Create a Global Forwarding Rule

6. Test the Load Balancer

Once the setup was complete, we obtained the external IP of the forwarding rule and tested it using a browser or cURL command:

curl http://[EXTERNAL_IP]

Observations

• We observed that traffic was correctly distributed between the two Cloud Run services based on regional availability.
• The Load Balancer provided a single entry point for multiple backend services hosted in different regions.
• By using NEGs, we achieved a serverless, scalable, and efficient load-balancing solution.

Conclusion

NEGs provide a powerful mechanism to integrate Google Cloud Load Balancing with serverless and hybrid environments. Our lab experiment demonstrated how NEGs can be used to route traffic efficiently between multiple Cloud Run services deployed across different regions. By leveraging NEGs, organizations can optimize performance, improve availability, and achieve a seamless user experience.

Next Steps

• Explore additional routing configurations using URL maps.
• Implement health checks for backend services.
• Enable logging and monitoring

About CloudThat