Sdílená Transit Gateway: komu patří trasy v AWS RAM

Sdílení Transit Gateway přes Resource Access Manager dělá jednu konkrétní věc: umožňuje jinému účtu volat definovanou sadu API pro připojení vůči prostředku, který nevlastní. Nepřenáší bránu, její směrovací tabulky ani právo rozhodovat, jak se provoz předává. Lidé předpokládají opak, protože se připojení objeví v konzoli příjemce a hned funguje, což vypadá jako vlastnictví. Mechanismus pod tím je udělení oprávnění na sdílený prostředek a každý podřízený objekt zůstává uvnitř hranice účtu vlastníka. Toto rozdělení vysvětluje většinu tiketů s odmítnutým přístupem kolem sdíleného tranzitu.

Co sdílení skutečně deleguje

Sdílení prostředku pojmenovává prostředek, principála a spravované oprávnění. Oprávnění vypisuje akce, které tento principál smí provádět, a pro Transit Gateway tento seznam pokrývá operace připojení ke sdílenému prostředku.

Cokoli mimo seznam selže v API, ne v konzoli, a proto se chyba často objeví při prvním spuštění skriptu.

Směrovací tabulky, asociace a propagace zůstávají vlastníkovi

Předávání určují tři podřízené objekty: se kterou směrovací tabulkou je připojení asociováno, do kterých tabulek se propaguje a jaké trasy tyto tabulky drží. Dokumentace AWS ke sdílení uvádí, že příjemce nemůže přes sdílení vytvářet, upravovat ani mazat směrovací tabulky tranzitní brány ani jejich asociace a propagace. Tyto volání patří účtu vlastníka. Příjemce, který potřebuje novou asociaci, žádá administrativní změnu, nevykonává oprávnění, které zapomněl povolit.

Tabulka níže je rozdělení, které dávám do návrhových dokumentů, protože přežije změny personálu.

Přečtěte si pozorně prostřední řádek: vlastník VPC řídí trasy své podsítě, vlastník brány řídí centrální rozhodnutí o předávání a funkční cesta potřebuje obojí. Žádný z účtů to nedokáže dokončit sám.

Jedna cesta, dva účty

Sledujte paket z spoke VPC k lokálnímu prefixu. Směrovací tabulka spoke podsítě musí poslat tento prefix na připojení tranzitní brány, což vlastník VPC může změnit. Brána pak musí mít v přidružené tabulce připojení trasu ukazující na VPN připojení, což může změnit jen vlastník. Zpětný provoz potřebuje zrcadlo obojího. Vynechejte kteroukoli stranu a dostanete cestu napůl nainstalovanou, která vypadá jako problém s firewallem.

Napište obě změny do jednoho tiketu se dvěma řešiteli, jinak budou dokončeny v různých týdnech.

Používejte ID zón dostupnosti, když záleží na umístění

Názvy zón jsou aliasy místní pro účet. us-east-1a v jednom účtu nemusí být stejná fyzická zóna jako us-east-1a v jiném. Když návrh potřebuje připojení a pracovní zátěž ve stejné zóně, porovnejte ID AZ a zaznamenejte je.

Porovnání názvů vytvoří diagram, který vypadá správně, a profil latence, který správný není. Zkontrolujte to, dokud se diagram ještě kreslí, ne poté, co někdo změří rozdíl.

Zrušení sdílení nepřeruší datovou cestu

Odebrání sdílení působí jako odvolání, ale není to okamžité zastavení provozu. AWS dokumentuje, že připojení zůstává funkční, když brána přestane být sdílena. Oprávnění spravovat prostředek zmizí, zatímco existující připojení dál předává, dokud ho někdo nesmaže nebo nevypne. Naplánujte odvolání ve dvou krocích: odeberte sdílení, pak připojení, přičemž druhý krok provede vlastník.

Pokud je sdílení vaše jediná kontrola, nemáte žádnou kontrolu.

Uchovávejte záznam o sdílení a záznam o směrování pohromadě

Dva artefakty odpovídají na dvě různé otázky. Záznam o sdílení říká, kdo smí s prostředkem pracovat. Směrovací tabulky říkají, které sítě spolu skutečně mohou mluvit. Uložte je společně se stejným seznamem vlastníků, jinak příští incident začne tím, že někdo dokazuje oprávnění, které nikdy nebylo problémem.

Poté otestujte jeden tok v každém směru a jeden prefix, který má zůstat nedostupný.