രണ്ട് AWS അക്കൗണ്ടുകൾ, ഒരു ലോക്കൽ നെറ്റ്വർക്ക്: ഏത് പാത?
പങ്കിട്ട Transit Gateway, രണ്ട് സ്വതന്ത്ര VPN-കൾ അല്ലെങ്കിൽ ഒരു ഇടുങ്ങിയ പ്രോക്സി: ഇന്ന് ഏത് റൂട്ട് ചേർക്കാൻ എളുപ്പമെന്നതല്ല, ഉടമസ്ഥതയും സ്വാധീനത്തിന്റെ വ്യാപ്തിയും അടിസ്ഥാനമാക്കി തിരഞ്ഞെടുക്കുക.
വ്യക്തമായ ചട്ടക്കൂട് peering vs 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 ഉപയോഗിക്കാൻ കഴിയില്ല എന്ന് ചോദിച്ചാൽ, ആ രേഖയാണ് ഉത്തരം, അടുത്ത പ്രോജക്റ്റിൽ അതേ മൂന്ന് ഓപ്ഷനുകൾ വീണ്ടും ചർച്ച ചെയ്യുന്നതിൽ നിന്ന് അത് നിങ്ങളെ രക്ഷിക്കുന്നു.