Dua akun AWS, satu jaringan lokal: jalur mana?
Transit Gateway bersama, dua VPN independen, atau satu proxy sempit: pilih berdasarkan kepemilikan dan radius dampak, bukan berdasarkan rute mana yang paling mudah ditambahkan hari ini.
Kerangka yang tampak jelas adalah peering versus VPN, dan itu kerangka yang salah. VPC yang di-peering tidak dapat meminjam koneksi VPN tetangganya untuk perutean ujung ke ujung, jadi opsi itu tidak pernah tersedia, apa pun yang disarankan tabel rute. Yang sebenarnya Anda pilih adalah hub jaringan bersama, dua jalur VPN independen, dan satu pintu masuk aplikasi yang sempit. Masing-masing menjawab pertanyaan berbeda tentang siapa yang memiliki perutean.
Tiga opsi dan satu yang bukan opsi
Mulailah dengan menghapus gagasan peering, lalu bandingkan yang tersisa berdasarkan kepemilikan, bukan kesederhanaan diagram. Tabel di bawah ini adalah keputusannya dalam bentuk ringkas.
| 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 |
Jika akun A memerlukan keterjangkauan ke seluruh jaringan lokal, baris proxy adalah bentuk yang salah. Jika akun A memerlukan satu API, dua baris pertama adalah jaringan yang lebih banyak daripada yang diminta kebutuhan.
Kapan Transit Gateway bersama menang
Transit Gateway melampirkan setiap VPC dan VPN sebagai jaringan terpisah, dan berbagi antar-akun memungkinkan pemilik VPC menggunakan hub tanpa menggabungkan akun. Itulah daya tariknya: satu tempat di mana prefiks lokal bertemu jaringan AWS, dan satu tempat untuk menalar lampiran mana mempelajari rute mana.
Melampirkan semuanya tidak berarti mengizinkan semuanya. Asosiasi dan propagasi menentukan lampiran mana menggunakan tabel rute mana, sehingga dua prefiks VPC masing-masing dapat menjangkau layanan lokal sementara akses timbal baliknya tetap dikecualikan oleh desain hub. Sisi lokal tetap memerlukan rute balik untuk prefiks AWS, dan itu adalah tiket perubahan tim lain.
Biayanya bersifat organisasi sekaligus finansial. Pemilik hub mengendalikan hubungan perutean yang diandalkan tim lain, sehingga perubahan pada satu lampiran dapat memindahkan lalu lintas layanan yang belum pernah didengar pemilik hub. Jam lampiran dan pemrosesan data bertambah dengan setiap jaringan yang Anda lampirkan, itulah sebabnya hub cenderung tumbuh lebih cepat daripada tim yang menjalankannya.
Kapan VPN terpisah atau proxy sempit menang
Dua VPN independen cocok untuk penerapan kecil dengan batas operasional nyata: setiap akun mengubah terowongannya sendiri, dan tidak ada yang dapat merusak yang lain dengan mengedit tabel rute. Batasannya ada di sisi lokal. Gateway pasangan memerlukan kapasitas untuk terowongan tambahan, rencana alamat tidak boleh tumpang tindih, dan dua konfigurasi yang mengiklankan prefiks sama memerlukan preferensi yang disengaja, bukan harapan.
Proxy adalah antarmuka tersempit. Jika akun A memerlukan satu basis data atau satu API di akun B, perantara yang dibatasi memberi Anda pintu masuk terdefinisi dengan cerita autentikasi, pencatatan, dan ketersediaannya sendiri. Ini juga opsi yang paling mungkin disalahgunakan: perantara yang meneruskan ke setiap tujuan privat telah menjadi relai tanpa batas dengan langkah tambahan, dan tidak akan berperilaku sebagai transit transparan dari VPC ke jaringan lokal untuk hal lain.
Pembatasan peering VPC layak dibaca sebelum semua ini, karena menjelaskan mengapa gagasan keempat terus kembali dan mengapa itu tidak dapat berhasil.
Pilih antarmuka tersempit yang memenuhi kebutuhan
Urutkan pertanyaannya: apakah A memerlukan jaringan, sekumpulan jaringan, atau satu layanan? Apakah tim lokal menginginkan satu jalur atau beberapa? Siapa yang boleh mengubah perutean lalu lintas tim lain? Jawaban pertama yang menghasilkan antarmuka tersempit adalah arsitekturnya, dan semua setelahnya adalah implementasi.
Catat jawabannya bersama rencana prefiks, kepemilikan rute, inventaris terowongan atau lampiran, dan mode kegagalan yang diharapkan setiap sisi. Ketika nanti seseorang bertanya mengapa akun A tidak bisa begitu saja menggunakan VPN akun B, catatan itu adalah jawabannya, dan itu menyelamatkan Anda dari memperdebatkan tiga opsi yang sama pada proyek berikutnya.