All networking pricing

This page describes pricing for networking products.

Virtual Private Cloud

The following prices are applied both during and after the Google Cloud Free Trial period. During the Free Trial period, these prices are charged against the Free Trial credit amount.

General network pricing information

Data transfer

Data transfer can be traffic coming into a Google Cloud resource (e.g. VM), leaving Google Cloud region out into the internet, or in between two resources within Google Cloud.

A region is a set of buildings operated by Google in a geographic location, such as a data center campus. Traffic can travel as follows:

• Within the set of buildings at the location, which always used Google's network (intra-zone and intra-region pricing)
• To another building operated by Google in another location, which always used Google's network (inter-region pricing)
• To a location not operated by Google over a Cloud Interconnect connection (Cloud Interconnect pricing)
• To a location not operated by Google not over a Cloud Interconnect connection (internet data transfer out pricing)

Premium Tier

The Network Service Tiers Premium Tier leverages Google's premium backbone to carry traffic to and from your external users. The public internet is usually only used between the user and the closest Google network ingress point.

Standard Tier

The Network Service Tiers Standard Tier leverages the public internet to carry traffic between your services and your users. While using the public internet provides a lower quality of service, it is more economical than Premium Tier.

Inbound data transfer pricing

VM-VM data transfer pricing within Google Cloud

The following prices are applied both during and after the Google Cloud Free Trial period. During the Free Trial period, these prices are charged against the Free Trial credit amount.

Inter-zone data transfer

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

Inter-region data transfer

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

VM-to-Google service

The following prices are applied both during and after the Google Cloud Free Trial period. During the Free Trial period, these prices are charged against the Free Trial credit amount.

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

Internet data transfer rates

Premium Tier pricing

Premium Tier is the default tier for all Google Cloud data transfer. To use Standard Tier, you must specify it explicitly.

The following prices are applied both during and after the Google Cloud Free Trial period. During the Free Trial period, these prices are charged against the Free Trial credit amount.

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

Standard Tier pricing

Data transfer out pricing is per GiB delivered. Pricing is based on source geolocation of traffic. Ingress pricing is still free. Always Free usage limits do not apply to Standard Tier.

Contact sales for pricing beyond 500 TiB.

Internal IP address pricing

There is no charge for static or ephemeral internal IP addresses.

External IP address pricing

You are charged for static and ephemeral external IP addresses according to the following table.

If you reserve a static external IP address and do not assign it to a resource such as a VM instance or a forwarding rule, you are charged at a higher rate than for static and ephemeral external IP addresses that are in use.

You are not charged for static external IP addresses that are assigned to forwarding rules.

You are not charged for external IPv6 address ranges that are assigned to subnets or for external IPv6 addresses that are assigned to VM instances. You are not charged for static regional IPv6 addresses (Preview).

In use or not

Google Cloud considers a static external IP address as in use if it is associated with a VM instance whether the instance is running or stopped. If the instance is deleted or if the IP address is dissociated from the instance, Google Cloud considers the static IP address as not in use.

For an ephemeral IP address, Google Cloud considers the address as in use only when the associated VM instance is running. When the instance is stopped or deleted, Google Cloud releases the ephemeral IP address and no longer considers it as in use.

You can check whether a static external IP address is in use by making a gcloud compute addresses list request. This command returns a list of static external IP addresses and their statuses:

gcloud compute addresses list

NAME          REGION  ADDRESS        STATUS
address-1             130.211.8.68   IN_USE
address-2             35.186.217.84  RESERVED

In this example, IPv4 address-1 is in use while IPv4 address-2 is reserved but not being used. Both addresses are charged according to the External IP address pricing table in this document.

Firewall rules

For Cloud Next Generation Firewall pricing, see the Cloud NGFW pricing page.

Private Service Connect

The costs associated with Private Service Connect vary depending on the configuration.

Consumer charges

Using a Private Service Connect endpoint (forwarding rule) to access Google APIs

Using a Private Service Connect backend (load balancer) to access Google APIs

Private Service Connect backends use a load balancer to access Google APIs. All load balancer pricing applies. Traffic to Private Service Connect NEGs that is directed to Google APIs incurs load balancing charges for data processed by load balancer. However, there is no Private Service Connect charge for data transfer traffic between the Private Service Connect NEG and Google APIs.

