പങ്കിട്ട Transit Gateway: AWS RAM-ലെ റൂട്ടുകൾ ആരുടെ ഉടമസ്ഥതയിൽ
RAM പങ്കിടൽ മറ്റൊരു അക്കൗണ്ടിന് VPC എന്നിടാൻ അനുവദിക്കുന്നു, പക്ഷേ റൂട്ട് പട്ടികകൾ, അസോസിയേഷനുകൾ, പ്രൊപഗേഷനുകൾ ഗേറ്റ്‌വേ ഉടമയിൽ തന്നെ തുടരുന്നു. ഇവിടെയാണ് അതിർത്തി.
Transit Gateway ഒരു Resource Access Manager-നൊപ്പം പങ്കിടുന്നത് ഒരു നിർദ്ദിഷ്ട കാര്യം ചെയ്യുന്നു: സ്വന്തമല്ലാത്ത ഒരു റിസോഴ്‌സിനെതിരെ നിർവചിച്ച അറ്റാച്ച്‌മെന്റ് API കൂട്ടം വിളിക്കാൻ മറ്റൊരു അക്കൗണ്ടിനെ അനുവദിക്കുന്നു. ഇത് ഗേറ്റ്‌വേയോ അതിന്റെ റൂട്ട് പട്ടികകളോ ട്രാഫിക് എങ്ങനെ കൈമാറ്റം ചെയ്യപ്പെടുന്നു എന്നത് തീരുമാനിക്കാനുള്ള അവകാശമോ കൈമാറുന്നില്ല. അറ്റാച്ച്‌മെന്റ് സ്വീകർത്താവിന്റെ കൺസോളിൽ കാണപ്പെടുകയും ഉടൻ പ്രവർത്തിക്കുകയും ചെയ്യുന്നതിനാൽ ആളുകൾ വിപരീതം അനുമാനിക്കുന്നു, അത് ഉടമസ്ഥതയായി തോന്നുന്നു. അടിയിലുള്ള സംവിധാനം പങ്കിട്ട റിസോഴ്‌സിൽ അനുമതി നൽകുന്നതാണ്, കൂടാതെ ഓരോ ചൈൽഡ് ഒബ്ജക്റ്റും ഉടമയുടെ അക്കൗണ്ട് അതിർത്തിക്കുള്ളിൽ തുടരുന്നു. ആ വിഭജനം പങ്കിട്ട ട്രാൻസിറ്റിനു ചുറ്റുമുള്ള മിക്ക ആക്സസ്-നിഷേധ ടിക്കറ്റുകളും വിശദീകരിക്കുന്നു.
പങ്കിടൽ യഥാർത്ഥത്തിൽ എന്താണ് നിയോഗിക്കുന്നത്
ഒരു റിസോഴ്‌സ് പങ്കിടൽ ഒരു റിസോഴ്‌സ്, ഒരു പ്രിൻസിപ്പൽ, ഒരു മാനേജ്ഡ് അനുമതി എന്നിവയെ പേരിടുന്നു. അനുമതി ആ പ്രിൻസിപ്പലിന് ചെയ്യാവുന്ന പ്രവർത്തനങ്ങൾ പട്ടികപ്പെടുത്തുന്നു, Transit Gateway-ക്ക് ആ പട്ടിക പങ്കിട്ട റിസോഴ്‌സിലെ അറ്റാച്ച്‌മെന്റ് പ്രവർത്തനങ്ങൾ ഉൾക്കൊള്ളുന്നു.
പട്ടികയ്ക്ക് പുറത്തുള്ളതെല്ലാം കൺസോളിൽ അല്ല, API-യിൽ പരാജയപ്പെടുന്നു, അതുകൊണ്ടാണ് സ്ക്രിപ്റ്റ് ആദ്യമായി പ്രവർത്തിക്കുമ്പോൾ പിശക് പലപ്പോഴും പ്രത്യക്ഷപ്പെടുന്നത്.
റൂട്ട് പട്ടികകൾ, അസോസിയേഷനുകൾ, പ്രൊപഗേഷനുകൾ ഉടമയിൽ തുടരുന്നു
കൈമാറ്റം മൂന്ന് ചൈൽഡ് ഒബ്ജക്റ്റുകൾ തീരുമാനിക്കുന്നു: അറ്റാച്ച്‌മെന്റ് ഏത് റൂട്ട് പട്ടികയുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, ഏത് പട്ടികകളിലേക്ക് അത് പ്രൊപഗേറ്റ് ചെയ്യുന്നു, ആ പട്ടികകളിൽ ഏത് റൂട്ടുകളുണ്ട്. AWS-ന്റെ പങ്കിടൽ രേഖകൾ പറയുന്നത്, സ്വീകർത്താവിന് പങ്കിടലിലൂടെ ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ റൂട്ട് പട്ടികകളോ അവയുടെ അസോസിയേഷനുകളോ പ്രൊപഗേഷനുകളോ സൃഷ്ടിക്കാനോ മാറ്റാനോ ഇല്ലാതാക്കാനോ കഴിയില്ല എന്നാണ്. ആ വിളികൾ ഉടമയുടെ അക്കൗണ്ടിന്റേതാണ്. പുതിയ അസോസിയേഷൻ ആവശ്യമുള്ള സ്വീകർത്താവ് ഒരു ഭരണപരമായ മാറ്റം അഭ്യർത്ഥിക്കുന്നു, പ്രവർത്തനക്ഷമമാക്കാൻ മറന്ന അനുമതി പ്രയോഗിക്കുന്നില്ല.
താഴെയുള്ള പട്ടിക ഞാൻ ഡിസൈൻ രേഖകളിൽ ഇടുന്ന വിഭജനമാണ്, കാരണം അത് ജീവനക്കാരുടെ മാറ്റങ്ങളെ അതിജീവിക്കുന്നു.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
മധ്യ വരി ശ്രദ്ധയോടെ വായിക്കുക: VPC ഉടമ തന്റെ സബ്‌നെറ്റ് റൂട്ടുകൾ നിയന്ത്രിക്കുന്നു, ഗേറ്റ്‌വേ ഉടമ കേന്ദ്ര കൈമാറ്റ തീരുമാനം നിയന്ത്രിക്കുന്നു, പ്രവർത്തിക്കുന്ന പാതയ്ക്ക് രണ്ടും വേണം. ഏതെങ്കിലും ഒരു അക്കൗണ്ടിന് അത് ഒറ്റയ്ക്ക് പൂർത്തിയാക്കാൻ കഴിയില്ല.
ഒരു പാത, രണ്ട് അക്കൗണ്ടുകൾ
സ്പോക്ക് VPC മുതൽ ഓൺ-പ്രെമൈസസ് പ്രിഫിക്‌സ് വരെ ഒരു പാക്കറ്റ് പിന്തുടരുക. സ്പോക്ക് സബ്‌നെറ്റ് റൂട്ട് പട്ടിക ആ പ്രിഫിക്‌സ് ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ അറ്റാച്ച്‌മെന്റിലേക്ക് അയക്കണം, അത് VPC ഉടമയ്ക്ക് മാറ്റാം. തുടർന്ന് ഗേറ്റ്‌വേയുടെ അറ്റാച്ച്‌മെന്റിന്റെ അനുബന്ധ പട്ടികയിൽ VPN അറ്റാച്ച്‌മെന്റിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് ഉണ്ടായിരിക്കണം, അത് ഉടമയ്ക്ക് മാത്രമേ മാറ്റാൻ കഴിയൂ. മടങ്ങിവരുന്ന ട്രാഫിക്കിന് രണ്ടിന്റെയും പ്രതിബിംബം വേണം. ഏതെങ്കിലും വശം വിട്ടുപോയാൽ നിങ്ങൾക്ക് പകുതി ഇൻസ്റ്റാൾ ചെയ്ത, ഫയർവാൾ പ്രശ്നം പോലെ തോന്നുന്ന ഒരു പാത ലഭിക്കും.
രണ്ട് മാറ്റങ്ങളും രണ്ട് ഉത്തരവാദികളുള്ള ഒരു ടിക്കറ്റിൽ എഴുതുക, അല്ലെങ്കിൽ അവ വ്യത്യസ്ത ആഴ്ചകളിൽ പൂർത്തിയാകും.
സ്ഥാനം പ്രധാനമാകുമ്പോൾ ലഭ്യത മേഖല ID-കൾ ഉപയോഗിക്കുക
മേഖലയുടെ പേരുകൾ അക്കൗണ്ട്-പ്രാദേശിക ഉപനാമങ്ങളാണ്. ഒരു അക്കൗണ്ടിലെ us-east-1a മറ്റൊരു അക്കൗണ്ടിലെ us-east-1a-ന്റെ അതേ ഭൗതിക മേഖലയാണെന്ന് ഉറപ്പില്ല. ഡിസൈനിന് ഒരേ മേഖലയിൽ അറ്റാച്ച്‌മെന്റും വർക്ക്ലോഡും വേണമെങ്കിൽ, AZ ID-കൾ താരതമ്യം ചെയ്ത് രേഖപ്പെടുത്തുക.
പേരുകൾ താരതമ്യം ചെയ്യുന്നത് ശരിയെന്ന് തോന്നുന്ന ഒരു ഡയഗ്രവും ശരിയല്ലാത്ത ഒരു ലേറ്റൻസി പ്രൊഫൈലും നൽകുന്നു. ഡയഗ്രം ഇപ്പോഴും വരയ്ക്കുമ്പോൾ തന്നെ അത് പരിശോധിക്കുക, ആരെങ്കിലും വ്യത്യാസം അളന്നതിന് ശേഷമല്ല.
പങ്കിടൽ റദ്ദാക്കുന്നത് ഡാറ്റാ പാത മുറിക്കുന്നില്ല
പങ്കിടൽ നീക്കുന്നത് റദ്ദാക്കലായി തോന്നുന്നു, അത് ഉടനടിയുള്ള ട്രാഫിക് നിർത്തലല്ല. ഗേറ്റ്‌വേ പങ്കിടലിൽ നിന്ന് പുറത്താകുമ്പോൾ അറ്റാച്ച്‌മെന്റ് പ്രവർത്തനക്ഷമമായി തുടരുന്നു എന്ന് AWS രേഖപ്പെടുത്തുന്നു. റിസോഴ്‌സ് നിയന്ത്രിക്കാനുള്ള അനുമതി അപ്രത്യക്ഷമാകുന്നു, ഇപ്പോൾ നിലവിലുള്ള അറ്റാച്ച്‌മെന്റ് ആരെങ്കിലും അത് ഇല്ലാതാക്കുകയോ പ്രവർത്തനരഹിതമാക്കുകയോ ചെയ്യുന്നതുവരെ കൈമാറ്റം തുടരുന്നു. റദ്ദാക്കൽ രണ്ട് ഘട്ടങ്ങളായി ആസൂത്രണം ചെയ്യുക: പങ്കിടൽ നീക്കുക, തുടർന്ന് അറ്റാച്ച്‌മെന്റ് നീക്കുക, രണ്ടാമത്തേത് ഉടമ ചെയ്യണം.
പങ്കിടൽ മാത്രമാണ് നിങ്ങളുടെ നിയന്ത്രണമെങ്കിൽ, നിങ്ങൾക്ക് നിയന്ത്രണമില്ല.
പങ്കിടൽ രേഖയും റൂട്ടിംഗ് രേഖയും ഒരുമിച്ച് സൂക്ഷിക്കുക
രണ്ട് കലാകൃതികൾ രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. പങ്കിടൽ രേഖ ആർക്ക് റിസോഴ്‌സുമായി പ്രവർത്തിക്കാമെന്ന് പറയുന്നു. റൂട്ട് പട്ടികകൾ ഏത് നെറ്റ്‌വർക്കുകൾക്ക് യഥാർത്ഥത്തിൽ സംസാരിക്കാമെന്ന് പറയുന്നു. അവ ഒരേ ഉടമ പട്ടികയോടൊപ്പം ഒരുമിച്ച് സൂക്ഷിക്കുക, അല്ലെങ്കിൽ അടുത്ത സംഭവം ഒരിക്കലും പ്രശ്നമല്ലാതിരുന്ന ഒരു അനുമതി തെളിയിക്കുന്ന ഒരാളിൽ നിന്ന് ആരംഭിക്കും.
തുടർന്ന് ഓരോ ദിശയിലും ഒരു പ്രവാഹവും എത്തിച്ചേരാൻ പാടില്ലാത്ത ഒരു പ്രിഫിക്‌സും പരിശോധിക്കുക.