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 šta predlaže tabela ruta. Ono između čega zapravo birate je zajedničko mrežno čvorište, dvije nezavisne VPN putanje i uski ulaz za aplikaciju. Svaka od njih odgovara na drugo pitanje o tome ko posjeduje usmjeravanje.

Tri opcije i ona koja nije opcija

Počnite tako što ćete izbrisati ideju 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 zajednički Transit Gateway

Transit Gateway povezuje svaki VPC i VPN kao zasebne mreže, a dijeljenje između računa omogućava 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 dozvoliti 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 č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 finansijski. Vlasnik čvorišta kontroliše odnose usmjeravanja o kojima zavise drugi timovi, pa promjena na jednom priključku može premjestiti saobraćaj za uslugu za koju vlasnik čvorišta nikada nije čuo. Sati priključka i obrada podataka se zbrajaju 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 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 sopstvenom 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 prenos od VPC-a do lokalne mreže ni za šta 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 jednu putanju ili više? Kome je dozvoljeno mijenjati usmjeravanje za saobraćaj 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