For pricing information for your load balancer, see pricing for global external Application Load Balancers or internal Application Load Balancers.

Using a Private Service Connect endpoint (forwarding rule) to access a published service

Private Service Connect automatically creates a Service Directory namespace to register endpoints in. A single default namespace is used for endpoints in the same region of a project unless you explicitly create additional namespaces. For more information about Service Directory pricing, see Service Directory pricing.

Using a Private Service Connect backend (load balancer) to access a published service

Private Service Connect backends use a load balancer to access published services. All load balancer pricing applies. Traffic between Private Service Connect NEGs and Private Service Connect published services incurs both load balancing charges for data processed by load balancer and Private Service Connect charges data transfer traffic between the NEG and the published service.

The following table summarizes the applicable charges for this configuration.

Using a Private Service Connect interface for access to a producer or consumer VPC network

Service Directory

Consumer data processing

Private Service Connect consumers are charged consumer data processing according to the following table. Consumer data processing is charged inbound and outbound.

Producer charges

Charges to publish a managed service by using a Private Service Connect service attachment

There are no Private Service Connect hourly or data transfer charges for publishing services through service attachments. Producers are charged for any load balancing charges incurred on the load balancer that is published to consumers.

Deploying a service by using service connection maps

When you deploy a service by using service connection maps, there are no producer charges for the deployment of service connection maps themselves. However, the consumer is charged for the following:

• Resources that are deployed into the consumer project through service connectivity automation
• Using a Private Service Connect endpoint to access a published service

Private services access

When you create a private services access connection, there are no hourly or data charges for the connection itself. However, you are charged for the following:

• Resources that you provision in the service producer's network
• Data transfer traffic from your VMs to the service producer's network

Serverless VPC Access

Network telemetry

Network Vended Logs generate charges. You are charged for the following products:

• VPC Flow Logs
• Firewall Rules Logging
• Cloud NAT logging

Packet Mirroring

You are charged for the amount of data processed by Packet Mirroring. You are not charged for Packet Mirroring forwarding rules. Currently, there is no additional per-VM charge for using Packet Mirroring. The costs for the data processed by Packet Mirroring are described in the following table.

Normal data transfer rates are charged for traffic outbound from a load balancer. There is no additional load balancer data transfer cost beyond normal data transfer out rates.

Cloud Load Balancing

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 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.

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

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.

^* 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:

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:

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:

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.

Google Cloud Armor

This document explains Google Cloud Armor and Google Cloud Armor Enterprise pricing details. This pricing is active.

Protected resources include the following backend types in each enrolled project; the backends are counted as protected resources for all covered endpoint and load balancer types in the enrolled project.

Data processing fee

The Cloud Armor Enterprise data processing fee meters the data transferred to the internet from all protected resources for every project that is enrolled in Cloud Armor Enterprise. When you use Cloud Armor Enterprise Annual, the data processing fee is billed at the project level, but usage is aggregated across all protected resources in all projects enrolled in Cloud Armor Enterprise Annual. When you use Cloud Armor Enterprise Paygo, the data processing fee is billed and usage is aggregated at the project level. The Cloud Armor Enterprise data processing fee is separate from the Cloud Load Balancing data processing fee.

Prices are per GiB transferred to the internet directly or through Carrier Peering, and are in addition to other data transfer fees. For example, for workloads behind a supported Google Cloud load balancer, the data processing fee meters the bits data transferred to the internet through the enrolled load balancer endpoints but does not meter the associated inter-region or inter-zone traffic by the underlying workload. The charge is $0.05 per GiB data transferred for the first 100 TiB and $0.04 per GiB for the next 400 TiB. If the content being served is using Cloud CDN and is considered cacheable, then the data processing fee for Cloud CDN is applied for that content. The following table contains complete pricing.

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

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

Cloud Intrusion Detection System

This document explains Cloud IDS pricing details. This pricing is active. Prices on this page are listed in US dollars (USD).

Cloud CDN

This document discusses pricing for Cloud CDN.

Prices on this page are listed in US dollars (USD). If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.

Pricing structure

