Gedeelde Transit Gateway: wie bezit de routes in AWS RAM
RAM-deling laat een ander account een VPC koppelen, maar routetabellen, associaties en propagaties blijven bij de gateway-eigenaar. Hier ligt de grens.
Een Transit Gateway delen met Resource Access Manager doet één specifiek ding: het laat een ander account een gedefinieerde set attachment-API's aanroepen tegen een resource die het niet bezit. Het draagt de gateway, de routetabellen of het recht om te bepalen hoe verkeer wordt doorgestuurd niet over. Mensen denken van wel omdat de attachment in de console van de ontvanger verschijnt en meteen werkt, wat als eigendom voelt. Het mechanisme eronder is een machtiging op een gedeelde resource, en elk child-object blijft binnen de accountgrens van de eigenaar. Die splitsing verklaart de meeste toegang-geweigerd-tickets rond gedeeld transit.
Wat de deling feitelijk delegeert
Een resource share benoemt een resource, een principal en een beheerde machtiging. De machtiging somt de acties op die die principal mag uitvoeren, en voor een Transit Gateway omvat die lijst attachment-operaties op de gedeelde resource.
Alles buiten de lijst faalt bij de API in plaats van in de console, daarom verschijnt de fout vaak bij de eerste keer dat een script draait.
Routetabellen, associaties en propagaties blijven bij de eigenaar
Doorgifte wordt bepaald door drie child-objecten: aan welke routetabel een attachment is gekoppeld, in welke tabellen het propageert en welke routes die tabellen bevatten. De deel-documentatie van AWS stelt dat een ontvanger geen routetabellen van de transit-gateway of hun associaties en propagaties via de deling kan aanmaken, wijzigen of verwijderen. Die aanroepen horen bij het eigenaaraccount. Een ontvanger die een nieuwe associatie nodig heeft, vraagt om een administratieve wijziging en oefent geen machtiging uit die hij vergat in te schakelen.
De tabel hieronder is de splitsing die ik in ontwerpdocumenten zet, omdat die personeelswisselingen overleeft.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
Lees de middelste rij aandachtig: de VPC-eigenaar beheert de routes van zijn subnet, de gateway-eigenaar beheert de centrale doorgiftebeslissing, en een werkend pad heeft beide nodig. Geen van beide accounts kan het alleen afmaken.
Eén pad, twee accounts
Volg een pakket van een spoke-VPC naar een lokaal prefix. De routetabel van het spoke-subnet moet dat prefix naar de transit-gateway-attachment sturen, wat de VPC-eigenaar kan wijzigen. Daarna moet de gateway in de gekoppelde tabel van de attachment een route hebben die naar de VPN-attachment wijst, wat alleen de eigenaar kan wijzigen. Terugverkeer heeft de spiegel van beide nodig. Mist één kant en je krijgt een half geïnstalleerd pad dat op een firewallprobleem lijkt.
Schrijf beide wijzigingen in één ticket met twee verantwoordelijken, anders worden ze in verschillende weken afgerond.
Gebruik Availability Zone-ID's wanneer plaatsing ertoe doet
Zonenamen zijn account-lokale aliassen. us-east-1a in het ene account is niet gegarandeerd dezelfde fysieke zone als us-east-1a in een ander. Als het ontwerp een attachment en een workload in dezelfde zone vereist, vergelijk dan AZ-ID's en leg ze vast.
Namen vergelijken levert een diagram op dat er goed uitziet en een latencyprofiel dat dat niet is. Controleer dat terwijl het diagram nog wordt getekend, niet nadat iemand het verschil heeft gemeten.
Delen opheffen knipt het datapad niet door
De deling verwijderen voelt als intrekken, en het is geen onmiddellijke verkeersstop. AWS documenteert dat een attachment functioneel blijft wanneer de gateway niet meer wordt gedeeld. De machtiging om de resource te beheren verdwijnt, terwijl de bestaande attachment blijft doorsturen tot iemand hem verwijdert of uitschakelt. Plan intrekking in twee stappen: verwijder de deling en daarna de attachment, waarbij de eigenaar de tweede uitvoert.
Als de deling je enige controle is, heb je geen controle.
Houd het deelrecord en het routingrecord bij elkaar
Twee artefacten beantwoorden twee verschillende vragen. Het deelrecord zegt wie met de resource mag werken. De routetabellen zeggen welke netwerken echt kunnen praten. Bewaar ze samen met dezelfde eigenarenlijst, anders begint het volgende incident met iemand die een machtiging bewijst die nooit het probleem was.
Test dan één stroom in elke richting en één prefix dat onbereikbaar moet blijven.