Transit Gateway partagé : à qui appartiennent les routes dans AWS RAM

Partager une Transit Gateway avec Resource Access Manager fait une chose précise : cela permet à un autre compte d’appeler un ensemble défini d’API d’attachement sur une ressource qu’il ne possède pas. Cela ne transfère ni la passerelle, ni ses tables de routes, ni le droit de décider comment le trafic est acheminé. Les gens supposent le contraire parce que l’attachement apparaît dans la console du destinataire et fonctionne immédiatement, ce qui donne l’impression d’une propriété. Le mécanisme sous-jacent est une autorisation accordée sur une ressource partagée, et chaque objet enfant reste à l’intérieur de la frontière du compte propriétaire. Cette séparation explique la plupart des tickets d’accès refusé autour du transit partagé.

Ce que le partage délègue réellement

Un partage de ressources nomme une ressource, un principal et une autorisation gérée. L’autorisation énumère les actions que ce principal peut effectuer, et pour une Transit Gateway cette liste couvre les opérations d’attachement sur la ressource partagée.

Tout ce qui sort de la liste échoue au niveau de l’API plutôt que dans la console, ce qui explique pourquoi l’erreur apparaît souvent au premier lancement d’un script.

Les tables de routes, les associations et les propagations restent au propriétaire

L’acheminement est décidé par trois objets enfants : la table de routes à laquelle un attachement est associé, les tables dans lesquelles il propage et les routes que ces tables contiennent. La documentation AWS sur le partage indique qu’un destinataire ne peut ni créer, ni modifier, ni supprimer les tables de routes de la passerelle de transit, ni leurs associations et propagations, via le partage. Ces appels appartiennent au compte propriétaire. Un destinataire qui a besoin d’une nouvelle association demande un changement administratif, il n’exerce pas une autorisation qu’il a oublié d’activer.

Le tableau ci-dessous est la séparation que je mets dans les documents de conception, parce qu’elle survit aux changements de personnel.

Lisez attentivement la ligne du milieu : le propriétaire du VPC contrôle les routes de son sous-réseau, le propriétaire de la passerelle contrôle la décision centrale d’acheminement, et un chemin fonctionnel a besoin des deux. Aucun des deux comptes ne peut le terminer seul.

Un chemin, deux comptes

Suivez un paquet d’un VPC spoke vers un préfixe local. La table de routes du sous-réseau spoke doit envoyer ce préfixe vers l’attachement de la passerelle de transit, ce que le propriétaire du VPC peut modifier. La passerelle doit ensuite avoir, dans la table associée de l’attachement, une route pointant vers l’attachement VPN, ce que seul le propriétaire peut modifier. Le trafic de retour a besoin du miroir des deux. Ratez l’un des deux côtés et vous obtenez un chemin à moitié installé qui ressemble à un problème de pare-feu.

Écrivez les deux changements dans un seul ticket avec deux responsables, sinon ils seront terminés des semaines différentes.

Utilisez les ID de zone de disponibilité quand le placement compte

Les noms de zone sont des alias locaux au compte. us-east-1a dans un compte n’est pas garanti comme la même zone physique que us-east-1a dans un autre. Lorsque la conception exige un attachement et une charge de travail dans la même zone, comparez les ID de zone de disponibilité et notez-les.

Comparer les noms produit un schéma qui semble correct et un profil de latence qui ne l’est pas. Vérifiez-le pendant que le schéma est encore dessiné, pas après que quelqu’un a mesuré la différence.

Annuler le partage ne coupe pas le chemin des données

Retirer le partage ressemble à une révocation, et ce n’est pas un arrêt immédiat du trafic. AWS documente qu’un attachement reste fonctionnel lorsque la passerelle n’est plus partagée. L’autorisation de gérer la ressource disparaît, tandis que l’attachement existant continue d’acheminer jusqu’à ce que quelqu’un le supprime ou le désactive. Planifiez la révocation en deux étapes : retirez le partage, puis l’attachement, le propriétaire effectuant la seconde.

Si le partage est votre seul contrôle, vous n’avez pas de contrôle.

Gardez l’enregistrement du partage et celui du routage ensemble

Deux artefacts répondent à deux questions différentes. L’enregistrement du partage dit qui peut travailler avec la ressource. Les tables de routes disent quels réseaux peuvent réellement communiquer. Conservez-les ensemble avec la même liste de propriétaires, sinon le prochain incident commencera avec quelqu’un qui prouve une autorisation qui n’a jamais été le problème.

Testez ensuite un flux dans chaque direction et un préfixe qui doit rester inaccessible.