Overview

Cache data transfer out and cache fill are calculated in gibibytes (GiB).

Pricing calculator

You can use the Google Cloud Pricing Calculator to estimate the cost of using Cloud CDN.

Cache data transfer out

Cache data transfer out charges represent cached responses served from Cloud CDN's caches, and vary based on the destination and your monthly usage. Monthly usage is calculated per project per destination. Destination is a geographic area that's determined by where traffic leaves the Google network.

Cache fill

Monthly cache fill charges represent the data required to populate Cloud CDN's caches. For typical workloads where you are serving popular content, cache fill is often less than 10% of your total data transfer GiB. Charges vary based on the source and destination, where the source is the region of your backend service, or for external backends, the geographic area based on your origin's IP address.

Pricing notes

• Network usage is calculated in gibibytes (GiB).
• Charges accrue daily, but Cloud CDN bills you only at the end of the billing period. You can view unbilled usage on your project's billing page in the Google Cloud console.
• The metered bytes for cache data transfer out or cache fill include HTTP response headers (after compression, if applicable) and the response body, as well as any trailers.

Pricing example

The following example shows a simple scenario that might apply if you are just getting started with Cloud CDN.

Suppose you have the following Cloud CDN usage pattern in a given month.

Your bill for the month is calculated as follows.

Cloud Interconnect

This document explains Cloud Interconnect pricing details.

Dedicated Interconnect

Google charges you on an hourly basis for both Cloud Interconnect connections and VLAN attachments. The hourly charge for each resource, either Cloud Interconnect connection or VLAN attachment, is charged to the project that owns the resource.

Data transfer from your Virtual Private Cloud (VPC) networks through your Cloud Interconnect connections is discounted compared to general network pricing for Google Cloud. Data transfer out pricing depends on the number of gibibytes (GiB) transferred and the location of your Cloud Interconnect connection.

This discounted pricing applies only to traffic that originates in the region where the VLAN attachment is located. You can use VLAN attachments to access services located in a different region than the VLAN attachment. In this case, you are charged standard cross-region rates for traffic between the region where the VLAN attachment is located and the region where the service is located.

Cloud Interconnect data transfer out charges accrue to the project that owns the VLAN attachment. The project that owns the Cloud Interconnect connection is not billed for the data transfer. Specifically, costs for data transfer from a VLAN attachment in a Shared VPC service project, which travels through a Cloud Interconnect connection in a different host project, are attributed to the service project.

For HA VPN over Cloud Interconnect deployments, you are charged for your Dedicated Interconnect connections, VLAN attachments, HA VPN tunnels, and regional external IP addresses, if an IP address is assigned to a VPN gateway but not used by a tunnel.

In terms of HA VPN over Cloud Interconnect data transfer, you are charged only for Cloud Interconnect data transfer out. You are not charged for Cloud VPN data transfer.

For more information, see Cloud VPN pricing.

Pricing tables

Dedicated Interconnect pricing

Data transfer from a VPC network through a Cloud Interconnect connection

North America

Europe, Middle East, and Africa (EMEAR)

Asia

Australia

South America

Inbound data transfer through a Cloud Interconnect connection

Pricing example

The following table shows an example usage pattern of Dedicated Interconnect connections for a single month.

Partner Interconnect

Google charges you on an hourly basis for VLAN attachments, depending on their capacity. The hourly charges are billed to the project that owns the VLAN attachment. Your service provider might also charge you for services such as using their network, which isn't included in your Google Cloud bills. For information about their pricing, contact your service provider.

Data transfer from your VPC networks though your attachments is discounted compared to general network pricing for Google Cloud. Outbound data transfer pricing depends on the number of gibibytes (GiB) transferred and the location of your Cloud Interconnect connection.

This discounted pricing applies only to traffic that originates in the region where the VLAN attachment is located. You can use VLAN attachments to access services located in a different region than the VLAN attachment. In this case, you are charged standard cross-region rates for traffic between the region where the VLAN attachment is located and the region where the service is located.

Cloud Interconnect data transfer out charges accrue to the project that owns the VLAN attachment. The project that owns the Cloud Interconnect connection is not billed for data transfer. Specifically, costs for data transfer traffic from a VLAN attachment in a Shared VPC service project, which travels through a Cloud Interconnect connection in a different host project, are attributed to the service project.

