How We Reduced Costs on GCP by Optimizing a Single SKU: Network Inter Zone Data Transfer Out

Sachin Arote
4 min readOct 16, 2024

Cloud cost optimization is a critical task for organizations managing infrastructure on platforms like Google Cloud Platform (GCP). One small configuration tweak can often lead to significant savings. In this blog, I’ll walk you through how we cut down our cloud expenses simply by optimizing a single SKU: Network Inter Zone Data Transfer Out.

Understanding the “Network Inter Zone Data Transfer Out” SKU

Before diving into the optimization steps, let’s first understand the SKU we focused on: Network Inter Zone Data Transfer Out. This SKU refers to the cost associated with data moving between different zones within the same region. A “zone” is an isolated location within a GCP region where resources like virtual machines (VMs) are deployed. While this inter-zone traffic stays within a region, it still incurs charges due to the infrastructure involved in maintaining high-speed networking.

We noticed a substantial portion of our monthly bill was tied to this specific cost, which seemed unnecessary. Our application required VM communication, but moving data between zones wasn’t crucial for our workload. That gave us the opportunity to optimize.

Step-by-Step Approach to Cutting Costs

1. Identifying High Data Transfer Zones

The first step was to analyze where the costs were coming from. Using GCP’s Cost Management Tools, particularly the Cost Breakdown and Billing Reports, we could pinpoint which zones were communicating heavily with each other. The network traffic between zones seemed unusually high, especially between our development and production environments.

Key finding: VMs in different zones were communicating for tasks that didn’t require inter-zone communication. For example, load balancers were distributing traffic between zones even when that wasn’t necessary.

2. Evaluating Workload Necessities

Next, we assessed whether cross-zone traffic was vital to our system’s performance. In our case, we found that some non-essential workloads, such as logging, monitoring, and routine backups, were unnecessarily crossing zones. We also found that a few misconfigurations in our Kubernetes clusters led to services talking across zones when they didn’t need to.

Key action: We updated configurations so that tasks like logging, monitoring, and backups were processed within the same zone, and we made sure Kubernetes pods were more tightly bound to their respective zones for inter-pod communication.

3. Consolidating Resources in Fewer Zones

The next optimization step was to consolidate our workloads. Since GCP provides multiple zones within a region for redundancy and fault tolerance, we initially spread our instances across three zones for high availability. After reviewing our architecture, we realized that two zones were sufficient for our use case. We weren’t operating in a mission-critical scenario where we needed three zones for failover.

Key action: We reduced the number of zones used by our deployment from three to two, which cut the data transfer between zones by roughly 33%.

4. Leveraging Zonal Resources

To avoid unnecessary network traffic, we focused on utilizing zonal resources whenever possible. This included making sure that our load balancers, VMs, and databases were zonal instead of regional if they didn’t require the extra redundancy.

Key action: Moving zonal traffic, where VMs and databases operate within the same zone, led to a notable decrease in cross-zone communication, which helped further reduce inter-zone data transfer costs.

5. Monitoring with GCP Tools

Cost optimization is not a one-time effort. After making the adjustments, we closely monitored the results using GCP’s Cloud Monitoring and Billing Dashboard. This allowed us to track reductions in inter-zone traffic and ensure that performance was not impacted.

6. Continuous Fine-Tuning

Finally, we implemented a continuous review process. Periodically, our team checks for changes in data transfer patterns, monitors resource usage, and ensures that traffic remains within zones wherever feasible. As a part of our DevOps practice, we set alerts that notify us when network traffic between zones spikes, enabling us to take corrective action immediately.

Results: Significant Cost Savings

By optimizing the Network Inter Zone Data Transfer Out SKU, we managed to reduce our GCP costs by a significant margin. Here’s a breakdown of the results:

  • Total reduction in inter-zone data transfer: 45%
  • Monthly savings: Approximately 20% off our GCP bill, amounting to thousands of dollars annually
  • Performance impact: Zero. In fact, reducing cross-zone traffic also improved performance in some cases by decreasing latency.

Key Takeaways

  • Analyze detailed costs: Always break down your cloud bill to see where your money is going. GCP’s tools make it easy to pinpoint costly areas like data transfer.
  • Zone optimization: Not every workload needs to span multiple zones. For certain applications, sticking to zonal resources can dramatically lower your costs.
  • Configuration review: Misconfigurations or overlooked settings in your cloud infrastructure could be leading to unnecessary charges. Regular reviews are essential for staying optimized.
  • Continuous monitoring: Set up alerts and regularly check cost reports to stay ahead of any cost spikes and adjust your configurations as needed.

With just a few strategic changes, we were able to save on GCP costs while maintaining (and sometimes even improving) performance. Sometimes, it’s as simple as tweaking one SKU — like Network Inter Zone Data Transfer Out — to see significant financial benefits.

By keeping an eye on where your cloud costs are coming from and continuously optimizing, you can ensure you’re not overspending while still getting the most out of your infrastructure.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Sachin Arote
Sachin Arote

Written by Sachin Arote

DevOps Architect | Docker | GCP |AWS | Terraform | Spinnaker|Jenkins|Prometheus|Grafana | Kubernetes |Victoria Metrics

Responses (2)

Write a response