Resource Access Manager સાથે Transit Gateway શેર કરવું એક ચોક્કસ કામ કરે છે: તે બીજા એકાઉન્ટને એવા સંસાધન સામે નિર્ધારિત જોડાણ API સમૂહને કૉલ કરવા દે છે જે તેની માલિકીનું નથી. તે ગેટવે, તેના રૂટ કોષ્ટકો કે ટ્રાફિક કેવી રીતે ફોરવર્ડ થાય તે નક્કી કરવાનો અધિકાર સ્થાનાંતરિત કરતું નથી. લોકો વિપરીત ધારે છે કારણ કે જોડાણ પ્રાપ્તકર્તાના કન્સોલમાં દેખાય છે અને તરત જ કામ કરે છે, જે માલિકી જેવું લાગે છે. નીચેની પદ્ધતિ શેર કરેલા સંસાધન પર પરવાનગી આપવાની છે, અને દરેક ચાઇલ્ડ ઑબ્જેક્ટ માલિકના એકાઉન્ટ સીમાની અંદર જ રહે છે. તે વિભાજન શેર કરેલા ટ્રાન્ઝિટ આસપાસની મોટાભાગની ઍક્સેસ-નકારેલી ટિકિટો સમજાવે છે.

શેરિંગ ખરેખર શું સોંપે છે

સંસાધન શેરિંગ સંસાધન, પ્રિન્સિપાલ અને મેનેજ્ડ પરવાનગીનું નામ આપે છે. પરવાનગી તે પ્રિન્સિપાલ કરી શકે તેવી ક્રિયાઓની યાદી આપે છે, અને Transit Gateway માટે તે યાદી શેર કરેલા સંસાધન પર જોડાણ કામગીરી આવરી લે છે.

યાદીની બહારની કોઈપણ વસ્તુ કન્સોલમાં નહીં પણ API પર નિષ્ફળ જાય છે, તેથી સ્ક્રિપ્ટ પ્રથમ વખત ચાલે ત્યારે જ ભૂલ ઘણી વખત દેખાય છે.

રૂટ કોષ્ટકો, સંબંધો અને પ્રસારણો માલિક પાસે જ રહે છે

ફોરવર્ડિંગ ત્રણ ચાઇલ્ડ ઑબ્જેક્ટ દ્વારા નક્કી થાય છે: જોડાણ કયા રૂટ કોષ્ટક સાથે સંકળાયેલું છે, તે કયા કોષ્ટકોમાં પ્રસરે છે, અને તે કોષ્ટકોમાં કયા રૂટ છે. AWS ના શેરિંગ દસ્તાવેજીકરણમાં જણાવ્યું છે કે પ્રાપ્તકર્તા શેરિંગ દ્વારા ટ્રાન્ઝિટ ગેટવે રૂટ કોષ્ટકો કે તેમના સંબંધો અને પ્રસારણો બનાવી, બદલી કે ડિલીટ કરી શકતું નથી. તે કૉલ માલિક એકાઉન્ટના છે. નવા સંબંધની જરૂર હોય તેવો પ્રાપ્તકર્તા વહીવટી ફેરફાર માંગે છે, તે સક્ષમ કરવાનું ભૂલી ગયેલી પરવાનગીનો ઉપયોગ કરતો નથી.

નીચેનું કોષ્ટક એ વિભાજન છે જે હું ડિઝાઇન દસ્તાવેજોમાં મૂકું છું, કારણ કે તે કર્મચારી ફેરફારોમાં ટકી રહે છે.

RoleWhat it controls
Transit Gateway ownerThe gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here.
VPC owner using the shareIts own attachment, subnet route tables and security policy for the workloads.
Shared-subnet participantWorkload traffic only, following routes the VPC owner already set.

વચ્ચેની પંક્તિ ધ્યાનથી વાંચો: VPC માલિક તેના સબનેટ રૂટ નિયંત્રિત કરે છે, ગેટવે માલિક કેન્દ્રીય ફોરવર્ડિંગ નિર્ણય નિયંત્રિત કરે છે, અને કામ કરતા માર્ગને બંનેની જરૂર છે. બંનેમાંથી કોઈ એક એકાઉન્ટ તેને એકલા પૂર્ણ કરી શકતું નથી.

