Delt Transit Gateway: hvem eier rutene i AWS RAM

Å dele en Transit Gateway med Resource Access Manager gjør én bestemt ting: det lar en annen konto kalle et definert sett attachment-API-er mot en ressurs den ikke eier. Det overfører ikke gatewayen, rutetabellene eller retten til å bestemme hvordan trafikk videresendes. Folk antar det motsatte fordi attachmenten dukker opp i mottakerens konsoll og virker umiddelbart, noe som føles som eierskap. Mekanismen bak er en tillatelsesgivning på en delt ressurs, og hvert underordnet objekt blir innenfor eierens kontogrense. Denne delingen forklarer de fleste tilgangsnektet-sakene rundt delt transitt.

Hva delingen faktisk delegerer

En ressursdeling navngir en ressurs, en principal og en administrert tillatelse. Tillatelsen lister opp handlingene principalen kan utføre, og for en Transit Gateway dekker listen attachment-operasjoner på den delte ressursen.

Alt utenfor listen feiler i API-et i stedet for i konsollen, derfor dukker feilen ofte opp første gang et skript kjøres.

Rutetabeller, tilknytninger og utbredelser blir hos eieren

Videresending avgjøres av tre underordnede objekter: hvilken rutetabell en attachment er knyttet til, hvilke tabeller den utbredes til, og hvilke ruter disse tabellene inneholder. AWS-dokumentasjonen om deling sier at en mottaker ikke kan opprette, endre eller slette transit-gateway-rutetabeller eller tilknytningene og utbredelsene deres gjennom delingen. Disse kallene tilhører eierkontoen. En mottaker som trenger en ny tilknytning, ber om en administrativ endring, ikke om å utøve en tillatelse den glemte å aktivere.

Tabellen nedenfor er delingen jeg skriver i designdokumenter, fordi den overlever personalendringer.

Les den midterste raden nøye: VPC-eieren styrer sine subnett-ruter, gateway-eieren styrer den sentrale videresendingsbeslutningen, og en fungerende sti trenger begge. Ingen av kontiene kan fullføre det alene.

Én sti, to konti

Følg en pakke fra en spoke-VPC til et lokalt prefiks. Spoke-subnett-rutetabellen må sende prefikset til transit-gateway-attachmenten, noe VPC-eieren kan endre. Deretter må gatewayen ha en rute i attachmentens tilknyttede tabell som peker på VPN-attachmenten, noe bare eieren kan endre. Returtrafikk trenger speilbildet av begge. Mangler du én side, får du en sti som er halvinstallert og ser ut som et brannmurproblem.

Skriv begge endringene i én sak med to ansvarlige, ellers blir de ferdige i forskjellige uker.

Bruk Availability Zone-ID-er når plassering betyr noe

Sonenavn er konto-lokale aliaser. us-east-1a i én konto er ikke garantert å være samme fysiske sone som us-east-1a i en annen. Når designet krever en attachment og en arbeidsbelastning i samme sone, sammenlign AZ-ID-er og noter dem.

Å sammenligne navn gir et diagram som ser riktig ut og en latenprofil som ikke gjør det. Kontroller det mens diagrammet fortsatt tegnes, ikke etter at noen har målt forskjellen.

Å fjerne delingen kutter ikke datastien

Å fjerne delingen føles som tilbakekalling, og det er ikke en umiddelbar trafikkstopp. AWS dokumenterer at en attachment forblir funksjonell når gatewayen tas ut av delingen. Tillatelsen til å administrere ressursen forsvinner, mens den eksisterende attachmenten fortsetter å videresende til noen sletter eller deaktiverer den. Planlegg tilbakekalling i to trinn: fjern delingen, deretter attachmenten, og la eieren utføre det andre.

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

Hold delingsposten og rutingposten sammen

To artefakter svarer på to forskjellige spørsmål. Delingsposten sier hvem som kan arbeide med ressursen. Rutetabellene sier hvilke nettverk som faktisk kan snakke sammen. Oppbevar dem sammen med samme eierliste, ellers begynner neste hendelse med at noen beviser en tillatelse som aldri var problemet.

Test deretter én strøm i hver retning og ett prefiks som skal forbli utilgjengelig.