Cloud NAT charges a per-GiB data processing fee on all traffic routed through the gateway — both inbound responses and outbound requests. For high-throughput workloads such as web crawlers, data pipelines, container image pulls, and API-heavy microservices, these per-GiB charges can become the dominant cost component of the NAT gateway, far exceeding the hourly gateway and IP address fees. In environments processing large volumes of data monthly, data processing fees can represent the vast majority of total Cloud NAT spend, making the managed service significantly more expensive than alternative NAT architectures when comparing direct infrastructure costs alone.
The core issue is that Cloud NAT applies its data processing fee to traffic that would otherwise be free or low-cost — particularly inbound traffic (ingress), which Google Cloud does not normally charge for. When private instances pull large datasets, download container images, or receive high volumes of API responses through Cloud NAT, each GiB incurs the processing fee. Organizations can avoid these per-GiB charges by deploying self-managed NAT instances on Compute Engine — VMs configured with IP forwarding and NAT translation rules — where the only direct cost is the compute instance itself. However, this trade-off introduces substantial operational complexity, ongoing maintenance burden, and availability risk: self-managed NAT requires manual configuration, network expertise, continuous monitoring, security patching, high-availability planning, capacity management, incident response procedures, and troubleshooting capabilities that Cloud NAT handles automatically. The engineering time required for initial implementation, the ongoing operational labor for maintenance, and the business impact of potential service disruptions must all be factored into the total cost of ownership.
This optimization is highly workload-specific and situational rather than universally applicable or recommended. The break-even point depends not only on monthly traffic volume, the number of VMs behind the gateway, and the chosen instance type for self-managed NAT, but also on the fully-loaded cost of engineering time, the organization's operational maturity, the criticality of affected workloads, and the tolerance for increased operational risk. In most cases, the operational overhead, complexity, and risk of self-managed NAT infrastructure outweigh the direct cost savings unless data processing fees are exceptionally high and sustained over time. Organizations should perform a comprehensive total cost of ownership analysis before migrating, accounting for both direct infrastructure costs and indirect costs such as engineering effort, operational burden, monitoring infrastructure, and the business risk of connectivity failures. This is not a straightforward cost optimization — it is a deliberate trade-off between managed service convenience and operational control that only makes sense at very high traffic volumes where the cost differential is substantial enough to justify the additional complexity and risk.
NAT Gateway charges a per-gigabyte data processing fee on all traffic that passes through it — in either direction — regardless of whether the destination is the public internet or another AWS service in the same region. This per-GB charge is separate from and additive to the hourly provisioning cost, and for workloads with meaningful throughput, it quickly becomes the dominant cost component. In many US regions, the data processing charge matches the hourly rate (e.g., $0.045/GB in US East Ohio), meaning that once monthly traffic exceeds roughly 720 GB, data processing costs surpass the baseline hourly charges entirely. For internet-bound traffic, a compounding effect occurs: hourly provisioning, per-GB data processing, and standard data transfer out charges all apply simultaneously — creating a combined variable cost that can reach $0.135 per GB or more.
This cost structure is frequently underestimated during architecture planning. Teams designing VPC layouts often account for the hourly cost of NAT Gateways but overlook how significantly the per-GB processing fee scales with traffic volume. The result is that workloads routing high-throughput traffic to AWS services like S3, DynamoDB, container registries, or logging endpoints through NAT Gateway incur substantial and avoidable data processing charges. Gateway VPC endpoints for S3 and DynamoDB carry no hourly or data processing charges at all, and interface VPC endpoints for other AWS services process data at a fraction of the NAT Gateway rate. Without deliberate traffic routing decisions, NAT Gateway data processing can quietly become one of the largest line items on an AWS bill.
Azure NAT Gateways are commonly deployed to provide outbound internet connectivity for resources within virtual network subnets. Over time, the workloads that originally required this outbound access may be scaled down, migrated, or decommissioned entirely. However, the NAT Gateway often remains attached to the subnet — continuing to incur hourly charges even when no active resources are using it. Because billing begins the moment the resource is created and continues for every hour it exists, an idle NAT Gateway generates a steady, fixed cost with zero functional return.
This waste pattern is particularly common in development, testing, and staging environments where infrastructure is provisioned for temporary workloads but networking components are not included in cleanup processes. NAT Gateways are subnet-level networking primitives, often provisioned by platform or infrastructure teams separately from the application teams that use them. This organizational separation creates gaps in ownership and cleanup responsibility, allowing idle gateways to persist unnoticed. Additionally, NAT Gateway has no stopped or paused state — the only way to stop billing is to delete the resource entirely. Even seemingly idle subnets can generate small data processing charges from background processes such as operating system updates or monitoring agents, which may create a misleading appearance of utilization and further delay cleanup.
The cost impact compounds when organizations maintain multiple idle NAT Gateways across subscriptions and environments. Each gateway also typically has an associated public IP address that incurs its own separate hourly charge, adding to the waste.
Azure Private Endpoints are network interfaces that provide private connectivity from a virtual network to Azure PaaS services such as Storage Accounts, SQL Databases, or Key Vaults. When the target service behind a private endpoint is deleted, migrated, or replaced, the private endpoint itself is not automatically removed. Instead, it transitions to a disconnected state and persists as an orphaned network resource that continues to incur hourly charges. Because private endpoints are network-layer resources managed separately from the application resources they connect to, they are frequently overlooked when services are decommissioned — particularly when the service owner and the network owner are different teams.
This pattern is especially common in development and testing environments where resources are created and destroyed frequently, but networking components are not consistently cleaned up as part of the resource lifecycle. It also occurs during production migrations, service replacements, or architecture changes. Over time, these orphaned endpoints accumulate silently — occupying private IP addresses in subnets, contributing to IP address exhaustion, and generating ongoing charges with no functional benefit. Because each private endpoint maps to a specific target resource and subresource (for example, separate endpoints are required for blob versus file storage on the same storage account), even a single decommissioned service can leave behind multiple orphaned endpoints.
Azure Firewall is available in three SKUs — Basic, Standard, and Premium — each designed for different security requirements and priced accordingly. The Premium SKU includes advanced threat protection capabilities such as TLS inspection, signature-based intrusion detection and prevention (IDPS), URL filtering, and web categories. These features are designed for highly sensitive and regulated environments, such as those processing payment card data or requiring PCI DSS compliance. However, many organizations deploy the Premium SKU by default — often during initial provisioning or as a precautionary measure — without actively configuring or requiring any of these Premium-exclusive features.
The cost impact is significant because the Premium SKU carries a substantially higher fixed hourly deployment charge compared to the Standard SKU — approximately 40% more — while the per-gigabyte data processing rate remains the same across both tiers. Since this hourly charge accrues continuously regardless of whether Premium features are enabled or traffic is flowing, every firewall instance running on the Premium SKU without leveraging its advanced capabilities represents a persistent and avoidable cost premium. In organizations with multiple firewall deployments across subscriptions and environments, this waste compounds quickly.
This pattern is especially common in non-production environments such as development and staging, where advanced threat protection features like TLS inspection and IDPS provide little practical value. Microsoft has recognized this as a frequent optimization opportunity and introduced a zero-downtime SKU change feature specifically to simplify the downgrade process from Premium to Standard.
Azure Bastion incurs continuous hourly charges from the moment it is deployed until the resource is deleted — regardless of whether any connections are actively being made. This means a Bastion host sitting idle in a development or test environment generates the same cost as one actively serving remote sessions. Because there is no ability to pause or stop a Bastion deployment, the only way to eliminate charges is to delete the resource entirely.
This inefficiency is especially common in non-production environments where Bastion may have been provisioned for occasional troubleshooting or administrative access but then left running indefinitely. Teams often deploy Bastion during initial environment setup and forget about it, or assume it only costs money when sessions are active. Over time, these idle deployments quietly accumulate significant charges — particularly when deployed at the Basic, Standard, or Premium SKU tiers, which use dedicated infrastructure and carry meaningful hourly rates.
The cost impact compounds across an organization with multiple subscriptions or environments. A single idle Bastion host may seem modest in isolation, but dozens of forgotten deployments across dev, test, staging, and sandbox environments can represent a substantial and entirely avoidable expense.
This inefficiency occurs when Azure Load Balancers remain provisioned after the backend workloads they supported have been scaled down, stopped, or decommissioned. This is common in non-production environments where virtual machines are shut down outside business hours, but the associated load balancers are left in place. Even when no meaningful traffic is flowing, the load balancer continues to incur base charges, resulting in ongoing cost without delivering value.
This inefficiency occurs when an Azure Virtual WAN hub is provisioned with more capacity than required to support real network traffic. Because hub costs scale with the number of configured scale units, overprovisioned hubs continue to incur higher charges even when traffic levels remain consistently low. This commonly happens when hubs are sized for peak or anticipated demand that never materializes, or when traffic patterns change over time without corresponding capacity adjustments.
As organizations migrate from the Basic to the Standard tier of Azure Load Balancer (driven by Microsoft’s retirement of the Basic tier), they may unknowingly inherit cost structures they didn’t previously face. Specifically, each load balancing rule—both inbound and outbound—can contribute to ongoing charges. In applications that historically relied only on Basic load balancers, outbound rules may never have been configured, meaning their inclusion post-migration could be unnecessary.
This inefficiency tends to emerge in larger Azure estates where infrastructure-as-code or templated environments create load balancers in bulk, often replicating rules without review. Over time, dozens or hundreds of unused or outdated rules can accumulate, inflating network costs with no operational benefit.
Each Cloud NAT gateway provisioned in GCP incurs hourly charges for each external IP address attached, regardless of whether traffic is flowing through the gateway. In many environments, NAT configurations are created for temporary access (e.g., one-off updates, patching windows, or ephemeral resources) and are never cleaned up. If no traffic is flowing, these NAT gateways remain idle yet continue to generate charges due to reserved IPs and persistent gateway configuration. This is especially common in non-production environments or when legacy configurations are forgotten.
