Cloud Load Balancing pricing

Load balancing and forwarding rules

The pricing tables in this section apply to the following load balancers:

• Internal and external passthrough Network Load Balancers
• Internal and external proxy Network Load Balancers
• Global, classic, and regional external Application Load Balancers

For regional and cross-region internal Application Load Balancers, see the Internal Application Load Balancer section.

For Private Service Connect forwarding rules, see the Private Service Connect section.

The following table shows the pricing for global forwarding rules. There are no global data processing charges. Data processing is charged by the region, depending on where the traffic is processed.

If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.

The following table shows regional forwarding rule charges and inbound and outbound data processing charges by region.

If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.

Ways to lower external Application Load Balancer costs

Global external Application Load Balancer users can use Google Cloud Armor, Cloud CDN, or both, to minimize the impact of Outbound data processing charges.

• Cloud CDN: Static objects that are served to the client from the cache do not transit through the load balancer. An effective caching strategy would reduce the amount of outbound data being processed by the load balancer and lower your costs. To implement caching, it is necessary to understand which portion of your traffic is static and cacheable. For additional information, refer the Cloud CDN documentation.

• Google Cloud Armor: If your application receives a significant amount of undesirable traffic, you can deploy Google Cloud Armor to block such traffic. Requests that are blocked by Google Cloud Armor do not transit through the load balancer, effectively reducing the amount of outbound data processed by the load balancer. The impact on your costs depends on the percentage of undesirable traffic blocked by the Google Cloud Armor security policies you've implemented.

If your application can operate in a single region or is required to operate in a single region, you can use the Regional external Application Load Balancer. The regional external Application Load Balancer uses only the Standard Network Tier which has lower outbound data transfer charges making it a cost effective option.

External Application Load Balancer pricing with Serverless NEGs

If you are using serverless NEG backends with an external Application Load Balancer (global, regional, or classic), existing load balancer charges will apply in addition to the serverless compute charges for Cloud Run, Cloud Run functions, or App Engine backends as applicable. If Google Cloud Armor or Cloud CDN are used, their respective charges also apply.

However, you will not be charged for serverless outbound data transfer. Only internet outbound data transfer rates apply. Cloud Run functions outbound data transfer charges, App Engine outgoing network traffic charges and Cloud Run data transfer charges do not apply to requests passed from an external Application Load Balancer (using serverless NEGs) to a Cloud Run functions, App Engine, or Cloud Run service.

Cross-project service referencing with Shared VPC

Review the following points to understand how projects and billing accounts are charged for networking SKUs when you use cross-project service referencing.

• Cloud Load Balancing related charges are always attributed to the project where the forwarding rule is configured (service project A in figure 1). This includes charges for forwarding rules, inbound data processed, and outbound data processed by the global external Application Load Balancer. Review Cloud Load Balancing pricing basics.
• Network internet data transfer out for Premium Tier and Standard Tier are always attributed to the project where the forwarding rule is configured (service project A in figure 1). Review Network data transfer pricing.
• If you configure Cloud CDN on a backend service that is referenced by a URL map using cross-project service referencing, then all Cloud CDN charges for cacheable content (cache data transfer out, cache lookup, cache fill) are always attributed to the project that contains the Cloud CDN-enabled backend service (service project B in figure 1), and not the project that configured the forwarding rules. Review Cloud CDN pricing.

• If you configure Google Cloud Armor on a backend service that is referenced by a URL map using cross-project service referencing, then all Google Cloud Armor related charges are attributed to the project that contains the Google Cloud Armor-enabled backend service (service project B in figure 1), and not the project that configured the forwarding rules. Review Google Cloud Armor pricing. Specifically, all Google Cloud Armor Standard Tier and Cloud Armor Enterprise Tier charges are attributed to service project B.

  The following additional considerations also apply when you're using Google Cloud Armor with cross-project service referencing:

  • Subscription changes related to Cloud Armor Enterprise are attributed to the billing account that you specified during enrollment. If you want to use the same Cloud Armor Enterprise subscription across multiple projects to include all the backend services referenced using cross-project service referencing, make sure that you include all the relevant service projects as part of the same Cloud Armor Enterprise billing account.
  • When you're using cross-project service referencing, some features offered in Cloud Armor Enterprise, such as DDoS telemetry and DDoS response, require Cloud Armor Enterprise tier enrollment for both the frontend forwarding rule project and the backend service projects.

