Očigledan okvir je peering nasuprot VPN-a, i to je pogrešan okvir. Povezani VPC ne može posuditi VPN vezu svog susjeda za usmjeravanje od ruba do ruba, pa ta opcija nikada nije bila na stolu, bez obzira što predlaže tablica ruta. Ono između čega zapravo birate je zajedničko mrežno čvorište, dva neovisna VPN puta i uski ulaz za aplikaciju. Svaki od njih odgovara na drugo pitanje o tome kome pripada usmjeravanje.

Tri opcije i ona koja nije opcija

Počnite tako što ćete izbrisati ideju peeringa, pa usporedite ono što ostaje po vlasništvu, a ne po jednostavnosti dijagrama. Tablica 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 zajednički Transit Gateway

Transit Gateway povezuje svaki VPC i VPN kao zasebne mreže, a dijeljenje između računa omogućuje vlasnicima VPC-a da koriste čvorište bez spajanja računa. To je privlačnost: jedno mjesto gdje se lokalni prefiksi susreć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 tablicu ruta, tako da dva VPC prefiksa mogu svaki dosegnuti lokalnu uslugu dok njihov međusobni pristup ostaje isključen dizajnom čvoriš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 čvorišta kontrolira odnose usmjeravanja o kojima ovise drugi timovi, pa promjena na jednom priključku može premjestiti promet za uslugu za koju vlasnik čvorišta nikada nije čuo. Sati priključka i obrada podataka zbrajaju se sa svakom mrežom koju priključite, zbog čega čvorišta obično rastu brže od tima koji ih vodi.

Kada pobjeđuju odvojeni VPN-ovi ili uski proxy

Dva neovisna VPN-a odgovaraju malom postavljanju sa stvarnim operativnim granicama: svaki račun mijenja svoje tunele, i nijedan ne može pokvariti drugi uređivanjem tablice 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 definiran 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 funkcionirati.

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 za promet 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 netko 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