Internal passthrough Network Load Balancer and Service Directory overview
Stay organized with collections
Save and categorize content based on your preferences.
You can choose to automatically register your internal load balancer service
with Service Directory when you create an internal load balancer. This enables client
applications to use Service Directory through HTTP, gRPC, or DNS to resolve
the address of the internal load balancer service and connect to it directly.
Registering your internal load balancer with Service Directory lets you do the
following:
Choose custom DNS names to serve the network locations of your
internal load balancers as opposed to DNS accessing your internal load
balancer only through an internally generated DNS name in the
.internal domain.
Serve multiple internal load balancers from the same DNS domain name,
which is otherwise not possible with the current auto-generated DNS records.
Register internal load balancers directly and automatically in
Service Directory providing a single repository for all your services
in Google Cloud.
See standalone services, endpoints, and your internal load
balancer endpoints with a single command in the Service Directory API.
Apply administrative actions like access control to Service Directory
resources at the namespace or service level to encompass both your internal
load balancer endpoints as well as other backend services.
Register an internal passthrough Network Load Balancer with Service Directory
To register an internal passthrough Network Load Balancer, run the gcloud compute forwarding-rules
create command and
set the service-directory-registration flag:
FORWARDING_RULE_NAME: a name for the forwarding rule
that you want to create
REGION: the region to create the forwarding rule in
NETWORK_NAME: the network that this forwarding rule applies
to
SUBNET_NAME: the subnetwork that this forwarding rule
applies to
RESERVED_IP_ADDRESS: the IP address that the forwarding
rule serves
PROTOCOL_TYPE: the IP protocol that the rule will serve
PORT_NUMBER: a list of comma-separated ports
BACKEND_SERVICE_NAME: target backend service that
receives the traffic
SD_SERVICE_NAME: the fully qualified name of the
Service Directory service where you want to register the endpoint. It must
live in the same project and region as the forwarding rule being created.
For example:
projects/PROJECT/locations/REGION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME.
To learn about limitations of Service Directory integration with
internal passthrough Network Load Balancer and how to verify the endpoint, see
Register an internal load balancer.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Internal passthrough Network Load Balancer and Service Directory overview\n\nYou can choose to automatically register your internal load balancer service\nwith Service Directory when you create an internal load balancer. This enables client\napplications to use Service Directory through HTTP, gRPC, or DNS to resolve\nthe address of the internal load balancer service and connect to it directly.\n\nRegistering your internal load balancer with Service Directory lets you do the\nfollowing:\n\n- Choose custom DNS names to serve the network locations of your internal load balancers as opposed to DNS accessing your internal load balancer only through an internally generated DNS name in the `.internal` domain.\n- Serve multiple internal load balancers from the same DNS domain name, which is otherwise not possible with the current auto-generated DNS records.\n- Register internal load balancers directly and automatically in Service Directory providing a single repository for all your services in Google Cloud.\n- See standalone services, endpoints, and your internal load balancer endpoints with a single command in the Service Directory API.\n- Apply administrative actions like access control to Service Directory resources at the namespace or service level to encompass both your internal load balancer endpoints as well as other backend services.\n\n| **Note:** Cross-region internal Application Load Balancers don't support Service Directory registrations.\n\nRegister an internal passthrough Network Load Balancer with Service Directory\n-----------------------------------------------------------------------------\n\nTo register an internal passthrough Network Load Balancer, run the [`gcloud compute forwarding-rules\ncreate`](/sdk/gcloud/reference/compute/forwarding-rules/create) command and\nset the `service-directory-registration` flag: \n\n```\ngcloud compute forwarding-rules create FORWARDING_RULE_NAME \\\n --region=REGION \\\n --load-balancing-scheme=INTERNAL \\\n --network=NETWORK_NAME \\\n --subnet=SUBNET_NAME \\\n --address=RESERVED_IP_ADDRESS \\\n --ip-protocol=PROTOCOL_TYPE \\\n --ports=PORT_NUMBER \\\n --backend-service=BACKEND_SERVICE_NAME \\\n --backend-service-region=REGION \\\n --service-directory-registration=SD_SERVICE_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eFORWARDING_RULE_NAME\u003c/var\u003e: a name for the forwarding rule that you want to create\n- \u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e: the region to create the forwarding rule in\n- \u003cvar translate=\"no\"\u003eNETWORK_NAME\u003c/var\u003e: the network that this forwarding rule applies to\n- \u003cvar translate=\"no\"\u003eSUBNET_NAME\u003c/var\u003e: the subnetwork that this forwarding rule applies to\n- \u003cvar translate=\"no\"\u003eRESERVED_IP_ADDRESS\u003c/var\u003e: the IP address that the forwarding rule serves\n- \u003cvar translate=\"no\"\u003ePROTOCOL_TYPE\u003c/var\u003e: the IP protocol that the rule will serve\n- \u003cvar translate=\"no\"\u003ePORT_NUMBER\u003c/var\u003e: a list of comma-separated ports\n- \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e: target backend service that receives the traffic\n- \u003cvar translate=\"no\"\u003eSD_SERVICE_NAME\u003c/var\u003e: the fully qualified name of the Service Directory service where you want to register the endpoint. It must live in the same project and region as the forwarding rule being created. For example: projects/\u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e/locations/\u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e/namespaces/\u003cvar translate=\"no\"\u003eNAMESPACE_NAME\u003c/var\u003e/services/\u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e.\n\nWhat's next\n-----------\n\n- To learn more about Service Directory, see [Service Directory\n overview](/service-directory/docs/overview).\n- To learn about limitations of Service Directory integration with internal passthrough Network Load Balancer and how to verify the endpoint, see [Register an internal load balancer](/service-directory/docs/configuring-ilb-in-sd).\n- To troubleshoot next hop issues with your internal passthrough Network Load Balancer, see [Troubleshoot load balancer as next hop issues](/load-balancing/docs/internal/troubleshooting-ilb#lb-as-next-hop)."]]