WAN-Design: SD-WAN vs. MPLS vs. Internet-Only – Entscheidungsmatrix

WAN-Design ist heute weniger eine Frage von „welche Leitung kaufen wir“, sondern eine Architekturentscheidung, die Sicherheit, Nutzererlebnis, Cloud-Strategie und Betriebskosten langfristig prägt. Unternehmen stehen dabei häufig vor drei Grundoptionen: klassisches MPLS, SD-WAN (oft als Overlay über Internet und/oder MPLS) oder ein Internet-Only-WAN mit direktem SaaS/Cloud-Zugriff. Jede Option kann „richtig“ sein – abhängig von Applikationsprofilen, Standortlandschaft, Sicherheitsarchitektur, regulatorischen Anforderungen und operativer Reife. Genau hier entstehen in der Praxis Fehlentscheidungen: MPLS wird als „automatisch zuverlässig“ angenommen, SD-WAN als „magische Performance-Lösung“ verkauft oder Internet-Only als „billig und modern“ eingeführt, ohne Egress-Sicherheit, Observability und Failover-Verhalten sauber zu planen. Ein belastbares WAN-Design braucht deshalb eine Entscheidungsmatrix, die nicht auf Marken oder Trends basiert, sondern auf messbaren Anforderungen: Verfügbarkeit, Latenz/Jitter/Loss, kritische Servicepfade (User→SaaS, Site→DC/Cloud), Change-Frequenz, Providerrealität und Security-Governance. Dieser Artikel liefert eine praxistaugliche Entscheidungsmatrix für SD-WAN vs. MPLS vs. Internet-Only, zeigt typische Designmuster und benennt die wichtigsten Fallstricke, damit die Wahl im Betrieb standhält – nicht nur im PowerPoint.

Begriffe sauber trennen: Was genau wird verglichen?

Viele Diskussionen werden unproduktiv, weil Begriffe unscharf bleiben. Für eine Entscheidungsmatrix ist es hilfreich, die Optionen als Architekturmodelle zu definieren.

• MPLS-WAN: Providerbasiertes WAN, typischerweise als private IP-VPN-Services mit definierten Klassen (QoS), oft mit zentralen Hubs und kontrollierten Übergängen zu Internet/Cloud.
• SD-WAN: Ein Overlay, das mehrere Underlays (MPLS, Internet, LTE/5G) nutzen kann und Pfadwahl, Steering, Verschlüsselung und Policies zentral steuert. SD-WAN ist selten „statt“ MPLS, sondern häufig „über“ Internet und/oder MPLS.
• Internet-Only: Standorte nutzen ausschließlich Internetzugänge (ggf. dual), erreichen SaaS/Cloud direkt und verbinden sich zu internen Services über VPN/SD-WAN-Tunnel oder Zero-Trust-Zugänge.

Wichtig: „Internet-Only“ ist kein Synonym für „ohne Security“. In modernen Architekturen gehört ein abgesichertes Egress-Modell (z. B. Secure Web Gateway/SASE) fast immer dazu. Eine gute Orientierung für Sicherheitsgrundlagen und Kontrollziele bieten die CIS Controls.

Die Leitfrage: Welche Services müssen Sie garantieren?

WAN-Design ist dann belastbar, wenn es an Servicepfaden ausgerichtet ist, nicht an Leitungen. Typische Pfade, die in die Entscheidungsmatrix gehören:

• User → SaaS: Microsoft 365, CRM, Collaboration, Branchenplattformen.
• User → DC/Private Cloud: klassische Client-Server-Apps, Legacy, zentrale Daten.
• Site → Site: Filiale zu Filiale, Produktion zu Zentrale, Peer-Kommunikation.
• Remote User → Apps: VPN/Zero Trust, Performance und Stabilität in hybriden Arbeitsmodellen.
• Operational Traffic: Monitoring, Logging, Management, Updates, Backups.

Wenn Sie diese Pfade als Service Level Objectives (SLOs) ausdrücken können (z. B. Verfügbarkeit, P95-Latenz, maximaler Loss), wird die Entscheidung deutlich objektiver. Eine verständliche Einführung in SLO-Denken bietet Site Reliability Engineering.

Entscheidungsmatrix: Kriterien, die wirklich unterscheiden

Eine praxistaugliche Matrix bewertet Optionen entlang weniger, aber aussagekräftiger Dimensionen. Die folgenden Kriterien haben sich in Enterprise-Projekten besonders bewährt:

