Bandwidth-/Throughput-Limits in der Cloud: Warum nicht wie erwartet?

Bandwidth-/Throughput-Limits in der Cloud führen in der Praxis regelmäßig zu Überraschungen: Sie wählen eine größere VM-Instanz, sehen im Datenblatt „bis zu X Gbit/s“, starten einen Speedtest – und erreichen trotzdem nur einen Bruchteil davon. Oder ein Transfer läuft anfangs schnell und fällt dann ab. Oder innerhalb einer Region ist alles flott, aber über ein Load Balancer-, NAT- oder VPN-Setup wirkt das System „gedeckelt“. Der Kernpunkt ist: Cloud-Throughput ist selten ein einzelner Wert. Er entsteht aus einem Zusammenspiel aus Instanztyp, Netzwerkkarte (virtuell oder SR-IOV), CPU/Encryption-Overhead, Paketgröße, Anzahl paralleler Flows, TCP-Settings, Routing-Pfad, Service-Limits (z. B. NAT-Gateway, Load Balancer, Firewall-Appliance), Quotas sowie „weichen“ Faktoren wie Shared-Backbone und Placement. Wer Bandbreite in der Cloud zuverlässig plant und validiert, braucht daher ein mentalen Modell, das mehr umfasst als „Gbit/s“. Dieser Artikel erklärt, warum Durchsatz nicht wie erwartet ausfällt, welche typischen Bottlenecks in AWS/Azure/GCP auftreten, wie Sie Messungen korrekt durchführen und welche Stellschrauben den größten Effekt haben.

Bandwidth, Throughput, Goodput: Warum es schon bei Begriffen hakt

Wenn Teams von „Bandbreite“ sprechen, meinen sie oft unterschiedliche Dinge. Das führt zu falschen Erwartungen, insbesondere bei Performance-Tests und SLOs.

• Bandwidth: theoretische maximale Datenrate eines Links oder Systems (z. B. 10 Gbit/s).
• Throughput: tatsächlich gemessene Datenrate auf Transportebene (z. B. TCP-Durchsatz in iperf3).
• Goodput: Nutzdatenrate, also Throughput abzüglich Protokoll-Overhead, Retransmits, TLS/IPsec-Overhead.

Protokoll-Overhead ist nicht „optional“

Je nach Pfad addieren sich Header und Encapsulation: Ethernet/IP/TCP, ggf. TLS, ggf. HTTP/2 oder QUIC, ggf. VPN (IPsec), ggf. Overlay (VXLAN/GENEVE). Bei kleinen Paketen fällt Overhead besonders ins Gewicht; bei großen Paketen dominieren eher CPU und Window/RTT.

Die wichtigste Physik im Hintergrund: RTT und TCP-Window begrenzen Throughput

Ein häufiger Grund für „zu wenig Durchsatz“ ist nicht die Cloud, sondern die Kombination aus Round-Trip-Time (RTT) und TCP-Window (bzw. Bandwidth-Delay Product). Selbst ein perfekter 10-Gbit/s-Link bringt wenig, wenn die Verbindung ein kleines Window hat und eine relevante RTT.

$\mathrm{Throughput}\approx \frac{\mathrm{TCP\_Window}}{\mathrm{RTT}}$

Beispielhaft (ohne konkrete Zahlen zu erzwingen): Steigt RTT, muss das effektive Window groß genug sein, um die Leitung zu füllen. In Cloud-Szenarien mit Cross-AZ, Cross-Region, Hybrid (VPN/Direct Connect/ExpressRoute) oder Service-Chaining (LB → WAF → Proxy → App) wächst RTT oft unbemerkt. Dadurch wirkt ein System „gedeckelt“, obwohl die nominelle Bandbreite hoch ist.

Single Stream vs. Parallel Streams

Viele Tests nutzen einen einzelnen TCP-Stream. In der Praxis erreichen Sie hohe Gbit/s-Werte oft erst mit mehreren parallelen Streams, weil ein einzelner Flow durch Congestion Control, Window-Limits oder per-Flow-Hashing an Grenzen stößt. Das ist kein Trick, sondern reale Betriebswirklichkeit: Auch Anwendungen nutzen oft mehrere gleichzeitige Verbindungen (Sharding, Multipart Uploads, parallele Requests).