For HA VPN over Cloud Interconnect deployments, you are charged for your VLAN attachments, HA VPN tunnels, and regional external IP addresses, if an address is assigned to a VPN gateway but not used by a tunnel.

In terms of HA VPN over Cloud Interconnect data transfer, you are charged only for Cloud Interconnect outbound data transfer. You are not charged for Cloud VPN data transfer.

For more information, see Cloud VPN pricing.

Pricing tables

Partner Interconnect pricing

Data transfer from a VPC network through a Cloud Interconnect connection

North America

Europe, Middle East, and Africa (EMEAR)

Asia

Australia

South America

Inbound data transfer through a Cloud Interconnect connection

Pricing example

The following table shows an example usage pattern of Partner Interconnect connections for a single month.

Cross-Cloud Interconnect

Google charges you on an hourly basis for both Cross-Cloud Interconnect connections and VLAN attachments. The hourly charge for each resource, either Cross-Cloud Interconnect connection or VLAN attachment, is charged to the project that owns the resource.

Data transfer from your Virtual Private Cloud (VPC) networks through your Cross-Cloud Interconnect connections is discounted compared to general network pricing for Google Cloud. Data transfer pricing depends on the number of gibibytes (GiB) transferred and the location of your Cross-Cloud Interconnect connection.

This discounted pricing applies only to traffic that originates in the region where the VLAN attachment is located. You can use VLAN attachments to access services located in a different region than the VLAN attachment. In this case, you are charged standard cross-region rates for traffic between the region where the VLAN attachment is located and the region where the service is located.

Cross-Cloud Interconnect data transfer out charges accrue to the project that owns the VLAN attachment. The project that owns the Cloud Interconnect connection is not billed for data transfer. Specifically, costs for data transfer from a VLAN attachment in a Shared VPC service project, which travels through a Cloud Interconnect connection in a different host project, are attributed to the service project.

For HA VPN over Cloud Interconnect deployments, you are charged for your Cross-Cloud Interconnect connections, VLAN attachments, HA VPN tunnels, and regional external IP addresses, if an IP address is assigned to a VPN gateway but not used by a tunnel.

In terms of HA VPN over Cloud Interconnect data transfer out, you are charged only for Cloud Interconnect data transfer. You are not charged for Cloud VPN data transfer.

For more information, see Cloud VPN pricing.

Pricing tables

Cross-Cloud Interconnect pricing

Data transfer from a VPC network through a Cloud Interconnect connection

North America

Europe, Middle East, and Africa (EMEAR)

Asia

Australia

South America

Inbound data transfer through a Cloud Interconnect connection

Pricing example

The following table shows an example usage pattern of Cross-Cloud Interconnect connections for a single month.

Pricing scenarios

This section describes different pricing scenarios for how Google Cloud calculates pricing for Cloud Interconnect outbound data transfer; that is, when a virtual machine (VM) instance or a non-VM Google Cloud product or service sends traffic to your on-premises location over a VLAN attachment located in the same or different geographical location:

• A VM in the same region as a VLAN attachment, using either regional or global VPC dynamic routing
• A VM in the same continent but different region than a VLAN attachment, using global VPC dynamic routing
• A VM in a different continent than a VLAN attachment, using global VPC dynamic routing
• A VM in a different continent than a VLAN attachment, using VPC Network Peering
• A non-VM Google Cloud product or service in a different location than a VLAN attachment, using global VPC dynamic routing

For more information about costs for each scenario, including data transfer charges between regions within a continent and between continents, see General network pricing.

A VM in the same region as a VLAN attachment, using either regional or global VPC dynamic routing

In this scenario, there are two regions within North America, us-west1 and us-east1. These regions use VPC regional dynamic routing provided by Cloud Router. In this scenario, it doesn't matter which dynamic routing mode you use.

You order a Cloud Interconnect connection running from your on-premises location to San Jose (SJC) and create two VLAN attachments over that connection. One VLAN attachment goes to region us-east1, and the other VLAN attachment goes to region us-west1.

