Ungenutzte Load Balancer, Gateways und Firewalls

Ungenutzter Load Balancer Kosten sind Stundengebühren für einen Load Balancer ohne Ziele, ein Application Gateway ohne Backend, eine Azure Firewall vor einem leeren Netz, ein VPN-Gateway ohne Verbindung oder eine Weiterleitungsregel ohne Backend-Dienst: jedes dieser Objekte wird je Stunde berechnet, ob eine Anfrage ankommt oder nicht, und die meisten entstehen mit einer Umgebung und überleben sie. Die Einsparung entsteht, weil ein Gateway ohne Ziel gelöscht wird und mehrere Load Balancer mit je einer Anwendung zu einem mit Regeln zusammengelegt werden. Die Behebung gehört dem Team, dem die Anwendung dahinter gehörte.

Symptom

Die Rechnung zeigt Gateway-Stunden ohne Kapazitätseinheiten oder Bytes. Bei AWS sind das lineItem/UsageType EUC1-LoadBalancerUsage mit vollen Stunden und EUC1-LCUUsage nahe null je Load Balancer unter AWSELB, und EUC1-VPN-Usage-Hours für Site-to-Site-VPN-Verbindungen. Bei Azure stehen MeterCategory Application Gateway mit Fixed Cost-Stunden ohne Capacity Units, Azure Firewall mit Deployment-Stunden ohne Data Processed, VPN Gateway mit Gateway-Stunden, und Load Balancer mit Regelstunden. In Google Cloud trägt Cloud Load Balancing die SKU Forwarding Rule Minimum Service Charge je Weiterleitungsregel und Cloud VPN die Tunnelstunden. Was Load Balancer grundsätzlich kosten, steht in Load Balancer, NAT und öffentliche IPs; diese Seite behandelt die ohne Ziel.

So erkennen Sie es

AWS

Die Load Balancer, ihre Zielgruppen und die Gesundheit der Ziele:

aws elbv2 describe-load-balancers --query 'LoadBalancers[].[LoadBalancerName,Type,Scheme,CreatedTime,LoadBalancerArn]' --output table
aws elbv2 describe-target-groups --load-balancer-arn <arn> --query 'TargetGroups[].[TargetGroupName,TargetType,TargetGroupArn]' --output table
aws elbv2 describe-target-health --target-group-arn <target-group-arn> --query 'TargetHealthDescriptions[].[Target.Id,TargetHealth.State]' --output table

Ein Load Balancer ohne Zielgruppe oder mit einer leeren gilt als Kandidat; bei einem mit Zielen zeigen die CloudWatch-Metriken RequestCount, ActiveConnectionCount und ConsumedLCUs im Namensraum AWS/ApplicationELB über zwei Wochen, ob Verkehr fließt; RequestCount wird nur gemeldet, wenn Ziele registriert sind (ALB-Metriken). VPN-Verbindungen und ihr Tunnelstatus: aws ec2 describe-vpn-connections --query 'VpnConnections[].[VpnConnectionId,State,VgwTelemetry[].Status|join(,,@)]'. Trusted Advisor meldet unter "Idle Load Balancers" einen Load Balancer ohne aktive oder gesunde Backend-Instanzen oder mit weniger als 100 Anfragen pro Tag in den letzten sieben Tagen, allerdings nur für Classic Load Balancer (gelesen am 2026-10-21); Compute Optimizer bewertet Load Balancer nicht. In den Abrechnungsdaten ist der Kandidat eine LoadBalancerUsage-Position mit 720 Stunden und LCUUsage nahe null für dieselbe lineItem/ResourceId (AWS Cost and Usage Report).

Azure

Application Gateways mit ihren Backend-Pools, Firewalls, Netzwerkgateways mit ihren Verbindungen:

az network application-gateway list --query "[].{name:name, rg:resourceGroup, sku:sku.name, state:operationalState, backends:backendAddressPools[].length(backendAddresses)|join(',', @)}" -o table
az network firewall list --query "[].{name:name, rg:resourceGroup, sku:sku.tier, subnet:ipConfigurations[0].subnet.id}" -o table
az network vnet-gateway list --resource-group <rg> --query "[].{name:name, sku:sku.name, type:gatewayType}" -o table
az network vpn-connection list --resource-group <rg> --query "[].{name:name, gateway:virtualNetworkGateway1.id, status:connectionStatus}" -o table

Ein Application Gateway mit leeren Backend-Pools und die Metrik Total Requests bei null, eine Firewall mit Data processed bei null, und ein Netzwerkgateway ohne Verbindung sind die Kandidaten; Azure Advisor empfiehlt als Vorschau unter "Delete Azure virtual network gateways with no connections" das Löschen und nennt die Stundengebühr des Gateways und seiner öffentlichen Adresse. Im Kostenexport ist der Kandidat eine applicationGateways/-, azureFirewalls/- oder virtualNetworkGateways/-Ressource mit vollen Stunden und ohne Verbrauchsmeter (Azure-Kostenexporte).

Google Cloud

Weiterleitungsregeln, Backend-Dienste und ihre Backends, VPN-Tunnel:

