Networking

Networking cost optimization best practices: an overview

Every cloud deployment needs a network over which to move data. Without a network, you can’t view cat videos or upload your selfies, much less allow microservices to talk to one another. 

Google Cloud provides a global, scalable, flexible network for your cloud-based workloads and services, and how you utilize that network impacts four critical aspects of your deployment: cost, security, performance and availability. 

When designing a reliable, sound, yet cost effective network architecture, you’ll want multiple teams within the company to weigh in on these four elements, to determine your priorities. The following tips highlight a few considerations you should think about when architecting your network solution. 

(Note that we’ll focus here on optimizing network cost. Check out our blog for cost optimizations on Cloud Storage and BigQuery.)

Flow and behold

The first step when reviewing your overall networking spend strategy is to understand what you’re using, namely, what traffic is flowing in and out of your Google Cloud Platform (GCP) environment. This is easy to do with VPC Flow Logs, which keeps a record of the network flows sent from and received by VM instances. Each flow log entry records details such as source IP, destination IP, and bytes sent and received for each network connection—exactly the type of information needed when trying to understand your network traffic. These logs are collected in Stackdriver logging and you can then export these logs to BigQuery to help visualize your trends. Some of the use cases for VPC Flow Logs include: network monitoring, forensics, real-time security analysis, and for today’s purposes, cost optimization. 

When it comes to optimizing networking spend, the most relevant information in VPC Flow Logs is:

  • Traffic between regions and zones

  • Traffic to specific countries on the Internet

  • Top talkers

Here are step-by-step instructions on how to enable VPC Flow logs. 

What’s in a name? That which we call a region might not cost the same

The information you get from VPC Flow Logs can help you determine where you might be able to save on your existing network costs. For example, geo location is an important factor to consider when architecting for optimal spend. Not all network charges are created equal; different regions have varying network costs. As well as using VPC Flow Logs, you can also take advantage of the recently released network monitoring, verification and optimization platform, Network Intelligence Center, which allows you to  view the network bandwidth in use between regions and geo locations. When transferring data around the world either to customers or to other internal services in your GCP environment, the ability to drill down and understand your traffic patterns across regions is crucial.

For general internet egress charges, e.g., a group of web servers that serve content to the internet, prices can vary depending on the region where those servers are located. For instance, the price per GB in us-central1 is cheaper than the price per GB in asia-southeast1. Another example is traffic flowing between GCP regions, which can vary significantly depending on the location of those regions—even if it isn’t egressing out to the Internet. For example, the cost to synchronize data between asia-south1 (India) and asia-east1 (Taiwan) is five times as much as synchronizing traffic between us-east1 (South Carolina) and us-west1 (Oregon).

As well as regional considerations, you should also consider which zones your workloads are in, as depending on their availability requirements, you may be able to architect them to use intrazone network traffic at no cost. You read that right, at no cost! Consider your VMs communicating via public, external IP addresses, but that are in the same region or zone. By configuring them to communicate via their internal IP address, you can save on the cost of what you would have paid for that traffic communicating via external IP addresses. 

Keep in mind, you’ll need to weigh any potential network cost saving with the availability implications of a single-zone architecture. Deploying to only a single zone is not recommended for workloads that require high availability, but it can make sense to have certain services use a VPC network within the same zone. One example could be to use a single-zone approach in regions that have higher costs (Asia), but a multi-zone or multi-regional architecture in North American where the costs are lower.

Once you have established what your network costs are for an average month, you may want to consider a few different approaches to better allocate spending. Some customers re-architect solutions to bring applications closer to their user base, and some employ Cloud CDN to reduce traffic volume and latency, as well as potentially take advantage of CDN’s lower costs to serve content to users. Both of these are viable options that can both reduce costs and/or enhance performance.

To VPN or not to VPN?

Next in line when reviewing overall networking spend is total bytes transferred. Using VPC Flow Logs, you can see the “Top Talkers” within your environment, and if you’re pushing large amounts of data, you want to ensure that you take advantage of any potential discounts you might be entitled to. 

We have seen many customers who push large amounts of data on a daily basis from their on-premises environment to GCP, either using a VPN or perhaps directly over the Internet (encrypted with SSL hopefully!). Some customers, for example, have databases on dedicated, on-prem hardware, whereas their frontend applications are serving requests in GCP. If this describes you, consider whether you should leverage a Dedicated Interconnect or Partner Interconnect. If you push large amounts of data (think TBs/PBs) on a consistent basis, it can be cheaper to establish a dedicated connection vs. accruing costs associated with your traffic traversing the public internet or using a VPN. 

There are a few architectural considerations to review when selecting an Interconnect, which you can read about in further detail here

Your network optimized your way with Network Tiers

One of Google Cloud’s biggest differentiators is having access to Google’s premium network backbone, which is used by default for all services. But you might not need that performance and low latency for all your services. An example might be the distribution of a daily sales report that doesn’t need to be immediately available around the globe. With services for which you are willing to trade off between performance and cost, we offer Network Service Tiers

By choosing either Standard or Premium Tier, you can allocate the appropriate connectivity between your services, fine-tuning the network to the needs of your application and potentially reducing costs on services that might tolerate more latency and don’t require an SLA.

There are some limitations when leveraging the Standard tier for its pricing benefits. At a high level, these include compliance needs around traffic traversing the public internet, as well as HTTP(S), SSL Proxy, TCP Proxy load-balancing, or usage of Cloud CDN. You can read about these in more detail here. After reviewing some of the recommendations, you’ll be empowered to review your services with your team and determine whether you can benefit from lower Standard Tier pricing without impacting the performance of your external-facing services.

Waste not, want not

The above topics are some of the larger levers you can pull when conducting a networking cost review. But overall you should ensure that you are taking advantage of one of the greatest cloud benefits: pay only for what you use. With this in mind, we recommend reviewing the following to ensure you get the most out of your GCP investment:

Reviewing the above will ensure you are eliminating wasteful spending within your design, and also ensure that you are taking full advantage of your cloud-based solution. 

A packet saved is a penny earned

Balancing costs with performance, availability, and security is no simple feat, often requiring collaboration across multiple teams. We like to think that there are many approaches to consider, and more often than not, cost optimization is not so much a one time review, but your application teams’ philosophy. Hopefully this post will give you food for thought when reviewing your network designs. Click here to learn more about Google Cloud’s networking portfolio. And for more on cost optimization, check out these blogs on cost optimization for Cloud Storage and BigQuery.