• Servicequalität: Latenz/Jitter/Loss, Stabilität unter Last, Performance im Failover.
• Resilienz: N-1/N-2-Fähigkeit, Provider-Diversität, deterministisches Failover.
• Security & Compliance: Segmentierung, Encryption, Logging, Kontrollpunkte, Nachweisfähigkeit.
• Cloud-Alignment: Direkter SaaS-Zugriff, Cloud On-Ramps, Egress-Strategie, DNS.
• Operability: Monitoring/Telemetry, Troubleshooting, Change- und Rollback-Fähigkeit, Automatisierung.
• Cost & Contracting: Leitungs- und Providerkosten, SLA-Modell, Lieferzeiten, Vendor Lock-in.

MPLS-WAN: Wann es (immer noch) überzeugt

MPLS ist in vielen Organisationen nicht „alt“, sondern ein etabliertes Modell für vorhersehbare Servicequalität, klare QoS-Klassen und managed Provider-SLAs. MPLS kann besonders stark sein, wenn standortübergreifende, latenzkritische oder stark regulierte Kommunikation im Vordergrund steht und die Providerqualität historisch gut ist.

• Stärken: Predictability durch Provider-Klassen, klare SLA-Strukturen, häufig stabile Latenz und niedriger Loss.
• Stärken: Einfache Hub-Spoke-Kontrolle, gut integrierbar in klassische Sicherheitsperimeter.
• Schwächen: Kosten, lange Lieferzeiten, weniger flexibel bei SaaS-First; Breakouts sind häufig zentralisiert und erzeugen Hairpinning.
• Schwächen: Skalierung und Agilität: neue Standorte oder kurzfristige Kapazitätserhöhungen sind oft träge.

Typische MPLS-Designmuster

• Hub-and-Spoke: Zentrale Hubs, klare Steuerung, gut für Legacy und zentrale Security.
• Dual-Hub (georedundant): Reduziert Blast Radius, aber erhöht Routing- und Betriebslogik.
• MPLS + Internet Breakout: Hybridmodell, in dem SaaS lokal ausbricht, aber interne Pfade über MPLS laufen.

SD-WAN: Wann es der beste Architekturhebel ist

SD-WAN ist besonders wertvoll, wenn Sie mehrere Underlays intelligent nutzen möchten: Internet als kostengünstiges Transportmedium, MPLS als „Premium“-Pfad für definierte Klassen und LTE/5G als Backup. Der echte Nutzen entsteht durch zentrale Policy-Steuerung, Applikationserkennung, Performance-basiertes Steering und standardisierte Rollouts.

• Stärken: Multi-Transport, dynamische Pfadwahl, zentrale Policy-Modelle, schnelle Rollouts und bessere Standortagilität.
• Stärken: Verschlüsselung over-the-top, segmentierte Overlays, häufig gute Telemetrie für Pfadqualität.
• Schwächen: Komplexität verschiebt sich ins Overlay: Policy-Sprawl, Troubleshooting und Vendor-spezifische Implementierungsdetails sind Risiken.
• Schwächen: Qualität hängt stark von Underlay-Realität ab; „Internet“ ist nicht automatisch gut, und Failover unter Last muss getestet werden.

SD-WAN-Designmuster, die sich bewähren

• Dual Internet + SD-WAN: Zwei diverse Provider, SD-WAN steuert nach Loss/Latenz/Jitter; oft die effektivste Kosten-/Resilienz-Kombination.
• MPLS + Internet + SD-WAN: Übergangsmodell, bei dem kritische Klassen über MPLS laufen und SaaS/Best Effort über Internet.
• Regional Hubs / Cloud Gateways: Statt zentralem Hairpinning werden regionale Aggregationspunkte oder Cloud On-Ramps genutzt.

Internet-Only: Wann es sinnvoll ist und wann es gefährlich wird

Internet-Only ist attraktiv, weil es Kosten senken und SaaS/Cloud-Performance verbessern kann – vorausgesetzt, Security, Observability und Resilienz sind sauber designt. In vielen Organisationen ist Internet-Only kein „Minimalmodell“, sondern ein modernes Design, das mit SASE/SWG, Zero Trust und klaren Traffic-Policies kombiniert wird.

• Stärken: Direkter SaaS-Zugriff, kurze Pfade, gute Agilität bei neuen Standorten, oft niedrigere Kosten.
• Stärken: Provider-Diversität ist leichter erreichbar (lokale Business-Internet-Angebote, 5G als Backup).
• Schwächen: Qualität ist variabel; ohne Telemetrie und Steering werden Voice/Real-Time und kritische Apps unzuverlässig.
• Schwächen: Security muss explizit sein (Egress, DNS, Identity, Logging), sonst entstehen große Compliance- und Risiko-Lücken.

Internet-Only-Designmuster

• Local Breakout + SWG/SASE: Standort geht direkt ins Internet, Security wird über Cloud-Security-Edge oder lokale Security umgesetzt.
• Internet-Only + Overlay für interne Apps: Interne Pfade laufen über verschlüsselte Tunnels/SD-WAN oder Zero-Trust-Zugänge.
• Dual Internet + 5G Failover: Hohe Verfügbarkeit mit diverser Last Mile, wenn Failover-Tests und QoS-Konzepte existieren.

