Optimize cost: Networking

This document in the Google Cloud Architecture Framework provides recommendations to help you optimize the cost of your networking resources in Google Cloud.

The guidance in this section is intended for architects and administrators responsible for provisioning and managing networking for workloads in the cloud.

Design considerations

A fundamental difference between on-premises and cloud networks is the dynamic, usage-based cost model in the cloud, compared with the fixed cost of networks in traditional data centers.

When planning cloud networks, it's critical to understand the pricing model, which is based on the traffic direction, as follows:

  • You incur no charges for ingress traffic into Google Cloud. Resources that process ingress traffic, like Cloud Load Balancing, incur costs.
  • For egress traffic, which includes both traffic between virtual machines (VMs) in Google Cloud and traffic from Google Cloud to the internet and to on-premises hosts, pricing is based on the following factors:
    • Whether the traffic uses an internal or external IP address
    • Whether the traffic crosses zone or region boundaries
    • Whether the traffic leaves Google Cloud
    • The distance that the traffic travels before leaving Google Cloud

When two VMs or cloud resources within Google Cloud communicate, traffic in each direction is designated as egress at the source and ingress at the destination, and is priced accordingly.

Consider the following factors for designing cost-optimal cloud networks:

  • Geo-location
  • Network layout
  • Connectivity options
  • Network Service Tiers
  • Logging

These factors are discussed in more detail in the following sections.

Geo-location

Networking costs can vary depending on the Google Cloud region where your resources are provisioned. To analyze network bandwidth between regions, you can use VPC Flow Logs and the Network Intelligence Center. For traffic flowing between Google Cloud regions, cost can vary depending on the location of the regions even if the traffic doesn't go through the internet.

Besides the Google Cloud region, consider the zones where your resources are deployed. Depending on availability requirements, you might be able to design your applications to communicate at no cost within a zone through internal IP addresses. When considering a single-zone architecture, weigh any potential savings in networking cost with the impact on availability.

Network layout

Analyze your network layout, how traffic flows between your applications and users, and the bandwidth consumed by each application or user. The Network Topology tool provides comprehensive visibility into your global Google Cloud deployment and its interaction with the public internet, including an organization-wide view of the topology, and associated network performance metrics. You can identify inefficient deployments, and take necessary actions to optimize your regional and intercontinental network egress cost.

Connectivity options

When you need to push a large volume of data (TBs or PBs) frequently from on-premises environments to Google Cloud, consider using Dedicated Interconnect or Partner Interconnect. A dedicated connection can be cheaper when compared with costs associated with traversing the public internet or using a VPN.

Use Private Google Access when possible to reduce cost and improve your security posture.

Network Service Tiers

Google's premium network infrastructure (Premium Tier), is used by default for all services. For resources that don't need the high performance and low latency that Premium Tier offers, you can choose Standard Tier, which costs less.

When choosing a service tier, consider the differences between the tiers and the limitations of Standard Tier. Fine-tune the network to the needs of your application, and potentially reduce the networking cost for services that can tolerate more latency and don't require an SLA.

Logging

VPC Flow Logs, Firewall Rule Logging, and NAT Logging let you analyze network logs and identify opportunities to reduce cost.

For VPC Flow Logs and Cloud Load Balancing, you can also enable sampling, which can reduce the volume of logs written to the database. You can vary the sampling rate from 1.0 (all log entries are retained) to 0.0 (no logs are kept). For troubleshooting or custom use cases, you can choose to always collect telemetry for a particular VPC network or subnet, or monitor a specific VM Instance or virtual interface.

Design recommendations

To optimize network traffic, we recommend the following:

  • Design your solutions to bring applications closer to your user base. Use Cloud CDN to reduce traffic volume and latency, and take advantage of CDN's lower pricing to serve content that you expect many users to access frequently.
  • Avoid synchronizing data globally across regions that are distant from the end user or that can incur high networking costs. If an application is used only within a region, avoid cross-region data processing.
  • Ensure that communication between VMs within a zone is routed through their internal IP addresses, and not routed externally.
  • Reduce egress cost and client latency by compressing data output.
  • Analyze spending patterns and identify opportunities to control cost by observing egress and ingress traffic flows for critical projects using VPC Flow Logs.
  • When designing your networks in the cloud, consider the trade-off between the high availability that a distributed network offers and the cost savings from centralizing traffic within a single zone or region.

To optimize the price that you pay for networking services, we recommend the following:

  • If the server location is not a constraint, assess the cost at different regions, and select the most cost-efficient region. For general egress traffic, like content served by a group of web servers, prices can vary depending on the region where the servers are provisioned.
  • To reduce the cost of moving high volumes of data frequently to the cloud, use a direct connection between the on-premises and Google Cloud networks. Consider using Dedicated Interconnect or Partner Interconnect.
  • Choose an appropriate service tier for each environment: that is, Standard Tier for development and test environments, and Premium Tier for production.

What's next