Setting up Internal HTTP(S) Load Balancing has two phases:
- Performing prerequisite tasks, such as ensuring that required accounts have the correct permissions and preparing the VPC network
- Setting up the load balancer resources
This guide describes how to set up the prerequisites. Additional guides describe how to set up the load balancing resources.
Before following this guide, familiarize yourself with the following:
Permissions
To follow this guide, you must be able to create instances and modify a network in a project. You must be either a project owner or editor, or you must have all of the following Compute Engine IAM roles:
Task | Required Role |
---|---|
Create networks, subnets, and load balancer components | Network Admin |
Add and remove firewall rules | Security Admin |
Create instances | Instance Admin |
Setup overview
You can configure Internal HTTP(S) Load Balancing as described in the following high-level configuration flow. The numbered steps refer to the numbers in the diagram.
As shown in the diagram, this example creates an internal HTTP(S) load
balancer in a VPC network in region us-west1
, with
one backend service and two backend groups.
The diagram shows:
A VPC network with two subnets:
One subnet is used for backends (instance groups and NEGs) and the forwarding rule. Its primary IP address range is
10.1.2.0/24
.One subnet is a proxy-only subnet in the
us-west1
region. You must create one proxy-only subnet in each region of a VPC network where you use internal HTTP(S) load balancers. The region's proxy-only subnet is shared among all internal HTTP(S) load balancers in the region. Source addresses of packets sent from the internal HTTP(S) load balancer to your service's backends are allocated from the proxy-only subnet. In this example, the proxy-only subnet for the region has a primary IP address range of10.129.0.0/26
. For more information, refer to Proxy-only subnets for internal HTTP(S) load balancers.
Firewall rules that permit desired traffic flows in your network. This includes adding one rule that allows TCP port 80, 443, and 8000 traffic from 10.129.0.0/26 (the range of the proxy-only subnet in this example) and another rule for the health check probes.
Backend instances. This example demonstrates the following backend deployments:
Instance groups and NEGs:
- Managed or unmanaged instance groups for Compute Engine VM deployments
- NEGs for GKE deployments
In each zone, you can have combination of backend group types based on the requirements of your deployment.
A regional health check that reports the readiness of your backends.
A regional backend service that monitors the usage and health of backends.
A regional URL map that parses the URL of a request and forwards requests to specific backend services based on the host and path of the request URL.
A regional target HTTP or HTTPS proxy, which receives a request from the user and forwards it to the URL map. For HTTPS, configure a regional SSL certificate resource. The target proxy decrypts SSL traffic using the SSL certificate if you configure HTTPS load balancing. The target proxy can forward traffic to your instances via HTTP or HTTPS.
A forwarding rule, which has the internal IP address of your load balancer, to forward each incoming request to the target proxy.
Configuring the network and subnets
You need a VPC network with two subnets: one for the load balancer's backends and the other for load balancer's proxies. An internal HTTP(S) load balancer is regional. Traffic within the VPC network is routed to the load balancer if the traffic's source is in a subnet in the same region as the load balancer.
This example uses the following VPC network, region, and subnets:
Network: The network is a custom-mode VPC network named
lb-network
.Subnet for backends: A subnet named
backend-subnet
in theus-west1
region uses10.1.2.0/24
for its primary IP range.Subnet for proxies: A subnet named
proxy-only-subnet
in theus-west1
region uses10.129.0.0/26
for its primary IP range.
Configuring the network and subnet for backends
Console
- Go to the VPC networks page in the Google Cloud Console.
Go to the VPC network page - Click Create VPC network.
- For the Name, enter
lb-network
. - In the Subnets section:
- Set the Subnet creation mode to Custom.
- In the New subnet section, enter the following information:
- Name:
backend-subnet
- Region:
us-west1
- IP address range:
10.1.2.0/24
- Click Done.
- Name:
- Click Create.
gcloud
Create the custom VPC network with the gcloud compute networks create command:
gcloud compute networks create lb-network --subnet-mode=custom
Create a subnet in the
lb-network
network in theus-west1
region with the gcloud compute networks subnets create command:gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
api
Make a POST
request to the
networks.insert
method,
replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/networks
{
"routingConfig": {
"routingMode": "REGIONAL"
},
"name": "lb-network",
"autoCreateSubnetworks": false
}
Make a POST
request to the
subnetworks.insert
method,
replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/subnetworks
{
"name": "backend-subnet",
"network": "projects/[project-id]/global/networks/lb-network",
"ipCidrRange": "10.1.2.0/24",
"region": "projects/[project-id]/regions/us-west1",
}
Configuring the proxy-only subnet
The proxy-only subnet is for all internal HTTP(S) load balancers in the
us-west1
region.
console
If you're using the GCP Console, you can wait and create the proxy-only subnet later in the Load Balancing UI. See Continuing the setup process.
gcloud
Create the proxy-only subnet with the gcloud compute networks subnets create command.
gcloud compute networks subnets create proxy-only-subnet \ --purpose=INTERNAL_HTTPS_LOAD_BALANCER \ --role=ACTIVE \ --region=us-west1 \ --network=lb-network \ --range=10.129.0.0/26
api
Create the proxy-only subnet with the
subnetworks.insert
method, replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/projects/[project-id]/regions/us-west1/subnetworks
{
"name": "proxy-only-subnet",
"ipCidrRange": "10.129.0.0/26",
"network": "projects/[project-id]/global/networks/lb-network",
"region": "projects/[project-id]/regions/us-west1",
"purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
"role": "ACTIVE"
}
Configuring firewall rules
This example uses the following firewall rules:
fw-allow-backend-subnet
: An ingress rule, applicable to all targets in the VPC network, allowing all TCP, UDP, and ICMP traffic from sources in the10.1.2.0/24
range. This rules allows incoming traffic from any source within thebackend-subnet
to the instances (VMs) being load balanced. The example shows the firewall rule applied to all instances in the network. Alternatively, you can apply the rule only to the actual backends of the load balancer.fw-allow-ssh
: An ingress rule, applicable to the instances being load balanced, that allows incoming SSH connectivity on TCP port 22 from any address. You can choose a more restrictive source IP range for this rule; for example, you can specify just the IP ranges of the system from which you initiate SSH sessions. This example uses the target tagallow-ssh
to identify the VMs to which the firewall rule applies.fw-allow-health-check
: An ingress rule, applicable to the instances being load balanced, that allows all TCP traffic from the Google Cloud health checking systems (in130.211.0.0/22
and35.191.0.0/16
). This example uses the target tagload-balanced-backend
to identify the instances to which it should apply.fw-allow-proxies
: An ingress rule, applicable to the instances being load balanced, that allows TCP traffic on ports80
,443
, and8000
from the internal HTTP(S) load balancer's managed proxies. This example uses the target tagload-balanced-backend
to identify the instances to which it should apply.
Without these firewall rules, the default deny ingress rule blocks incoming traffic to the backend instances.
Console
- Go to the Firewall rules page in the Google Cloud Console.
Go to the Firewall rules page - Click Create firewall rule and enter the following
information to create the rule to allow subnet traffic:
- Name:
fw-allow-backend-subnet
- Network:
lb-network
- Direction of traffic: ingress
- Action on match: allow
- Targets: All instances in the network
- Source filter:
IP ranges
- Source IP ranges:
10.1.2.0/24
- Protocols and ports:
- Choose Specified protocols and ports.
- Check
tcp
andudp
. - Under Other protocols, enter
icmp
.
- Name:
- Click Create.
- Click Create firewall rule again to create the rule to allow incoming
SSH connections:
- Name:
fw-allow-ssh
- Network:
lb-network
- Direction of traffic: ingress
- Action on match: allow
- Targets: Specified target tags
- Target tags:
allow-ssh
- Source filter:
IP ranges
- Source IP ranges:
0.0.0.0/0
- Protocols and ports:
- Choose Specified protocols and ports.
- Check
tcp
and type22
for the port number.
- Name:
- Click Create.
- Click Create firewall rule a third time to create the rule to allow
Google Cloud health checks:
- Name:
fw-allow-health-check
- Network:
lb-network
- Direction of traffic: ingress
- Action on match: allow
- Targets: Specified target tags
- Target tags:
load-balanced-backend
- Source filter:
IP ranges
- Source IP ranges:
130.211.0.0/22
and35.191.0.0/16
- Protocols and ports:
- Choose Specified protocols and ports
- Check
tcp
and enter80
. As a best practice, limit this rule to just the protocols and ports that match those used by your health check. If you usetcp:80
for the protocol and port, Google Cloud can contact your VMs using HTTP on port 80, but it cannot contact them using HTTPS on port 443.
- Name:
- Click Create.
- Click Create firewall rule a fourth time to create the rule to allow
the load balancer's proxy servers to connect the backends:
- Name:
fw-allow-proxies
- Network:
lb-network
- Direction of traffic: ingress
- Action on match: allow
- Targets: Specified target tags
- Target tags:
load-balanced-backend
- Source filter:
IP ranges
- Source IP ranges:
10.129.0.0/26
- Protocols and ports:
- Choose Specified protocols and ports.
- Check
tcp
and type80, 443, 8000
for the port numbers.
- Name:
- Click Create.
gcloud
Create the
fw-allow-backend-subnet
firewall rule to allow communication from within the subnet with the gcloud compute firewall-rules create command.gcloud compute firewall-rules create fw-allow-backend-subnet \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.1.2.0/24 \ --rules=tcp,udp,icmp
Create the
fw-allow-ssh
firewall rule to allow SSH connectivity to VMs with the network tagallow-ssh
. When you omitsource-ranges
, Google Cloud interprets the rule to mean any source.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Create the
fw-allow-health-check
rule to allow Google Cloud health checks. This example allows all TCP traffic from health check probers; however, you can configure a narrower set of ports to meet your needs.gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
Create the
fw-allow-proxies
rule to allow the internal HTTP(S) load balancer's proxies to connect to your backends.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/26 \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8000
api
Create the fw-allow-backend-subnet
firewall rule by making a POST
request to
the firewalls.insert
method, replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
"name": "fw-allow-backend-subnet",
"network": "projects/[project-id]/global/networks/lb-network",
"sourceRanges": [
"10.1.2.0/24"
],
"allowed": [
{
"IPProtocol": "tcp"
},
{
"IPProtocol": "udp"
},
{
"IPProtocol": "icmp"
}
],
"direction": "INGRESS"
}
Create the fw-allow-ssh
firewall rule by making a POST
request to
the firewalls.insert
method, replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
"name": "fw-allow-ssh",
"network": "projects/[project-id]/global/networks/lb-network",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS"
}
Create the fw-allow-health-check
firewall rule by making a POST
request to
the firewalls.insert
method, replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
"name": "fw-allow-health-check",
"network": "projects/[project-id]/global/networks/lb-network",
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp"
}
],
"direction": "INGRESS"
}
Create the fw-allow-proxies
firewall rule to allow TCP traffic within the
proxy subnet the
firewalls.insert
method, replacing [project-id] with your project ID.
POST https://www.googleapis.com/compute/v1/projects/{project}/global/firewalls
{
"name": "fw-allow-proxies",
"network": "projects/[project-id]/global/networks/lb-network",
"sourceRanges": [
"10.129.0.0/26"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"80"
]
},
{
"IPProtocol": "tcp",
"ports": [
"443"
]
},
{
"IPProtocol": "tcp",
"ports": [
"8000"
]
}
],
"direction": "INGRESS"
}
Continuing the setup process
To set up Internal HTTP(S) Load Balancing, use one of the following procedures, depending on whether your backend services run on Compute Engine VMs or GKE pods:
- Setting Up Internal HTTP(S) Load Balancing for Compute Engine VMs
- Setting Up Internal HTTP(S) Load Balancing for GKE pods
What's next
- See Internal HTTP(S) Load Balancing Concepts for information on how Internal HTTP(S) Load Balancing works.
- See Proxy-only subnet for internal HTTP(S) load balancers for information on managing the proxy-only subnet resource required by Internal HTTP(S) Load Balancing.