Hesabu mbili za AWS, mtandao mmoja wa ndani: njia ipi?

Mwelekeo dhahiri ni peering dhidi ya VPN, na huo ni mwelekeo usio sahihi. VPC iliyounganishwa kwa peering haiwezi kuazima muunganisho wa VPN wa jirani yake kwa uelekezaji kutoka ukingo hadi ukingo, kwa hivyo chaguo hilo halikuwa mezani kamwe, bila kujali jedwali la njia linapendekeza nini. Unachochagua kwa kweli ni kati ya kitovu cha mtandao kinachoshirikiwa, njia mbili huru za VPN na mlango mmoja mwembamba wa programu. Kila kimoja hujibu swali tofauti kuhusu nani anamiliki uelekezaji.

Chaguo tatu na lile ambalo si chaguo

Anza kwa kufuta wazo la peering, kisha linganisha kile kinachobaki kwa umiliki badala ya urahisi wa mchoro. Jedwali lililo hapa chini ni uamuzi kwa muundo mfupi.

Ikiwa akaunti A inahitaji kufikia mtandao mzima wa ndani, safu ya proksi ina umbo lisilo sahihi. Ikiwa akaunti A inahitaji API moja, safu mbili za kwanza ni mtandao mwingi kuliko unaodaiwa na hitaji.

Wakati Transit Gateway inayoshirikiwa inashinda

Transit Gateway huunganisha kila VPC na VPN kama mitandao tofauti, na kushiriki kati ya akaunti huwawezesha wamiliki wa VPC kutumia kitovu bila kuunganisha akaunti. Hiyo ndiyo mvuto: mahali pamoja ambapo viambishi vya ndani hukutana na mitandao ya AWS, na mahali pamoja pa kufikiri ni kiambatisho kipi kinachojifunza njia ipi.

Kuunganisha kila kitu hakumaanishi kuruhusu kila kitu. Ushirika na uenezaji huamua kiambatisho kipi kinatumia jedwali gani la njia, kwa hivyo viambishi viwili vya VPC vinaweza kila kimoja kufikia huduma ya ndani huku ufikiaji wao wa pamoja ukibaki umetengwa na muundo wa kitovu. Upande wa ndani bado unahitaji njia za kurudi kwa viambishi vya AWS, na hiyo ni tikiti ya mabadiliko ya timu nyingine.

Gharama ni ya kitaasisi kama ilivyo ya kifedha. Mmiliki wa kitovu anadhibiti mahusiano ya uelekezaji ambayo timu nyingine zinategemea, kwa hivyo mabadiliko kwenye kiambatisho kimoja yanaweza kuhamisha trafiki ya huduma ambayo mmiliki wa kitovu hajawahi kuisikia. Saa za kiambatisho na usindikaji wa data huongezeka kwa kila mtandao unaounganisha, ndiyo sababu vitovu huwa hukua haraka kuliko timu inayoviendesha.

Wakati VPN tofauti au proksi nyembamba inashinda

VPN mbili huru zinafaa kwa usambazaji mdogo wenye mipaka halisi ya uendeshaji: kila akaunti hubadilisha vichuguu vyake yenyewe, na hakuna kinachoweza kuvunja kingine kwa kuhariri jedwali la njia. Mipaka iko upande wa ndani. Lango la rika linahitaji uwezo wa vichuguu vya ziada, mipango ya anwani haipaswi kuingiliana, na usanidi mbili zinazotangaza viambishi sawa unahitaji upendeleo wa makusudi badala ya matumaini.

Proksi ni kiolesura chembamba zaidi. Ikiwa akaunti A inahitaji hifadhidata moja au API moja katika akaunti B, mpatanishi aliye na mipaka hukupa mlango uliofafanuliwa na hadithi yake mwenyewe ya uthibitishaji, uwekaji kumbukumbu na upatikanaji. Pia ni chaguo linalowezekana zaidi kutumika vibaya: mpatanishi anayesambaza kwa kila lengwa la kibinafsi amekuwa relay isiyo na kikomo na hatua za ziada, na hayatofanya kazi kama usafirishaji wazi kutoka VPC hadi mtandao wa ndani kwa kitu kingine chochote.

Inafaa kusoma vikwazo vya peering vya VPC kabla ya haya yote, kwa sababu vinaeleza kwa nini wazo la nne linarudi tena na tena na kwa nini haliwezi kufanya kazi.

Chagua kiolesura chembamba zaidi kinachokidhi hitaji

Panga maswali: je, A anahitaji mtandao, seti ya mitandao au huduma moja? Je, timu ya ndani inataka njia moja au kadhaa? Nani anaruhusiwa kubadilisha uelekezaji wa trafiki ya timu nyingine? Jibu la kwanza linalozalisha kiolesura chembamba zaidi ni usanifu, na kila kitu baada ya hapo ni utekelezaji.

Rekodi jibu pamoja na mpango wa viambishi, umiliki wa njia, orodha ya vichuguu au viambatisho na hali ya kushindwa ambayo kila upande unatarajia. Wakati mtu akiuliza baadaye kwa nini akaunti A haiwezi kutumia tu VPN ya akaunti B, rekodi hiyo ndiyo jibu, na inakuokoa kutoka kujadili tena chaguo tatu zile zile katika mradi unaofuata.