Decision Matrix in der Praxis: Typische „Wenn-Dann“-Regeln

Statt abstrakter Pro/Contra-Listen hilft eine klare Zuordnung nach Rahmenbedingungen. Die folgenden Regeln sind bewusst pragmatisch formuliert und sollten mit Messwerten validiert werden.

• Wenn SaaS dominiert und Standorte schnell wachsen müssen: SD-WAN oder Internet-Only mit sauberem Egress- und Security-Modell ist meist vorteilhaft.
• Wenn viele latenzkritische, standortübergreifende Legacy-Apps existieren: MPLS oder SD-WAN mit „Premium“-Pfad (MPLS oder sehr hochwertiges Internet) ist oft stabiler.
• Wenn Compliance, Nachweisbarkeit und zentrale Kontrolle sehr hoch sind: MPLS oder SD-WAN mit klaren zentralen Kontrollpunkten, strikter Policy-Governance und Logging-Standards.
• Wenn Providerqualität stark schwankt: SD-WAN mit Performance-Steering und Dual-Underlay reduziert Risiko deutlich.
• Wenn Betriebsteam klein ist und Standards fehlen: Ein zu komplexes SD-WAN-Policy-Modell kann mehr schaden als nutzen; dann sind klare, einfache Muster entscheidend.

Failover-Realität: Warum „zwei Leitungen“ nicht automatisch Resilienz bedeutet

Unabhängig von der gewählten WAN-Option ist Failover-Verhalten einer der häufigsten blinden Flecken. Besonders bei Voice und Echtzeit ist nicht nur „Connectivity“ wichtig, sondern Degradation unter Failover-Last. Planen Sie daher immer für N-1 und messen Sie den Service-Impact.

• Provider-Diversität prüfen: Zwei Leitungen sind wertlos, wenn sie dieselbe Trasse, denselben PoP oder denselben Carrier teilen.
• Headroom im Failover: Wenn beide Links im Normalbetrieb stark ausgelastet sind, führt Failover zu Überlast, Jitter und Drops.
• Stateful Pfade: NAT, Proxies, zentrale Firewalls und VPN-Gateways können Sessions bei Pfadwechsel brechen; Symmetrie ist relevant.
• Degradation erkennen: Link „up“ kann unbrauchbar sein (Loss, Jitter). Ohne Probes/Telemetry wird zu spät reagiert.

Security-Architektur als Entscheidungsfaktor

WAN-Entscheidungen sind heute eng mit Security-Architekturen verbunden. Zentraler Perimeter vs. verteilte Egress-Edges, Zero Trust vs. klassische VPNs, Logging und Forensik – all das bestimmt, ob MPLS, SD-WAN oder Internet-Only im Betrieb „rund“ wirkt.

• Egress-Strategie: zentraler Breakout bündelt Risiken und erzeugt Hairpinning; dezentraler Breakout erfordert konsistente Security über alle Standorte.
• Segmentierung: VRFs/Overlays für User, IoT, OT, Management; Microsegmentierung setzt ein klares Zonenmodell voraus.
• Encryption: SD-WAN liefert häufig Ende-zu-Ende-Verschlüsselung; bei MPLS wird Verschlüsselung oft zusätzlich benötigt (abhängig von Anforderungen).
• Logging/Telemetry: Ohne zentrale Sichtbarkeit sind Internet-Only-Modelle schwer auditierbar; definieren Sie Mindest-Logs und Retention.

Cloud- und SaaS-Alignment: Der häufigste Treiber für Veränderungen

Viele WAN-Modernisierungen werden durch SaaS und Cloud ausgelöst. Klassische MPLS-Hubmodelle erzeugen dabei oft unnötige Umwege: User→Hub→Internet→SaaS. Das verschlechtert Latenz, erhöht Kosten und überlastet zentrale Kontrollpunkte. Moderne Modelle setzen auf direkte Pfade, aber mit Steuerung und Security.

• Local Breakout: Direkter SaaS-Zugang aus dem Standort, sofern Security und DNS sauber sind.
• Cloud On-Ramps: Regionale Übergänge in Cloud-Plattformen reduzieren Latenz und vereinfachen Routing.
• DNS als Steuerinstrument: Viele SaaS-Optimierungen hängen von DNS-Strategien und Resolver-Platzierung ab.
• Servicepfade messen: Latenz/Jitter/Loss zu SaaS-Endpoints kontinuierlich beobachten, nicht nur Link-Utilization.

Operability: Was das Betriebsteam wirklich leisten muss

