Komuna Transit Gateway: kiu posedas la vojojn en AWS RAM

Kunhavigi Transit Gateway per Resource Access Manager faras unu konkretan aferon: ĝi lasas alian konton voki difinitan aron de aldonaĵaj API-oj kontraŭ rimedo, kiun ĝi ne posedas. Ĝi ne transdonas la enirejon, ĝiajn enkursigajn tabelojn aŭ la rajton decidi, kiel trafiko estas plusendata. Homoj supozas male, ĉar la aldonaĵo aperas en la konzolo de la ricevanto kaj tuj funkcias, kio sentiĝas kiel posedo. La mekanismo sube estas permesa dono sur kunhavigita rimedo, kaj ĉiu ida objekto restas ene de la konta limo de la posedanto. Tiu disigo klarigas la plej multajn mesaĝojn pri rifuzita aliro ĉirkaŭ kunhavigita transiro.

Kion la kunhavigo efektive delegas

Rimeda kunhavigo nomas rimedon, ĉefon kaj administritan permeson. La permeso listigas la agojn, kiujn tiu ĉefo rajtas plenumi, kaj por Transit Gateway tiu listo kovras aldonaĵajn operaciojn sur la kunhavigita rimedo.

Io ajn ekster la listo malsukcesas ĉe la API anstataŭ en la konzolo, tial la eraro ofte aperas la unuan fojon, kiam skripto ruliĝas.

Enkursigaj tabeloj, asocioj kaj propagadoj restas ĉe la posedanto

Plusendadon decidas tri idaj objektoj: al kiu enkursiga tabelo aldonaĵo estas asociita, en kiujn tabelojn ĝi propagiĝas, kaj kiujn vojojn tiuj tabeloj enhavas. La kunhaviga dokumentaro de AWS diras, ke ricevanto ne povas krei, modifi aŭ forigi enkursigajn tabelojn de la transira enirejo aŭ iliajn asociojn kaj propagadojn per la kunhavigo. Tiuj vokoj apartenas al la posedanta konto. Ricevanto, kiu bezonas novan asocion, petas administran ŝanĝon, ne plenumas permeson, kiun ĝi forgesis ŝalti.

La suba tabelo estas la disigo, kiun mi metas en projektajn dokumentojn, ĉar ĝi postvivas personarajn ŝanĝojn.

Legi la mezan vicon atente: la VPC-posedanto regas siajn subretajn vojojn, la enireja posedanto regas la centran plusendadan decidon, kaj funkcianta vojo bezonas ambaŭ. Neniu el la du kontoj povas fini ĝin sola.

Unu vojo, du kontoj

Spuru pakaĵon de spoke-VPC al loka prefikso. La enkursiga tabelo de la spoke-subreto devas sendi tiun prefikson al la aldonaĵo de la transira enirejo, kion la VPC-posedanto povas ŝanĝi. Poste la enirejo devas havi en la asociita tabelo de la aldonaĵo vojon montrantan al la VPN-aldonaĵo, kion nur la posedanto povas ŝanĝi. Revena trafiko bezonas la spegulon de ambaŭ. Maltrafu ajnan flankon kaj vi ricevas duoninstalitan vojon, kiu aspektas kiel fajroŝirma problemo.

Skribu ambaŭ ŝanĝojn en unu bileton kun du respondeculoj, alie ili estos finitaj en malsamaj semajnoj.

Uzu ID-ojn de haveblecaj zonoj, kiam lokigo gravas

Zonaj nomoj estas kontaj lokaj kaŝnomoj. us-east-1a en unu konto ne estas garantiata esti la sama fizika zono kiel us-east-1a en alia. Kiam la dezajno bezonas aldonaĵon kaj laborŝarĝon en la sama zono, komparu AZ-ID-ojn kaj notu ilin.

Kompari nomojn produktas diagramon, kiu aspektas ĝuste, kaj latentan profilon, kiu ne estas. Kontrolu tion dum la diagramo ankoraŭ desegniĝas, ne post kiam iu mezuras la diferencon.

Malkunhavigo ne tranĉas la datan vojon

Forigi la kunhavigon sentiĝas kiel revoko, kaj ĝi ne estas tuja trafika halto. AWS dokumentas, ke aldonaĵo restas funkcianta, kiam la enirejo estas malkunhavigita. La permeso administri la rimedon malaperas, dum la jam ekzistanta aldonaĵo daŭre plusendas ĝis iu forigos aŭ malŝaltos ĝin. Planu revokon en du paŝoj: forigu la kunhavigon, poste la aldonaĵon, kaj la posedanto plenumu la duan.

Se la kunhavigo estas via sola kontrolo, vi ne havas kontrolon.

Tenu la kunhavigan rikordon kaj la enkursigan rikordon kune

Du artefaktoj respondas du malsamajn demandojn. La kunhaviga rikordo diras, kiu rajtas labori kun la rimedo. La enkursigaj tabeloj diras, kiuj retoj efektive povas paroli. Konservu ilin kune kun la sama posedanta listo, alie la sekva okazaĵo komenciĝas per iu pruvanta permeson, kiu neniam estis la problemo.

Poste testu unu fluon en ĉiu direkto kaj unu prefikson, kiu devus resti neatingebla.