Wie würdest du ein On-Premises-Rechenzentrum an eine Cloud-VPC anbinden?

Ein Site-to-Site-VPN über das Internet ist schnell aufgesetzt, verschlüsselt und billig, aber Bandbreite und Latenz hängen am öffentlichen Internet. Eine dedizierte Leitung gibt dir konstanten Durchsatz und niedrigere Latenz, kostet mehr und hat Wochen Vorlauf. Viele Organisationen fahren die dedizierte Leitung mit VPN als automatischem Backup. Was auch immer du wählst: plan nicht überlappende Adressbereiche, Routing und DNS-Auflösung in beide Richtungen, bevor du anfängst.

Es gibt zwei echte Optionen. Ein Site-to-Site-VPN läuft über das Internet, ist an einem Nachmittag fertig und für moderaten, toleranten Traffic in Ordnung, aber du erbst, was das Internet an dem Tag gerade treibt. Eine dedizierte Leitung gibt dir vorhersehbare Bandbreite und Latenz, was du für gesprächige Protokolle oder Massentransfer brauchst, aber sie kostet mehr und die Bereitstellung dauert Wochen, sie ist also nie die Antwort auf ein dringendes Problem. Der übliche Landepunkt ist die dedizierte Leitung als Primary mit einem VPN als automatischem Failover, eine billige Versicherung für eine Leitung, die irgendwann jemand mit einem Bagger durchtrennt. Vorher will ich die Adressierung geklärt haben, denn wenn der On-Premises-Bereich sich mit dem VPC-Bereich überschneidet, hängst du für immer in NAT-Workarounds. Routing muss in beide Richtungen propagieren und gefiltert sein, damit ich nicht mehr ankündige als beabsichtigt. DNS ist der Teil, der vergessen wird: Cloud-Workloads müssen interne Namen auflösen und umgekehrt, ich richte also Forwarding-Regeln in beide Richtungen ein. Sobald mehr als ein paar VPCs das brauchen, läuft alles über einen Transit-Hub statt über ein Netz aus Peerings.