Два акаунта в AWS, една локална мрежа: кой път?

Очевидната рамка е peering срещу VPN и тя е грешната рамка. Свързан с peering VPC не може да заеме VPN връзката на съседа си за маршрутизиране от край до край, така че тази опция никога не е била на масата, каквото и да подсказва таблица за маршрути. Това, между което всъщност избирате, е споделен мрежов хъб, два независими VPN пътя и един тесен вход за приложение. Всяко от тях отговаря на различен въпрос за това кой притежава маршрутизирането.

Три опции и тази, която не е опция

Започнете с изтриването на идеята за peering, след което сравнете останалото по собственост, а не по простота на диаграмата. Таблицата по-долу е решението в сбита форма.

Ако акаунт A се нуждае от достъп до цяла локална мрежа, редът с прокси има грешна форма. Ако акаунт A се нуждае от един API, първите два реда са повече мрежа, отколкото изискването е поискало.

Кога печели споделеният Transit Gateway

Transit Gateway свързва всяко VPC и VPN като отделни мрежи, а споделянето между акаунти позволява на собствениците на VPC да използват хъба, без да обединяват акаунти. Това е привлекателното: едно място, където локалните префикси се срещат с мрежите на AWS, и едно място за разсъждение кой прикачен елемент научава кой маршрут.

Прикачването на всичко не означава разрешаване на всичко. Асоциацията и разпространението определят кой прикачен елемент използва коя таблица за маршрути, така че два VPC префикса могат всеки да достигне до локална услуга, докато взаимният им достъп остава изключен от дизайна на хъба. Локалната страна все още се нуждае от обратни маршрути за префиксите на AWS, а това е промяна на друг екип.

Разходът е организационен точно толкова, колкото и финансов. Собственикът на хъба контролира отношения на маршрутизиране, от които зависят други екипи, така че промяна в един прикачен елемент може да премести трафика на услуга, за която собственикът на хъба никога не е чувал. Часовете на прикачване и обработката на данни се натрупват с всяка мрежа, която прикачите, и затова хъбовете обикновено растат по-бързо от екипа, който ги управлява.

Кога печелят отделните VPN или тесният прокси

Два независими VPN пасват на малко внедряване с реални оперативни граници: всеки акаунт променя своите тунели и нито един не може да повреди другия чрез редактиране на таблица за маршрути. Ограниченията са от локалната страна. Партньорският шлюз се нуждае от капацитет за допълнителните тунели, плановете за адреси не трябва да се припокриват, а две конфигурации, които обявяват едни и същи префикси, се нуждаят от съзнателно предпочитание, а не от надежда.

Проксито е най-тесният интерфейс. Ако акаунт A се нуждае от една база данни или един API в акаунт B, ограничен посредник ви дава дефиниран вход със собствена история за удостоверяване, регистриране и наличност. Това е и опцията, която най-често се злоупотребява: посредник, който препраща към всяка частна дестинация, се е превърнал в неограничено реле с допълнителни стъпки и няма да се държи като прозрачен пренос от VPC към локалната мрежа за нищо друго.

Ограниченията на peering за VPC си струва да се прочетат преди всичко това, защото обясняват защо четвъртата идея се връща отново и отново и защо не може да работи.

Изберете най-тесния интерфейс, който отговаря на изискването

Подредете въпросите: има ли A нужда от мрежа, набор от мрежи или една услуга? Иска ли локалният екип един път или няколко? Кой има право да променя маршрутизирането за трафика на другия екип? Първият отговор, който дава най-тесния интерфейс, е архитектурата, а всичко след това е реализация.

Запишете отговора заедно с плана за префикси, собствеността на маршрутите, инвентара на тунелите или прикачените елементи и режима на отказ, който всяка страна очаква. Когато някой по-късно попита защо акаунт A не може просто да използва VPN на акаунт B, този запис е отговорът и ви спестява повторно обсъждане на същите три опции в следващия проект.