Hinn augljósi rammi er peering gegn VPN, og það er rangur rammi. VPC í peering getur ekki fengið VPN-tengingu nágrannans að láni fyrir leiðsögn frá brún til brúnar, svo sá valkostur var aldrei á borðinu, hvað sem leiðartöflur segja. Það sem þú velur í raun er milli sameiginlegs netkjarna, tveggja óháðra VPN-leiða og þröngrar inngöngu fyrir forrit. Hver þeirra svarar annarri spurningu um hver á leiðsögnina.

Þrír valkostir og sá sem er ekki valkostur

Byrjaðu á að eyða peering-hugmyndinni og berðu síðan saman það sem eftir er út frá eignarhaldi en ekki einfaldleika skýringarmyndarinnar. Taflan hér að neðan er ákvörðunin í þjappaðri mynd.

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

Ef reikningur A þarf að ná til heils staðbundins nets er proxy-röðin röng að lögun. Ef reikningur A þarf eitt API eru fyrstu tvær raðirnar meira net en krafan bað um.

Hvenær sameiginlegt Transit Gateway vinnur

Transit Gateway tengir hvert VPC og VPNið sem aðskilin net, og deiling milli reikninga leyfir eigendum VPC að nota kjarnann án þess að sameina reikninga. Það er aðdráttaraflið: einn staður þar sem staðbundnu forskeytin mæta AWS-netunum, og einn staður til að rökræða hvaða viðhengi lærir hvaða leið.

Að tengja allt þýðir ekki að leyfa allt. Félag og útbreiðsla ákvarða hvaða viðhengi notar hvaða leiðartöflu, svo tvö VPC-forskeyti geta hvort náð staðbundinni þjónustu á meðan gagnkvæmur aðgangur þeirra helst útilokaður af hönnun kjarnans. Staðbundið hlið þarf enn afturleiðir fyrir AWS-forskeytin, og það er breytingamiði frá öðru teymi.

Kostnaðurinn er skipulagslegur jafnt sem fjárhagslegur. Eigandi kjarnans stýrir leiðsagnarsamböndum sem önnur teymi treysta á, svo breyting á einu viðhengi getur fært umferð fyrir þjónustu sem eigandi kjarnans hefur aldrei heyrt um. Viðhengistímar og gagnavinnsla leggjast saman með hverju neti sem þú tengir, og þess vegna vaxa kjarnar yfirleitt hraðar en teymið sem rekur þá.

Hvenær aðskilin VPN eða þröngur proxy vinnur

Tvö óháð VPN henta lítilli uppsetningu með raunverulegum rekstrarmörkum: hver reikningur breytir sínum eigin göngum, og hvorugt getur brotið hitt með því að breyta leiðartöflu. Mörkin eru á staðbundinni hlið. Jafningjahliðið þarf afkastagetu fyrir viðbótargöngin, netfangaskipulögin mega ekki skarast, og tvær stillingar sem auglýsa sömu forskeytin þurfa viljandi forgang frekar en von.

Proxy er þrengsta viðmótið. Ef reikningur A þarf eina gagnagrunn eða eitt API í reikningi B gefur afmarkaður milliliður þér skilgreinda inngöngu með eigin sögu um auðkenningu, skráningu og framboð. Það er líka sá valkostur sem líklegast er að misnota: milliliður sem sendir áfram á hvert einkaaðfang hefur orðið takmarkalaus endurvarpi með aukaskrefum, og hann mun ekki haga sér sem gagnsæ flutningur frá VPC til staðbundins nets fyrir nokkuð annað.

Það er þess virði að lesa takmarkanir VPC-peering fyrir allt þetta, því þær útskýra hvers vegna fjórða hugmyndin kemur aftur og aftur og hvers vegna hún getur ekki virkað.

Veldu þrengsta viðmótið sem uppfyllir kröfuna

Raðaðu spurningunum: þarf A net, safn neta eða eina þjónustu? Vill staðbundið teymi eina leið eða fleiri? Hver má breyta leiðsögn fyrir umferð hins teymisins? Fyrsta svarið sem gefur þrengsta viðmótið er arkitektúrinn, og allt eftir það er útfærsla.

Skráðu svarið með forskeytaáætluninni, eignarhaldi leiða, skrá yfir göng eða viðhengi og bilanatstillingunni sem hvor hlið væntir. Þegar einhver spyr síðar hvers vegna reikningur A geti ekki einfaldlega notað VPN reiknings B, er sú skráning svarið, og hún sparar þér að ræða sömu þrjá valkostina aftur í næsta verkefni.

Tengdir greinar