Zwei AWS-Konten, ein lokales Netz: Welcher Weg?

Die naheliegende Einordnung ist Peering gegen VPN, und sie ist falsch. Eine gepeerte VPC kann die VPN-Verbindung ihres Nachbarn nicht für Edge-to-Edge-Routing ausleihen, diese Option stand also nie zur Debatte, egal was eine Routentabelle nahelegt. Tatsächlich wählen Sie zwischen einem gemeinsamen Netzwerk-Hub, zwei unabhängigen VPN-Pfaden und einem schmalen Anwendungseinstieg. Jede beantwortet eine andere Frage dazu, wer das Routing besitzt.

Drei Optionen und die, die keine ist

Löschen Sie zuerst die Peering-Idee und vergleichen Sie dann das Verbleibende nach Eigentum statt nach Einfachheit des Diagramms. Die folgende Tabelle ist die Entscheidung in komprimierter Form.

Wenn Konto A ein ganzes lokales Netz erreichen muss, hat die Proxy-Zeile die falsche Form. Wenn Konto A eine API braucht, sind die ersten beiden Zeilen mehr Netz, als die Anforderung verlangt.

Wann das gemeinsame Transit Gateway gewinnt

Ein Transit Gateway bindet jede VPC und das VPN als getrennte Netze an, und kontenübergreifendes Teilen lässt die VPC-Eigentümer den Hub nutzen, ohne Konten zusammenzulegen. Das ist der Reiz: eine Stelle, an der die lokalen Präfixe auf die AWS-Netze treffen, und eine Stelle, an der sich begründen lässt, welcher Anhang welche Route lernt.

Alles anzubinden heißt nicht, alles zu erlauben. Assoziation und Propagation entscheiden, welcher Anhang welche Routentabelle nutzt, sodass zwei VPC-Präfixe jeweils einen lokalen Dienst erreichen können, während ihr gegenseitiger Zugriff durch das Design des Hubs ausgeschlossen bleibt. Die lokale Seite braucht weiterhin Rückrouten für die AWS-Präfixe, und das ist ein Änderungsticket eines anderen Teams.

Die Kosten sind organisatorisch wie finanziell. Der Hub-Eigentümer steuert Routing-Beziehungen, von denen andere Teams abhängen, eine Änderung an einem Anhang kann also Verkehr für einen Dienst verschieben, von dem der Hub-Eigentümer nie gehört hat. Anhangstunden und Datenverarbeitung summieren sich mit jedem angebundenen Netz, deshalb wachsen Hubs meist schneller als das Team, das sie betreibt.

Wann getrennte VPNs oder ein schmaler Proxy gewinnen

Zwei unabhängige VPNs passen zu einer kleinen Bereitstellung mit echten Betriebsgrenzen: Jedes Konto ändert seine eigenen Tunnel, und keines kann das andere durch Bearbeiten einer Routentabelle beschädigen. Die Grenzen liegen auf der lokalen Seite. Das Peer-Gateway braucht Kapazität für die zusätzlichen Tunnel, die Adresspläne dürfen sich nicht überschneiden, und zwei Konfigurationen, die dieselben Präfixe ankündigen, brauchen eine bewusste Präferenz statt Hoffnung.

Ein Proxy ist die schmalste Schnittstelle. Wenn Konto A eine Datenbank oder eine API in Konto B braucht, gibt ein abgegrenzter Vermittler einen definierten Einstieg mit eigener Geschichte zu Authentifizierung, Protokollierung und Verfügbarkeit. Es ist auch die Option, die am ehesten missbraucht wird: Ein Vermittler, der an jedes private Ziel weiterleitet, ist zu einem unbeschränkten Relay mit Zusatzschritten geworden, und er verhält sich für alles andere nicht wie transparenter Verkehr von der VPC ins lokale Netz.

Die VPC-Peering-Beschränkungen lohnen sich vor all dem, weil sie erklären, warum die vierte Idee immer wiederkehrt und warum sie nicht funktionieren kann.

Wählen Sie die schmalste Schnittstelle, die die Anforderung erfüllt

Ordnen Sie die Fragen: Braucht A ein Netz, eine Menge von Netzen oder einen Dienst? Will das lokale Team einen Pfad oder mehrere? Wer darf das Routing für den Verkehr des anderen Teams ändern? Die erste Antwort, die die schmalste Schnittstelle ergibt, ist die Architektur, und alles danach ist Umsetzung.

Halten Sie die Antwort mit dem Präfixplan, dem Routeneigentum, dem Tunnel- oder Anhangsinventar und dem Ausfallmodus fest, den jede Seite erwartet. Wenn später jemand fragt, warum Konto A nicht einfach das VPN von Konto B nutzen kann, ist diese Aufzeichnung die Antwort, und sie erspart Ihnen, dieselben drei Optionen im nächsten Projekt erneut zu verhandeln.