„Bis zu X Gbit/s“ ist eine Spanne, kein Versprechen

Cloud-Provider geben Netzwerkperformance häufig als „bis zu“ oder in Klassen an. Dahinter stecken Mechanismen wie geteilte Ressourcen, Burst-Modelle oder Abhängigkeiten vom Instanztyp und dessen NIC/Offload-Fähigkeiten. Typische Gründe, warum „bis zu“ nicht erreicht wird:

• Instanzgröße skaliert nicht linear: CPU, Memory und Netzwerk sind gekoppelt. Manche Größen haben identische Netzwerkklasse, andere springen stufenweise.
• Bursts: Kurzzeitig hoher Durchsatz ist möglich, aber nicht dauerhaft (je nach Service/Instance-Klasse).
• Per-Flow Limits: Ein einzelner Flow kann deutlich unter dem Aggregatlimit liegen.
• PPS-Limits: Nicht nur Bits/s, sondern Packets/s begrenzen, besonders bei kleinen Paketen.

Packets per Second: Der versteckte Deckel bei kleinen Paketen

Wenn Sie viele kleine Requests erzeugen (z. B. Telemetrie, Chatty Microservices, DNS-lastige Workloads), kann das PPS-Limit früher greifen als das Gbit/s-Limit. Dann sehen Sie niedrigen Durchsatz trotz hoher „Bandbreite“, begleitet von CPU-Interrupt-Last, erhöhten Latenzen oder Drops.

Instanz- und NIC-Faktoren: Accelerated Networking, ENA, SR-IOV

Netzwerkperformance hängt stark davon ab, wie die virtuelle Netzwerkkarte implementiert ist und ob Offloads verfügbar sind. Konzepte wie SR-IOV und „Accelerated Networking“ reduzieren Hypervisor-Overhead und verbessern Throughput, PPS und Latenz.

• AWS: Enhanced Networking (z. B. ENA) ist bei vielen Instanzen Standard und relevant für hohen Durchsatz und niedrige Latenz.
• Azure: Accelerated Networking (SR-IOV) sollte für performante Workloads aktiviert werden, sofern VM-Typ und NIC es unterstützen.
• GCP: Netzwerkperformance ist an Machine Types und Plattformfunktionen gekoppelt; je nach Typ variieren Durchsatz und egress-Fähigeiten.

CPU ist oft der Flaschenhals, nicht das Netzwerk

Durchsatztests, die TLS terminieren, IPsec nutzen oder Daten komprimieren/verschlüsseln, können CPU-limitieren. Das gilt besonders bei kleineren Instanzen oder wenn Nebenlast (Logging, Sidecars, IDS-Agenten) läuft. Ein klarer Indikator: CPU-Utilization steigt bis an die Grenze, während Netzwerkdurchsatz „stehen bleibt“.

Service-Limits in der Kette: Load Balancer, NAT, Firewalls, Gateways

In der Cloud läuft Traffic selten „direkt“ von A nach B. Häufig passieren Daten mehrere Managed Services oder Appliances. Jeder dieser Punkte kann ein eigenes Throughput- oder PPS-Limit haben – und damit Ihr Gesamtsystem deckeln, unabhängig davon, wie groß Ihre Instanzen sind.

• NAT-Gateways / NAT-Services: Können bei hoher Parallelität oder vielen Zielendpunkten an Skalierungsgrenzen stoßen (Ports, Flows, PPS).
• Load Balancer: Durchsatz hängt von SKU/Typ, Listener-Konfiguration, TLS-Settings, Zielgruppen und Cross-Zone/Regional Routing ab.
• Firewalls/WAF/IDS: Inspection kostet CPU und Speicher; außerdem können State Tables zum Bottleneck werden.
• VPN-Gateways: IPsec-Tunnel haben oft klare Durchsatzgrenzen; zusätzlich wirken MTU/MSS und PMTUD stark auf Goodput.

Symptom „Skalieren hilft nicht“

