Hybride Anbindung

Das eigene Rechenzentrum an AWS und Azure anbinden

Ein Site-to-Site-VPN trägt länger, als die meisten annehmen: für Verwaltungszugriffe, Verzeichnisdienste und den Großteil der Fachanwendungen reicht es aus. ExpressRoute oder Direct Connect brauchst du, sobald Datenbanken synchron replizieren, täglich große Datenmengen fließen oder die Latenz vertraglich zugesichert sein muss. Teuer wird beides erst durch den ausgehenden Datenverkehr, und den rechnet fast niemand vorher.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Betriebsingenieur analysiert Kosten- und Monitoring-Dashboards an drei Bildschirmen

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum die Anbindung öfter scheitert als die Migration selbst

Die Verbindung zwischen Rechenzentrum und Cloud ist der Teil des Projekts, der sich am schlechtesten nachträglich korrigieren lässt. Adressbereiche, die sich überschneiden, repariert keine Einstellung, weil weder Azure noch AWS zwei identische Netze auf beiden Seiten einer Verbindung auseinanderhalten können. Wer im Rechenzentrum flächig aus 10.0.0.0/8 vergibt und in der Cloud den Standardvorschlag übernimmt, merkt das erst, wenn die erste Route nicht mehr eindeutig ist. Der Umbau danach betrifft jede Firewallregel, jedes Monitoring-Ziel und jede fest eingetragene IP-Adresse in einer Fachanwendung.

Die zweite Hürde ist die Beschaffung. Ein Site-to-Site-VPN steht an einem Nachmittag, eine dedizierte Leitung braucht einen Carrier, eine Kreuzverbindung im Rechenzentrum des Providers und je nach Standort mehrere Wochen bis Monate Vorlauf. Wer die Entscheidung vertagt, baut faktisch auf VPN und muss die Leitung später im laufenden Betrieb nachziehen. Das funktioniert, ist aber ein zweites Projekt mit eigenem Wartungsfenster, eigenem Routing-Umbau und einem Zeitraum, in dem beide Wege parallel überwacht werden müssen.

Der dritte Punkt taucht erst in der Rechnung auf. Datenverkehr in die Cloud hinein ist kostenlos, Datenverkehr heraus wird je Gigabyte berechnet. Eine Sicherung, die täglich mehrere Terabyte aus der Cloud ins eigene Rechenzentrum zieht, kostet mehr als die Leitung, über die sie läuft. Dazu kommt die Namensauflösung: Solange Cloud-Ressourcen die internen Namen nicht auflösen und die internen Systeme die Cloud-Zonen nicht kennen, scheitern Domänenbeitritt, Zertifikatsprüfung und ein guter Teil der Fachanwendungen, obwohl das Netz nachweislich steht.

Miniatur-Szene: Leitstand mit steigender Kostenanzeige, Münzstapel neben einer Cloud, Lupe über einem Leck

Sechs Schritte zur belastbaren Anbindung

01 Bandbreite, Latenz und Datenmengen messen
02 Adressplan je Region festlegen und dokumentieren
03 Site-to-Site-VPN mit BGP aufbauen
04 Namensauflösung in beide Richtungen einrichten
05 Zweiten Pfad ergänzen und den Ausfall testen
06 Bei Bedarf auf ExpressRoute oder Direct Connect wechseln

Was du mitnimmst

Die Reihenfolge, in der die Entscheidungen fallen sollten

Netz zuerst, Dienste danach. Jede Abkürzung an dieser Stelle rächt sich in dem Moment, in dem der erste produktive Dienst umgezogen ist und niemand mehr umbauen will.

Adressplan vor der ersten Ressource

Reserviere je Region einen zusammenhängenden Bereich, der sich mit nichts im Rechenzentrum überschneidet, und führe ihn zentral. Rechne großzügig: Ein VNet oder eine VPC lässt sich zwar erweitern, die Subnetzschnitte darin aber nicht beliebig verschieben. Adressbereiche für Kubernetes-Dienste und Pods gehören von Anfang an in den Plan, sie sind der häufigste Nachzügler.