If you send traffic from a VM in us-east1 or from a VM in us-west1 to your on-premises location over your Cloud Interconnect connection in SJC, you are charged the following rates:

• Cloud Interconnect data transfer out charges for North America (because that is where the Cloud Interconnect connection is located).
• You are not charged region-to-region data transfer charges because the VMs are using a VLAN attachment in the same region.

A VM in the same continent but different region than a VLAN attachment, using global VPC dynamic routing

In this scenario, you have VMs in two regions located in North America, us-west1 and us-east1. You have enabled global dynamic routing for your VPC network by using Cloud Router. Global dynamic routing enables VLAN attachments in one region to be used by one or more VMs located in another region.

You order a Cloud Interconnect connection running from your on-premises location to San Jose (SJC) and create one VLAN attachment over that connection to us-west1. You then send traffic from a VM in us-east1 to your on-premises location through the VLAN attachment located in us-west1. You are then charged the following rates:

• Region-to-region data transfer charges for forwarding traffic from us-east1 to the VLAN attachment in us-west1. The VLAN attachment in us-west1 is considered the source of traffic.
• Cloud Interconnect data transfer charges for North America for traffic from region us-west1 to your on-premises location.

A VM in a different continent than a VLAN attachment, using global VPC dynamic routing

This scenario is the same as the preceding example, except that one region, us-west1, is located in North America, and the other region, asia-east1, is located in Asia. Sending traffic between regions on different continents results in more expensive inter-region data transfer rates.

The only way to send traffic from asia-east1 over Cloud Interconnect in North America is by enabling VPC global dynamic routing. This makes the VLAN attachment in us-west1 available to VMs in all regions in your VPC network. You are then charged the following rates:

• Intercontinental region-to-region data transfer charges for traffic forwarded from asia-east1 to us-west1.
• Cloud Interconnect data transfer charges for North America for traffic from region us-west1 to your on-premises location.

A VM in a different continent than a VLAN attachment, using VPC Network Peering

This scenario is similar to the preceding example, except that there are two VPC networks connected through VPC Network Peering. Sending traffic between regions results in the same rates as the preceding example that uses global dynamic routing.

You send traffic from us-east4 to your on-premises network over Cloud Interconnect in Asia by using VPC Network Peering. You are then charged the following rates:

• Intercontinental region-to-region data transfer charges for traffic forwarded from us-east4 to asia-northeast1.
• Cloud Interconnect data transfer charges for Asia for traffic from region asia-northeast1 to your on-premises location.

A non-VM Google Cloud product or service in a different location than a VLAN attachment, using global VPC dynamic routing

In addition to the preceding scenarios, Cloud Interconnect data transfer charges apply to traffic sent from a Google Cloud product or service that is not a VM to your on-premises location over a VLAN attachment. You pay the product's data transfer charges to reach the region of the VLAN attachment, and then pay the Cloud Interconnect data transfer out charges based on the continent where the Cloud Interconnect connection is located.

The following example describes charges for traffic transferring out from a Cloud Storage bucket in a different region in North America than the region where the VLAN attachment is located.

In this scenario, you have resources in two regions located in North America, us-west1 (Oregon) and northamerica-northeast1 (Montreal). You have enabled global dynamic routing for your VPC network by using Cloud Router.

You order a Cloud Interconnect connection running from your on-premises location to San Jose (SJC) and create one VLAN attachment over that connection to us-west1. You then send traffic from a Cloud Storage bucket in northamerica-northeast1 to your on-premises location through the VLAN attachment located in us-west1. You are charged the following rates:

• The Cloud Storage data transfer cost for forwarding traffic from a Cloud Storage bucket in northamerica-northeast1 to a VLAN attachment in us-west1.
• Cloud Interconnect data transfer charges for North America for traffic from region us-west1 to your on-premises location (because that is where your Cloud Interconnect connection is located).

If the Cloud Storage bucket is located in a different continent than the VLAN attachment, you pay Cloud Storage intercontinental data transfer charges to reach the VLAN attachment in us-west1.

For a full list of pricing scenarios for Cloud Storage, see the Cloud Storage pricing page.

Cloud Router

Cloud Router is provided free of charge. General networking costs apply to control plane (BGP) traffic. In most cases, these costs are negligible.

