Două conturi AWS, o rețea locală: ce cale?

Cadrul evident este peering versus VPN, și este cadrul greșit. Un VPC împerecheat nu poate împrumuta conexiunea VPN a vecinului pentru rutare de la margine la margine, așa că acea opțiune nu a fost niciodată pe masă, indiferent ce sugerează un tabel de rute. Ceea ce alegeți de fapt este între un hub de rețea partajat, două căi VPN independente și o intrare îngustă de aplicație. Fiecare răspunde la o altă întrebare despre cine deține rutarea.

Trei opțiuni și cea care nu este o opțiune

Începeți prin a șterge ideea de peering, apoi comparați ce rămâne după proprietate, nu după simplitatea diagramei. Tabelul de mai jos este decizia în formă comprimată.

Dacă contul A are nevoie de acces la o rețea locală întreagă, rândul cu proxy are forma greșită. Dacă contul A are nevoie de un singur API, primele două rânduri sunt mai multă rețea decât cere cerința.

Când câștigă Transit Gateway partajat

Un Transit Gateway atașează fiecare VPC și VPN-ul ca rețele separate, iar partajarea între conturi le permite proprietarilor de VPC să folosească hubul fără a fuziona conturile. Acesta este avantajul: un singur loc unde prefixele locale întâlnesc rețelele AWS și un singur loc pentru a raționa ce atașament învață ce rută.

A atașa tot nu înseamnă a permite tot. Asocierea și propagarea decid ce atașament folosește ce tabel de rute, astfel încât două prefixe VPC pot ajunge fiecare la un serviciu local în timp ce accesul lor reciproc rămâne exclus de proiectarea hubului. Partea locală are în continuare nevoie de rute de retur pentru prefixele AWS, iar asta este un tichet de modificare al altei echipe.

Costul este organizațional la fel de mult ca financiar. Proprietarul hubului controlează relații de rutare de care depind alte echipe, așa că o modificare la un atașament poate muta traficul unui serviciu de care proprietarul hubului nu a auzit niciodată. Orele de atașament și procesarea datelor se adună cu fiecare rețea pe care o atașați, motiv pentru care huburile tind să crească mai repede decât echipa care le operează.

Când câștigă VPN-uri separate sau un proxy îngust

Două VPN-uri independente se potrivesc unei implementări mici cu limite operaționale reale: fiecare cont își schimbă propriile tuneluri și niciunul nu îl poate strica pe celălalt editând un tabel de rute. Limitele sunt de partea locală. Gateway-ul pereche are nevoie de capacitate pentru tunelurile suplimentare, planurile de adrese nu trebuie să se suprapună, iar două configurații care anunță aceleași prefixe au nevoie de o preferință deliberată, nu de speranță.

Un proxy este interfața cea mai îngustă. Dacă contul A are nevoie de o bază de date sau de un API în contul B, un intermediar delimitat oferă o intrare definită cu propria poveste de autentificare, jurnalizare și disponibilitate. Este și opțiunea cea mai predispusă la utilizare greșită: un intermediar care redirecționează către fiecare destinație privată a devenit un releu nerestricționat cu pași în plus și nu se va comporta ca un tranzit transparent de la VPC la rețeaua locală pentru nimic altceva.

Merită citite restricțiile de peering ale VPC înainte de toate acestea, pentru că explică de ce a patra idee revine mereu și de ce nu poate funcționa.

Alegeți interfața cea mai îngustă care satisface cerința

Ordonați întrebările: are A nevoie de o rețea, de un set de rețele sau de un singur serviciu? Vrea echipa locală o singură cale sau mai multe? Cine are voie să schimbe rutarea traficului celeilalte echipe? Primul răspuns care produce interfața cea mai îngustă este arhitectura, iar tot ce urmează este implementare.

Înregistrați răspunsul împreună cu planul de prefixe, proprietatea rutelor, inventarul tunelurilor sau atașamentelor și modul de eșec pe care îl așteaptă fiecare parte. Când cineva întreabă mai târziu de ce contul A nu poate folosi pur și simplu VPN-ul contului B, acea înregistrare este răspunsul și vă scutește de a rejudeca aceleași trei opțiuni în proiectul următor.