બે AWS એકાઉન્ટ, એક સ્થાનિક નેટવર્ક: કયો માર્ગ?
શેર કરેલ Transit Gateway, બે સ્વતંત્ર VPN, અથવા એક સાંકડું પ્રોક્સી: આજે કયો માર્ગ ઉમેરવો સૌથી સરળ છે તેના પર નહીં, પરંતુ માલિકી અને અસરના વ્યાપના આધારે પસંદ કરો.
સ્પષ્ટ ઢાંચો peering વિરુદ્ધ VPN છે, અને તે ખોટો ઢાંચો છે. પીઅર કરેલ VPC તેના પડોશીનું VPN જોડાણ ધાર થી ધાર સુધી રાઉટિંગ માટે ઉધાર લઈ શકતું નથી, તેથી તે વિકલ્પ ક્યારેય ટેબલ પર નહોતો, રૂટ ટેબલ ગમે તે સૂચવે. તમે ખરેખર જેમાંથી પસંદ કરો છો તે છે શેર કરેલ નેટવર્ક હબ, બે સ્વતંત્ર VPN માર્ગો અને એક સાંકડું એપ્લિકેશન પ્રવેશદ્વાર. દરેક રાઉટિંગની માલિકી વિશે અલગ પ્રશ્નનો જવાબ આપે છે.
ત્રણ વિકલ્પો અને જે વિકલ્પ નથી
peering નો વિચાર ભૂંસીને શરૂ કરો, પછી જે બાકી રહે છે તેને ડાયાગ્રામની સરળતા પર નહીં, માલિકી પર તુલના કરો. નીચેનું ટેબલ સંક્ષિપ્ત સ્વરૂપમાં નિર્ણય છે.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
જો એકાઉન્ટ A ને આખા સ્થાનિક નેટવર્ક સુધી પહોંચની જરૂર હોય, તો પ્રોક્સી પંક્તિ ખોટા આકારની છે. જો એકાઉન્ટ A ને એક API ની જરૂર હોય, તો પ્રથમ બે પંક્તિઓ જરૂરિયાત માંગે તેના કરતાં વધુ નેટવર્ક છે.
ક્યારે શેર કરેલ Transit Gateway જીતે છે
Transit Gateway દરેક VPC અને VPN ને અલગ નેટવર્ક તરીકે જોડે છે, અને એકાઉન્ટ વચ્ચે શેરિંગ VPC માલિકોને એકાઉન્ટ ભેગા કર્યા વિના હબ વાપરવા દે છે. તે જ આકર્ષણ છે: એક જગ્યા જ્યાં સ્થાનિક પ્રીફિક્સ AWS નેટવર્ક સાથે મળે છે, અને એક જગ્યા જ્યાં વિચારી શકાય કે કઈ જોડાણ કયો રૂટ શીખે છે.
બધું જોડવાનો અર્થ બધું મંજૂર કરવું નથી. એસોસિએશન અને પ્રચાર નક્કી કરે છે કે કઈ જોડાણ કયું રૂટ ટેબલ વાપરે છે, તેથી બે VPC પ્રીફિક્સ દરેક સ્થાનિક સેવા સુધી પહોંચી શકે છે જ્યારે તેમનો પરસ્પર પ્રવેશ હબની ડિઝાઇન દ્વારા બહાર રહે છે. સ્થાનિક બાજુને હજી પણ AWS પ્રીફિક્સ માટે પરત રૂટની જરૂર છે, અને તે બીજી ટીમની ફેરફાર-ટિકિટ છે.
ખર્ચ નાણાકીય જેટલો જ સંસ્થાકીય છે. હબનો માલિક રાઉટિંગ સંબંધો નિયંત્રિત કરે છે જેના પર બીજી ટીમો આધાર રાખે છે, તેથી એક જોડાણમાં ફેરફાર એવી સેવાનું ટ્રાફિક ખસેડી શકે છે જે હબના માલિકે ક્યારેય સાંભળી નથી. જોડાણના કલાકો અને ડેટા પ્રોસેસિંગ તમે જોડો તે દરેક નેટવર્ક સાથે ઉમેરાય છે, તેથી હબ સામાન્ય રીતે તેમને ચલાવતી ટીમ કરતાં ઝડપથી વધે છે.
ક્યારે અલગ VPN અથવા સાંકડું પ્રોક્સી જીતે છે
બે સ્વતંત્ર VPN વાસ્તવિક ઓપરેશનલ સીમાઓવાળા નાના ડિપ્લોયમેન્ટ માટે યોગ્ય છે: દરેક એકાઉન્ટ પોતાના ટનલ બદલે છે, અને કોઈ પણ રૂટ ટેબલ સંપાદિત કરીને બીજાને બગાડી શકતું નથી. મર્યાદાઓ સ્થાનિક બાજુ પર છે. પીઅર ગેટવેને વધારાના ટનલ માટે ક્ષમતાની જરૂર છે, સરનામાં યોજનાઓ ઓવરલેપ ન થવી જોઈએ, અને સમાન પ્રીફિક્સની જાહેરાત કરતી બે રૂપરેખાંકનોને આશાને બદલે ઇરાદાપૂર્વકની પસંદગીની જરૂર છે.
પ્રોક્સી સૌથી સાંકડું ઇન્ટરફેસ છે. જો એકાઉન્ટ A ને એકાઉન્ટ B માં એક ડેટાબેઝ અથવા એક API ની જરૂર હોય, તો મર્યાદિત મધ્યસ્થ તમને પોતાની પ્રમાણીકરણ, લોગિંગ અને ઉપલબ્ધતાની વાર્તા સાથે નિર્ધારિત પ્રવેશ આપે છે. તે સૌથી વધુ દુરુપયોગ થનાર વિકલ્પ પણ છે: દરેક ખાનગી ગંતવ્ય પર ફોરવર્ડ કરતું મધ્યસ્થ વધારાના પગલાં સાથે અમર્યાદિત રિલે બની ગયું છે, અને બીજા કોઈ પણ માટે તે VPC થી સ્થાનિક નેટવર્ક સુધી પારદર્શક પ્રવાહની જેમ વર્તશે નહીં.
આ બધા પહેલાં VPC peering ની મર્યાદાઓ વાંચવી યોગ્ય છે, કારણ કે તે સમજાવે છે કે ચોથો વિચાર કેમ વારંવાર પાછો આવે છે અને કેમ તે કામ કરી શકતો નથી.
જરૂરિયાત પૂરી કરતું સૌથી સાંકડું ઇન્ટરફેસ પસંદ કરો
પ્રશ્નો ગોઠવો: A ને એક નેટવર્ક, નેટવર્કનો સમૂહ કે એક સેવા જોઈએ? સ્થાનિક ટીમ એક માર્ગ ઇચ્છે છે કે ઘણા? બીજી ટીમના ટ્રાફિક માટે રાઉટિંગ કોણ બદલી શકે? સૌથી સાંકડું ઇન્ટરફેસ આપતો પહેલો જવાબ એ આર્કિટેક્ચર છે, અને તે પછીનું બધું અમલીકરણ છે.
જવાબને પ્રીફિક્સ યોજના, રૂટની માલિકી, ટનલ અથવા જોડાણોની યાદી અને દરેક પક્ષ જે નિષ્ફળતા-સ્થિતિ ધારે છે તેની સાથે નોંધો. જ્યારે પછી કોઈ પૂછે કે એકાઉન્ટ A સીધું એકાઉન્ટ B નું VPN કેમ વાપરી શકતું નથી, ત્યારે તે નોંધ જ જવાબ છે, અને તે આગલા પ્રોજેક્ટમાં એ જ ત્રણ વિકલ્પો પર ફરી ચર્ચા કરવાથી તમને બચાવે છે.