gcloud compute forwarding-rules list --format="table(name,region.basename(),IPAddress,loadBalancingScheme,target.basename(),backendService.basename())"
gcloud compute backend-services list --format="table(name,region.basename(),protocol,backends[].group.basename().list())"
gcloud compute vpn-tunnels list --format="table(name,region.basename(),status,peerIp)"

Ein Backend-Dienst mit leerem backends-Feld und eine Weiterleitungsregel, die auf ihn zeigt, zahlen die Mindestgebühr je Regel ohne Verkehr; die Metrik loadbalancing.googleapis.com/https/request_count je Regel über zwei Wochen ist der Nachweis, ein Tunnel im Status ESTABLISHED ohne Bytes der zweite. Einen Recommender für Load Balancer gibt es nicht. Im Abrechnungsexport ist der Kandidat eine Forwarding Rule Minimum Service Charge-Position ohne Network Load Balancing: Data Processed daneben (Google-Cloud-Abrechnungsexport).

So beheben Sie es

1. Je Objekt klären, ob es Teil einer Umgebung ist, die noch kommt, oder einer, die gegangen ist; der Name, das Tag und das Erstellungsdatum sagen es, der Verantwortliche entscheidet.
2. Löschen, nach der Liste. AWS: aws elbv2 delete-load-balancer --load-balancer-arn <arn> und danach aws elbv2 delete-target-group --target-group-arn <arn>, ohne Dry-Run, deshalb nur gegen die geprüfte Liste; die Elastic-IP-Adresse eines Network Load Balancers bleibt und braucht release-address; VPN mit aws ec2 delete-vpn-connection --vpn-connection-id <id> --dry-run. Azure: az network application-gateway delete --name <gateway> --resource-group <rg>, az network firewall delete, az network vnet-gateway delete, danach die öffentlichen Adressen. Google Cloud: gcloud compute forwarding-rules delete <rule> --region=<region>, dann gcloud compute backend-services delete, gcloud compute vpn-tunnels delete.
3. Zusammenlegen, wo ein Load Balancer je Anwendung läuft: ein Application Load Balancer mit hostbasierten Regeln je Umgebung, ein Application Gateway mit mehreren Listenern, ein Google-Cloud-Load-Balancer mit einer URL-Map; bei Kubernetes ein Ingress oder Gateway statt eines Service vom Typ LoadBalancer je Dienst (Kubernetes-Effizienz).
4. Die Vorlage korrigieren: Load Balancer und Gateways entstehen mit der Umgebung und werden mit ihr gelöscht, in demselben Modul; eine Firewall oder ein VPN-Gateway bekommt ein Ablaufdatum, wenn es für einen Test entsteht (Kostenprüfung von Infrastrukturcode).

Die Stundengebühr endet mit dem Löschen; der Tagesexport zeigt es am Folgetag.

Risiken und Nebenwirkungen

• Ein Load Balancer ohne Ziele ist zuweilen der DNS-Anker einer Anwendung, die gerade umzieht; sein Hostname steht in Einträgen, die mit ihm verschwinden. Ein Blick auf die DNS-Zone gehört vor das Löschen.
• Ein Application Gateway lässt sich stoppen, bevor es gelöscht wird; ob ein gestopptes Gateway Gebühren trägt, hängt vom SKU ab und steht auf der Preisseite, deshalb ist Stoppen ein Test, nicht die Einsparung.
• Ein VPN-Gateway ohne Verbindung ist zuweilen die Gegenstelle eines Partners, der seinen Tunnel nur bei Bedarf aufbaut; die Verbindungshistorie und der Partner entscheiden.
• Zusammenlegen erhöht die Abhängigkeit: ein Load Balancer für zehn Anwendungen ist ein Ausfallpunkt für zehn, und seine Kapazitätseinheiten summieren sich; die Stundengebühr sinkt, die LCU- oder Capacity-Unit-Position nicht.
• Eine Firewall erfüllt eine Sicherheitsanforderung; eine Firewall ohne Verkehr, die eine Richtlinie "kein direkter Internetzugang" erfüllt, bleibt, bis die Richtlinie anders erfüllt ist.

So weisen Sie die Einsparung nach

Vorher: je Objekt die Stundenposition im letzten vollen Monat, LoadBalancerUsage, VPN-Usage-Hours, Fixed Cost, Deployment, Gateway-Stunden, Forwarding Rule Minimum Service Charge, und daneben die Verbrauchsposition, LCUUsage, Capacity Units, Data Processed. Nachher: dieselben Objekte im ersten vollen Monat nach dem Löschen, erwartet null, und bei einer Zusammenlegung die Stundenposition des verbleibenden Load Balancers mit einer Verbrauchsposition, die um die übernommenen Anfragen steigt. Die Summe der Stundengebühren der Löschliste ist die Schätzung, die Freigabe macht sie akzeptiert, das Löschen umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Zahl der Gateways ohne Ziel ist die Kennzahl, die danach null bleibt.

Quellen

Gelesen am 2026-10-21. Trusted Advisor, Kostenoptimierungsprüfungen, CloudWatch-Metriken für Application Load Balancer, aws elbv2, Azure Advisor, Kostenempfehlungen, az network application-gateway, az network vnet-gateway, gcloud compute forwarding-rules, gcloud compute backend-services.