Condividere una Transit Gateway con Resource Access Manager fa una cosa precisa: consente a un altro account di chiamare un insieme definito di API di collegamento su una risorsa che non possiede. Non trasferisce il gateway, le sue tabelle di routing o il diritto di decidere come viene inoltrato il traffico. Le persone suppongono il contrario perché il collegamento compare nella console del destinatario e funziona subito, il che sembra una proprietà. Il meccanismo sottostante è una concessione di autorizzazione su una risorsa condivisa, e ogni oggetto figlio resta dentro il confine dell'account del proprietario. Questa separazione spiega la maggior parte dei ticket di accesso negato intorno al transito condiviso.

Cosa delega davvero la condivisione

Una condivisione di risorse nomina una risorsa, un principal e un'autorizzazione gestita. L'autorizzazione elenca le azioni che quel principal può eseguire, e per una Transit Gateway quell'elenco copre le operazioni di collegamento sulla risorsa condivisa.

Qualsiasi cosa fuori dall'elenco fallisce nell'API anziché nella console, ed è per questo che l'errore compare spesso al primo avvio di uno script.

Le tabelle di routing, le associazioni e le propagazioni restano al proprietario

L'inoltro è deciso da tre oggetti figli: a quale tabella di routing è associato un collegamento, in quali tabelle propaga e quali rotte contengono quelle tabelle. La documentazione AWS sulla condivisione afferma che un destinatario non può creare, modificare o eliminare le tabelle di routing del transit gateway né le loro associazioni e propagazioni tramite la condivisione. Quelle chiamate appartengono all'account proprietario. Un destinatario che ha bisogno di una nuova associazione sta chiedendo un cambiamento amministrativo, non esercitando un'autorizzazione che ha dimenticato di abilitare.

La tabella qui sotto è la separazione che metto nei documenti di progettazione, perché sopravvive ai cambi di personale.

RoleWhat it controls
Transit Gateway ownerThe gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here.
VPC owner using the shareIts own attachment, subnet route tables and security policy for the workloads.
Shared-subnet participantWorkload traffic only, following routes the VPC owner already set.

Leggi con attenzione la riga centrale: il proprietario della VPC controlla le rotte della propria subnet, il proprietario del gateway controlla la decisione centrale di inoltro, e un percorso funzionante ha bisogno di entrambi. Nessuno dei due account può completarlo da solo.

Un percorso, due account

Segui un pacchetto da una VPC spoke a un prefisso locale. La tabella di routing della subnet spoke deve inviare quel prefisso al collegamento del transit gateway, cosa che il proprietario della VPC può cambiare. Poi il gateway deve avere nella tabella associata del collegamento una rotta che punta al collegamento VPN, cosa che solo il proprietario può cambiare. Il traffico di ritorno ha bisogno dello specchio di entrambe. Se manca uno dei due lati ottieni un percorso installato a metà che sembra un problema di firewall.

Scrivi entrambe le modifiche in un solo ticket con due assegnatari, altrimenti verranno completate in settimane diverse.

Usa gli ID delle zone di disponibilità quando il posizionamento conta

I nomi delle zone sono alias locali all'account. us-east-1a in un account non è garantito essere la stessa zona fisica di us-east-1a in un altro. Quando il progetto richiede un collegamento e un carico di lavoro nella stessa zona, confronta gli ID AZ e annotali.

Confrontare i nomi produce un diagramma che sembra corretto e un profilo di latenza che non lo è. Verificalo mentre il diagramma è ancora in fase di disegno, non dopo che qualcuno ha misurato la differenza.

Annullare la condivisione non taglia il percorso dei dati

Rimuovere la condivisione sembra una revoca, e non è un arresto immediato del traffico. AWS documenta che un collegamento resta funzionante quando il gateway non è più condiviso. L'autorizzazione a gestire la risorsa scompare, mentre il collegamento esistente continua a inoltrare finché qualcuno non lo elimina o lo disabilita. Pianifica la revoca in due passaggi: rimuovi la condivisione, poi il collegamento, con il proprietario che esegue il secondo.

Se la condivisione è il tuo unico controllo, non hai alcun controllo.

Tieni insieme il record di condivisione e il record di routing

Due artefatti rispondono a due domande diverse. Il record di condivisione dice chi può lavorare con la risorsa. Le tabelle di routing dicono quali reti possono davvero parlare. Conservali insieme con lo stesso elenco di proprietari, altrimenti il prossimo incidente inizierà con qualcuno che dimostra un'autorizzazione che non è mai stata il problema.

Poi prova un flusso in ogni direzione e un prefisso che deve restare irraggiungibile.

Articoli correlati