For more information about networking costs, see General network pricing in the Virtual Private Cloud (VPC) documentation.

Cloud VPN

At a high level, your Cloud VPN charges consist of the following:

• An hourly charge for each Cloud VPN gateway; this charge is determined partly by the number of tunnels attached to the gateway, as well as the location of the gateway
• A monthly charge for IPsec traffic
• An hourly charge for any external IP address assigned to a VPN gateway but not used by a tunnel

For more information about Cloud VPN, see the Cloud VPN overview.

Pricing table

To view pricing, select the location of the Cloud VPN gateway. Except where otherwise noted, all details apply to both Classic VPN and HA VPN.

Google does not charge for forwarding rules that send traffic to the VPN gateway.

Pricing scenarios

For help understanding Cloud VPN pricing, refer to the following examples.

us-central1 gateway to data center

Suppose you have a VPN gateway in us-central1. That gateway uses two tunnels to connect with an on-premises data center in Iowa.

Each month, you send 2 tebibytes (TiB) of data through the tunnel, from your Virtual Private Cloud (VPC) network to your data center. At the same time, you send 2 TiB in the other direction—from the data center to your VPC network.

Additionally, your gateway uses a reserved external IP address.

The following table shows the charges that you'd incur during a 30-day month with this setup.

asia-northeast1 gateway to data center and another VPC network

Suppose your project has a VPC network called Network A, which includes a VPN gateway in asia-northeast1. This gateway uses two tunnels to connect with an on-premises data center in Tokyo. Additionally, this gateway uses two tunnels to connect with Network B, another VPC network in your project. Network B's gateway is located in europe-west6.

Each month, your data usage is as follows:

• Users in Network A download 10 TiB of data from Cloud Storage and send it to the Tokyo data center.
• Networks A and B send each other about 20 TiB of data.

Both the asia-northeast1 and europe-west6 gateways use reserved external IP addresses.

Additionally, you have a third VPN gateway in southamerica-east1. You created this gateway several months ago and assigned it a reserved external IP address. However, you never set up a tunnel for this gateway.

The following table shows the charges that this setup would incur during a 30-day month.

Network Connectivity Center

This document describes pricing for Network Connectivity Center.

Network Connectivity Center is a hub-and-spoke model for network connectivity management in Google Cloud. With this model, virtual private cloud networks and on-premises networks connect to a Network Connectivity Center hub by using spokes that have supported Google Cloud spoke resources attached to them.

For more information about Network Connectivity Center, see the Network Connectivity Center overview.

Current pricing

The following sections describe the current pricing for Network Connectivity Center.

Hubs and spokes

The following table describes charges for hubs and spokes. Spoke hours refers to the number of hours within a month that a spoke is active.

Spoke hour charges are waived for up to three VPN spokes and three Cloud Interconnect spokes.

Data transfer

Data transfer refers to any traffic that flows between a set of hybrid spokes connected to Network Connectivity Center.

Network Connectivity Center data transfer traffic is different from data transfer in and data transfer out, which flows either into or out of Google's network. In contrast, Network Connectivity Center data transfer can be both: it can flow into and out of Google's network, because it is traffic that is exchanged between any two hybrid spokes.

Data transfer charges are based on gibibytes (GiB) of traffic per month.

Advanced Data Networking

Advanced Data Networking (ADN) refers to the processing fee charged for all traffic that is sent from a spoke through a hub.

The ADN charge is $0.02 per Gibibyte (GiB) per month.

This charge currently applies for traffic between VPC spokes. ADN charges for hybrid spokes are currently waived.

Pricing example

Advanced Data Networking

In this example, an enterprise has two Virtual Private Cloud (VPC) global networks, VPC-1 and VPC-2, which it connects via VPC spokes to their Network Connectivity Center hub. Each VPC is in its own project distinct from the hub project.

Each month, VPC-1 sends 10 TiB of data to VPC-2, and VPC-2 sends 5 TiB of data to VPC-1.

The following table describes the charges for one 30-day month.

Note that both the Spoke hour charges and Advanced Data Networking charges for VPC spokes accrue in their respective projects.

Data transfer

