Očito kadriranje je peering protiv VPN-a, i to je pogrešno kadriranje. Povezani VPC ne može posuditi VPN vezu susjeda za usmjeravanje od ruba do ruba, pa ta opcija nikada nije bila na stolu, bez obzira što tabela ruta predlaže. Između čega zapravo birate jest zajedničko mrežno središte, dva nezavisna VPN puta i uski ulaz u aplikaciju. Svako od njih odgovara na različito pitanje o tome kome pripada usmjeravanje.

Tri opcije i ona koja nije opcija

Počnite brisanjem ideje peeringa, pa uporedite ono što ostaje po vlasništvu, a ne po jednostavnosti dijagrama. Tabela ispod je odluka u sažetom obliku.

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

Ako računu A treba dostupnost cijele lokalne mreže, red s proxyjem je pogrešnog oblika. Ako računu A treba jedan API, prva dva reda su više mreže nego što zahtjev traži.

Kada pobjeđuje dijeljeni Transit Gateway

Transit Gateway povezuje svaki VPC i VPN kao odvojene mreže, a dijeljenje između računa omogućuje vlasnicima VPC-a da koriste središte bez spajanja računa. U tome je privlačnost: jedno mjesto gdje se lokalni prefiksi sreću s AWS mrežama, i jedno mjesto za razmišljanje o tome koji priključak uči koju rutu.

Priključiti sve ne znači dopustiti sve. Pridruživanje i propagacija odlučuju koji priključak koristi koju tabelu ruta, tako da dva VPC prefiksa mogu svaki dosegnuti lokalnu uslugu dok njihov međusobni pristup ostaje isključen dizajnom središta. Lokalna strana i dalje treba povratne rute za AWS prefikse, a to je promjena koju mora odobriti drugi tim.

Trošak je organizacijski koliko i financijski. Vlasnik središta kontrolira odnose usmjeravanja o kojima ovise drugi timovi, pa promjena na jednom priključku može premjestiti promet za uslugu za koju vlasnik središta nikada nije čuo. Sati priključka i obrada podataka zbrajaju se sa svakom mrežom koju priključite, zbog čega središta obično rastu brže od tima koji ih vodi.

Kada pobjeđuju odvojeni VPN-ovi ili uski proxy

Dva nezavisna VPN-a odgovaraju malom postavljanju sa stvarnim operativnim granicama: svaki račun mijenja svoje tunele, i nijedan ne može pokvariti drugi uređivanjem tabele ruta. Ograničenja su na lokalnoj strani. Mrežni prolaz vršnjaka treba kapacitet za dodatne tunele, planovi adresa ne smiju se preklapati, a dvije konfiguracije koje oglašavaju iste prefikse trebaju namjernu prednost, a ne nadu.

Proxy je najuži interfejs. Ako računu A treba jedna baza podataka ili jedan API u računu B, ograničeni posrednik daje vam definisan ulaz sa vlastitom pričom o autentifikaciji, evidentiranju i dostupnosti. To je i opcija koja se najčešće zloupotrebljava: posrednik koji prosljeđuje na svako privatno odredište postao je neograničen relej s dodatnim koracima, i neće se ponašati kao transparentni prijenos od VPC-a do lokalne mreže ni za što drugo.

Ograničenja VPC peeringa vrijedi pročitati prije svega ovoga, jer objašnjavaju zašto se četvrta ideja stalno vraća i zašto ne može funkcionisati.

Odaberite najuži interfejs koji zadovoljava zahtjev

Poredajte pitanja: treba li A mreža, skup mreža ili jedna usluga? Želi li lokalni tim jedan put ili više? Kome je dopušteno mijenjati usmjeravanje prometa drugog tima? Prvi odgovor koji daje najuži interfejs je arhitektura, a sve poslije toga je implementacija.

Zabilježite odgovor uz plan prefiksa, vlasništvo nad rutama, inventar tunela ili priključaka i način otkaza koji svaka strana očekuje. Kada neko kasnije pita zašto račun A ne može jednostavno koristiti VPN računa B, taj zapis je odgovor, i spašava vas od ponovnog raspravljanja o iste tri opcije na sljedećem projektu.

Povezani članci