Айқын шеңбер — peering пен VPN қарсылығы, және бұл қате шеңбер. Пирингі бар VPC көршісінің VPN қосылымын шеттен шетке маршруттау үшін қарызға ала алмайды, сондықтан бұл нұсқа ешқашан үстелде болған емес, маршрут кестесі не ұсынса да. Шын мәнінде сіз ортақ желілік хаб, екі тәуелсіз VPN жолы және бір тар қолданба кіреберісінің арасында таңдайсыз. Әрқайсысы маршруттау кімге тиесілі деген сұраққа басқаша жауап береді.

Үш нұсқа және нұсқа болып табылмайтын біреуі

Peering идеясын жойып бастаңыз, содан кейін қалғанын диаграмма қарапайымдылығына емес, меншікке қарай салыстырыңыз. Төмендегі кесте — шешімнің жинақы түрі.

OptionWho owns the pathMain cost
Shared transit gatewayHub owner, used by both VPC ownersShared blast radius, attachment and data-processing charges
Separate VPNs per accountEach account independentlyPeer capacity, duplicated tunnels, overlapping prefixes to coordinate
Application proxyThe account that hosts the intermediaryNew 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-ін қарапайым пайдалана алмайды деп сұраса, сол жазба — жауап, және ол келесі жобада сол үш нұсқаны қайта талқылаудан құтқарады.

Қатысты мақалалар