Wenn Sie App-Instanzen hochskalieren, aber der Durchsatz bleibt gleich, ist häufig ein zentraler Control Point (NAT, LB, Gateway, Firewall) der Engpass. Dann ist horizontales Skalieren am falschen Ort.

Storage und Netzwerk: Egress ist nicht gleich Datenbank- oder Objekt-Throughput

Viele Workloads „messen Netzwerk“, testen aber in Wahrheit Storage: Objekt-Storage Downloads, Datenbank-Backups, Replikationen oder Block-Storage Reads/Writes. Dabei gelten eigenständige Limits und Pfade.

• Block Storage: IOPS und Durchsatz hängen an Volume-Typ, Size, Provisioning und ggf. Instanz-IO-Limits.
• Object Storage: Durchsatz hängt stark von Parallelität (Multipart), Client-Implementation, TLS und Request-Patterns ab.
• Datenbanken: Netzwerkpfad plus DB-Engine-Overhead; oft begrenzt die DB selbst (CPU, Locks, Buffer Cache) statt das Netzwerk.

Praxisregel

Messen Sie Netzwerk isoliert (z. B. iperf3 zwischen zwei Endpunkten) und messen Sie Storage separat. Sonst optimieren Sie am falschen Layer.

Messmethodik: Warum Speedtests in der Cloud oft irreführen

Öffentliche Speedtests sind für Enduser-Internet optimiert, nicht für Cloud-interne Pfade oder definierte Topologien. Für belastbare Ergebnisse brauchen Sie reproduzierbare Tests.

• Tooling: iperf3 (TCP/UDP), ntttcp (Windows), pktgen/trex für PPS-lastige Tests.
• Topologie: Gleiche AZ vs. Cross-AZ, gleiche Region vs. Cross-Region, mit/ohne LB/NAT/VPN.
• Parallelität: Single Stream und Multi Stream messen; Ergebnisse getrennt betrachten.
• Paketgröße: Kleine und große Payloads testen, um PPS vs. Bandbreite zu unterscheiden.
• Dauer: Lang genug testen, um Bursting-Effekte zu erkennen.

Typische Testfehler

• Nur ein Testlauf, keine Wiederholung zu unterschiedlichen Tageszeiten.
• Nur ein Flow (Single Stream), dann falsche Schlussfolgerung „Link ist langsam“.
• CPU-Limit ignoriert (TLS, VPN, Kompression) und Netzwerk dafür verantwortlich gemacht.
• Test über mehrere Services (LB/WAF/NAT), aber Ergebnis dem „Netzwerk der VM“ zugeschrieben.

Netzwerkpfad und Placement: Warum zwei identische VMs unterschiedliche Werte liefern

Cloud ist ein verteiltes System. Zwei identische Instanzen können je nach Placement, zugrundeliegender Hardware, Nachbarschaftslast oder Netzwerkpfad unterschiedliche Performance zeigen. Das ist kein „Zufall“, sondern Ergebnis der Ressourcenzuteilung.

• Placement Groups / Proximity: Bestimmte Platzierungsoptionen verbessern Latenz und Durchsatz innerhalb eines Clusters.
• Cross-Zone Routing: Kann zusätzliche Hops einführen und Durchsatz/Latenz verändern.
• Gemeinsame Engpässe: Ein zentraler Transit (Firewall/Proxy) kann saturieren, auch wenn Endpunkte frei sind.

Diagnose-Indikator

Wenn ein Problem nur bei bestimmten Paaren von Instanzen auftritt, lohnt sich ein Vergleich „Same host family / same AZ / same subnet“ und ein gezielter Test ohne Zwischenkomponenten.

Konfiguration: TCP, NIC-Offloads, MTU/MSS und warum Defaults nicht immer passen

Cloud-Defaults sind auf „funktioniert für die meisten“ optimiert, nicht auf Ihr spezielles Performance-Ziel. Häufige Stellschrauben:

• TCP Congestion Control: Je nach Kernel/OS können Algorithmen unterschiedlich performen, besonders bei hoher RTT.
• Receive/Send Buffer: Zu kleine Buffer begrenzen Throughput bei höherer RTT.
• MTU/MSS: In VPN/Overlay-Setups kann falsche MTU zu Retransmits und massiv reduziertem Goodput führen.
• NIC-Offloads: Checksum Offload, TSO/GSO/GRO können CPU entlasten, sollten aber bewusst geprüft werden (insbesondere bei Appliances/DPDK).

