Isang site-to-site na VPN para sa maraming VPC sa AWS Transit Gateway

Dalawang VPC ang nangangailangan ng network ng opisina ngayong quarter, at sa ikalawang tunnel nagkakawatak-watak ang estima. Ang AWS Transit Gateway ay maaaring maging shared routing hub: ang VPN ay ikinakabit nang isang beses, at bawat VPC ay ikinakabit sa parehong hub. Pagkatapos, naaabot ng on-premises network ang bawat nakakabit na VPC sa isang koneksyon. Binabago nito kung sino ang may hawak ng desisyon sa routing, at iyon ang bahaging mali sa karamihan ng disenyo.

Ang attachment ng VPN at ang mga attachment ng VPC ay magkahiwalay na object sa parehong gateway, kaya ang mga relasyon sa routing ay kailangang itayo pagkatapos.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Bakit ang peering ay hindi ang shortcut na inaasahan ng mga tao

Ang nakakaakit na alternatibo ay tapusin ang VPN sa VPC A at i-peer ang VPC B dito. Ang ordinaryong VPC peering ay hindi nagbibigay ng transit mula sa gilid hanggang gilid sa koneksyon ng VPN ng A. Ang peer ay umaabot lamang sa mga address na ibinibigay ng peering mismo, at ang gilid ng VPN ay hindi isa sa mga iyon. Ang transit ay ibinibigay ng hub; ang peering ay nagbibigay ng isang pares.

Ang paghihigpit na iyon ay katangian ng peering, hindi quota na maaaring itaas.

Ang asosasyon at pagpapalaganap ay gumagawa ng magkaibang trabaho

Sa loob ng transit gateway, pinipili ng asosasyon ang routing table na ginagamit upang hanapin ang trapikong dumarating mula sa isang attachment. Ang pagpapalaganap ang nagpapasya kung aling mga table ang tatanggap ng mga natutunan o nakakabit na prefix ng isang attachment. Ang isang attachment ay maaaring maiugnay sa isang table habang nagpapalaganap sa marami. Ang paghahalo ng dalawa ay ang paraan upang matapos ang isang disenyo na may maabot na walang nagplano.

Ang maliit na hub na ganap na konektado ang madaling kaso.

Ilagay ang bawat attachment sa isang table at ang VPN kasama ang dalawang prefix ng VPC ay malinis na nalulutas. Pinapayagan din nito ang pag-abot sa pagitan ng mga VPC na maaaring hindi kailanman inaasahan ng organisasyon, dahil ang shared table ay walang konsepto ng spoke.

Ang mga ruta ng workload ay nakatira sa ibang lugar

Ang bawat subnet ng workload ay kailangan pa rin ng sarili nitong ruta patungo sa transit gateway para sa mga nilalayong lokal na prefix. Ang mga routing table ng VPC na iyon ay magkahiwalay na object mula sa mga table ng gateway mismo. Idagdag ang mga prefix na kailangan at panatilihin ang umiiral na mga ruta sa halip na palitan ang bawat destinasyon ng bagong default. Ang ruta ng subnet ay wala ring inaanunsyo sa device ng customer.

Piliin ang dynamic o static na routing nang sinasadya; ang peering ay wala sa dalawa.

Ihiwalay ang mga spoke nang hindi nawawala ang lokal na access

Kapag ang A at B ay parehong makakaabot sa opisina ngunit hindi dapat mag-ruta sa isa't isa, hatiin ang mga table. Ang asosyadong table ng attachment ng VPN ay may mga prefix ng VPC. Ang asosyadong table ng mga attachment ng VPC ay may mga lokal na prefix, na walang rutang nag-uugnay kay A at B. Ang pagpapalaganap ang lumilikha ng relasyong iyon, kaya hindi mo kailangang tanggapin ang bawat default na asosasyon.

Ito ay paghihiwalay ng routing, at hindi ito awtorisasyon ng application.

Ang mga security group, network ACL, firewall ng host at sariling pahintulot ng bawat serbisyo ay nagpapasya pa rin kung anong trapiko ang tinatanggap. Kung kailangan ng inspeksyon, idisenyo nang tahasan ang sinusuportahang landas nito sa halip na ipagpalagay na ginagawa ito ng hub.

Ang hindi inaayos ng hub

Ang mga plano sa address ay kailangan pa ring walang overlap, dahil hindi pinapayagan ng hub na ang isang prefix ay tukuyin ang dalawang workload. Ang bawat attachment ng VPC ay nangangailangan ng saklaw ng Availability Zone na inaasahan ng mga workload nito. Sa BGP, ang mga ruta ng device ng customer pabalik sa bawat kinakailangang prefix ay dapat tumugma sa disenyo at sa patakaran ng pag-import nito. Ang nawawalang anunsyo ay mukhang eksaktong sirang tunnel.

Ang koneksyon ng VPN at ang transit gateway ay shared infrastructure na ngayon.

Planuhin ang redundancy ng mga tunnel, kapasidad ng device, pagsubaybay at pagpapanatili sa paligid ng lahat ng umaasa na VPC sa halip na ituring ang bawat isa na independiyenteng konektado.

Ang paglipat mula sa umiiral na virtual private gateway ay karapat-dapat sa parehong tahasang plano. Itayo ang mga attachment at patakaran, ilipat ang isang kontroladong landas ng workload, at kumpirmahin ang pinapayagan at tinatanggihang relasyon bago i-retiro ang lumang landas. Nakakatulong ang sentralisasyon kapag binibigyan nito ang network team ng isang lugar upang pamahalaan ang shared connectivity, at nakakasama kapag itinatago nito kung sino ang makakaabot kanino sa likod ng isang malaking table.