Forwarding rules pricing examples

Google Cloud charges for forwarding rules whether they are created for load balancing or other uses, such as Packet Mirroring.

The following examples use US pricing:

You can create up to 5 forwarding rules for the price of $0.025/hour. For example, if you create one forwarding rule, you are charged $0.025/hour. If you have 3 forwarding rules, you are still charged $0.025/hour. However, if you have 10 forwarding rules, you are charged as follows:

• 5 forwarding rules = $0.025/hour
• Each additional forwarding rule = $0.01/hour

$0.025/hour for 5 rules + (5 additional rules * $0.01/hour) = $0.075/hour

For most load balancing use cases, you need only one forwarding rule per load balancer.

Google Cloud charges for global forwarding rules and regional forwarding rules separately, and also per project. For example, if you use one global forwarding and one regional forwarding rule in two separate projects (four rules total), you are charged $0.10/hour (4 x $0.025/hour).

Estimating load balancing charges

To estimate load balancing charges:

1. Go to the Pricing Calculator.
2. On the Cloud Load Balancing tab.
3. From the dropdown menu, select a region.
4. Enter your estimated number of forwarding rules.
5. Enter your monthly estimated amount of network traffic processed.

For example:

• Iowa
• Number of forwarding rules: 10
• Inbound data processed by load balancer: 2,048 GiB
• Total Estimated Cost: USD 71.13 per 1 month

This example doesn't include the internet data transfer out cost of sending replies from the backends.

Internal Application Load Balancer

The following charges apply to both regional internal Application Load Balancers and cross-region internal Application Load Balancers. Some additional cross-region data transfer charges also apply to the cross-region internal Application Load Balancer.

If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.

^* Internal Application Load Balancers use a fleet of managed proxy instances that are dynamically allocated to your network to handle traffic volume. The per proxy instance charge is determined based on the number of proxy instances required to handle your traffic over a specific time period.

Proxy instance charge

Envoy-based load balancers automatically scale the number of proxies available to handle your traffic based on your traffic needs. The proxy instance charge is based on the number of proxy instances needed to satisfy your traffic needs. Each additional proxy incurs an additional hourly charge according to the prices indicated in the pricing table.

The number of proxies allocated to your load balancer is calculated based on the measured capacity needed to handle your traffic over a 10-minute time period. During this time period, we look at the greater of:

• The number of proxies needed to serve your traffic's bandwidth needs. Each proxy instance can handle up to 18 MB per second. We monitor the total bandwidth required and divide that total by the bandwidth that a proxy instance can support.
• The number of proxies needed to handle connections and requests. We count the total of each of the following resources and divide each value by what a proxy instance can handle:
  • 600 (HTTP) or 150 (HTTPS) new connections per second
  • 3,000 active connections
  • 1,400 requests per second^*

^* A proxy instance can handle 1,400 requests per sec if Cloud Logging is disabled. If you enable Logging, your proxy instance can handle fewer requests per second. For example: logging 100% of requests decreases the proxy's request handling capacity to 700 requests per second. You can set Logging to sample a smaller percentage of traffic. This enables you to meet your observability needs while controlling your cost.

Example calculation

In a 10-minute period, 180 MB per second of data pass through the load balancer. 180 MB per second / 18 MB per second per proxy instance = 10 proxy instances

During this same period, 300 new HTTPS connections are established per second, 3,000 connections are active and 2,800 requests are sent per second:

300 new HTTPS connections per second / 150 new HTTPS connections per second per proxy instance = 2 proxy instances 3,000 active connections / 3,000 active connections per proxy instance = 1 proxy instance 2,800 requests per second / 1,400 requests per second per proxy instance = 2 proxy instances