In this example, an enterprise connects two Router appliance spokes to their Network Connectivity Center hub. One spoke represents an office in Los Angeles (us-west2). Another represents an office in Mumbai (asia-south1).

Every month, the US office transfers 5 TiB of data to the Asia office, and the Asia office transfers 5 TiB to the US office.

The following table describes the charges for one 30-day month.

Pricing for other Google Cloud resources

The pricing on this page does not include charges for other Google Cloud resources and products that you might be using in conjunction with Network Connectivity Center. For example:

• If you use Router appliance spokes, you pay for the underlying Compute Engine resources.
• If you use VLAN attachment spokes, you pay for the underlying Cloud Interconnect resources.
• If you use VPN spokes, you pay for the underlying Cloud VPN resources.

Router appliance

Pricing for Router appliance is part of Network Connectivity Center pricing. For pricing, see Network Connectivity Center pricing.

For more information about networking costs, see General network pricing in the Virtual Private Cloud documentation.

Cloud NAT

Cloud NAT pricing is based on the following usage:

• An hourly price for the NAT gateway that is based on the number of VM instances that are using the gateway. The per-hour rate is capped at 32 VM instances. Gateways that are serving instances beyond the maximum number are charged at the maximum per-hour rate.

  Google Cloud counts VM instances that get a NAT assignment as using the gateway. The NAT gateway performs source NAT (SNAT) for data transfer traffic from resources that don't have external IP addresses, and destination NAT (DNAT) for ingress packets that arrive as responses to outbound packets.

• A per-GiB cost for data transfer that is processed by the gateway. The data processing price is the same across all regions. Data transfer costs to send traffic from the VM out of the network also apply.

• An hourly price for each static or ephemeral external IP address that is used by a NAT gateway.

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

The total cost for running a NAT gateway and running traffic through it is as follows:

total cost for running the gateway = hourly cost for the NAT gateway
+ cost per GiB of data that is processed by the gateway
+ hourly cost for the external IP addresses used by the gateway
+ data transfer costs for any traffic leaving the network

Pricing example

The following table shows the estimated monthly cost for a single NAT gateway that uses external IP addresses to serve a different number of VM instances. For both cases, the gateway runs for 720 hours in a billing cycle.

Logging pricing

NAT logging pricing is described in Network Telemetry pricing.

Standard pricing for Cloud Logging, BigQuery, or Pub/Sub apply.

Cloud DNS

With Cloud DNS pricing, the charge is per zone per month (regardless of whether you use your zone), and you also pay for queries against your zones.

Pricing table

The following pricing applies to all zone types: public, private, and forwarding. All zone types are aggregated for purposes of pricing. For example, if you have 10 public zones, 10 private zones, and 10 forwarding zones, then your pricing is based on having 30 zones. All queries are aggregated as well, regardless of zone type.

You can use labels to label zones in certain ways. You can then use these labels to see per-label breakdowns in your billing.

Query pricing

Managed zone pricing

^* Managed zone pricing is calculated based on the number of managed zones that exist at a time, prorated by the percentage of the month they exist. This prorating is measured by hour. Zones that exist for a fraction of an hour are counted as having existed for the whole hour.

Cloud DNS usage does not result in any data transfer out charges.

Pricing for health checks

Pricing example

The following table shows sample Cloud DNS usage patterns and the potential costs per month:

Pricing for queries is proportional to usage. So 500,000 queries would be charged $0.20 (half the price of 1 million queries).

Post GA pricing example for health checks

Service Directory

Note that if you use Service Directory zones, you are billed separately for Cloud DNS based on Cloud DNS pricing.

Service Extensions

This document explains Service Extensions pricing details.

The following charges apply for Service Extensions callouts on Cloud Load Balancing. Other relevant charges for data transfer may apply for cross-region traffic and any compute at the other end of the callout.

Cloud Domains

Pricing overview

Domains are registered in increments of one year. By registering a domain, you're committing to paying for the whole year. Domains are renewed automatically. If your domain renews in Cloud Domains, you are billed for the 12 months following your renewal date. If you want to stop paying for your domain, or if don't want your domain to automatically renew, see Turn off automatic renewal for a domain name.

Pricing per domain ending