એક માર્ગ, બે એકાઉન્ટ

સ્પોક VPC થી ઑન-પ્રેમાઇઝિસ પ્રીફિક્સ સુધી પેકેટને અનુસરો. સ્પોક સબનેટ રૂટ કોષ્ટકે તે પ્રીફિક્સ ટ્રાન્ઝિટ ગેટવે જોડાણને મોકલવું જોઈએ, જે VPC માલિક બદલી શકે છે. પછી ગેટવેમાં જોડાણના સંકળાયેલા કોષ્ટકમાં VPN જોડાણ તરફ નિર્દેશ કરતો રૂટ હોવો જોઈએ, જે ફક્ત માલિક જ બદલી શકે છે. પરત ટ્રાફિકને બંનેનું પ્રતિબિંબ જોઈએ. કોઈપણ બાજુ ચૂકી જાઓ તો તમને અડધું ઇન્સ્ટોલ થયેલો માર્ગ મળે છે જે ફાયરવૉલ સમસ્યા જેવો લાગે છે.

બંને ફેરફારો બે જવાબદાર વ્યક્તિઓ સાથે એક ટિકિટમાં લખો, નહીં તો તે વિવિધ અઠવાડિયામાં પૂરા થશે.

જ્યારે સ્થાન મહત્વનું હોય ત્યારે Availability Zone ID વાપરો

ઝોન નામો એકાઉન્ટ-સ્થાનિક ઉપનામો છે. એક એકાઉન્ટમાં us-east-1a બીજા એકાઉન્ટના us-east-1a જેવો જ ભૌતિક ઝોન હશે તેની ખાતરી નથી. જ્યારે ડિઝાઇનને એક જ ઝોનમાં જોડાણ અને વર્કલોડની જરૂર હોય, ત્યારે AZ ID ની સરખામણી કરો અને નોંધો.

નામની સરખામણી સાચું દેખાતું ડાયાગ્રામ અને સાચું ન હોય તેવું લેટન્સી પ્રોફાઇલ આપે છે. ડાયાગ્રામ હજી દોરાઈ રહ્યું હોય ત્યારે જ તેને ચકાસો, કોઈએ તફાવત માપ્યા પછી નહીં.

શેરિંગ રદ કરવાથી ડેટા માર્ગ કપાતો નથી

શેરિંગ દૂર કરવું રદ કરવા જેવું લાગે છે, અને તે તાત્કાલિક ટ્રાફિક સ્ટોપ નથી. AWS દસ્તાવેજીકરણ કરે છે કે ગેટવે શેરિંગમાંથી બહાર થાય ત્યારે જોડાણ કાર્યરત રહે છે. સંસાધનનું સંચાલન કરવાની પરવાનગી અદૃશ્ય થાય છે, જ્યારે પહેલેથી અસ્તિત્વમાં રહેલું જોડાણ કોઈ તેને ડિલીટ કે નિષ્ક્રિય ન કરે ત્યાં સુધી ફોરવર્ડ કરતું રહે છે. રદ કરવાની બે પગલાંમાં યોજના કરો: શેરિંગ દૂર કરો, પછી જોડાણ દૂર કરો, અને બીજું માલિક કરશે.

જો શેરિંગ તમારું એકમાત્ર નિયંત્રણ હોય, તો તમારી પાસે કોઈ નિયંત્રણ નથી.

શેરિંગ રેકોર્ડ અને રૂટિંગ રેકોર્ડ સાથે રાખો

બે કલાકૃતિઓ બે અલગ પ્રશ્નોના જવાબ આપે છે. શેરિંગ રેકોર્ડ કહે છે કે સંસાધન સાથે કોણ કામ કરી શકે. રૂટ કોષ્ટકો કહે છે કે કયા નેટવર્ક ખરેખર વાત કરી શકે. તેમને સમાન માલિક યાદી સાથે સાથે સંગ્રહો, નહીં તો આગલી ઘટના એવા કોઈ સાથે શરૂ થશે જે ક્યારેય સમસ્યા ન હતી તેવી પરવાનગી સાબિત કરે છે.

પછી દરેક દિશામાં એક ફ્લો અને અપ્રાપ્ય રહેવું જોઈએ તેવું એક પ્રીફિક્સ ચકાસો.

સંબંધિત લેખો