This sums up to 5 proxy instances. This amount is lower than the 10 proxy instances required to serve bandwidth. Thus, the proxy instance charge for this 10-minute time period would be calculated as follows:

10 proxy instances * $0.025 per proxy instance per hour * (10 minutes / (60 minutes per hour)) = $0.0417

Billing is calculated based on the measured capacity needed to satisfy your traffic needs, not the number of proxy instances that are establishing connections to your backends. As such, you might be billed for a different number of proxy instances than you see in your infrastructure.

Minimum proxy instance charge

To ensure optimal performance and reliability, each load balancer is allocated at least three proxy instances in the Google Cloud region where the load balancer is deployed. These proxy instances are allocated even if the load balancer handles no traffic. After a forwarding rule (with load balancing scheme INTERNAL_MANAGED) is deployed to your project, you start to accrue proxy instance charges. Additional forwarding rules incur additional proxy instance charges as described previously (in other words, three additional proxy instances per forwarding rule).

The three proxy instances that are allocated to your load balancer result in a minimum hourly proxy instance charge. For example, for the us-central1 Google Cloud region, the minimum charge is calculated as follows:

3 proxy instances * $0.025 per proxy per hour = $0.075 per hour

As described previously, these proxy instances can each handle a certain amount of traffic. Once your traffic needs surpass the capacity of these three proxy instances, you will incur costs for the proxy instances required to handle any additional traffic.

Data processing charge

The data processing charge is calculated by measuring the total volume of data for requests and responses processed by your load balancer during the billing cycle. This charge scales according to your usage and there is no minimum charge for data processing.

Cross-region data transfer charges

Cross-region data transfer charges apply if you're using a cross-region internal Application Load Balancer. For example, if you have a cross-region internal Application Load Balancer deployment where the client, the Envoy proxy, and the backend are in separate regions, you'll see cross-region data transfer charges for each hop separately (client <-> Envoy proxy, and Envoy proxy <-> backend). To reduce these cross-region data transfer charges, you can deploy Envoy proxies in multiple regions.

Cross-project service referencing with Shared VPC

For data processing, hourly proxy instance usage, and inter-zone VM data transfer, the forwarding rule project is charged.

Internal Application Load Balancer pricing with serverless NEGs

If you are using serverless NEG backends for an internal Application Load Balancer, existing internal Application Load Balancer charges will apply in addition to the serverless compute charges for Cloud Run.

Regional internet NEG charges

Regional internet NEGs require the use of a Cloud NAT gateway which incurs additional charges. You'll be charged for both internet data transfer out and Cloud NAT usage for any traffic sent to and from the Envoy proxy-only subnet, and for health check traffic. However, the load balancer's charges apply only to user request traffic.

Cloud NAT gateways allocated for Cloud Load Balancing incur hourly charges equivalent to a network with more than 32 VM instances. For details, see Cloud NAT pricing

Authorization policy charges

Authorization policies are offered without usage fees for the duration of the Preview.

Custom request headers and Google Cloud Armor charges

If a backend service has a Google Cloud Armor policy associated with it, you can use the custom request headers feature with that backend service without any additional charge for the custom request headers feature.

If a backend service that uses the custom request headers feature does not have a Google Cloud Armor policy associated with it, the charges are $0.75 per 1,000,000 HTTP(S) requests per month per account. You are only charged for the first 666,666,667 requests per month per account.

Global access for internal load balancers

Global access allows client instances from any region to access your internal load balancer. If a forwarding rule has global access enabled, additional cross-region data transfer charges are incurred when traffic is sent to or from a client in a different region than the load balancer.

Global access is generally available for internal passthrough Network Load Balancers, regional internal Application Load Balancers, and regional internal proxy Network Load Balancers.

Protocol forwarding

Protocol forwarding is charged at the same rate as load balancing. There is a charge for the forwarding rule and a charge for the inbound data processed by the target instance.

SSL certificates

There is no charge for self-managed and Google-managed SSL certificates.

What's next

• Read the Cloud Load Balancing documentation.
• Try the Pricing calculator.