This sample demonstrates how to bring Apigee API Management capabilities to your services that currently use Google Cloud Load Balancing. We'll illustrate this integration using a gRPC backend deployed in Cloud Run. The core idea is that you can enhance your existing GCP Load Balancer services by adding a Service Extension, which enables the routing of gRPC (HTTP2) requests and responses through the Apigee Gateway runtime.
With this mechanism, you gain powerful control over your gRPC traffic. This works for both unary, and streaming gRPC services. You can easily add, remove, or modify headers the fly. More importantly, you can apply robust security and governance policies directly to your load-balanced gRPC services. This includes essential features like API Key validation for authentication and authorization, as well as quota enforcement to manage API consumption.
In essence, the Apigee Extension Processor lets you treat your gRPC services as fully managed APIs, leveraging Apigee's comprehensive suite of API management tools without requiring a complete re-architecture. For more information please read the docs on the Apigee Extension Processor and Cloud Load Balancing Service Extensions.
- Provision Apigee X
- Have access to deploy API Proxies in Apigee,
- Have access to create Environments and Environment Groups in Apigee
- Have access to create API Products, Developers, and Developer Apps in Apigee
- Have access to provision Load Balancer Resources (ip address, forwarding rule, url map, backend service, NEGs, etc)
- Have access to create Load Balancer Service Extensions
- Make sure the following tools are available in your terminal's $PATH (Cloud Shell has these preconfigured)
- gcloud SDK
- curl
- jq
Use the following GCP CloudShell tutorial, and follow the instructions in Cloud Shell. Alternatively, follow the instructions below.
-
Authenticate:
Ensure your active GCP account is selectedgcloud auth login
-
Navigate:
Change to the project directory.cd extension-processor-grpc -
Install grpcurl tool
./download-and-install-grpcurl.sh
Add it to your $PATH
export PATH="$HOME/.grpcurl/bin:${PATH}"
-
Configure and Source Environment:
Editenv.shwith your settings.Then, source it to apply the settings:
source ./env.sh
In this step, let's deploy a sample gRPC service to Cloud Run.
./1-create-grpc-service.shOnce the deployment is complete, it will print out the hostname for the gRPC service.
Export $CR_HOSTNAME variable that was output by the script.
export CR_HOSTNAME="..."Then, use the following commands to test it out:
export ID_TOKEN=$(gcloud auth print-identity-token)grpcurl -H "Authorization: Bearer ${ID_TOKEN}" \
${CR_HOSTNAME}:443 \
helloworld.Greeter.SayHelloYou can also try sending a request the CountTo RPC to test response streaming:
grpcurl -H "Authorization: Bearer ${ID_TOKEN}" \
-d '{"to":5}' \
${CR_HOSTNAME}:443 helloworld.Greeter.CountToIn this step, we will disable direct external access to the gRPC service, and instead expose it through a Load Balancer.
This will allow us to later apply Apigee API Management policies to this gRPC service (through a Service Extension).
The initial architecture will look like this:
So, let's create a new GCP External Global Load Balancer that uses a Serverless Network Endpoint Group (NEG) pointing to the gRPC service.
-
Run the script:
./2-create-load-balancer.sh
This script outputs the load balancer's hostname.
Export
$LB_HOSTNAMEvariable that was output by the script.export LB_HOSTNAME="..."
⏳ **Deployment takes about 15 minutes** (due to external certificate provisioning).
-
Test the gRPC service through the balancer:
Now, we are going to test the gRPC service again, but through the Load Balancer URL.
Execute the following grpcurl commands:
export ID_TOKEN=$(gcloud auth print-identity-token)
grpcurl -H "Authorization: Bearer ${ID_TOKEN}" \ ${LB_HOSTNAME}:443 \ helloworld.Greeter.SayHello
✅ You should see a success response.
⚠️ If you get a TLS error, wait 15 minutes and retry.ℹ️ Notice that you still needed to pass an
Authorizationheader with an ID token. This is because Global Load Balancer is simply passing through the calls to Cloud Run. That's fine for now. Later, once we add Apigee into the mix, the API Proxy itself will inject theAuthorizationheader.
Next, let's set up your Apigee Environment, API Proxy, and API Product by running the following scripts.
-
Create and Attach Environment:
Run the script to create an Apigee Environment (with the extension processor enabled) and attach it to a runtime instance:./3-create-environment.sh
Notice that the new environment has a special property
apigee-service-extension-enabledset.This tells the Apigee runtime that this is a special environment meant for use with Service Extensions.
-
Create and Deploy API Proxy:
Run the script to create an API proxy namedextproc-proxyand deploy it to the new environment:./4-create-api-proxy.sh
The API Proxy includes a Verify API Key policy. This means API calls will require a valid API Key.
The API Proxy also contains a policy that mints a Google Cloud Identity Token and injects the "Authorization" header for Cloud Run to use. -
Create API Product:
Run the script to create an API Product namedextproc-productthat includes theextproc-proxyAPI Proxy:./5-create-api-product.sh
Important: API traffic is not yet routed through Apigee. You will configure this routing in the next step.
Next, let's modify the External Global Load Balancer by adding a Service Extension to route traffic through the Apigee runtime.
The new architecture will look like this:
-
Add Service Extension:
Run the script:./6-create-service-extension.sh
Once the Service Extension is applied to the Load Balancer, it takes about a minute to take effect.
-
Test the Updated Load Balancer:
Run the grpcurl command:grpcurl ${LB_HOSTNAME}:443 helloworld.Greeter.SayHelloYou should see the request denied due to API Key validation fault.
✅ This confirms traffic is now routed through the Apigee runtime, and the
VA-VerifyAPIKeypolicy in theextproc-proxyAPI Proxy is triggering the fault.
In the next step, you will obtain an API Key and retry this request.
Finally, let's create an Apigee Developer App, extproc-app, and subscribe it to the extproc-product API Product.
Typically, API consumers create apps via a Developer Portal.
For this tutorial, instead, you'll create the app directly using the Apigee CLI.
-
Create the Developer App:
Run the following script:./7-create-developer-app.sh
The script will output the API Key for the new app.
Export the
$DEVELOPER_APP_KEYvariable that was output by the script:export DEVELOPER_APP_KEY="..."
-
Test the Service with the API Key:
Run the following command to send the request:
grpcurl -H "apikey: ${DEVELOPER_APP_API_KEY}" \ ${LB_HOSTNAME}:443 helloworld.Greeter.SayHello
You can also try sending a request the
CountToRPC to test response streaming:grpcurl -H "apikey: ${DEVELOPER_APP_API_KEY}" \ -d '{"to":5}' \ ${LB_HOSTNAME}:443 helloworld.Greeter.CountTo
🎉 If you see a success response, congrats, you've completed this tutorial!
Congratulations! You've successfully created a Google Cloud External Load Balancer and configured it to use the Apigee Extension Processor.
To clean up the artifacts created, source your env.sh script
source ./env.shThen, run the following scripts to clean up the resources created earlier.
./clean-service-extension.sh./clean-developer-app.sh./clean-api-product.sh./clean-api-proxy.sh./clean-environment.sh./clean-load-balancer.sh./clean-grpc-service.sh

