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.

Standard Load Balancers are frequently provisioned for internal services, internet-facing applications, or testing environments. When a workload is decommissioned or moved, the load balancer may be left behind without any active backend pool or traffic — but continues to incur hourly charges for each frontend IP configuration.Because Azure does not automatically remove or alert on inactive load balancers, and because they may not show significant outbound traffic, these resources often persist unnoticed. In dynamic or multi-team environments, this can result in a growing number of unused Standard Load Balancers generating silent, recurring costs.

In Azure, it’s common for public IP addresses to be created as part of virtual machine or load balancer configurations. When those resources are deleted or reconfigured, the IP address may remain in the environment unassigned. While Basic SKUs are free when idle, Standard SKUs incur ongoing hourly charges, even if the address is not in use.Unassigned Standard public IPs provide no functional value but continue to generate cost, especially in environments with high churn or inconsistent cleanup practices.

When EC2 instances, Lambda functions, or containerized workloads access AWS-managed services without VPC Endpoints, that traffic exits the VPC through a NAT Gateway or Internet Gateway. This introduces unnecessary egress charges and NAT processing costs, especially for data-intensive or high-frequency workloads.

Workloads in private subnets often access AWS services like S3 or DynamoDB. If this traffic is routed through a NAT Gateway, it incurs both hourly and data processing charges. However, AWS offers VPC Gateway Endpoints (for S3/DynamoDB) and Interface Endpoints (for other services), which provide private access paths that bypass the NAT Gateway entirely. When teams fail to use VPC endpoints — often due to default routing configurations or lack of awareness — they unnecessarily route internal service calls through a costlier, public-facing path. This leads to persistent and avoidable spend.

Elastic IPs are often provisioned but forgotten — left unassociated, or still attached to EC2 instances that have been stopped. In either case, AWS treats the EIP as idle and applies an hourly charge. Although the cost per hour is relatively small, these charges accumulate quietly, especially across environments with frequent provisioning, decommissioning, or ephemeral workloads. Many organizations overlook the fact that even a single EIP attached to a stopped instance is billable. Without periodic review, this creates persistent, low-visibility waste across AWS accounts.