Два акаўнты 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 патрэбна адна база даных або адзін API ў акаўнце B, абмежаваны пасярэднік дае вам вызначаны ўваход з уласнай гісторыяй аўтэнтыфікацыі, журналізацыі і даступнасці. Гэта таксама варыянт, які найчасцей злоўжываюць: пасярэднік, які перасылае да кожнага прыватнага пункта прызначэння, стаў неабмежаваным рэле з дадатковымі крокамі, і ён не будзе паводзіць сябе як празрысты транзіт з VPC у лакальную сетку ні для чаго іншага.
Абмежаванні peering VPC варта прачытаць перад усім гэтым, бо яны тлумачаць, чаму чацвёртая ідэя ўвесь час вяртаецца і чаму яна не можа працаваць.
Выберыце самы вузкі інтэрфейс, які задавальняе патрабаванне
Упарадкуйце пытанні: ці патрэбна A сетка, набор сетак або адна служба? Ці хоча лакальная каманда адзін шлях або некалькі? Каму дазволена змяняць маршрутызацыю трафіку іншай каманды? Першы адказ, які дае самы вузкі інтэрфейс, — гэта архітэктура, а ўсё пасля — рэалізацыя.
Запішыце адказ разам з планам прэфіксаў, уласнасцю маршрутаў, інвентаром тунэляў або далучэнняў і рэжымам адмовы, якога чакае кожны бок. Калі нехта пазней спытае, чаму акаўнт A не можа проста выкарыстаць VPN акаўнта B, гэты запіс — адказ, і ён пазбавіць вас ад паўторнага абмеркавання тых жа трох варыянтаў у наступным праекце.