Эки AWS аккаунту, бир жергиликтүү тармак: кайсы жол?
Жалпы Transit Gateway, эки көз карандысыз VPN же бир кууш прокси: бүгүн кошуу эң оңой болгон маршрутка эмес, ээлик жана таасир аймагына карап тандаңыз.
Айкын алкак — peering жана 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ин жөн эле колдоно албайт деп сураса, ошол жазуу — жооп, жана ал кийинки долбоордо ошол эле үч вариантты кайра талкуулоодон куткарат.