Take back control of your infrastructure.
The OpenMetal team is standing by to assist you with scoping out a fixed-cost model based infrastructure plan to fit your needs, budgets and timelines.
Enterprise teams across industries are discovering that hyperscaler networking costs have become the most unpredictable component of their cloud spending, with charges that can swing wildly based on architectural decisions, traffic patterns, and deployment topologies that seemed logical at design time.
While compute and storage costs from major cloud providers follow relatively predictable patterns, networking charges operate under a complex web of per-gigabyte fees, gateway costs, and cross-region penalties that can turn cost-optimized architectures into budget disasters. The challenge isn’t just the expense—it’s the unpredictability that makes long-term planning nearly impossible.
TL;DR: Key Takeaways
- Hyperscaler networking costs are highly variable due to per-GB egress charges, cross-AZ fees, and gateway pricing that penalize distributed architectures
- Internal traffic isn’t free on major cloud platforms—even communication between your own services triggers charges when crossing availability zones or regions
- Traditional cost optimization strategies fail because they require you to choose between architectural best practices and budget predictability
- 95th percentile billing eliminates the cost volatility of traffic spikes, protecting against viral content or seasonal demand surges
- OpenMetal’s two-network model separates billable external traffic from free internal communication, enabling distributed architectures without multiplicative costs
- High-capacity private fabric (20 Gbps per server) ensures internal communication never becomes a performance bottleneck
- VLAN/VXLAN segmentation provides enterprise-grade network isolation without the complexity of cloud networking constructs
Why Networking Becomes the Budget Wild Card
Internet Egress Complexity
Every major hyperscaler charges for data leaving their network, but the pricing structures vary dramatically based on destination, volume tiers, and service integration. AWS charges $0.09 per GB for the first 10 TB of monthly egress traffic, dropping to $0.05 per GB for traffic exceeding 500 TB¹. These rates apply to any data flowing from your applications to end users, whether it’s web content, API responses, file downloads, or CDN origin pulls.
The complexity multiplies when you consider that different services calculate egress differently. CloudFront distributions, S3 bucket access, EC2 instances, and Lambda functions each have distinct egress pricing models. A single user request might trigger egress charges across multiple services, making it nearly impossible to predict costs based on application usage patterns.
Google Cloud Platform follows a similar model but with regional variations². Traffic to other Google services within the same region is free, but cross-region communication and external egress follow tiered pricing that ranges from $0.12 per GB to $0.05 per GB depending on volume and destination.
Inter-Region & Cross-AZ Hidden Costs
The most surprising networking costs often come from traffic that never leaves the cloud provider’s infrastructure. AWS charges $0.01 per GB for data transfer between availability zones within the same region, and $0.02 per GB for cross-region transfers within the US³. These charges apply to communication between your own services—database replication, microservice API calls, load balancer health checks, and distributed cache synchronization all trigger per-gigabyte fees.
Consider a typical three-tier application deployed across multiple availability zones for high availability. Every database write requires replication across zones, triggering cross-AZ charges. Every API call between your web tier and application tier generates billable traffic. Your monitoring system collecting metrics from distributed services creates a constant stream of billable internal communication.
Azure’s approach is similar, with $0.01 per GB for cross-AZ traffic and $0.02 per GB for cross-region transfers⁴. The European Union’s recent push for data transfer portability has led to some pricing adjustments, but the fundamental per-gigabyte model remains intact.
Gateway Fees Overview
NAT Gateways, VPN connections, and API Gateway services add fixed hourly costs plus per-gigabyte processing fees that compound the unpredictability. AWS NAT Gateways cost $0.045 per hour plus $0.045 per GB of processed data⁵. For enterprises with significant outbound traffic, these gateway processing fees can exceed the underlying egress charges.
API Gateway pricing adds another layer of complexity with per-request charges, data transfer costs, and caching fees that vary based on usage patterns. A busy API serving mobile applications or third-party integrations can generate substantial gateway costs that scale independently of your core infrastructure.
The Gotchas in Detail
Internet Egress (North-South)
North-south traffic—data flowing between your applications and external users—represents the most visible networking cost but also the most difficult to optimize. Unlike compute resources that you can scale down during off-peak hours, egress traffic directly correlates with business success. Higher user engagement, viral content, and successful marketing campaigns all increase egress costs.
The pricing tiers create perverse incentives for architectural decisions. Organizations approaching volume tier thresholds might delay product launches or limit feature rollouts to stay within favorable pricing brackets. Conversely, teams exceeding high-volume tiers might over-architect for traffic levels that prove unsustainable, leading to infrastructure waste.
Content delivery networks partially address egress costs by caching content closer to users, but they introduce their own pricing complexity. CDN costs include origin pull charges, edge location fees, and request-based pricing that varies by geographic region.
Inter-Region & Cross-AZ (East-West That Still Costs)
East-west traffic—communication between your own services—should be operational overhead, but hyperscalers treat it as billable usage. This pricing model fundamentally conflicts with modern distributed system design patterns that assume abundant internal bandwidth.
Database clusters suffer particularly from cross-AZ charges. A PostgreSQL primary-replica setup with synchronous replication across availability zones generates continuous billable traffic for every write operation. MongoDB replica sets, Elasticsearch clusters, and Redis Cluster configurations all create persistent cross-AZ traffic streams that scale with your data volume and write frequency.
Microservice architectures multiply these costs exponentially. A single user request might trigger dozens of internal API calls as services communicate with each other, authentication systems, logging infrastructure, and monitoring platforms. Each service-to-service call crossing availability zone boundaries generates billable traffic, making distributed architectures financially prohibitive at scale.
Container orchestration platforms like Kubernetes compound the problem by scheduling workloads across zones for high availability. Pod-to-pod communication, service mesh traffic, and persistent volume access all generate cross-AZ charges that weren’t considered in the original cost projections.
NAT/VPN Gateways
Gateway services create dual billing exposure through both hourly infrastructure costs and per-gigabyte processing fees. NAT Gateways are required for private subnet internet access, making them unavoidable for security-conscious deployments. The $0.045 per hour charge equals $32.40 per month per gateway, before processing any traffic.
The processing fees scale with your application’s external dependencies. API calls to third-party services, software update downloads, container image pulls, and backup operations all flow through NAT Gateways, generating processing charges on top of egress fees. A busy application making frequent external API calls can generate hundreds of dollars in monthly NAT Gateway processing fees.
VPN Gateway costs follow similar patterns with additional complexity for site-to-site connections. Each VPN connection includes hourly gateway fees, data processing charges, and potential cross-region costs if connecting to resources in different geographic areas. Enterprise networks with multiple office locations or hybrid cloud deployments can accumulate substantial VPN-related networking costs.
OpenMetal’s Counter-Model
OpenMetal approaches networking costs with a fundamentally different philosophy that recognizes how modern distributed applications actually communicate. Instead of monetizing every byte of data movement, OpenMetal’s architecture separates billable external traffic from operational internal communication.
“We’ve seen enterprises get blindsided by networking costs that double their cloud bills overnight,” says Todd Robinson, OpenMetal’s President. “Our two-network model eliminates the largest source of cost uncertainty by making internal traffic truly free, not just cheaper. When you’re designing distributed systems, you shouldn’t have to choose between architectural best practices and budget predictability.”
Two-Network Architecture Model
OpenMetal fundamentally separates public and private network traffic through a dual-network design that recognizes how modern distributed applications actually communicate. Every OpenMetal deployment automatically provisions two distinct network paths: a public network for internet-bound traffic (north-south) and a private network fabric for inter-service communication (east-west).
This architectural separation means that heavy internal workloads like database replication, microservice communication, backup operations, and analytics shuffles never touch the billable public egress path. Unlike hyperscalers where cross-AZ or inter-region communication can trigger per-GB charges even for internal traffic, OpenMetal’s private fabric treats all internal communication as operational overhead that should be included in base infrastructure costs, not metered separately.
Included Private Traffic with Zero Per-GB Internal Charges
OpenMetal includes all private network traffic between servers, storage systems, and services within your deployment at no additional per-GB cost. This means that chatty applications like Kafka clusters, Elasticsearch nodes performing shard replication, Ceph storage clusters synchronizing data, or Spark jobs shuffling data between workers generate zero additional networking fees on the private fabric.
The economic model recognizes that modern distributed systems are inherently communicative and that charging per-GB for essential inter-service traffic creates perverse architectural incentives. Teams can design for optimal performance and reliability without constantly calculating the cost impact of moving data between application tiers, running backup operations, or scaling horizontally with additional service instances.
95th Percentile Billing for Predictable Public Egress
Instead of charging for every single gigabyte of public egress, OpenMetal uses 95th percentile billing beyond included traffic levels, which fundamentally changes how traffic spikes impact your bill. The system takes bandwidth measurements regularly throughout the billing period, sorts these samples from highest to lowest, and discards the top 5% of measurements.
Your bill is calculated based on the sustained bandwidth usage pattern rather than peak moments. This approach protects against the cost volatility that comes from legitimate traffic patterns like CDN cache warming, batch processing windows, viral content distribution, or seasonal traffic spikes. A Black Friday traffic surge or a popular content release won’t dominate your monthly networking bill if these events represent temporary rather than sustained demand patterns.
High-Capacity Private Network Fabric
OpenMetal provisions 20 Gbps private networking capacity per server class as standard infrastructure, with higher bandwidth options available on premium server configurations. This high-capacity private fabric ensures that internal communication never becomes a performance bottleneck, even for the most demanding distributed applications.
The private network can handle intensive workloads like real-time analytics processing, machine learning model training with large datasets, high-frequency database synchronization, or media processing pipelines without degrading performance or triggering additional costs. The architecture scales to support modern application patterns that assume abundant internal bandwidth, from containerized microservices with service mesh communication to distributed storage systems that require constant background rebalancing.
How the OpenMetal Network Is Put Together
Segmentation & Isolation
OpenMetal provides enterprise-grade network segmentation through both traditional VLANs and modern VXLAN overlay networks, giving you cloud-style network virtualization with bare metal performance characteristics. VLAN segmentation enables crisp Layer-2 isolation for different environments (development, staging, production), business units, or security zones, with the ability to trunk multiple VLANs to hosts when applications require access to multiple network segments.
VXLAN overlays extend this segmentation capability beyond the traditional 4,096 VLAN limit by creating virtualized Layer-2 networks over the Layer-3 underlay infrastructure. This technology means large-scale multi-tenant deployments, complex networking topologies, and sophisticated traffic engineering while maintaining the performance benefits of dedicated hardware.
The combination provides the network flexibility of public cloud with the predictable performance and cost structure of private infrastructure. Security teams can implement zero-trust network segmentation without worrying about the networking charges that would accumulate from encrypted inter-service communication across cloud availability zones.
East-West vs. North-South Traffic Handling
OpenMetal’s dual-network architecture creates a clear distinction between operational traffic (east-west) and revenue-generating traffic (north-south). East-west communication flows over the high-capacity private fabric at no additional cost, while north-south traffic uses the public network with predictable 95th percentile billing.
This separation eliminates the cost uncertainty that comes from architectural decisions. Deploying additional application tiers, implementing service meshes, or scaling database clusters doesn’t trigger multiplicative networking costs because internal communication remains free. Teams can focus on performance, reliability, and scalability without calculating the networking cost implications of every architectural decision.
The private fabric handles the communication patterns that generate the highest traffic volumes in modern applications: database synchronization, distributed cache updates, log aggregation, metrics collection, and inter-service API communication. These operational traffic patterns scale with your application’s complexity and data volume, but they don’t create linear cost increases.
Why 95th Percentile Billing Helps
95th percentile billing smooths out the cost volatility that makes traditional per-gigabyte pricing unpredictable. Traffic spikes from viral content, seasonal campaigns, or legitimate business growth don’t create budget surprises when they represent temporary rather than sustained demand increases.
The billing method takes 5-minute bandwidth samples throughout the month, creating approximately 8,640 data points. By discarding the top 5% of measurements, the system focuses on sustained usage patterns rather than peak moments. This means that up to 432 samples (approximately 36 hours of peak traffic throughout the month) don’t impact your bill.
This approach particularly benefits applications with variable traffic patterns: media companies with viral content spikes, e-commerce platforms with seasonal demand, SaaS applications with batch processing windows, or global applications serving users across multiple time zones. The billing method rewards efficient architecture by not penalizing temporary traffic increases that good systems should handle gracefully.
Architecture Patterns That Benefit Most from OpenMetal’s Networking Approach
Distributed Database Systems
Applications using distributed databases see immediate benefits from OpenMetal’s free internal traffic model. MongoDB replica sets, Cassandra clusters, PostgreSQL streaming replication, and Elasticsearch shards generate continuous inter-node communication that creates substantial cross-AZ charges on hyperscalers.
Real-time analytics platforms with distributed processing engines like Apache Spark or Apache Flink benefit significantly from high-capacity private networking. These systems shuffle large datasets between worker nodes during processing, creating traffic patterns that would be prohibitively expensive on per-gigabyte billing models.
Microservice Architectures
Service mesh deployments with encrypted inter-service communication generate substantial internal traffic through proxy sidecars, control plane synchronization, and telemetry collection. The network overhead of security-focused architectures becomes cost-neutral on OpenMetal’s private fabric.
Event-driven architectures using message queues, event streaming platforms, or pub/sub systems create persistent internal communication streams that scale with application activity. Kafka clusters, RabbitMQ deployments, and custom event processing pipelines generate zero additional networking costs.
Hybrid and Multi-Cloud Deployments
Organizations maintaining hybrid cloud architectures benefit from OpenMetal’s predictable egress billing when synchronizing data between environments or serving content to distributed user bases. The 95th percentile billing model protects against cost spikes from batch synchronization operations or failover scenarios.
Multi-cloud strategies using OpenMetal as a cost-predictable tier can reduce overall networking costs while maintaining geographic distribution and vendor diversification. The transparent pricing model makes it easier to optimize workload placement across providers.
Buyer’s Checklist: Evaluating Networking Cost Models
Audit Your Current Networking Costs
- Review the past 12 months of cloud bills to identify networking cost patterns and volatility. Calculate what percentage of your total cloud spend goes to data transfer, cross-AZ communication, and gateway services. Look for unexpected spikes that coincided with traffic increases or architectural changes.
- Inventory your inter-service communication patterns. Document which applications generate the most internal traffic: database replication, distributed caches, log aggregation, monitoring systems, and backup operations. These represent the workloads that benefit most from free internal traffic models.
Model Cost Scenarios
- Project your networking costs under different growth scenarios. How would your current per-gigabyte charges scale with 2x or 5x traffic growth? What architectural changes are you avoiding due to networking cost concerns?
- Calculate the cost impact of best practices you’re not implementing: multi-AZ database deployments, comprehensive monitoring, real-time analytics, or service mesh security. These operational improvements often get deferred due to networking cost implications on hyperscaler platforms.
Evaluate Cost Predictability Requirements
- Assess your finance team’s tolerance for networking cost variance. Organizations with strict budget controls or predictable revenue models often struggle with the 40-60% monthly networking cost swings common on hyperscaler platforms.
- Consider the operational overhead of networking cost optimization. Time spent architecting around cross-AZ charges, managing NAT Gateway usage, or implementing complex caching strategies has opportunity costs that should factor into total cost of ownership calculations.
Test Traffic Spike Scenarios
- Model the cost impact of success scenarios: viral marketing campaigns, seasonal traffic increases, or rapid user growth. How would current networking pricing handle Black Friday traffic levels or a successful product launch?
- Evaluate disaster recovery and failover costs. Cross-region replication, backup operations, and failover testing all generate substantial inter-region traffic that creates budget surprises during critical operational periods.
The Takeaway
Hyperscaler networking costs have evolved into enterprise budgeting wild cards that force false choices between architectural best practices and cost predictability. The per-gigabyte billing of internal communication conflicts with modern distributed system design, while traffic spike pricing punishes business success with budget volatility.
OpenMetal’s two-network architecture addresses these fundamental conflicts by separating operational traffic from billable usage and smoothing external traffic costs through 95th percentile billing. The result is a networking cost model that rewards good architecture rather than penalizing it.
For CTOs and infrastructure directors managing substantial cloud budgets, the networking cost predictability enables long-term planning and architectural decision-making without constant cost calculation overhead. The model scales with business growth rather than fighting against it.
The question isn’t whether networking costs will continue growing—it’s whether your infrastructure partner’s pricing model supports or conflicts with your architectural and business objectives. In an era where distributed systems are operational necessities rather than optional optimizations, networking cost predictability has become a competitive requirement.
Ready to escape unpredictable networking charges? Contact OpenMetal today to learn how our two-network architecture can cut your networking costs while eliminating budget surprises.
Works Cited
- Amazon Web Services. “Amazon EC2 On-Demand Pricing – Data Transfer.” AWS, aws.amazon.com/ec2/pricing/on-demand/.
- Google Cloud. “VPC Network Pricing.” Google Cloud Platform, https://cloud.google.com/vpc/network-pricing.
- Amazon Web Services. “AWS Data Transfer Pricing.” AWS, aws.amazon.com/ec2/pricing/data-transfer/.
- Microsoft. “Bandwidth Pricing Details.” Microsoft Azure, azure.microsoft.com/en-us/pricing/details/bandwidth/.
- nOps. “AWS Egress Costs and How to Avoid.” nOps Blog, https://www.nops.io/blog/aws-egress-costs-and-how-to-avoid/.