AWS Transit Gateway પર ઘણા VPC માટે એક સાઇટ-થી-સાઇટ VPN

આ ત્રિમાસમાં બે VPC ને ઓફિસ નેટવર્કની જરૂર છે, અને બીજી ટનલમાં જ અંદાજ તૂટે છે. AWS Transit Gateway સહિયારા રાઉટિંગ હબ તરીકે કામ કરી શકે છે: VPN એક વાર જોડાય છે, અને દરેક VPC એ જ હબ સાથે જોડાય છે. પછી સ્થાનિક નેટવર્ક એક જ કનેક્શન દ્વારા દરેક જોડાયેલા VPC સુધી પહોંચે છે. આ બદલે છે કે રાઉટિંગ નિર્ણય કોની પાસે છે, અને મોટાભાગની ડિઝાઇન ખરેખર આ ભાગમાં ભૂલ કરે છે.

VPN જોડાણ અને VPC જોડાણો એક જ ગેટવે પર અલગ ઑબ્જેક્ટ છે, તેથી રાઉટિંગ સંબંધો પછી બનાવવા પડે છે.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

પિયરિંગ એ લોકો જે ટૂંકો રસ્તો ઇચ્છે છે તે કેમ નથી

લલચાવતો વિકલ્પ એ છે કે VPN ને VPC A પર સમાપ્ત કરો અને VPC B ને તેની સાથે પિયર કરો. સામાન્ય VPC પિયરિંગ A ના VPN કનેક્શન દ્વારા ધારથી ધાર સુધી ટ્રાન્ઝિટ આપતું નથી. પિયર ફક્ત એ જ સરનામાં સુધી પહોંચે છે જે પિયરિંગ પોતે આપે છે, અને VPN ધાર તેમાંની એક નથી. ટ્રાન્ઝિટ હબ આપે છે; પિયરિંગ તમને એક જોડી આપે છે.

આ મર્યાદા પિયરિંગની લાક્ષણિકતા છે, એવો કોટા નથી જે તમે વધારી શકો.

સંબંધ અને પ્રસાર જુદું કામ કરે છે

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

સંપૂર્ણ જોડાયેલું નાનું હબ સરળ કેસ છે.

દરેક જોડાણ એક ટેબલમાં મૂકો અને VPN સાથે બંને VPC પ્રીફિક્સ સ્વચ્છ રીતે ઉકેલાય છે. આ VPC-થી-VPC પહોંચને પણ મંજૂરી આપે છે જે સંસ્થાએ કદાચ ક્યારેય ઇચ્છી ન હોય, કારણ કે સહિયારા ટેબલમાં સ્પોકની કલ્પના નથી.

વર્કલોડ રૂટ બીજે રહે છે

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

ડાયનેમિક કે સ્ટેટિક રાઉટિંગ સભાનપણે પસંદ કરો; પિયરિંગ બંનેમાંથી એક પણ આપતું નથી.

સ્થાનિક ઍક્સેસ ગુમાવ્યા વિના સ્પોકને અલગ કરો

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

આ રાઉટિંગ અલગતા છે, અને તે એપ્લિકેશન અધિકૃતિ નથી.

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

હબ જે ઠીક કરતું નથી

સરનામાં યોજનાઓ હજી પણ અતિક્રમણ-મુક્ત રહેવી જોઈએ, કારણ કે હબ એક પ્રીફિક્સને બે વર્કલોડ ઓળખવા દેતું નથી. દરેક VPC જોડાણને તેના વર્કલોડ જે Availability Zone આવરણ ધારે છે તે જોઈએ. BGP સાથે, ગ્રાહક ઉપકરણના દરેક જરૂરી પ્રીફિક્સ તરફ પાછા જતા રૂટ ડિઝાઇન અને તેની આયાત નીતિ સાથે મેળ ખાવા જોઈએ. ખૂટતી જાહેરાત બરાબર તૂટેલી ટનલ જેવી લાગે છે.

VPN કનેક્શન અને ટ્રાન્ઝિટ ગેટવે હવે સહિયારી ઇન્ફ્રાસ્ટ્રક્ચર છે.

ટનલ રિડંડન્સી, ઉપકરણ ક્ષમતા, મોનિટરિંગ અને જાળવણીનું આયોજન બધા આશ્રિત VPC આસપાસ કરો, દરેકને સ્વતંત્ર રીતે જોડાયેલા ગણવાને બદલે.

હાલની virtual private gateway ગોઠવણીમાંથી સ્થળાંતર પણ એ જ સ્પષ્ટ યોજના માગે છે. જોડાણો અને નીતિઓ બનાવો, એક નિયંત્રિત વર્કલોડ માર્ગ ખસેડો, અને જૂનો માર્ગ નિવૃત્ત કરતાં પહેલાં મંજૂર અને નકારેલા સંબંધોની પુષ્ટિ કરો. કેન્દ્રીકરણ ત્યારે મદદ કરે છે જ્યારે નેટવર્ક ટીમને સહિયારી કનેક્ટિવિટી સંભાળવા એક જગ્યા આપે છે, અને નુકસાન કરે છે જ્યારે એક મોટા ટેબલ પાછળ કોણ કોના સુધી પહોંચી શકે તે છુપાવે છે.