VPN als Standard, Leitung nach Bedarf

Ein Site-to-Site-VPN über IPsec deckt Verwaltungszugriffe, Verzeichnisdienste, Dateizugriffe und die meisten Fachanwendungen ab. Eine dedizierte Leitung, also ExpressRoute bei Azure oder Direct Connect bei AWS, brauchst du bei synchroner Replikation, bei großen täglichen Datenmengen, bei Sprach- und Videodiensten und überall dort, wo die Latenz vertraglich zugesichert sein muss.

BGP statt statischer Routen

Mit BGP lernen beide Seiten die Netze der Gegenseite, und ein ausgefallener Tunnel führt automatisch zum Umschwenken auf den zweiten. Statische Routen funktionieren im Labor und werden in dem Moment zum Problem, in dem jemand ein neues Subnetz anlegt und die Gegenseite nichts davon erfährt. Plane eine eigene AS-Nummer aus dem privaten Bereich mit ein.

Namensauflösung in beide Richtungen

Azure löst das mit dem Private DNS Resolver samt eingehendem und ausgehendem Endpunkt, AWS mit Route 53 Resolver Endpoints und Weiterleitungsregeln. Beides ersetzt die früher üblichen Weiterleitungs-VMs, die niemand patchen wollte. Ohne diesen Baustein scheitern Domänenbeitritt, Zertifikatsprüfung und alles, was auf interne Namen statt auf IP-Adressen zeigt.

Redundanz, die getestet ist

Zwei Tunnel zu zwei Endpunkten sind Pflicht, weil die Anbieter ihre Gateways planmäßig warten. Bei dedizierten Leitungen gehören zwei Kreuzverbindungen an zwei Standorten dazu, sonst ist der Provider der alleinige Ausfallpunkt, unabhängig vom SLA der Cloud. Der Nachweis ist kein Diagramm, sondern ein Test, bei dem ein Pfad im laufenden Betrieb abgeschaltet wird.

Kosten vorher rechnen

Ein Gateway kostet je Stunde, unabhängig von der Last, und bei ExpressRoute kommen die Gebühren des Providers zusätzlich zum Port hinzu. Dazu addiert sich der ausgehende Datenverkehr, der über eine dedizierte Leitung je Gigabyte deutlich günstiger ist als über das Internet. Erst beide Posten zusammen ergeben den Vergleich, der die Entscheidung trägt.

Tutorial

Von der Messung bis zum getesteten Ausfall

Ein Site-to-Site-VPN trägt länger, als die meisten annehmen, eine dedizierte Leitung brauchst du erst bei synchroner Replikation, großen täglichen Datenmengen oder vertraglich zugesicherter Latenz. Teuer wird beides durch den ausgehenden Datenverkehr, und den rechnet fast niemand vorher. Deshalb läuft ein Netzprojekt hier in dieser Reihenfolge: Bedarf messen, Adressplan festlegen, VPN mit BGP aufbauen, Namensauflösung einrichten, zweiten Pfad ergänzen und den Ausfall testen, jeweils mit Azure und AWS nebeneinander.

Schritt 1: Bandbreite und Latenz messen, nicht schätzen

Die Entscheidung zwischen VPN und Leitung hängt an drei Zahlen: Spitzenbandbreite, tolerierbare Latenz und Datenmenge je Tag. Alle drei lassen sich vorher messen, statt sie im Entwurf zu behaupten.

Ist-Zustand am Übergang aufnehmen

# Latenz und Paketverlust zum naechstgelegenen Cloud-Standort
mtr -rwzc 100 ec2.eu-central-1.amazonaws.com

# Durchsatz zwischen zwei Endpunkten pruefen
iperf3 -s                      # auf der Gegenseite starten
iperf3 -c 10.60.1.10 -t 30 -P 4