Die „beste“ WAN-Architektur ist die, die Ihr Betriebsteam zuverlässig betreiben kann. SD-WAN kann Komplexität reduzieren, wenn Standards und Automation existieren – oder sie massiv erhöhen, wenn Policies unkontrolliert wachsen. MPLS kann einfach wirken, wenn der Provider viel übernimmt – oder schwierig, wenn interne Security- und Cloud-Anforderungen ständig Sonderwege erzwingen.

• Policy-Governance: Wenige wiederverwendbare Klassen statt individueller Regeln pro Anwendung.
• Observability: End-to-End-Probes, Flow-Daten, Logs und klare Dashboards pro kritischem Pfad.
• Change-Disziplin: Staged Rollouts, getestete Rollbacks, Drift-Kontrolle (Standards vs. Abweichungen).
• Runbooks: Degradation-Erkennung, Provider-Eskalation, Failover-Tests, Incident-Diagnose.

Kostenmodell: TCO statt „Leitungspreis“

In der Entscheidungsmatrix sollten Kosten nicht nur als monatliche Leitungsgebühr betrachtet werden. Total Cost of Ownership umfasst Betrieb, Tooling, Security-Services, Ausfallkosten, Lieferzeiten und Vertragsrisiken.

• Direkte Kosten: Leitungen, CPE/Edges, Lizenzen, Security-Services (SWG/SASE), Monitoring.
• Indirekte Kosten: Projektaufwand, Betriebsaufwand, Training, Vendor Lock-in, Komplexitätskosten.
• Ausfallkosten: Produktivitätsverlust bei SaaS-Ausfällen, Voice-Degradation, Produktionsunterbrechungen.
• Time-to-Deliver: Lieferzeiten für MPLS vs. schnelle Aktivierung von Internet/5G kann strategisch entscheidend sein.

Praxis-Blueprints: Drei robuste Zielbilder

• Blueprint A: MPLS-zentriert mit kontrolliertem Breakout
  • Für stark regulierte Umgebungen oder stabile Legacy-Lasten
  • Zentrale Hubs, QoS-Klassen, definierte Internet-/Cloud-Edges
  • Risikofokus: Hairpinning, Kapazitätsengpässe an zentralen Kontrollpunkten
• Blueprint B: SD-WAN Hybrid (MPLS + Internet)
  • Für schrittweise Migration, Performance-Steering und bessere Agilität
  • Applikationsbasierte Pfadwahl, klare Serviceklassen, Dual-Underlay
  • Risikofokus: Policy-Sprawl, Testpflicht im Failover, Standardisierung
• Blueprint C: Internet-Only mit SASE/SWG und Overlay
  • Für SaaS-first und schnell wachsende Standortlandschaften
  • Direkter Breakout, Security als Service, verschlüsselte Tunnels zu internen Apps
  • Risikofokus: Providerqualität, Observability, konsistente Security-Governance

Test- und Abnahmekatalog: Damit die Entscheidung im Betrieb trägt

Egal welche Option Sie wählen: Ohne Tests bleibt WAN-Design ein Versprechen. Ein praxistauglicher Abnahmekatalog umfasst nicht nur „Connectivity“, sondern degradierte Zustände und Failover unter Last.

• Failover-Tests: Link/Provider-Ausfall, Umschaltzeiten, Session-Stabilität, Voice-Qualität.
• Degradation-Tests: Loss/Jitter/Latenzspikes; prüfen, ob Steering und QoS die kritischen Klassen schützt.
• Security-Tests: Logging-Vollständigkeit, DNS/Egress-Policies, Segmentierungswirksamkeit.
• Peak-Tests: Replikation/Backups + Usertraffic; Hotspot- und Queue-Drops überwachen.
• Rollback-Tests: Änderungen rückgängig machen können, ohne neue Instabilität zu erzeugen.

Checkliste: Entscheidungsmatrix für SD-WAN vs. MPLS vs. Internet-Only

• Servicepfade definiert: User→SaaS, User→DC/Cloud, Site→Site, Remote→Apps mit messbaren Zielen.
• Providerrealität verstanden: Diversität, PoPs, Trassen, Performance in Peaks und degradieren Zuständen.
• Failover geplant und getestet: N-1-Headroom, Session-Stabilität, Voice/Real-Time-Impact.
• Security-Modell klar: Egress-Strategie, Segmentierung, Encryption, Logging, Auditierbarkeit.
• Cloud-Alignment umgesetzt: Breakout/On-Ramps/DNS-Strategie vermeiden Hairpinning und verbessern SaaS-Performance.
• Operability gesichert: Standards, Policy-Governance, Observability, Runbooks, Change-Disziplin.
• TCO bewertet: Leitungen + Lizenzen + Security-Services + Betriebsaufwand + Ausfallkosten.
• Rollout in Wellen: Pilot → regionale Wellen → Skalierung, mit klaren Exit-Kriterien und Rollback.

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.