Delt Transit Gateway: kven eig rutene i AWS RAM

Å dele ein Transit Gateway med Resource Access Manager gjer éin bestemd ting: det lèt ein annan konto kalle eit definert sett attachment-API-ar mot ein ressurs han ikkje eig. Det overfører ikkje gatewayen, rutetabellane eller retten til å avgjere korleis trafikk blir vidaresend. Folk trur det motsette fordi attachmenten dukkar opp i konsollen til mottakaren og verkar med ein gong, noko som kjennest som eigarskap. Mekanismen bak er ei løyvegjeving på ein delt ressurs, og kvart underordna objekt blir innanfor kontogrensa til eigaren. Denne delinga forklarer dei fleste tilgangsnekta-sakene rundt delt transitt.

Kva delinga faktisk delegerer

Ei ressursdeling namngjev ein ressurs, ein principal og ei styrt løyve. Løyvet listar opp handlingane principalen kan utføre, og for ein Transit Gateway dekkjer lista attachment-operasjonar på den delte ressursen.

Alt utanfor lista feilar i API-et i staden for i konsollen, difor dukkar feilen ofte opp første gongen eit skript køyrer.

Rutetabellar, tilknytingar og utbreiingar blir hos eigaren

Vidaresending blir avgjord av tre underordna objekt: kva rutetabell ein attachment er knytt til, kva tabellar han blir utbreidd til, og kva ruter desse tabellane inneheld. AWS-dokumentasjonen om deling seier at ein mottakar ikkje kan opprette, endre eller slette rutetabellar for transit-gatewayen eller tilknytingane og utbreiingane deira gjennom delinga. Desse kalla høyrer til eigarkontoen. Ein mottakar som treng ei ny tilknyting, ber om ei administrativ endring, ikkje om å bruke eit løyve han gløymde å slå på.

Tabellen nedanfor er delinga eg skriv i designdokument, fordi ho overlever personalendringar.

Les den midterste rada nøye: VPC-eigaren styrer rutene i subnettet sitt, gateway-eigaren styrer den sentrale vidaresendingsavgjerda, og ein fungerande sti treng begge. Ingen av kontoane kan fullføre det åleine.

Éin sti, to kontoar

Følg ein pakke frå ein spoke-VPC til eit lokalt prefiks. Rutetabellen til spoke-subnettet må sende prefikset til transit-gateway-attachmenten, noko VPC-eigaren kan endre. Deretter må gatewayen ha ei rute i den tilknytte tabellen til attachmenten som peikar på VPN-attachmenten, noko berre eigaren kan endre. Returtrafikk treng spegelbiletet av begge. Manglar du éi side, får du ein sti som er halvinstallert og ser ut som eit brannmurproblem.

Skriv begge endringane i éi sak med to ansvarlege, elles blir dei ferdige i ulike veker.

Bruk Availability Zone-ID-ar når plassering betyr noko

Sonenamn er konto-lokale alias. us-east-1a i éin konto er ikkje garantert den same fysiske sona som us-east-1a i ein annan. Når designet krev ein attachment og ein arbeidslast i same sone, samanlikn AZ-ID-ar og noter dei.

Å samanlikne namn gir eit diagram som ser rett ut og ein latenprofil som ikkje gjer det. Kontroller det medan diagrammet enno blir teikna, ikkje etter at nokon har målt skilnaden.

Å fjerne delinga kuttar ikkje datastien

Å fjerne delinga kjennest som tilbakekalling, og det er ikkje ein augneblikkeleg trafikkstopp. AWS dokumenterer at ein attachment held fram med å verke når gatewayen blir teken ut av delinga. Løyvet til å styre ressursen forsvinn, medan den eksisterande attachmenten held fram med å senda vidare til nokon slettar eller deaktiverer han. Planlegg tilbakekalling i to steg: fjern delinga, deretter attachmenten, og lat eigaren utføre det andre.

Viss delinga er den einaste kontrollen din, har du ingen kontroll.

Hald delingsposten og rutingsposten saman

To artefaktar svarar på to ulike spørsmål. Delingsposten seier kven som kan arbeide med ressursen. Rutetabellane seier kva nettverk som faktisk kan snakke saman. Oppbevar dei saman med den same eigarlista, elles byrjar neste hending med at nokon beviser eit løyve som aldri var problemet.

Test deretter éin straum i kvar retning og eitt prefiks som skal halde fram med å vere utilgjengeleg.