# Tatsaechliches Volumen am Uebergang ueber Zaehler mitschreiben
nft list ruleset | grep -B2 counter
vnstat -i eth0 -d

Die Latenz nach Frankfurt liegt aus den meisten deutschen Rechenzentren im niedrigen einstelligen Millisekundenbereich, nach Amsterdam oder Dublin deutlich höher. Für synchrone Datenbankreplikation ist genau diese Zahl das Ausschlusskriterium, nicht die Bandbreite.

Wann ein VPN reicht und wann nicht

Anforderung	Site-to-Site-VPN	ExpressRoute oder Direct Connect
Verwaltungszugriff, Verzeichnisdienst, Dateizugriff	Reicht aus	Überdimensioniert
Dauerhaft mehrere hundert MBit/s Nutzlast	Nur mit mehreren Tunneln und ECMP	Klar im Vorteil
Synchrone Replikation, Sprache, Video	Latenz nicht zugesichert	Erforderlich
Großer täglicher Datenabfluss aus der Cloud	Teuer über den Internet-Egress	Deutlich günstiger je Gigabyte
Vorlaufzeit bis zur Inbetriebnahme	Stunden	Wochen bis Monate
Vertraglich zugesicherte Verfügbarkeit	Begrenzt und abhängig vom Internetpfad	Im SLA des Anbieters geregelt

Schritt 2: Adressplan und Subnetze anlegen

Der Adressplan ist die einzige Entscheidung in diesem Projekt, die sich später nicht mehr korrigieren lässt, ohne alles andere anzufassen.

Azure: VNet mit vorgeschriebenem Gateway-Subnetz

az group create -n rg-hub -l germanywestcentral

az network vnet create -g rg-hub -n vnet-hub \
  --address-prefixes 10.60.0.0/16 \
  --subnet-name snet-app --subnet-prefixes 10.60.1.0/24

# Der Name GatewaySubnet ist vorgeschrieben, lieber /27 als /29 waehlen
az network vnet subnet create -g rg-hub --vnet-name vnet-hub \
  -n GatewaySubnet --address-prefixes 10.60.255.0/27

Azure erkennt das Gateway-Subnetz ausschließlich am Namen GatewaySubnet. Ein /29 ist zwar erlaubt, lässt aber keinen Platz für ExpressRoute im selben Netz und lässt sich nicht vergrößern, solange ein Gateway darin liegt.

AWS: VPC und Transit Gateway als zentraler Übergang

VPC=$(aws ec2 create-vpc --cidr-block 10.61.0.0/16 --query Vpc.VpcId --output text)
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.61.1.0/24 --availability-zone eu-central-1a
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.61.2.0/24 --availability-zone eu-central-1b

TGW=$(aws ec2 create-transit-gateway --description hub \
  --options AmazonSideAsn=64512 --query TransitGateway.TransitGatewayId --output text)

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id $TGW --vpc-id $VPC --subnet-ids subnet-0aaa subnet-0bbb

Das Transit Gateway lohnt sich, sobald mehr als eine VPC angebunden wird. Es kostet eine Stundengebühr je Anhang und eine Gebühr je verarbeitetem Gigabyte, dafür entfällt das Geflecht aus einzelnen Peerings und die Routen liegen an einer Stelle.

Schritt 3: Site-to-Site-VPN mit BGP aufbauen

Beide Anbieter arbeiten nach demselben Muster: Gateway auf Cloud-Seite, Beschreibung der Gegenstelle, Verbindung mit gemeinsamem Schlüssel. Der Unterschied steckt fast nur in den Bezeichnungen.

Azure: Gateway, Gegenstelle und Verbindung

az network public-ip create -g rg-hub -n pip-vpngw \
  --sku Standard --allocation-method Static --zone 1 2 3

az network vnet-gateway create -g rg-hub -n vpngw-hub \
  --vnet vnet-hub --gateway-type Vpn --vpn-type RouteBased \
  --sku VpnGw2AZ --public-ip-addresses pip-vpngw --asn 65515

