Delt Transit Gateway: hvem ejer ruterne i AWS RAM

At dele en Transit Gateway med Resource Access Manager gør én bestemt ting: det lader en anden konto kalde et defineret sæt attachment-API'er mod en ressource, den ikke ejer. Det overfører ikke gatewayen, dens rutetabeller eller retten til at bestemme, hvordan trafik videresendes. Folk antager det modsatte, fordi attachmenten dukker op i modtagerens konsol og virker med det samme, hvilket føles som ejerskab. Mekanismen bagved er en tilladelsesgivning på en delt ressource, og hvert underordnet objekt bliver inde i ejerens kontogrænse. Den opdeling forklarer de fleste adgangsafviste sager omkring delt transit.

Hvad delingen faktisk delegerer

En ressourcedeling navngiver en ressource, en principal og en administreret tilladelse. Tilladelsen oplister de handlinger, som principalen må udføre, og for en Transit Gateway dækker listen attachment-operationer på den delte ressource.

Alt uden for listen fejler i API'et i stedet for i konsollen, og derfor dukker fejlen ofte op første gang et script kører.

Rutetabeller, tilknytninger og udbredelser bliver hos ejeren

Videresendelse afgøres af tre underordnede objekter: hvilken rutetabel en attachment er knyttet til, hvilke tabeller den udbredes til, og hvilke ruter disse tabeller indeholder. AWS' dokumentation om deling angiver, at en modtager ikke kan oprette, ændre eller slette transit-gateway-rutetabeller eller deres tilknytninger og udbredelser gennem delingen. Disse kald tilhører ejerkontoen. En modtager, der har brug for en ny tilknytning, anmoder om en administrativ ændring, ikke om at udøve en tilladelse, den glemte at aktivere.

Tabellen nedenfor er den opdeling, jeg skriver i designdokumenter, fordi den overlever personaleforandringer.

Læs den midterste række omhyggeligt: VPC-ejeren styrer sine subnetruter, gatewayejeren styrer den centrale videresendelsesbeslutning, og en fungerende sti kræver begge. Ingen af konti kan fuldføre det alene.

Én sti, to konti

Følg en pakke fra en spoke-VPC til et lokalt præfiks. Spoke-subnetrutetabellen skal sende det præfiks til transit-gateway-attachmenten, hvilket VPC-ejeren kan ændre. Gatewayen skal derefter have en rute i attachmentens tilknyttede tabel, der peger på VPN-attachmenten, hvilket kun ejeren kan ændre. Returtrafik kræver spejlbilledet af begge. Mangler du en side, får du en sti, der er halvt installeret og ligner et firewallproblem.

Skriv begge ændringer i én sag med to ansvarlige, ellers bliver de færdige i forskellige uger.

Brug Availability Zone-ID'er, når placering betyder noget

Zonenavne er konto-lokale aliaser. us-east-1a i én konto er ikke garanteret at være den samme fysiske zone som us-east-1a i en anden. Når designet kræver en attachment og en arbejdsbyrde i samme zone, sammenlign AZ-ID'er og noter dem.

At sammenligne navne giver et diagram, der ser rigtigt ud, og en latenprofil, der ikke gør. Kontroller det, mens diagrammet stadig tegnes, ikke efter nogen har målt forskellen.

At fjerne delingen afbryder ikke datastien

At fjerne delingen føles som tilbagekaldelse, og det er ikke et øjeblikkeligt trafikstop. AWS dokumenterer, at en attachment forbliver funktionel, når gatewayen afdeles. Tilladelsen til at administrere ressourcen forsvinder, mens den eksisterende attachment fortsætter med at videresende, indtil nogen sletter eller deaktiverer den. Planlæg tilbagekaldelse i to trin: fjern delingen, fjern derefter attachmenten, og lad ejeren udføre det andet.

Hvis delingen er din eneste kontrol, har du ingen kontrol.

Hold delingsposten og routingposten sammen

To artefakter besvarer to forskellige spørgsmål. Delingsposten siger, hvem der må arbejde med ressourcen. Rutetabellerne siger, hvilke netværk der faktisk kan tale sammen. Opbevar dem sammen med den samme ejerliste, ellers begynder den næste hændelse med, at nogen beviser en tilladelse, der aldrig var problemet.

Test derefter én strøm i hver retning og et præfiks, der skal forblive uopnåeligt.