Pinagsasaluhang Transit Gateway: sino ang may-ari ng mga ruta sa AWS RAM
Pinapayagan ng pagbabahagi sa RAM ang ibang account na mag-attach ng VPC, ngunit ang mga talahanayan ng ruta, asosasyon at pagpapalaganap ay nananatili sa may-ari ng gateway. Narito ang hangganan.
Ang pagbabahagi ng Transit Gateway sa Resource Access Manager ay gumagawa ng isang partikular na bagay: pinapayagan ang ibang account na tumawag ng tinukoy na hanay ng attachment API laban sa isang resource na hindi nito pag-aari. Hindi nito inililipat ang gateway, ang mga talahanayan ng ruta nito o ang karapatang magpasya kung paano ipinapasa ang trapiko. Ipinapalagay ng mga tao ang kabaligtaran dahil lumilitaw ang attachment sa console ng tatanggap at agad na gumagana, na parang pagmamay-ari. Ang mekanismong nasa ilalim ay isang pagbibigay ng pahintulot sa isang pinagsasaluhang resource, at bawat child object ay nananatili sa loob ng hangganan ng account ng may-ari. Ang paghahating iyon ang nagpapaliwanag sa karamihan ng mga ticket ng tinanggihang access sa paligid ng pinagsasaluhang transit.
Ano ang aktwal na ipinagkakatiwala ng pagbabahagi
Ang pagbabahagi ng resource ay nagpapangalan ng resource, principal at pinamamahalaang pahintulot. Inililista ng pahintulot ang mga aksyon na maaaring gawin ng principal, at para sa Transit Gateway saklaw ng listahang iyon ang mga operasyon ng attachment sa pinagsasaluhang resource.
Anumang nasa labas ng listahan ay nabigo sa API at hindi sa console, kaya madalas lumilitaw ang error sa unang pagtakbo ng script.
Ang mga talahanayan ng ruta, asosasyon at pagpapalaganap ay nananatili sa may-ari
Ang pagpapasa ay pinagpapasyahan ng tatlong child object: kung aling talahanayan ng ruta naka-associate ang attachment, kung aling mga talahanayan ito nagpapalaganap at anong mga ruta ang nilalaman ng mga talahanayang iyon. Sinasabi ng dokumentasyon ng pagbabahagi ng AWS na hindi maaaring gumawa, magbago o magbura ang tatanggap ng mga talahanayan ng ruta ng transit gateway o ng kanilang mga asosasyon at pagpapalaganap sa pamamagitan ng pagbabahagi. Ang mga tawag na iyon ay pag-aari ng account ng may-ari. Ang tatanggap na nangangailangan ng bagong asosasyon ay humihingi ng administratibong pagbabago, hindi gumagamit ng pahintulot na nakalimutang i-enable.
Ang talahanayan sa ibaba ang paghahating inilalagay ko sa mga dokumento ng disenyo, dahil nakakaligtas ito sa pagbabago ng tauhan.
| 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. |
Basahin nang mabuti ang gitnang hilera: kinokontrol ng may-ari ng VPC ang mga ruta ng subnet nito, kinokontrol ng may-ari ng gateway ang sentral na desisyon sa pagpapasa, at kailangan ng gumaganang landas ang dalawa. Walang account na makakumpleto nito nang mag-isa.
Isang landas, dalawang account
Sundan ang isang packet mula sa spoke VPC hanggang sa on-premises prefix. Dapat ipadala ng talahanayan ng ruta ng spoke subnet ang prefix na iyon sa attachment ng transit gateway, na maaaring baguhin ng may-ari ng VPC. Pagkatapos, kailangang may ruta ang gateway sa naka-associate na talahanayan ng attachment na tumuturo sa VPN attachment, at ang may-ari lang ang makakabago nito. Kailangan ng trapikong pabalik ang salamin ng dalawa. Kung mapalampas ang alinmang panig makakakuha ka ng landas na kalahating naka-install at mukhang problema sa firewall.
Isulat ang dalawang pagbabago sa isang ticket na may dalawang responsable, kung hindi ay matatapos sila sa magkaibang linggo.
Gamitin ang Availability Zone ID kapag mahalaga ang lokasyon
Ang mga pangalan ng zone ay lokal na alias ng account. us-east-1a sa isang account ay hindi garantisadong parehong pisikal na zone ng us-east-1a sa iba. Kapag kailangan ng disenyo ang attachment at workload sa parehong zone, ihambing ang AZ ID at itala.
Ang paghahambing ng mga pangalan ay gumagawa ng diagram na mukhang tama at latency profile na hindi. Suriin iyon habang iginuguhit pa ang diagram, hindi pagkatapos sukatin ng iba ang pagkakaiba.
Hindi pinuputol ng pag-alis ng pagbabahagi ang landas ng data
Ang pagtanggal ng pagbabahagi ay parang pagbawi, at hindi ito agad na paghinto ng trapiko. Itinatala ng AWS na nananatiling gumagana ang attachment kapag tinanggal ang gateway sa pagbabahagi. Nawawala ang pahintulot na pamahalaan ang resource, habang ang umiiral na attachment ay patuloy na nagpapasa hanggang may magbura o mag-disable nito. Planuhin ang pagbawi sa dalawang hakbang: alisin ang pagbabahagi, pagkatapos ang attachment, at ang may-ari ang gagawa ng pangalawa.
Kung ang pagbabahagi lang ang tanging kontrol mo, wala kang kontrol.
Itago nang magkasama ang talaan ng pagbabahagi at talaan ng routing
Dalawang artifact ang sumasagot sa dalawang magkaibang tanong. Sinasabi ng talaan ng pagbabahagi kung sino ang makakapagtrabaho sa resource. Sinasabi ng mga talahanayan ng ruta kung aling mga network ang tunay na makakapag-usap. Itago ang mga ito nang magkasama kasama ang parehong listahan ng may-ari, kung hindi magsisimula ang susunod na insidente sa isang taong nagpapatunay ng pahintulot na hindi kailanman naging problema.
Pagkatapos, subukan ang isang daloy sa bawat direksyon at isang prefix na dapat manatiling hindi maabot.