az network local-gateway create -g rg-hub -n lgw-rz1 \
  --gateway-ip-address 203.0.113.10 \
  --local-address-prefixes 192.168.0.0/16 \
  --asn 65010 --bgp-peering-address 192.168.255.1

az network vpn-connection create -g rg-hub -n cn-rz1 \
  --vnet-gateway1 vpngw-hub --local-gateway2 lgw-rz1 \
  --shared-key "$PSK" --enable-bgp

Das Anlegen des Gateways dauert bis zu fünfundvierzig Minuten, plane das Wartungsfenster entsprechend. Die gewählte SKU bestimmt Durchsatz und Anzahl der möglichen Tunnel und ist der einzige Wert, den du später schwer änderst.

AWS: Customer Gateway und VPN-Verbindung

CGW=$(aws ec2 create-customer-gateway --type ipsec.1 \
  --public-ip 203.0.113.10 --bgp-asn 65010 \
  --query CustomerGateway.CustomerGatewayId --output text)

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id $CGW --transit-gateway-id $TGW \
  --options TunnelInsideIpVersion=ipv4

# Zustand beider Tunnel pruefen
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]' \
  --output table

AWS legt grundsätzlich zwei Tunnel je Verbindung an, und beide gehören konfiguriert. Ein einzelner aktiver Tunnel ist im Alltag unauffällig und genau das, was bei der nächsten planmäßigen Wartung des Anbieters ausfällt.

Auf der eigenen Seite gegenprüfen

swanctl --list-sas
swanctl --list-conns

# Lernt BGP die Cloud-Netze wirklich?
vtysh -c 'show bgp summary'
vtysh -c 'show ip route bgp'

Aus der anderen Richtung zeigen az network vnet-gateway list-bgp-peer-status und az network vnet-gateway list-learned-routes dasselbe Bild. Stimmen die gelernten Präfixe auf beiden Seiten überein, ist die Verbindung fertig. Fehlt ein Präfix, liegt es fast immer an einer Filterregel und nicht am Tunnel.

Schritt 4: Namensauflösung in beide Richtungen

Ohne funktionierende Namensauflösung ist die Verbindung technisch vorhanden und fachlich wertlos. Beide Anbieter haben dafür inzwischen einen verwalteten Dienst, der die früheren Weiterleitungs-VMs ersetzt.

Azure Private DNS Resolver

az extension add --name dns-resolver

# Je ein eigenes Subnetz fuer eingehende und ausgehende Aufloesung
az network vnet subnet create -g rg-hub --vnet-name vnet-hub \
  -n snet-dns-in --address-prefixes 10.60.250.0/28
az network vnet subnet create -g rg-hub --vnet-name vnet-hub \
  -n snet-dns-out --address-prefixes 10.60.250.16/28

VNET_ID=$(az network vnet show -g rg-hub -n vnet-hub --query id -o tsv)
az dns-resolver create -g rg-hub -n dnsr-hub -l germanywestcentral --id "$VNET_ID"

az dns-resolver inbound-endpoint list -g rg-hub --dns-resolver-name dnsr-hub -o table

Der eingehende Endpunkt bekommt eine IP aus dem Cloud-Netz, die du im Rechenzentrum als Weiterleitungsziel für die Cloud-Zonen einträgst. Der ausgehende Endpunkt zeigt über eine Weiterleitungsregel auf deine internen DNS-Server. Beide Subnetze dürfen ausschließlich diesem Zweck dienen, andere Ressourcen darin lehnt Azure ab.

AWS Route 53 Resolver mit Weiterleitungsregel

aws route53resolver create-resolver-endpoint --direction OUTBOUND \
  --name out-rz --creator-request-id "$(date +%s)" \
  --security-group-ids sg-0abc \
  --ip-addresses SubnetId=subnet-0aaa SubnetId=subnet-0bbb