Prices vary based on domain endings (TLDs) listed in the pricing table. For example, if you buy example.com, example.charity, and example.wiki, the yearly cost of each of these domains differ because the domain endings .com, .charity, and .wiki have different costs. The yearly price of each domain that you register is added to get the total cost. See the Pricing example.

Cloud Domains does not support the following kinds of domains:

• Premium domains
• Domains that require a trademark notice

Billing models

Subscription billing (for Cloud Billing accounts outside Brazil)

The Subscription billing model bills you the yearly amount for the domain in the first month following a domain registration, renewal, or transfer. This applies to all domains that are registered, renewed, or transferred at Cloud Domains general availability.

Charges from Cloud Domains show up on your invoice under Charges not specific to a project because the charges are tied to the Cloud Billing account.

The Subscription billing model is not included in the Enterprise Discount Program.

Commitment billing (for Cloud Billing accounts in Brazil)

If your Cloud Billing account has a Brazil address, the Commitment billing model bills you 1/12 of the total cost every month for the next 12 months until the domain expires. This applies to all domains that are registered, renewed, or transferred at Cloud Domains general availability.

Charges from Cloud Domains show up on your invoice under Charges not specific to a project because the charges are tied to the billing account.

The Subscription billing model is not included in the Enterprise Discount Program.

If you choose to transfer a registered domain to another registrar during the 12-month period from your registration, renewal, or transfer to Cloud Domains date, you are charged a cancellation fee. The cancellation fee is equal to the unbilled portion of the annual cost of the domain.

Billing for newly registered domains

When you register a domain using Cloud Domains, you are committing to paying for a full year of registration.

Billing for transferred-in domains

When you transfer in a domain from another provider, billing is as follows.

• Your existing registration time with your original provider is maintained.
• On completion of the transfer, the registration time is extended by a year.
• You are billed for the extended year right away.
• You are not billed again until your domain is about to expire and needs to be renewed.

Example

The following examples explain how billing works for transferred-in domains.

• If the domain had one month of registration time left before transfer, you get billed for 1 year at time of transfer. The next billing event after the transfer completes is the domain's next renewal, 13 months (1 month + 1 year) after the transfer.
• If the domain had two years of registration time left before transfer, the next billing event is 3 years (2 years + 1 year) later.

Billing for renewals

Renewed domains are billed using either subscription or commitment billing.

To stop automatic renewal, see Turn off automatic renewal for a domain name. To manage a domain's billing account individually (outside of a Google Cloud project), you must transfer it out to a third-party registrar. However, once you register a domain with Cloud Domains, if you choose to transfer your domain to a third party before the 12-month period expires, you are still charged for the domain for the remainder of the 12 months. The billing frequency depends on the billing model for your resource.

For more information about renewals, see Squarespace purchase of Google Domains FAQ.

You must use Cloud Domains billing to manage the billing of domains registered with Cloud Domains.

Free usage

Cloud Domains does not offer free usage for domain registration. For information on quotas, see the Quotas page.

Pricing table

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

Billing SKUs

To search for appropriate SKUs for the billing model applicable to your registration, transfer, or renewal, use the following links.

• All Cloud Domains SKUs.
• Subscription billing SKUs.
• Commitment billing SKUs.
• Cancellation SKUs.

Pricing example

The following examples use US pricing.

Example 1

Subscription billing: You buy a $12 .com domain. On your next monthly bill you are charged $12. Your next charge is one year later when the domain renews for $12.

Commitment billing: You buy a $12 .com domain. On your next monthly bill you are charged $1, and you are charged $1 for each monthly billing cycle until the domain expires. If you decide to delete the domain after being billed for 5 months ($5 total), you are billed a $7 cancellation fee to bring the billed total to $12.

Example 2

Suppose that you have registered three domains: example.charity, example.wiki, and example.info.

The cost is:

.charity = $30/year

.wiki = $28/year

.info = $12/year

Subscription cost = $30 + $28 + $12 = $70/year

Commitment billing = 1/12th of the yearly price = $70/12 = $5.83/month

What's next

• Read the Virtual Private Cloud documentation.
• Try the Pricing calculator.
• Learn about VPC solutions and use cases.