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.
Provisioned load balancers continue to generate costs even when they are no longer serving meaningful traffic. This often occurs when applications are decommissioned, testing infrastructure is left behind, or backend services are removed without deleting the associated frontend configurations. Without ingress or egress traffic, these load balancers offer no functional value but still consume billable resources, including forwarding rules and reserved external IPs.
Load balancers incur charges based on provisioned bandwidth shape, even if backend traffic is minimal. If traffic is low, or if only one backend server is configured, the load balancer may be oversized or unnecessary, especially in test or staging environments.
An ELB with only one registered EC2 instance does not achieve its core purpose—distributing traffic across multiple backends. In this configuration, the ELB adds complexity and cost without improving availability, scalability, or fault tolerance. This setup is often the result of premature scaling design or misunderstood architecture patterns. If there's no plan to horizontally scale the application, the ELB can often be removed entirely without user impact.
NAT Gateways are designed to serve private subnets within the same Availability Zone. When subnets in one AZ are configured to route traffic through a NAT Gateway in a different AZ, the traffic crosses AZ boundaries and incurs inter-AZ data transfer charges in addition to the standard NAT processing fees.
This typically happens when:
* NAT Gateways are deployed in multiple AZs (as recommended for resilience), but * Route tables for all subnets are configured to send traffic to a single NAT Gateway, ignoring AZ placement
In high-throughput environments, this misalignment silently generates excess cost. Ensuring that each subnet routes through the NAT Gateway in its own AZ avoids inter-AZ charges and aligns with AWS architectural best practices.