MTU-Probleme wirken wie „Throughput-Limit“

Wenn PMTUD scheitert (z. B. ICMP blockiert) oder MSS nicht passend ist, sehen Sie häufig Retransmits und scheinbar „gedeckelten“ Durchsatz. Typisch ist das Muster: kleine Transfers ok, große Transfers langsam oder timeouten. In solchen Fällen ist die „Bandbreite“ nicht das Problem, sondern Paketverlust durch MTU-Mismatch.

Quotas, Limits und „weiche“ Grenzen: Wenn es nicht technisch, sondern organisatorisch ist

Ein weiterer Klassiker: Die Architektur wäre theoretisch schnell genug, aber Sie laufen in Quotas oder Service-Limits. Das betrifft z. B. Anzahl von IPs, Limits pro Gateway, Anzahl von Routes, oder – je nach Dienst – Durchsatzklassen.

• Account-/Subscription-Limits: Manche Ressourcen skalieren erst nach Limit-Erhöhung.
• Service-spezifische Limits: NAT, LB, VPN, Firewall-Throughput hängt vom gewählten Dienst/Plan ab.
• Regionale Unterschiede: Verfügbarkeit und Performance-Charakteristika können je Region variieren.

Best Practice

Führen Sie ein „Limit-Inventar“: Welche Managed Services sind im Pfad? Welche dokumentierten Limits und welche Monitoring-Metriken gibt es? Damit verkürzen Sie Incident-Zeiten erheblich.

Praktische Troubleshooting-Checkliste: Wenn Throughput niedriger ist als erwartet

• 1) Scope klären: Geht es um VM↔VM intern, VM↔Internet, VM↔Storage, oder über LB/NAT/VPN?
• 2) CPU prüfen: Ist Sender oder Empfänger CPU-limitiert (insbesondere bei TLS/IPsec/Kompression)?
• 3) Single vs. Multi Stream testen: iperf3 einmal mit 1 Stream, dann mit mehreren parallelen Streams.
• 4) Paketgröße variieren: PPS-Limit erkennen (kleine Payloads) vs. Bandbreitenlimit (große Payloads).
• 5) Retransmits und Drops: TCP-Retransmits, Interface-Drops, Errors, Queueing analysieren.
• 6) Pfad vereinfachen: Test ohne LB/NAT/Firewall, dann schrittweise Komponenten hinzufügen.
• 7) MTU/MSS validieren: Besonders bei VPN/Overlay; PMTUD/ICMP nicht pauschal blocken.
• 8) Quotas/Limits prüfen: Dienstlimits und Account-Quotas, ggf. Erhöhung beantragen.
• 9) Placement prüfen: Same AZ vs. Cross AZ, ggf. Placement-Optionen nutzen.
• 10) Observability nachziehen: Dashboards für Durchsatz, PPS, Retransmits, LB/NAT/Gateway-Metriken.

Outbound-Links zu relevanten Informationsquellen

• AWS EC2 Instanztypen und Eigenschaften
• AWS Enhanced Networking (ENA) Übersicht
• Azure Accelerated Networking (SR-IOV) Überblick
• Azure VM-Größen und Leistungsmerkmale
• Google Cloud Compute Engine Machine Types
• Google Cloud VPC Dokumentation
• iperf3 Dokumentation
• TCP Spezifikation (RFC 9293)

Wenn Sie Bandwidth-/Throughput-Limits in der Cloud verlässlich „wie erwartet“ erreichen wollen, ist der entscheidende Schritt, Durchsatz als End-to-End-Eigenschaft zu behandeln: nicht nur Instanzgröße, sondern auch TCP/RTT, Parallelität, PPS, Service-Kette, MTU/MSS und Limits. Sobald Sie Messung und Architektur entlang dieser Faktoren strukturieren, verschwinden viele „mysteriöse“ Deckel – und die verbleibenden Limits sind zumindest klar erklärbar und gezielt adressierbar.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.