Dwa konta AWS, jedna sieć lokalna: którą drogą?
Wspólny Transit Gateway, dwa niezależne VPN-y czy jeden wąski proxy: wybieraj według własności i zasięgu skutków, a nie według tego, którą trasę dziś najłatwiej dodać.
Oczywiste ujęcie to peering kontra VPN i jest to ujęcie błędne. VPC połączone peeringiem nie może pożyczyć połączenia VPN sąsiada do routingu od krawędzi do krawędzi, więc ta opcja nigdy nie była na stole, niezależnie od tego, co sugeruje tabela tras. W rzeczywistości wybierasz między wspólnym hubem sieciowym, dwiema niezależnymi ścieżkami VPN i wąskim wejściem aplikacji. Każde odpowiada na inne pytanie o to, kto jest właścicielem routingu.
Trzy opcje i ta, która nie jest opcją
Zacznij od skreślenia pomysłu peeringu, a następnie porównaj to, co zostaje, według własności, a nie według prostoty diagramu. Poniższa tabela to decyzja w skróconej formie.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Jeśli konto A potrzebuje dostępu do całej sieci lokalnej, wiersz z proxy ma niewłaściwy kształt. Jeśli konto A potrzebuje jednego API, pierwsze dwa wiersze to więcej sieci, niż wymaga tego wymaganie.
Kiedy wygrywa wspólny Transit Gateway
Transit Gateway przyłącza każdą VPC i VPN jako odrębne sieci, a udostępnianie między kontami pozwala właścicielom VPC korzystać z huba bez łączenia kont. To jest zachęta: jedno miejsce, w którym lokalne prefiksy spotykają się z sieciami AWS, i jedno miejsce do rozważenia, które przyłączenie uczy się której trasy.
Przyłączenie wszystkiego nie oznacza zezwolenia na wszystko. Skojarzenie i propagacja decydują, które przyłączenie używa której tabeli tras, więc dwa prefiksy VPC mogą każdy dotrzeć do usługi lokalnej, podczas gdy ich wzajemny dostęp pozostaje wykluczony przez projekt huba. Strona lokalna nadal potrzebuje tras powrotnych dla prefiksów AWS, a to jest zgłoszenie zmiany innego zespołu.
Koszt jest organizacyjny równie mocno jak finansowy. Właściciel huba kontroluje relacje routingu, od których zależą inne zespoły, więc zmiana w jednym przyłączeniu może przenieść ruch usługi, o której właściciel huba nigdy nie słyszał. Godziny przyłączenia i przetwarzanie danych sumują się z każdą przyłączoną siecią, dlatego huby zwykle rosną szybciej niż zespół, który nimi zarządza.
Kiedy wygrywają osobne VPN-y lub wąski proxy
Dwa niezależne VPN-y pasują do małego wdrożenia z realnymi granicami operacyjnymi: każde konto zmienia własne tunele i żadne nie może zepsuć drugiego, edytując tabelę tras. Granice leżą po stronie lokalnej. Brama partnerska potrzebuje pojemności na dodatkowe tunele, plany adresów nie mogą się nakładać, a dwie konfiguracje ogłaszające te same prefiksy potrzebują świadomej preferencji, a nie nadziei.
Proxy to najwęższy interfejs. Jeśli konto A potrzebuje jednej bazy danych lub jednego API na koncie B, ograniczony pośrednik daje zdefiniowane wejście z własną historią uwierzytelniania, rejestrowania i dostępności. To także opcja najczęściej nadużywana: pośrednik przekazujący do każdego prywatnego celu stał się nieograniczonym przekaźnikiem z dodatkowymi krokami i nie będzie zachowywał się jak przezroczysty tranzyt z VPC do sieci lokalnej dla niczego innego.
Ograniczenia peeringu VPC warto przeczytać przed tym wszystkim, ponieważ wyjaśniają, dlaczego czwarty pomysł wciąż wraca i dlaczego nie może działać.
Wybierz najwęższy interfejs, który spełnia wymaganie
Uporządkuj pytania: czy A potrzebuje sieci, zestawu sieci czy jednej usługi? Czy lokalny zespół chce jednej ścieżki czy kilku? Kto może zmieniać routing ruchu drugiego zespołu? Pierwsza odpowiedź, która daje najwęższy interfejs, to architektura, a wszystko później to implementacja.
Zapisz odpowiedź wraz z planem prefiksów, własnością tras, inwentarzem tuneli lub przyłączeń i trybem awarii, którego oczekuje każda strona. Kiedy ktoś później zapyta, dlaczego konto A nie może po prostu użyć VPN konta B, ten zapis jest odpowiedzią i oszczędza ci ponownego roztrząsania tych samych trzech opcji w następnym projekcie.