aws route53resolver create-resolver-rule --rule-type FORWARD \
  --name fw-intern --domain-name intern.example \
  --creator-request-id "$(date +%s)" \
  --resolver-endpoint-id rslvr-out-0abc \
  --target-ips Ip=192.168.10.5,Port=53 Ip=192.168.10.6,Port=53

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-0abc --vpc-id $VPC

Für die Gegenrichtung brauchst du zusätzlich einen eingehenden Endpunkt, dessen IP-Adressen auf den DNS-Servern im Rechenzentrum als Weiterleitung für die Cloud-Zonen eingetragen werden. Denk an die Sicherheitsgruppen: UDP und TCP auf Port 53 aus den jeweiligen Quellnetzen, sonst antwortet nichts.

Schritt 5: Zweiter Pfad, Ausfalltest und Kostenkontrolle

Eine Anbindung ohne getesteten Ausfall ist eine Annahme. Und eine Anbindung ohne Blick auf den ausgehenden Datenverkehr wird zur Überraschung in der nächsten Rechnung.

Vor der Freigabe für den produktiven Betrieb

Zwei Tunnel zu zwei unabhängigen Endpunkten, beide aktivAnbieter warten ihre Gateways planmäßig. Mit nur einem aktiven Tunnel wird die Wartung des Anbieters zu deinem Ausfall.
Beide Pfade einmal im laufenden Betrieb abschaltenErst der Test zeigt, ob BGP wirklich umschwenkt und wie lange das dauert. Ein Netzdiagramm zeigt das nie.
BGP statt statischer Routen auf beiden SeitenNeue Subnetze werden sonst nur auf einer Seite bekannt, und der Fehler fällt erst im Betrieb auf, meist bei der ersten neuen Anwendung.
Bei dedizierten Leitungen zwei Kreuzverbindungen an zwei StandortenEine einzelne Leitung macht den Provider zum alleinigen Ausfallpunkt, unabhängig vom SLA der Cloud.
Überwachung auf Tunnelzustand und BGP-Sitzung, nicht nur auf PingEin Tunnel kann stehen, während Routen fehlen. Ein Ping, der über den zweiten Pfad läuft, verdeckt genau das.
Maximale Paketgröße und MSS-Clamping prüfenIPsec verkleinert die nutzbare Paketgröße. Ohne angepasste MSS brechen große Übertragungen ab, während Ping und Anmeldung problemlos funktionieren.

Was der Weg nach draußen kostet

# AWS: Kosten nach Nutzungsart, der Abfluss steht unter DataTransfer-Out
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

# Azure: laufender Monat, taeglich aufgeloest
az costmanagement query --type ActualCost \
  --scope "/subscriptions/$SUB_ID" \
  --timeframe MonthToDate --dataset-granularity Daily

Bei AWS sind die ersten 100 GB ausgehender Datenverkehr je Monat frei, danach gilt der Listenpreis je Gigabyte. Über Direct Connect beziehungsweise ExpressRoute liegt der Preis je Gigabyte deutlich niedriger, was eine Leitung ab einer bestimmten Datenmenge allein über die Übertragungskosten rechtfertigt. Wie du solche Posten systematisch aufschlüsselst, steht auf Cloud-Kosten analysieren.

Passende Kurse

Kurse zu hybrider Netzanbindung bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

AZ-700 Kurs: Entwerfen und Implementieren von Microsoft Azure-Netzwerklösungen (AZ-700T00) 3 Tage Präsenz nächster Termin 09.11.2026 Zum Kurs Networking Essentials for Cloud Applications on AWS 1 Tag Präsenz nächster Termin 14.09.2026 Zum Kurs CompTIA CloudNetX: CNX-001-Training mit Labs 4 Tage Präsenz nächster Termin 21.09.2026 Zum Kurs AZ-800 Training: Administering Windows Server Hybrid Core Infrastructure (AZ-800T00) 4 Tage Präsenz nächster Termin 03.08.2026 Garantietermin Zum Kurs AZ-801 Training: Configuring Windows Server Hybrid Advanced Services (AZ-801T00) 4 Tage Präsenz nächster Termin 15.09.2026 Zum Kurs AZ-305: Designing Microsoft Azure Infrastructure Solutions (AZ-305T00) 4 Tage Präsenz nächster Termin 24.08.2026 Garantietermin Zum Kurs

