Site icon bintorosoft.com

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

Red Snapper

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.

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.

Throughput ≈ TCP_Window 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:

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.

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.

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.

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.

Typische Testfehler

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.

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:

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.

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

Outbound-Links zu relevanten Informationsquellen

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:

Lieferumfang:

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.

 

Exit mobile version