Delad Transit Gateway: vem äger rutterna i AWS RAM

Att dela en Transit Gateway med Resource Access Manager gör en specifik sak: det låter ett annat konto anropa en definierad uppsättning attachment-API:er mot en resurs det inte äger. Det överför inte gatewayen, dess rutetabeller eller rätten att avgöra hur trafik vidarebefordras. Folk antar motsatsen eftersom attachmenten dyker upp i mottagarens konsol och fungerar direkt, vilket känns som ägande. Mekanismen bakom är ett tillståndsbeviljande på en delad resurs, och varje underordnat objekt stannar inom ägarens kontogräns. Den uppdelningen förklarar de flesta åtkomstnekade ärenden kring delad transit.

Vad delningen faktiskt delegerar

En resursdelning namnger en resurs, en principal och ett hanterat tillstånd. Tillståndet listar de åtgärder som principalen får utföra, och för en Transit Gateway omfattar listan attachment-operationer på den delade resursen.

Allt utanför listan misslyckas i API:et i stället för i konsolen, därför dyker felet ofta upp första gången ett skript körs.

Rutetabeller, associeringar och spridningar stannar hos ägaren

Vidarebefordran avgörs av tre underordnade objekt: vilken rutetabell en attachment är associerad med, vilka tabeller den sprids till och vilka rutter dessa tabeller innehåller. AWS dokumentation om delning anger att en mottagare inte kan skapa, ändra eller ta bort transit-gatewayns rutetabeller eller deras associeringar och spridningar genom delningen. Dessa anrop tillhör ägarkontot. En mottagare som behöver en ny associering begär en administrativ ändring, inte utövar ett tillstånd den glömde aktivera.

Tabellen nedan är uppdelningen jag sätter i designdokument, eftersom den överlever personalbyten.

Läs den mittersta raden noga: VPC-ägaren styr sina subnät-rutter, gateway-ägaren styr det centrala vidarebefordransbeslutet, och en fungerande väg behöver båda. Inget av kontona kan slutföra det ensamt.

En väg, två konton

Följ ett paket från en spoke-VPC till ett lokalt prefix. Spoke-subnätets rutetabell måste skicka prefixet till transit-gateway-attachmenten, vilket VPC-ägaren kan ändra. Därefter måste gatewayen ha en rutt i attachmentens associerade tabell som pekar på VPN-attachmenten, och det kan bara ägaren ändra. Returtrafik behöver spegelbilden av båda. Missar du någon sida får du en halvinstallerad väg som ser ut som ett brandväggsproblem.

Skriv båda ändringarna i ett ärende med två ansvariga, annars blir de klara olika veckor.

Använd Availability Zone-ID:n när placering spelar roll

Zonnamn är kontolokala alias. us-east-1a i ett konto är inte garanterat samma fysiska zon som us-east-1a i ett annat. När designen kräver en attachment och en arbetsbelastning i samma zon, jämför AZ-ID:n och anteckna dem.

Att jämföra namn ger ett diagram som ser rätt ut och en latensprofil som inte gör det. Kontrollera det medan diagrammet fortfarande ritas, inte efter att någon mätt skillnaden.

Att ta bort delningen kapar inte datavägen

Att ta bort delningen känns som ett återkallande, och det är inte ett omedelbart trafikstopp. AWS dokumenterar att en attachment förblir funktionell när gatewayen tas ur delningen. Tillståndet att hantera resursen försvinner, medan den befintliga attachmenten fortsätter vidarebefordra tills någon tar bort eller inaktiverar den. Planera återkallandet i två steg: ta bort delningen, sedan attachmenten, och ägaren utför det andra.

Om delningen är din enda kontroll har du ingen kontroll.

Håll delningsposten och routingposten tillsammans

Två artefakter svarar på två olika frågor. Delningsposten säger vem som får arbeta med resursen. Rutetabellerna säger vilka nätverk som faktiskt kan prata. Förvara dem tillsammans med samma ägarlista, annars börjar nästa incident med att någon bevisar ett tillstånd som aldrig var problemet.

Testa sedan ett flöde i varje riktning och ett prefix som ska förbli onåbart.