Unverbindlich beraten lassen Alle Azure-Kurse ansehen

Gut zu wissen

Häufige Fragen zu hybrider Netzanbindung

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Wann reicht ein VPN und wann brauche ich ExpressRoute oder Direct Connect?

Ein Site-to-Site-VPN reicht für Verwaltungszugriffe, Verzeichnisdienste, Dateizugriffe und die meisten Fachanwendungen, also für den Großteil der hybriden Szenarien. Eine dedizierte Leitung brauchst du, sobald Datenbanken synchron replizieren, große Datenmengen täglich in beide Richtungen fließen, Sprache und Video übertragen werden oder die Latenz vertraglich zugesichert sein muss. Der zweite Grund ist kaufmännisch: Ab einer bestimmten Menge ausgehender Daten ist die Leitung allein über den günstigeren Preis je Gigabyte gerechtfertigt.

Wie groß muss der Adressbereich in der Cloud sein?

Plane je Region einen zusammenhängenden Bereich, der die absehbare Entwicklung der nächsten Jahre abdeckt, in der Regel ein /16. Rechne Subnetze für Arbeitslasten, für Gateways, für private Endpunkte, für Verwaltung und für Kubernetes getrennt. Gerade die Adressbereiche für Pods und Dienste werden regelmäßig vergessen und sind später der Grund, warum ein zusätzliches VNet nötig wird. Ein VNet oder eine VPC lässt sich zwar um weitere Bereiche erweitern, die bestehenden Subnetzschnitte aber nicht mehr verschieben.

Was passiert, wenn sich Adressbereiche überschneiden?

Die Verbindung kommt entweder gar nicht zustande, oder der Verkehr verschwindet lautlos, weil die lokale Route immer Vorrang vor der gelernten hat. Eine Übersetzung zwischen zwei identischen Netzen bieten weder Azure noch AWS an. In der Praxis bleibt nur der Umbau auf einer der beiden Seiten, und der betrifft Firewallregeln, Überwachung, Sicherungsziele und jede Anwendung mit fest eingetragener IP-Adresse. Deshalb gehört der Adressplan an den Anfang und in eine zentrale Verwaltung, nicht in eine Tabelle auf einem Laufwerk.

Was kostet die Anbindung im Monat?

Bei einem VPN zahlst du das Gateway je Stunde, unabhängig von der Last, dazu den ausgehenden Datenverkehr je Gigabyte. Bei ExpressRoute oder Direct Connect kommen der Port, die Gebühr des Providers für die Anbindung und je nach Tarif der übertragene Datenverkehr hinzu. Die Übertragungskosten sind der Posten, der in Entwürfen am häufigsten fehlt. Rechne ihn aus gemessenen Werten, nicht aus einer Annahme, denn Sicherungen und Datenabgleiche verschieben die Summe schnell um eine Größenordnung.

Welcher Kurs passt zu diesem Thema?

Für Azure ist AZ-700 der passende Kurs, er behandelt VNets, VPN, ExpressRoute, Lastverteilung und die private Anbindung von Diensten. Microsoft hat die zugehörige Zertifizierung laut Microsoft Learn zum 27. Juli 2026 aktualisiert, die Inhalte sind also aktuell. Auf AWS-Seite passt Networking Essentials for Cloud Applications on AWS, und wer anbieterübergreifend arbeitet, findet in CompTIA CloudNetX die herstellerneutrale Ergänzung. Für hybride Windows-Landschaften kommen AZ-800 und AZ-801 dazu.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.

Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“

“

Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.

Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.