Divi AWS konti, viens vietējais tīkls: kurš ceļš?
Kopīgs Transit Gateway, divi neatkarīgi VPN vai viens šaurs starpniekserveris: izvēlieties pēc īpašumtiesībām un ietekmes apjoma, nevis pēc tā, kuru maršrutu šodien ir visvieglāk pievienot.
Acīmredzamais ietvars ir peering pret VPN, un tas ir nepareizais ietvars. Peering savienots VPC nevar aizņemties sava kaimiņa VPN savienojumu maršrutēšanai no malas līdz malai, tāpēc šī iespēja nekad nav bijusi uz galda, lai ko arī ieteiktu maršrutu tabula. Tas, starp ko jūs faktiski izvēlaties, ir kopīgs tīkla centrmezgls, divi neatkarīgi VPN ceļi un šaurs lietojumprogrammas ieeja. Katrs no tiem atbild uz citu jautājumu par to, kam pieder maršrutēšana.
Trīs iespējas un tā, kas nav iespēja
Sāciet ar peering idejas dzēšanu, pēc tam salīdziniet to, kas palicis, pēc īpašumtiesībām, nevis pēc diagrammas vienkāršības. Zemāk esošā tabula ir lēmums saspiestā formā.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Ja kontam A ir nepieciešama sasniedzamība uz visu vietējo tīklu, starpniekservera rinda ir nepareizā formā. Ja kontam A ir nepieciešams viens API, pirmās divas rindas ir vairāk tīkla, nekā prasa prasība.
Kad uzvar kopīgais Transit Gateway
Transit Gateway pievieno katru VPC un VPN kā atsevišķus tīklus, un kopīgošana starp kontiem ļauj VPC īpašniekiem izmantot centrmezglu, neapvienojot kontus. Tas ir vilinājums: viena vieta, kur vietējie prefiksi satiekas ar AWS tīkliem, un viena vieta, kur spriest, kura pievienojumvienība apgūst kuru maršrutu.
Pievienot visu nenozīmē atļaut visu. Asociācija un propagācija nosaka, kura pievienojumvienība izmanto kuru maršrutu tabulu, tāpēc divi VPC prefiksi var katrs sasniegt vietējo pakalpojumu, kamēr to savstarpējā piekļuve paliek izslēgta centrmezgla dizaina dēļ. Vietējai pusei joprojām ir vajadzīgi atpakaļceļi AWS prefiksiem, un tas ir citas komandas izmaiņu pieprasījums.
Izmaksas ir gan organizatoriskas, gan finansiālas. Centrmezgla īpašnieks kontrolē maršrutēšanas attiecības, no kurām atkarīgas citas komandas, tāpēc vienas pievienojumvienības izmaiņas var pārvietot pakalpojuma, par kuru centrmezgla īpašnieks nekad nav dzirdējis, trafiku. Pievienošanas stundas un datu apstrāde summējas ar katru pievienoto tīklu, tāpēc centrmezgli parasti aug ātrāk nekā to uzturētāja komanda.
Kad uzvar atsevišķi VPN vai šaurs starpniekserveris
Divi neatkarīgi VPN atbilst nelielai ieviešanai ar reālām darbības robežām: katrs konts maina savus tuneļus, un neviens nevar sabojāt otru, rediģējot maršrutu tabulu. Robežas ir vietējā pusē. Pāra vārtejai ir nepieciešama jauda papildu tuneļiem, adrešu plāni nedrīkst pārklāties, un divām konfigurācijām, kas reklamē vienus un tos pašus prefiksus, ir vajadzīga apzināta priekšroka, nevis cerība.
Starpniekserveris ir šaurākā saskarne. Ja kontam A ir nepieciešama viena datubāze vai viens API kontā B, ierobežots starpnieks dod jums definētu ieeju ar savu autentifikācijas, žurnālēšanas un pieejamības stāstu. Tā ir arī iespēja, kas visbiežāk tiek ļaunprātīgi izmantota: starpnieks, kas pārsūta uz katru privāto galamērķi, ir kļuvis par neierobežotu retranslatoru ar papildu soļiem, un tas neuzvedīsies kā caurspīdīga plūsma no VPC uz vietējo tīklu nekam citam.
Ir vērts izlasīt VPC peering ierobežojumus pirms visa šī, jo tie izskaidro, kāpēc ceturtā ideja atgriežas atkal un atkal un kāpēc tā nevar darboties.
Izvēlieties šaurāko saskarni, kas atbilst prasībai
Sakārtojiet jautājumus: vai A ir vajadzīgs tīkls, tīklu kopums vai viens pakalpojums? Vai vietējā komanda vēlas vienu ceļu vai vairākus? Kas drīkst mainīt otras komandas trafika maršrutēšanu? Pirmā atbilde, kas dod šaurāko saskarni, ir arhitektūra, un viss pēc tam ir ieviešana.
Pierakstiet atbildi kopā ar prefiksu plānu, maršrutu īpašumtiesībām, tuneļu vai pievienojumvienību inventarizāciju un atteices režīmu, ko sagaida katra puse. Kad kāds vēlāk jautās, kāpēc konts A nevar vienkārši izmantot konta B VPN, šis pieraksts būs atbilde, un tas ietaupīs jums laiku, atkal apspriežot tos pašus trīs variantus nākamajā projektā.