Ilmselge raamistus on peering versus VPN, ja see on vale raamistus. Peeritud VPC ei saa naabri VPN-ühendust servast serva marsruutimiseks laenata, nii et see valik ei olnud kunagi laual, ükskõik mida marsruutimistabel vihjab. Tegelikult valite jagatud võrgukeskme, kahe sõltumatu VPN-tee ja kitsa rakendusepääsu vahel. Igaüks neist vastab erinevale küsimusele selle kohta, kellele marsruutimine kuulub.

Kolm valikut ja see, mis ei ole valik

Alustage peeringu-idee kustutamisest ja võrrelge seejärel järelejäänut omandi, mitte diagrammi lihtsuse järgi. Allolev tabel on otsus kokkusurutud kujul.

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

Kui konto A vajab juurdepääsu tervele kohalikule võrgule, on puhverserveri rida vale kujuga. Kui konto A vajab ühte API-t, on kaks esimest rida rohkem võrku, kui nõue palub.

Millal võidab ühine Transit Gateway

Transit Gateway ühendab iga VPC ja VPN-i eraldi võrkudena, ja kontodevaheline jagamine laseb VPC omanikel keskust kasutada ilma kontosid ühendamata. See ongi võlu: üks koht, kus kohalikud prefiksid kohtuvad AWS-i võrkudega, ja üks koht, kus arutleda, milline kinnitus õpib millise marsruudi.

Kõige kinnitamine ei tähenda kõige lubamist. Seos ja levitamine otsustavad, milline kinnitus kasutab millist marsruutimistabelit, nii et kaks VPC prefiksit võivad mõlemad jõuda kohaliku teenuseni, samal ajal kui nende vastastikune juurdepääs jääb keskuse disaini tõttu välistatuks. Kohalik pool vajab endiselt AWS-i prefiksite jaoks tagasiteid, ja see on teise meeskonna muudatuspilet.

Kulu on sama palju organisatsiooniline kui rahaline. Keskuse omanik kontrollib marsruutimissuhteid, millest teised meeskonnad sõltuvad, nii et ühe kinnituse muudatus võib liigutada liiklust teenuse jaoks, millest keskuse omanik pole kunagi kuulnud. Kinnitustunnid ja andmetöötlus kogunevad iga kinnitatud võrguga, mistõttu keskused kasvavad tavaliselt kiiremini kui meeskond, kes neid haldab.

Millal võidavad eraldi VPN-id või kitsas puhverserver

Kaks sõltumatut VPN-i sobivad väikese kasutuselevõtuga, millel on tõelised operatiivsed piirid: iga konto muudab oma tunneleid ja kumbki ei saa teist rikkuda marsruutimistabelit muutes. Piirid on kohalikul poolel. Partnerlüüs vajab lisatunnelite jaoks mahtu, aadressiplaanid ei tohi kattuda ja kaks sama prefiksit reklaamivat konfiguratsiooni vajavad meelega tehtud eelistust, mitte lootust.

Puhverserver on kõige kitsam liides. Kui konto A vajab ühte andmebaasi või ühte API-t kontos B, annab piiratud vahendaja teile määratletud pääsu oma autentimise, logimise ja kättesaadavuse looga. See on ka kõige kergemini väärkasutatav valik: vahendaja, mis edastab igasse privaatsesse sihtkohta, on muutunud piiramatuks releeks lisasammudega ja ei käitu millegi muu jaoks läbipaistva VPC-st kohalikku võrku edastusena.

Enne kõike seda tasub lugeda VPC peeringu piiranguid, sest need selgitavad, miks neljas idee ikka ja jälle tagasi tuleb ja miks see ei saa toimida.

Vali kitsaim liides, mis nõude täidab

Järjestage küsimused: kas A vajab võrku, võrkude kogumit või ühte teenust? Kas kohalik meeskond tahab ühte teed või mitut? Kes tohib muuta teise meeskonna liikluse marsruutimist? Esimene vastus, mis annab kõige kitsama liidese, on arhitektuur, ja kõik pärast seda on teostus.

Kirjutage vastus üles koos prefiksiplaaniga, marsruutide omandiga, tunnelite või kinnituste loendiga ja tõrkerežiimiga, mida kumbki pool ootab. Kui keegi hiljem küsib, miks konto A ei saa lihtsalt konto B VPN-i kasutada, on see kirje vastus ja säästab teid samade kolme valiku uuesti arutamisest järgmises projektis.

Seotud artiklid