دو حساب 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 به یک پایگاه داده یا یک API در حساب B نیاز دارد، یک واسطه محدود به شما ورودی مشخصی با داستان احراز هویت، ثبت گزارش و دسترس‌پذیری خودش می‌دهد. همچنین گزینه‌ای است که بیش از همه در معرض سوءاستفاده است: واسطه‌ای که به هر مقصد خصوصی هدایت می‌کند به رله‌ای بی‌محدود با گام‌های اضافی تبدیل شده است، و برای هیچ چیز دیگری مانند گذر شفاف از VPC به شبکه محلی رفتار نخواهد کرد.
ارزش دارد محدودیت‌های peering در VPC را پیش از همه اینها بخوانید، زیرا توضیح می‌دهند چرا ایده چهارم همیشه بازمی‌گردد و چرا نمی‌تواند کار کند.
باریک‌ترین رابطی را انتخاب کنید که نیاز را برآورده می‌کند
پرسش‌ها را مرتب کنید: آیا A به یک شبکه، مجموعه‌ای از شبکه‌ها یا یک سرویس نیاز دارد؟ آیا تیم محلی یک مسیر می‌خواهد یا چند مسیر؟ چه کسی مجاز است مسیریابی ترافیک تیم دیگر را تغییر دهد؟ نخستین پاسخ که باریک‌ترین رابط را می‌سازد معماری است، و همه چیز پس از آن پیاده‌سازی است.
پاسخ را همراه با طرح پیشوند، مالکیت مسیرها، فهرست تونل‌ها یا اتصال‌ها و حالت شکستی که هر طرف انتظار دارد ثبت کنید. وقتی بعداً کسی می‌پرسد چرا حساب A نمی‌تواند به‌سادگی از VPN حساب B استفاده کند، همان سند پاسخ است، و شما را از بحث دوباره درباره همان سه گزینه در پروژه بعدی نجات می‌دهد.