Хоёр AWS бүртгэл, нэг дотоод сүлжээ: аль зам?
Хамтарсан Transit Gateway, хоёр бие даасан VPN эсвэл нэг нарийн прокси: өнөөдөр аль замыг нэмэхэд хялбар вэ гэхээс илүү эзэмшил, нөлөөний хүрээгээр сонгоно уу.
Тодорхой хүрээ бол peering ба VPN-ийн харьцуулалт бөгөөд энэ нь буруу хүрээ юм. Пирингтэй VPC хөршийнхөө VPN холболтыг ирмэгээс ирмэг хүртэл маршрутлахаар зээлж чадахгүй тул маршрутын хүснэгт юу ч санал болгосон энэ сонголт хэзээ ч ширээн дээр байгаагүй. Та бодитоор сүлжээний төв, хоёр бие даасан VPN зам, нэг нарийн аппликейшн орох хаалганы хооронд сонгож байна. Нэг бүр нь маршрутлал хэнд хамаарах тухай өөр асуултад хариулдаг.
Гурван сонголт ба сонголт биш нэг нь
Peering гэсэн санааг устгаж эхэл, дараа нь үлдсэнийг диаграмын энгийн байдлаар биш, эзэмшлээр харьцуул. Доорх хүснэгт нь шийдвэрийн товч хэлбэр юм.
| 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 |
Хэрэв A бүртгэл бүх дотоод сүлжээнд хүрэх шаардлагатай бол прокси мөр нь буруу хэлбэртэй. Хэрэв A бүртгэлд нэг API хэрэгтэй бол эхний хоёр мөр шаардлагаас илүү их сүлжээ юм.
Хамтарсан Transit Gateway хэзээ ялдаг
Transit Gateway нь VPC бүр болон VPN-ийг тусдаа сүлжээ болгон холбодог, бүртгэл хоорондын хуваалцалт нь VPC эзэмшигчдэд бүртгэлүүдийг нэгтгэхгүйгээр төвийг ашиглах боломж олгодог. Энэ нь татах хүч: дотоод префиксүүд AWS сүлжээнүүдтэй уулздаг нэг газар, аль хавсралт аль замыг сурдаг талаар бодох нэг газар.
Бүгдийг холбох нь бүгдийг зөвшөөрөх гэсэн үг биш. Холболт ба тархалт нь аль хавсралт аль маршрутын хүснэгтийг ашиглахыг шийддэг тул хоёр VPC префикс тус бүр дотоод үйлчилгээнд хүрч чадах бөгөөд харин тэдний харилцан хандалт төвийн дизайнаар гадуур үлддэг. Дотоод тал AWS префиксүүдэд буцах замыг одоо ч шаарддаг бөгөөд энэ нь өөр багийн өөрчлөлтийн тасалбар юм.
Зардал нь санхүүгийн адил байгууллагын ч байна. Төвийн эзэн бусад багууд хамааралтай маршрутлалын харилцааг удирддаг тул нэг хавсралтын өөрчлөлт төвийн эзний хэзээ ч сонсоогүй үйлчилгээний урсгалыг зөөж чадна. Хавсралтын цаг ба өгөгдлийн боловсруулалт нь холбосон сүлжээ бүртэй нэмэгддэг тул төвүүд ихэвчлэн тэдгээрийг ажиллуулдаг багаас хурдан өсдөг.
Тусдаа VPN эсвэл нарийн прокси хэзээ ялдаг
Хоёр бие даасан VPN нь бодит үйл ажиллагааны хил хязгаартай жижиг байршуулалтад тохирно: бүртгэл бүр өөрийн туннелүүдийг өөрчилдөг, аль нь ч маршрутын хүснэгтийг засварлаж нөгөөг нь эвдэж чадахгүй. Хязгаарууд дотоод талд байдаг. Хос гарц нь нэмэлт туннелүүдэд багтаамж хэрэгтэй, хаягийн төлөвлөгөө давхцаж болохгүй, нэг префиксыг зарласан хоёр тохиргоонд итгэл биш санаатай давуу эрх хэрэгтэй.
Прокси бол хамгийн нарийн интерфейс. Хэрэв A бүртгэлд B бүртгэл дэх нэг өгөгдлийн сан эсвэл нэг API хэрэгтэй бол хязгаарлагдмал зуучлагч танд өөрийн баталгаажуулалт, лог, боломжийн түүхтэй тодорхой орох хаалга өгдөг. Энэ нь мөн хамгийн их ашиглан буруу ашиглагддаг сонголт юм: хувийн зорчих газар бүр рүү дамжуулдаг зуучлагч нь нэмэлт алхамтай хязгааргүй реле болж, бусад бүх зүйлд VPC-ээс дотоод сүлжээ рүү тунгалаг дамжуулалт мэт ажиллахгүй.
VPC peering-ийн хязгаарлалтуудыг энэ бүхнээс өмнө унших нь зүйтэй, учир нь дөрөв дэх санаа яагаад дахин дахин буцаж ирдэг, яагаад ажиллаж чадахгүйг тэд тайлбарладаг.
Шаардлагад нийцсэн хамгийн нарийн интерфейсийг сонго
Асуултуудыг эрэмбэл: A-д нэг сүлжээ, сүлжээний багц эсвэл нэг үйлчилгээ хэрэгтэй юу? Дотоод баг нэг зам эсвэл хэд хэдэн зам хүсэж байна уу? Нөгөө багийн урсгалын маршрутлалыг хэн өөрчилж болох вэ? Хамгийн нарийн интерфейсийг бий болгодог эхний хариулт нь архитектур бөгөөд дараагийн бүх зүйл хэрэгжилт юм.
Хариултыг префиксийн төлөвлөгөө, маршрутын эзэмшил, туннель эсвэл хавсралтын бүртгэл, тал бүрийн хүлээж буй эвдрэлийн горимтой хамт бүртгэ. Хожим нэгэн A бүртгэл яагаад B бүртгэлийн VPN-ийг энгийнээр ашиглаж болохгүй гэж асуухад тэр бүртгэл нь хариулт бөгөөд дараагийн төсөлд ижил гурван сонголтыг дахин хэлэлцэхээс чөлөөлнө.