Due account AWS, una rete locale: quale percorso?
Transit Gateway condiviso, due VPN indipendenti o un proxy stretto: scegli in base alla proprietà e al raggio d'impatto, non in base a quale rotta è più facile aggiungere oggi.
L'inquadramento ovvio è peering contro VPN, ed è l'inquadramento sbagliato. Una VPC in peering non può prendere in prestito la connessione VPN del vicino per il routing da bordo a bordo, quindi quell'opzione non è mai stata sul tavolo, qualunque cosa suggerisca una tabella di routing. Ciò che si sceglie davvero è tra un hub di rete condiviso, due percorsi VPN indipendenti e un ingresso applicativo stretto. Ognuno risponde a una domanda diversa su chi possiede il routing.
Tre opzioni e quella che non è un'opzione
Iniziare cancellando l'idea del peering, poi confrontare ciò che resta in base alla proprietà anziché alla semplicità del diagramma. La tabella qui sotto è la decisione in forma compressa.
| 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 |
Se l'account A ha bisogno di raggiungere un'intera rete locale, la riga del proxy ha la forma sbagliata. Se l'account A ha bisogno di una sola API, le prime due righe sono più rete di quanto chieda il requisito.
Quando vince il Transit Gateway condiviso
Un Transit Gateway collega ogni VPC e la VPN come reti separate, e la condivisione tra account consente ai proprietari delle VPC di usare l'hub senza unire gli account. Ecco il richiamo: un unico punto in cui i prefissi locali incontrano le reti AWS, e un unico punto in cui ragionare su quale allegato apprende quale rotta.
Collegare tutto non significa consentire tutto. Associazione e propagazione decidono quale allegato usa quale tabella di routing, quindi due prefissi VPC possono raggiungere ciascuno un servizio locale mentre il loro accesso reciproco resta escluso dal progetto dell'hub. Il lato locale ha comunque bisogno di rotte di ritorno per i prefissi AWS, e questo è un ticket di modifica di un altro team.
Il costo è organizzativo oltre che finanziario. Il proprietario dell'hub controlla relazioni di routing da cui dipendono altri team, quindi una modifica a un allegato può spostare traffico di un servizio di cui il proprietario dell'hub non ha mai sentito parlare. Le ore di allegato e l'elaborazione dei dati si sommano con ogni rete collegata, ed è per questo che gli hub tendono a crescere più in fretta del team che li gestisce.
Quando vincono VPN separate o un proxy stretto
Due VPN indipendenti si adattano a un piccolo dispiegamento con confini operativi reali: ogni account modifica i propri tunnel, e nessuno può rompere l'altro modificando una tabella di routing. I limiti stanno sul lato locale. Il gateway peer ha bisogno di capacità per i tunnel aggiuntivi, i piani di indirizzamento non devono sovrapporsi, e due configurazioni che annunciano gli stessi prefissi hanno bisogno di una preferenza deliberata invece che di speranza.
Un proxy è l'interfaccia più stretta. Se l'account A ha bisogno di un database o di una API nell'account B, un intermediario circoscritto offre un ingresso definito con la propria storia di autenticazione, registrazione e disponibilità. È anche l'opzione più facilmente abusata: un intermediario che inoltra a ogni destinazione privata è diventato un relè senza restrizioni con passaggi extra, e non si comporterà come transito trasparente da VPC a rete locale per nient'altro.
Vale la pena leggere le restrizioni del peering VPC prima di tutto questo, perché spiegano perché la quarta idea continua a tornare e perché non può funzionare.
Scegliete l'interfaccia più stretta che soddisfa il requisito
Ordinate le domande: l'account A ha bisogno di una rete, di un insieme di reti o di un solo servizio? Il team locale vuole un percorso o più? Chi può modificare il routing del traffico dell'altro team? La prima risposta che produce l'interfaccia più stretta è l'architettura, e tutto il resto è implementazione.
Registrate la risposta insieme al piano dei prefissi, alla proprietà delle rotte, all'inventario dei tunnel o degli allegati e alla modalità di guasto che ciascun lato si aspetta. Quando qualcuno chiederà più avanti perché l'account A non può semplicemente usare la VPN dell'account B, quel registro è la risposta, e vi risparmia di ridiscutere le stesse tre opzioni nel prossimo progetto.