Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Jenis konektivitas hibrida dan pertimbangan desain
Bagian whitepaper ini mencakup pertimbangan yang memengaruhi pilihan Anda saat memilih jaringan hybrid untuk menghubungkan lingkungan lokal Anda. AWS Ini mengikuti proses pemikiran logis untuk mendukung Anda memilih solusi konektivitas hybrid yang optimal. *Pertimbangan yang memengaruhi desain Anda dikategorikan ke dalam pertimbangan yang memengaruhi *jenis konektivitas* Anda, dan pertimbangan yang memengaruhi desain konektivitas Anda.* Pertimbangan jenis konektivitas akan mendukung Anda memutuskan antara menggunakan VPN berbasis internet atau Direct Connect. Pertimbangan desain konektivitas akan mendukung Anda memutuskan cara mengatur koneksi.
Pertimbangan berikut yang memengaruhi *jenis konektivitas* Anda tercakup: waktu untuk menerapkan, keamanan, SLA, kinerja, dan biaya. Setelah meninjau pertimbangan tersebut, dan bagaimana pengaruhnya terhadap pilihan desain Anda, Anda akan dapat memutuskan apakah menggunakan koneksi berbasis internet atau Direct Connect direkomendasikan untuk memenuhi kebutuhan Anda.
Pertimbangan berikut yang memengaruhi *desain konektivitas* Anda tercakup: skalabilitas, model komunikasi, keandalan, dan integrasi SD-WAN pihak ketiga. Setelah meninjau pertimbangan tersebut, dan bagaimana pengaruhnya terhadap pilihan desain Anda, Anda akan dapat memutuskan desain logis optimal yang direkomendasikan untuk memenuhi kebutuhan Anda.
Struktur berikut digunakan untuk mendiskusikan dan menganalisis setiap pertimbangan pemilihan dan desain:
+ **Definisi** - Definisi singkat tentang apa yang menjadi pertimbangan.
+ **Pertanyaan kunci** - Menyediakan serangkaian pertanyaan untuk memungkinkan Anda mengumpulkan persyaratan yang terkait dengan pertimbangan.
+ **Kemampuan untuk dipertimbangkan** - Solusi untuk mengatasi persyaratan yang terkait dengan pertimbangan.
+ **Pohon keputusan** - Untuk beberapa pertimbangan atau sekelompok pertimbangan, pohon keputusan disediakan untuk membantu Anda memilih solusi jaringan hibrida yang optimal.
Pertimbangan yang mempengaruhi desain jaringan hybrid Anda tercakup dalam urutan di mana output dari satu pertimbangan adalah bagian dari input untuk pertimbangan berikutnya. Seperti yang diilustrasikan pada Gambar 2, langkah pertama adalah memutuskan jenis konektivitas, diikuti dengan menyempurnakannya dengan pertimbangan pemilihan desain.
Gambar 2 menunjukkan dua kategori pertimbangan, pertimbangan individu, dan urutan logis di mana pertimbangan tercakup dalam sub-bagian berikutnya. Itu adalah pertimbangan penting ketika membuat keputusan desain jaringan hybrid. Jika desain yang ditargetkan tidak memerlukan semua pertimbangan ini, Anda dapat fokus pada pertimbangan yang berlaku untuk kebutuhan Anda.
![\[Diagram yang menunjukkan kategori pertimbangan, pertimbangan individu, dan urutan logis di antara mereka\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/consideration-categories.png)
# Pemilihan jenis konektivitas
Bagian ini mencakup pertimbangan yang memengaruhi jenis konektivitas yang Anda pilih untuk beban kerja Anda. Ini termasuk waktu untuk menyebarkan, keamanan, kinerjaSLA, dan biaya.
**Topics**
+ [Waktu untuk menyebarkan](time-to-deploy.md)
+ [Keamanan](security.md)
+ [Perjanjian tingkat layanan (SLA)](service-level-agreement-sla.md)
+ [Kinerja](performance.md)
+ [Biaya](cost.md)
# Waktu untuk menyebarkan
## Definisi
Waktu untuk menyebarkan dapat menjadi faktor penting dalam memilih jenis konektivitas yang sesuai untuk beban kerja. Bergantung pada jenis konektivitas dan lokasi lokal, konektivitas dapat dibuat dalam beberapa jam, namun, mungkin diperlukan waktu berminggu-minggu atau berbulan-bulan jika sirkuit tambahan harus dipasang. Ini akan memengaruhi keputusan Anda untuk menggunakan koneksi berbasis internet, koneksi khusus pribadi, atau koneksi host pribadi yang disediakan sebagai layanan terkelola oleh Mitra. AWS Direct Connect
## Pertanyaan kunci
+ Apa timeline yang diperlukan untuk penyebaran — jam, hari, minggu, atau bulan?
+ Berapa lama koneksi akan dibutuhkan — apakah itu akan menjadi proyek berumur pendek atau infrastruktur permanen?
## Kemampuan untuk dipertimbangkan
Ketika Anda memerlukan AWS konektivitas dalam beberapa jam atau hari, kemungkinan besar Anda perlu menggunakan koneksi jaringan yang ada. Ini sering berarti membangun VPN koneksi AWS ke internet publik. Jika mitra AWS DX yang ada menyediakan AWS konektivitas pribadi kepada Anda, koneksi host baru dapat disediakan dalam beberapa jam.
Ketika Anda memiliki hari hingga berminggu-minggu, Anda dapat bekerja dengan AWS Direct Connect Mitra untuk membangun konektivitas pribadi AWS. AWS Direct Connect Mitra membantu Anda membangun konektivitas jaringan antara AWS Direct Connect lokasi dan pusat data, kantor, atau lingkungan lokasi bersama Anda. [AWS Direct Connect Mitra](https://aws.amazon.com/directconnect/partners/) tertentu disetujui untuk menawarkan [Koneksi Dihosting Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/hosted_connection.html). Koneksi yang di-host seringkali dapat disediakan lebih cepat daripada Koneksi Khusus. AWS Direct Connect Mitra akan menyediakan setiap Koneksi yang Dihosting menggunakan infrastruktur yang ada yang terhubung ke AWS tulang punggung.
Ketika Anda memiliki beberapa minggu hingga berbulan-bulan, Anda dapat menyelidiki membangun koneksi pribadi khusus dengan AWS. Penyedia layanan dan AWS Direct Connect Mitra memfasilitasi Koneksi AWS Direct Connect Khusus. Adalah umum bagi penyedia layanan untuk memasang peralatan jaringan di tempat pelanggan untuk memfasilitasi Koneksi Khusus Direct Connect. Bergantung pada penyedia layanan, lokasi situs Anda, dan faktor fisik lainnya, pemasangan Koneksi Khusus Direct Connect dapat berlangsung dari beberapa minggu hingga beberapa bulan.
Jika Anda sudah memasang peralatan jaringan di fasilitas colocation yang sama di mana AWS Direct Connect lokasinya ada, maka Anda dapat dengan cepat membuat Sambungan AWS Direct Connect Khusus melalui koneksi silang di situs co-location. Setelah Anda meminta koneksi, AWS buat Surat Otorisasi dan Penugasan Fasilitas Penghubung (LOA-CFA) tersedia untuk Anda unduh, atau mengirim email kepada Anda dengan permintaan informasi lebih lanjut. LOA- CFA adalah otorisasi untuk terhubung ke AWS, dan diperlukan oleh penyedia jaringan Anda untuk memesan koneksi silang untuk Anda.
*Tabel 1 — Perbandingan efektivitas biaya*
| | Konektivitas berbasis internet | DX Dedicated Connection (peralatan yang ada di lokasi DX) | Koneksi Khusus DX (net-new) | DX Hosted Connection (port yang ada dengan DX Partner) | Koneksi yang Dihosting DX (net-new) |
| --- | --- | --- | --- | --- | --- |
| Waktu penyediaan | Jam hingga berhari-hari | Hari | Beberapa minggu hingga bulan | Jam hingga berhari-hari | Beberapa hari hingga berminggu-minggu hingga berbulan-bulan |
**catatan**
Pedoman waktu penyediaan yang disediakan didasarkan pada pengamatan dunia nyata dan hanya berfungsi sebagai ilustrasi. Saat mempertimbangkan lokasi situs Anda, kedekatan dengan lokasi koneksi langsung, dan infrastruktur yang sudah ada sebelumnya, dan semuanya akan memengaruhi waktu penyediaan. AWS Direct Connect Mitra Anda akan memberi tahu Anda tentang waktu penyediaan yang tepat.
# Keamanan
## Definisi
Persyaratan keamanan akan memengaruhi jenis konektivitas hybrid Anda. Pertimbangan ini meliputi:
+ Jenis transportasi — koneksi internet atau jaringan pribadi
+ Persyaratan enkripsi
## Pertanyaan kunci
+ Apakah persyaratan dan kebijakan keamanan Anda memungkinkan penggunaan koneksi terenkripsi melalui internet untuk terhubung AWS, atau apakah mereka mengamanatkan penggunaan koneksi jaringan pribadi?
+ Saat memanfaatkan koneksi jaringan pribadi, apakah lapisan jaringan harus menyediakan enkripsi saat transit?
## Solusi teknis
Persyaratan dan kebijakan keamanan Anda mungkin mengizinkan penggunaan internet atau memerlukan penggunaan koneksi jaringan pribadi antara AWS dan jaringan perusahaan Anda. Mereka juga mempengaruhi keputusan apakah jaringan harus menyediakan enkripsi dalam perjalanan, atau jika melakukan enkripsi pada lapisan aplikasi dapat diterima.
Jika Anda dapat memanfaatkan internet, maka AWS Site-to-Site VPN dapat digunakan untuk membuat terowongan terenkripsi antara jaringan Anda dan Amazon Anda VPCs atau AWS Transit Gateway s melalui internet. Memperluas WAN solusi [SD](https://en.wikipedia.org/wiki/SD-WAN) Anda ke AWS internet juga merupakan pilihan jika Anda memanfaatkan koneksi berbasis internet. Bagian yang dikelola pelanggan VPN dan SD- WAN nanti di whitepaper ini mencakup pertimbangan khusus untuk SD-. WAN
Jika Anda memerlukan koneksi jaringan pribadi antara AWS dan jaringan perusahaan Anda, maka AWS rekomendasikan AWS Direct Connect untuk menggunakan Koneksi Khusus atau Koneksi yang Dihosting. Jika enkripsi dalam perjalanan diperlukan melalui koneksi jaringan pribadi, maka Anda harus membuat VPN over Direct Connect (baik melalui publik VIF atau transitVIF), atau pertimbangkan untuk menggunakan MACsec koneksi Dedicated 10Gbps atau 100Gbps.
*Tabel 2 — Contoh persyaratan jenis konektivitas Automotive Corp*
| | Site-to-Site VPN | Direct Connect |
| --- | --- | --- |
| Transportasi | Internet | Koneksi jaringan pribadi |
| Enkripsi bergerak | Ya | Memerlukan S2S VPN melalui DX, S2S VPN melalui transit, atau MACsec pada Koneksi Khusus VIF 10Gbps atau 100Gbps |
# Perjanjian tingkat layanan (SLA)
## Definisi
Organisasi bisnis sering membutuhkan penyedia layanan untuk memenuhi SLA untuk setiap layanan yang dikonsumsi organisasi. Organisasi pada gilirannya membangun layanannya sendiri di atas dan dapat menawarkan konsumen mereka sendiri. SLA Hal SLA ini penting karena menggambarkan bagaimana layanan disediakan dan dioperasikan, dan sering mencakup karakteristik terukur tertentu, seperti ketersediaan. Jika layanan melanggar yang ditentukanSLA, penyedia layanan biasanya menawarkan kompensasi finansial yang ditentukan oleh perjanjian. An SLA mendefinisikan jenis ukuran, persyaratan, dan periode pengukuran. Sebagai contoh, lihat definisi target uptime di bawah. [AWS Direct Connect SLA](https://aws.amazon.com/directconnect/sla/)
## Pertanyaan kunci
+ Apakah koneksi konektivitas hybrid SLA dengan kredit layanan diperlukan?
+ Apakah seluruh jaringan hybrid perlu mematuhi target uptime?
## Kemampuan untuk dipertimbangkan
**Jenis konektivitas:** Konektivitas internet tidak dapat diprediksi. AWS Meskipun sangat berhati-hati dengan beberapa tautan di tempat dengan serangkaian beragamISPs, administrasi internet hanya di luar AWS atau domain administratif penyedia tunggal. Ada sejumlah rekayasa rute dan pengaruh lalu lintas yang dapat dilakukan penyedia cloud setelah lalu lintas meninggalkan perbatasan jaringan mereka. Konon, ada [AWS Site-to-Site VPN SLA](https://aws.amazon.com/vpn/site-to-site-vpn-sla/)yang menyediakan target ketersediaan untuk AWS Site-to-Site VPN titik akhir.
AWS [Direct Connect menawarkan kredit layanan formal SLA](https://aws.amazon.com/directconnect/sla/) yang dihitung sebagai persentase dari total biaya AWS Direct Connect Port Hour yang dibayarkan oleh Anda untuk koneksi yang berlaku yang mengalami tidak tersedianya siklus penagihan bulanan di mana tidak SLA terpenuhi. Ini adalah transportasi yang direkomendasikan jika SLA diperlukan. AWS Direct Connect mencantumkan [persyaratan konfigurasi minimal tertentu](https://aws.amazon.com/directconnect/sla/) untuk setiap target uptime seperti jumlah AWS Direct Connect lokasi, koneksi, dan detail konfigurasi lainnya. Kegagalan untuk memenuhi persyaratan berarti bahwa kredit layanan tidak dapat ditawarkan jika jeda layanan ditentukanSLAs.
Yang penting, bahkan jika layanan yang dipilih untuk menyediakan konektivitas hybrid dikonfigurasi untuk memenuhi SLA persyaratan, sisa jaringan mungkin tidak memberikan tingkat yang samaSLA. AWS Tanggung jawab berakhir di AWS Direct Connect lokasi di AWS Direct Connect pelabuhan. Setelah AWS menyerahkan lalu lintas ke jaringan organisasi Anda, itu bukan lagi tanggung jawab AWS. Jika Anda menggunakan penyedia layanan antara AWS dan jaringan lokal Anda, konektivitas tunduk SLA antara Anda dan penyedia layanan, jika berlaku. Perlu diingat bahwa seluruh jaringan hybrid sama baiknya dengan bagian terlemahnya saat merancang konektivitas hybrid.
AWS Direct Connect mitra menawarkan AWS Direct Connect konektivitas. Mitra dapat menawarkan kredit SLA dengan layanan berdasarkan penawaran produk mereka hingga titik demarkasi dengan. AWS Opsi harus dievaluasi dan diteliti lebih lanjut secara langsung dengan APN Mitra. AWS menerbitkan [daftar mitra pengiriman yang divalidasi](https://aws.amazon.com/directconnect/partners/).
**Desain logis:** Selain jenis konektivitas, Anda juga harus mempertimbangkan blok bangunan lain sebagai bagian dari keseluruhan desain Anda. Sebagai contoh, [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/sla/)memiliki sendiriSLA, seperti halnya [AWS S2S VPN](https://aws.amazon.com/vpn/site-to-site-vpn-sla/). Anda mungkin menggunakan AWS Transit Gateway untuk skala dan AWS S2S VPN untuk alasan keamanan, tetapi Anda harus merancang keduanya dengan cara yang konsisten dengan masing-masing SLAs agar memenuhi syarat untuk kredit layanan dengan masing-masing layanan.
Tinjau [Rekomendasi AWS Direct Connect Ketahanan](https://aws.amazon.com/directconnect/resiliency-recommendation/) dan Toolkit [Ketahanan](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html).
![\[Diagram yang menunjukkan pohon keputusan SLA pertimbangan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/sla-decision-tree.png)
# Kinerja
## Definisi
Ada beberapa faktor yang mempengaruhi kinerja jaringan, seperti latency, packet loss, jitter, dan bandwidth. Bergantung pada persyaratan aplikasi, pentingnya masing-masing faktor ini dapat bervariasi.
## Pertanyaan kunci
Berdasarkan persyaratan aplikasi Anda, Anda perlu mengidentifikasi dan memprioritaskan faktor kinerja jaringan yang memengaruhi perilaku aplikasi dan pengalaman pengguna Anda.
### Bandwidth
*Bandwidth* mengacu pada kecepatan transfer data koneksi, dan biasanya diukur dalam bit per detik (bps). Megabit per detik (Mbps) dan gigabit per detik (Gbps) adalah penskalaan umum, dan merupakan basis 10 (1.000.000 bit per detik = 1 Mbps) sebagai lawan dari basis 2 (2 ^ 10) yang terlihat di tempat lain.
Saat mengevaluasi kebutuhan bandwidth aplikasi, perlu diingat bahwa persyaratan bandwidth dapat berubah seiring waktu. Penyebaran awal ke cloud, operasi normal, beban kerja baru, dan skenario failover semuanya dapat memiliki persyaratan bandwidth yang berbeda.
Aplikasi dapat memiliki pertimbangan bandwidth sendiri. Beberapa aplikasi mungkin memerlukan kinerja deterministik melalui koneksi bandwidth tinggi, sementara yang lain dapat memerlukan kinerja deterministik dan bandwidth tinggi. Sebuah aplikasi mungkin memerlukan konfigurasi khusus untuk menggunakan beberapa arus lalu lintas (kadang-kadang disebut sebagai aliran atau soket) secara paralel jika mencapai batas bandwidth arus lalu lintas, memungkinkannya untuk menggunakan lebih banyak bandwidth koneksi. VPNsdapat membatasi throughput karena overhead terowongan, MTU batas bawah, atau keterbatasan bandwidth perangkat keras.
### Latensi
*Latensi* adalah waktu yang dibutuhkan untuk paket untuk pergi dari sumber ke tujuan melalui koneksi jaringan, dan biasanya diukur dalam milidetik (ms), dengan persyaratan latensi rendah kadang-kadang dinyatakan dalam mikrodetik (μs). Latensi adalah fungsi dari kecepatan cahaya, sehingga latensi meningkat dengan jarak.
Persyaratan latensi aplikasi dapat mengambil bentuk yang berbeda. Aplikasi yang sangat interaktif, seperti desktop virtual, dapat memiliki target latensi yang diukur dari saat pengguna melakukan input hingga pengguna melihat desktop virtual bereaksi terhadap input tersebut. Aplikasi Voice over IP (VoIP) dapat memiliki persyaratan serupa. Jenis beban kerja kedua yang perlu dipertimbangkan adalah beban kerja yang sangat transaksional, membutuhkan respons dari server sebelum dapat melanjutkan. Database atau bentuk penyimpanan kunci/nilai lainnya dapat sangat dipengaruhi oleh peningkatan latensi jaringan.
### Jitter
*Jitter* mengukur seberapa konsisten latensi jaringan, dan, seperti latensi, biasanya diukur dalam milidetik (ms).
Persyaratan jitter aplikasi biasanya ditemukan dalam aplikasi streaming waktu nyata, termasuk pengiriman video dan suara. Aplikasi ini cenderung mengharuskan aliran datanya berada pada tingkat dan penundaan yang konsisten, dengan buffer kecil untuk mengoreksi sejumlah kecil jitter.
### Kehilangan paket
*Packet loss* adalah pengukuran berapa persentase lalu lintas jaringan yang tidak terkirim. Semua jaringan memiliki beberapa tingkat kehilangan paket pada waktu karena ledakan lalu lintas yang tinggi, pengurangan kapasitas, kegagalan peralatan jaringan, dan alasan lainnya. Dengan demikian, aplikasi harus memiliki toleransi terhadap kehilangan paket, namun, seberapa banyak mereka dapat mentolerir dapat bervariasi dari aplikasi ke aplikasi.
Aplikasi yang digunakan TCP untuk mengangkut lalu lintas mereka memiliki kemampuan untuk memperbaiki kehilangan paket melalui transmisi ulang. Aplikasi yang menggunakan UDP atau protokol mereka sendiri di atas IP perlu menerapkan cara mereka sendiri untuk menangani kehilangan paket, dan mungkin sangat sensitif terhadapnya. Aplikasi voice over IP dapat dengan mudah memasukkan keheningan ke bagian panggilan yang memiliki paket kehilangan, sebagai lawan mencoba mengirim ulang. Beberapa VPN solusi termasuk mekanisme mereka sendiri untuk memulihkan dari kehilangan paket pada jaringan yang mereka gunakan untuk membawa lalu lintas.
## Kemampuan untuk dipertimbangkan
Ketika latensi dan throughput yang dapat diprediksi diperlukan, AWS Direct Connect adalah pilihan yang disarankan, karena memberikan kinerja deterministik. Bandwidth dapat dipilih berdasarkan persyaratan throughput. AWS merekomendasikan penggunaan AWS Direct Connect ketika Anda membutuhkan pengalaman jaringan yang lebih konsisten daripada koneksi berbasis internet dapat menyediakan. Private VIFs dan Transit VIFs mendukung jumbo frame, yang dapat mengurangi jumlah paket melalui jaringan dan dapat meningkatkan throughput karena berkurangnya overhead. AWS Direct Connect [SiteLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/)memungkinkan menggunakan AWS tulang punggung untuk menyediakan konektivitas antara lokasi Anda dan dapat diaktifkan sesuai permintaan. Bandwidth yang digunakan untuk SiteLink harus diperhitungkan untuk pemilihan bandwidth Direct Connect Anda.
Menggunakan VPN enkripsi AWS Direct Connect tambahan tambahan. Namun, ini mengurangi MTU ukuran yang mungkin mengurangi throughput. AWS VPN[kemampuan managed Site-to-Site (S2S) dapat ditemukan dalam dokumentasi.AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) Banyak lokasi Direct Connection mendukung MACsec jika enkripsi melalui koneksi Anda adalah persyaratan enkripsi utama. MACsectidak memiliki pertimbangan throughput koneksi yang sama MTU atau potensial. Site-to-Site VPN AWS Transit Gateway memungkinkan pelanggan untuk skala horizontal jumlah VPN koneksi dan meningkatkan throughput sesuai dengan Equal-cost multi-path routing (). ECMP AWS Site-to-SiteVPNDukungan terkelola menggunakan transit Direct Connect VIFs untuk konektivitas pribadi — lihat [IP Pribadi VPN dengan AWS Direct Connect](https://docs.aws.amazon.com/vpn/latest/s2svpn/private-ip-dx.html) untuk detailnya.
Pilihan lain adalah menggunakan yang AWS dikelola Site-to-Site VPN melalui internet. Ini bisa menjadi pilihan yang menarik karena biaya rendah dan tersedia secara luas. Namun, perlu diingat bahwa kinerja melalui internet adalah upaya terbaik. Peristiwa cuaca internet, kemacetan, dan peningkatan periode latensi tidak dapat diprediksi. AWS menawarkan solusi dengan [AWS Accelerated S2S VPN](https://aws.amazon.com/blogs/architecture/improve-vpn-network-performance-of-aws-hybrid-cloud-with-global-accelerator/), yang dapat mengurangi beberapa kelemahan menggunakan jalur internet. Accelerated S2S VPN menggunakan AWS Global Accelerator, yang memungkinkan VPN lalu lintas memasuki AWS jaringan sedini mungkin dan sedekat mungkin dengan perangkat gateway pelanggan. Ini mengoptimalkan jalur jaringan, menggunakan jaringan AWS global bebas kemacetan, untuk mengarahkan lalu lintas ke titik akhir yang memberikan kinerja terbaik. Anda dapat menggunakan VPN koneksi yang dipercepat untuk menghindari gangguan jaringan yang dapat terjadi ketika lalu lintas dirutekan melalui internet publik.
# Biaya
## Definisi
Di cloud, biaya konektivitas hybrid mencakup biaya sumber daya dan penggunaan yang disediakan. Biaya sumber daya yang disediakan diukur dalam satuan waktu, biasanya per jam. Penggunaan untuk transfer data dan pemrosesan biasanya diukur dalam gigabyte (GB). Biaya lainnya termasuk biaya konektivitas ke titik kehadiran AWS jaringan. Jika jaringan Anda berada dalam fasilitas colocation yang sama, mungkin sesedikit biaya koneksi silang. Jika jaringan Anda berada di lokasi yang berbeda, akan ada biaya penyedia layanan atau mitra APN Direct Connect yang terlibat.
## Pertanyaan kunci
+ Berapa banyak data yang Anda antisipasi pengiriman AWS per bulan dari fasilitas Anda dan dari internet?
+ Berapa banyak data yang Anda antisipasi pengiriman dari AWS per bulan ke fasilitas Anda dan ke internet?
+ Seberapa sering jumlah ini akan berubah?
+ Perubahan apa dalam skenario kegagalan?
## Kemampuan untuk dipertimbangkan
Jika Anda memiliki beban kerja bandwidth yang berat yang ingin Anda jalankan AWS, AWS Direct Connect dapat mengurangi biaya jaringan Anda masuk dan keluar dengan dua cara. AWS Pertama, dengan mentransfer data ke dan dari AWS langsung, Anda dapat mengurangi biaya bandwidth yang dibayarkan ke penyedia layanan internet Anda. Kedua, semua data yang ditransfer melalui koneksi khusus Anda dikenakan biaya pada kecepatan transfer AWS Direct Connect data yang dikurangi, bukan kecepatan transfer data internet — lihat [halaman harga Direct Connect](https://aws.amazon.com/directconnect/pricing/) untuk detailnya.
AWS Direct Connect memungkinkan penggunaan AWS Direct Connect SiteLink untuk menghubungkan situs Anda menggunakan AWS tulang punggung - lihat [blog SiteLink peluncuran](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/) untuk informasi lebih lanjut. Memanfaatkan kemampuan ini menimbulkan biaya transfer data Direct Connect normal, bersama dengan biaya per jam SiteLink diaktifkan. Anda dapat mengaktifkan dan menonaktifkan SiteLink on-demand, dan ini mungkin merupakan pilihan yang baik untuk skenario kegagalan yang melibatkan internet atau konektivitas jaringan pribadi.
Jika Anda menggunakan penyedia layanan jaringan untuk konektivitas antara lokasi lokal dan lokasi Direct Connect, kemampuan Anda dan waktu yang diperlukan untuk mengubah komitmen bandwidth Anda didasarkan pada kontrak Anda dengan penyedia layanan.
AWS Tulang punggung dapat mengirimkan lalu lintas Anda ke mana pun Wilayah AWS kecuali China dari titik kehadiran AWS jaringan mana pun. Kemampuan ini memiliki banyak manfaat teknis dibandingkan menggunakan internet untuk mengakses jarak jauh Wilayah AWS, tetapi memiliki biaya — lihat [halaman harga Transfer EC2 Data](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) untuk detailnya. Jika ada [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/pricing/)di jalur lalu lintas, itu menambahkan biaya pemrosesan data per GB, namun jika menggunakan peering antar wilayah antara dua Gateway Transit, Anda hanya ditagih sekali untuk pemrosesan data Transit Gateway.
Desain aplikasi yang optimal menjaga pemrosesan data di dalam AWS dan meminimalkan biaya keluar data yang tidak perlu. Masuknya data ke AWS gratis.
**catatan**
Sebagai bagian dari solusi konektivitas keseluruhan, selain biaya AWS koneksi, Anda juga harus mempertimbangkan biaya end-to-end konektivitas termasuk biaya penyedia layanan, sambungan silang, rak, dan peralatan di dalam lokasi DX (jika diperlukan).
Jika Anda tidak yakin apakah Anda harus menggunakan internet atau koneksi pribadi, hitung titik impas di mana AWS Direct Connect menjadi lebih murah daripada menggunakan internet. Jika volume data berarti AWS Direct Connect lebih murah, dan Anda memerlukan konektivitas permanen, AWS Direct Connect adalah pilihan konektivitas yang optimal.
Jika konektivitas bersifat sementara dan internet memenuhi persyaratan lain, bisa lebih murah untuk menggunakan AWS S2S VPN melalui internet karena elastisitas internet. Perhatikan bahwa ini mengharuskan Anda memiliki konektivitas internet yang memadai dari jaringan lokal Anda.
Jika Anda berada dalam fasilitas yang memiliki AWS Direct Connect (daftar [tersedia di situs web Direct Connect](https://aws.amazon.com/directconnect/locations/)), Anda dapat membuat sambungan silang ke AWS. Ini berarti menggunakan koneksi khusus pada 1,10, atau 100Gbps. AWS Direct Connect mitra menawarkan lebih banyak opsi bandwidth dan kapasitas yang lebih kecil, yang dapat mengoptimalkan biaya konektivitas Anda. Misalnya, Anda dapat memulai dengan Koneksi Hosted 50 Mbps versus Koneksi Khusus 1 Gbps.
Dengan AWS Transit Gateway, Anda dapat berbagi koneksi Anda VPN dan Direct Connect dengan banyak orangVPCs. Meskipun Anda dikenakan biaya untuk jumlah koneksi yang Anda buat AWS Transit Gateway per jam dan jumlah lalu lintas yang mengalir AWS Transit Gateway, ini menyederhanakan manajemen dan mengurangi jumlah VPN koneksi dan VIFs diperlukan. Manfaat dan penghematan biaya overhead operasional yang lebih rendah dapat dengan mudah lebih besar daripada biaya tambahan pemrosesan data. Secara opsional, Anda dapat mempertimbangkan desain di mana AWS Transit Gateway berada di jalur lalu lintas ke sebagian besarVPCs, tetapi tidak semua. Pendekatan ini menghindari biaya pemrosesan AWS Transit Gateway data untuk kasus penggunaan di mana Anda perlu mentransfer data dalam AWS jumlah besar. Lihat bagian Model Konektivitas untuk detail lebih lanjut tentang desain ini. Pendekatan lain adalah menggabungkan AWS Direct Connect sebagai jalur utama dengan AWS S2S VPN melalui internet sebagai jalur cadangan/failover. Meskipun secara teknis layak dan sangat hemat biaya, solusi ini memiliki kelemahan teknis (dibahas di bagian Keandalan dari whitepaper ini) dan bisa lebih sulit untuk dikelola. AWS [tidak merekomendasikan ini untuk beban kerja yang sangat kritis atau kritis](https://aws.amazon.com/directconnect/resiliency-recommendation/).
Pendekatan terakhir adalah dikelola pelanggan VPN atau WAN digunakan SD di EC2 instans Amazon. Ini bisa lebih murah dalam skala jika ada puluhan hingga ratusan situs jika dibandingkan dengan AWS S2SVPN. Namun, ada overhead manajemen, biaya lisensi, dan biaya EC2 sumber daya untuk setiap alat virtual untuk dipertimbangkan.
## Matriks keputusan
*Tabel 3 — Contoh input desain konektivitas otomotif Corp.*
| Kategori | Dikelola pelanggan VPN atau SD- WAN | AWS S2S VPN | AWS S2S yang dipercepat VPN | AWS Direct Connect Koneksi yang Dihosting | AWS Direct Connect Koneksi Khusus |
| --- | --- | --- | --- | --- | --- |
| Membutuhkan koneksi internet | Ya | Ya | Ya | Tidak | Tidak |
| Biaya sumber daya yang disediakan | EC2contoh dan lisensi perangkat lunak | [AWS S2S VPN](https://aws.amazon.com/vpn/pricing/) | [AWS S2S VPN](https://aws.amazon.com/vpn/pricing/) [dan AWS Akselerator Global](https://aws.amazon.com/global-accelerator/pricing/) | [Potongan kapasitas yang berlaku dari biaya port](https://aws.amazon.com/directconnect/pricing/) | [Biaya port khusus](https://aws.amazon.com/directconnect/pricing/) |
| Biaya transfer data | Tarif internet | Tarif internet atau tarif Direct Connect | Internet dengan premi transfer data | Tingkat Direct Connect | Tingkat Direct Connect |
| Transit Gateway | Opsional | Opsional | Diperlukan | Opsional | Opsional |
| AWS Biaya pemrosesan data | N/A | Hanya dengan AWS Transit Gateway | Ya | Hanya dengan AWS Transit Gateway | Hanya dengan AWS Transit Gateway |
| Dapat digunakan di atas AWS Direct Connect? | Ya | Ya | Tidak | N/A | N/A |
# Pemilihan desain konektivitas
Bagian whitepaper ini mencakup pertimbangan yang memengaruhi pemilihan desain konektivitas Anda. Desain konektivitas mencakup aspek logis serta cara merancang dan mengoptimalkan keandalan konektivitas hybrid Anda.
Pertimbangan berikut akan dibahas: skalabilitas, model konektivitas, keandalan, dan dikelola pelanggan dan SD-VPN. WAN
**Topics**
+ [Skalabilitas](scalability.md)
+ [Model konektivitas](connectivity-models.md)
+ [Keandalan](reliability.md)
+ [Dikelola pelanggan VPN dan SD- WAN](customer-managed-vpn-and-sd-wan.md)
# Skalabilitas
## Definisi
Skalabilitas mengacu pada kemampuan solusi konektivitas Anda untuk tumbuh dan berkembang seiring waktu seiring dengan perubahan kebutuhan Anda.
Saat merancang solusi, Anda perlu mempertimbangkan ukuran saat ini, serta pertumbuhan yang diantisipasi. Pertumbuhan ini dapat berupa pertumbuhan organik, atau mungkin terkait dengan ekspansi yang cepat, seperti dalam skenario merger dan akuisisi.
Catatan: tergantung pada arsitektur solusi yang ditargetkan, tidak semua elemen sebelumnya mungkin perlu dipertimbangkan. Namun, mereka dapat berfungsi sebagai elemen dasar untuk mengidentifikasi persyaratan skalabilitas dari solusi jaringan hibrida yang paling umum. Whitepaper ini berfokus pada pemilihan dan desain konektivitas hybrid. Disarankan agar Anda juga mempertimbangkan skala konektivitas hybrid sehubungan dengan arsitektur VPC jaringan. Untuk informasi selengkapnya, lihat whitepaper [Membangun Infrastruktur Multi VPC AWS Jaringan yang Dapat Diskalakan dan Aman](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html).
## Pertanyaan kunci
+ Berapa jumlah saat ini dan yang diantisipasi VPCs yang memerlukan konektivitas ke situs atau situs lokal?
+ Apakah VPCs diterapkan dalam satu Wilayah AWS atau beberapa Wilayah?
+ Berapa banyak situs lokal yang perlu dihubungkan? AWS
+ Berapa banyak perangkat gateway pelanggan (biasanya router atau firewall) yang Anda miliki per situs yang perlu terhubung? AWS
+ Berapa banyak rute yang diharapkan untuk diiklankan ke Amazon VPCs dan berapa jumlah rute yang diharapkan akan diterima dari AWS samping?
+ Apakah ada persyaratan untuk meningkatkan bandwidth AWS seiring waktu?
## Kemampuan untuk dipertimbangkan
Skala merupakan faktor penting dalam desain konektivitas hybrid. Untuk itu, bagian selanjutnya akan memasukkan skala sebagai bagian dari desain model konektivitas yang ditargetkan.
Berikut ini adalah praktik terbaik yang direkomendasikan untuk meminimalkan kompleksitas skala desain konektivitas jaringan hybrid:
+ Ringkasan rute harus digunakan untuk mengurangi jumlah rute yang diiklankan dan diterima. AWS Dengan demikian, skema pengalamatan IP perlu dirancang untuk memaksimalkan penggunaan ringkasan rute. Rekayasa lalu lintas adalah pertimbangan utama secara keseluruhan. Untuk informasi lebih lanjut tentang teknik lalu lintas, lihat subbagian teknik lalu lintas di bagian [Keandalan](reliability.md).
+ Minimalkan jumlah sesi BGP peering Anda dengan menggunakan DXGW dengan VGW atau AWS Transit Gateway, di mana satu BGP sesi dapat menyediakan konektivitas ke beberapaVPCs.
+ Pertimbangkan Cloud WAN ketika beberapa situs lokal Wilayah AWS dan lokal perlu dihubungkan bersama.
# Model konektivitas
## Definisi
Model konektivitas mengacu pada pola komunikasi antara jaringan lokal dan sumber daya cloud di AWS. Anda dapat menerapkan sumber daya cloud dalam Amazon VPC dalam satu Wilayah AWS atau beberapa VPCs di beberapa Wilayah, serta AWS layanan yang memiliki titik akhir publik dalam satu atau beberapa Wilayah AWS, seperti Amazon S3 dan DynamoDB.
## Pertanyaan kunci
+ Apakah ada persyaratan untuk antar VPC komunikasi di dalam suatu Wilayah dan lintas Wilayah?
+ Apakah ada persyaratan untuk mengakses titik akhir AWS publik langsung dari lokal?
+ Apakah ada persyaratan untuk mengakses AWS layanan menggunakan VPC titik akhir dari lokal?
## Kemampuan untuk dipertimbangkan
Berikut ini adalah beberapa skenario model konektivitas yang paling umum. Setiap model konektivitas mencakup persyaratan, atribut, dan pertimbangan.
Catatan: seperti yang disorot sebelumnya, whitepaper ini difokuskan pada konektivitas hibrid antara jaringan lokal dan. AWS Untuk detail lebih lanjut tentang desain interkoneksiVPCs, lihat whitepaper [Building a Scalable and Secure VPC AWS Multi-Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html).
**Topics**
+ [Definisi](#definition-con)
+ [Pertanyaan kunci](#key-questions-con)
+ [Kemampuan untuk dipertimbangkan](#capabilities-to-consider-con)
+ [AWS Dipercepat Site-to-Site VPN - AWS Transit Gateway, Tunggal Wilayah AWS](aws-accelerated-site-to-site-vpn-aws-transit-gateway-single-aws-region.md)
+ [AWS DX - DXGW denganVGW, Wilayah Tunggal](aws-dx-dxgw-with-vgw-single-region.md)
+ [AWS DX — DXGW denganVGW, Multi-Wilayah, dan AWS Peering Publik](aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.md)
+ [AWS DX — DXGW dengan AWS Transit Gateway, Multi-Wilayah, dan AWS Peering Publik](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-and-aws-public-peering.md)
+ [AWS DX - DXGW dengan AWS Transit Gateway, Multi-Wilayah (lebih dari 3)](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-more-than-3.md)
# AWS Dipercepat Site-to-Site VPN - AWS Transit Gateway, Tunggal Wilayah AWS
**Model ini dibangun dari:**
+ Tunggal Wilayah AWS.
+ AWS Site-to-SiteVPNKoneksi terkelola dengan AWS Transit Gateway.
+ Dipercepat VPN diaktifkan.
![\[Diagram yang menunjukkan AWS Dikelola VPN - AWS Transit Gateway, Tunggal Wilayah AWS\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/managed-vpn-tg-single-region.png)
**Atribut model konektivitas:**
+ Menyediakan kemampuan untuk membangun VPN koneksi yang dioptimalkan melalui internet publik dengan menggunakan [ Site-to-SiteVPNkoneksi yang AWS dipercepat](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html).
+ Berikan kemampuan untuk mencapai bandwidth VPN koneksi yang lebih tinggi dengan mengonfigurasi beberapa VPN terowongan dengan. ECMP
+ Dapat digunakan untuk koneksi dari beberapa situs terpencil.
+ Menawarkan failover otomatis dengan perutean dinamis ()BGP.
+ Dengan AWS Transit Gateway terhubung keVPCs, semua yang terhubung VPCs dapat menggunakan VPN koneksi yang sama. Anda juga dapat mengontrol model komunikasi yang diinginkan di antaraVPCs, untuk informasi lebih lanjut lihat [Cara Kerja Gerbang Transit](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html).
+ Menawarkan opsi desain yang fleksibel untuk mengintegrasikan keamanan pihak ketiga dan peralatan WAN virtual SD dengan AWS Transit Gateway. Lihat [Keamanan jaringan terpusat untuk VPC-to-VPC dan lokal untuk VPC](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html) lalu lintas.
**Pertimbangan skala:**
+ Bandwidth hingga 50 Gbps dengan beberapa IPsec terowongan dan ECMP dikonfigurasi (setiap arus lalu lintas akan dibatasi hingga bandwidth maksimum per VPN terowongan).
+ [Ribuan](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html) VPCs dapat dihubungkan per AWS Transit Gateway.
+ Lihat [Site-to-Site VPNkuota](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html) untuk batas skala lainnya, seperti jumlah rute.
**Pertimbangan lain:**
+ Biaya AWS Transit Gateway pemrosesan tambahan untuk transfer data antara pusat data lokal dan AWS.
+ Kelompok keamanan remote VPC tidak dapat direferensikan AWS Transit Gateway - ini didukung oleh VPC peering, namun.
# AWS DX - DXGW denganVGW, Wilayah Tunggal
**Model ini dibangun dari:**
+ Tunggal Wilayah AWS.
+ AWS Direct Connect Koneksi Ganda ke lokasi DX independen.
+ AWS DXGWlangsung melekat pada VPCs penggunaanVGW.
+ Penggunaan opsional AWS Transit Gateway untuk Inter- VPC komunikasi.
![\[Diagram yang menunjukkan AWS DX - DXGW denganVGW, Tunggal Wilayah AWS\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-single-region.png)
**Atribut model konektivitas:**
+ Menyediakan kemampuan untuk terhubung ke VPCs dan koneksi DX di Wilayah lain di masa depan.
+ Menawarkan failover otomatis dengan perutean dinamis ()BGP.
+ Dengan AWS Transit Gateway Anda dapat mengontrol model komunikasi yang diinginkan di antaraVPCs. Untuk informasi lebih lanjut, lihat [Cara kerja gateway transit](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html).
**Pertimbangan skala:**
[AWS Direct Connect Kuota](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) referensi untuk informasi lebih lanjut tentang batas skala lainnya, seperti jumlah awalan yang didukung, jumlah VIFs per jenis koneksi DX (Khusus, dihosting). Beberapa pertimbangan utama:
+ BGPSesi untuk pribadi VIF dapat mengiklankan hingga 100 rute masing-masing untuk IPv4 danIPv6.
+ Hingga 20 VPCs dapat dihubungkan per satu DXGW BGP sesi. Jika lebih dari 20 VPCs diperlukan, tambahan DXGWs dapat ditambahkan untuk memfasilitasi konektivitas dalam skala besar, atau pertimbangkan untuk menggunakan integrasi Transit Gateway.
+ Tambahan AWS Direct Connect s dapat ditambahkan sesuai keinginan.
**Pertimbangan lain:**
+ Tidak dikenakan biaya pemrosesan AWS Transit Gateway terkait untuk transfer data antara AWS dan jaringan lokal.
+ Kelompok keamanan remote VPC tidak dapat direferensikan AWS Transit Gateway (perlu VPC mengintip).
+ VPCPeering dapat digunakan sebagai pengganti AWS Transit Gateway untuk memfasilitasi komunikasi antaraVPCs, namun, ini menambah kompleksitas operasional untuk membangun dan mengelola VPC point-to-point peering dalam jumlah besar dalam skala besar.
+ Jika Inter- VPC komunikasi tidak diperlukan, baik AWS Transit Gateway maupun VPC mengintip tidak diperlukan dalam model konektivitas ini.
# AWS DX — DXGW denganVGW, Multi-Wilayah, dan AWS Peering Publik
**Model ini dibangun dari:**
+ Beberapa pusat data lokal dengan koneksi ganda ke AWS.
+ AWS Direct Connect Koneksi Ganda ke lokasi DX independen.
+ AWS DXGWlangsung melekat pada lebih dari 10 VPCs menggunakanVGW, hingga 20 VPCs menggunakanVGW.
+ Penggunaan opsional AWS Transit Gateway untuk komunikasi Antar VPC dan Antar-Wilayah.
![\[Diagram yang menunjukkan AWS DX - DXGW denganVGW, Multi-Wilayah, dan Publik VIF\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-multi-region-public-vif.png)
**Atribut model konektivitas:**
+ AWS DXGWlangsung melekat pada lebih dari 10 VPCs menggunakan VGW hingga 20 VPCs menggunakanVGW.
+ AWS DX public VIF digunakan untuk mengakses layanan AWS publik, seperti Amazon S3, langsung melalui AWS koneksi DX.
+ Menyediakan kemampuan untuk terhubung ke VPCs dan koneksi DX di Wilayah lain di masa depan.
+ VPCKomunikasi antar VPC dan Antar-Wilayah difasilitasi oleh dan mengintip Transit AWS Transit Gateway Gateway.
**Pertimbangan skala:**
[AWS Direct Connect Kuota](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) referensi untuk informasi lebih lanjut tentang batas skala lainnya, seperti jumlah awalan yang didukung, jumlah VIFs per jenis koneksi DX (khusus, dihosting). Beberapa pertimbangan utama:
+ BGPSesi untuk pribadi VIF dapat mengiklankan hingga 100 rute masing-masing untuk IPv4 danIPv6.
+ Hingga 20 VPCs dapat dihubungkan per DXGW lebih dari satu BGP sesi pada setiap pribadiVIF, hingga 30 pribadi VIFs perDXGW.
+ Tambahan AWS Direct Connect s dapat ditambahkan sesuai keinginan.
**Pertimbangan lain:**
+ Tidak dikenakan biaya pemrosesan AWS Transit Gateway terkait untuk transfer data antara AWS dan jaringan lokal.
+ Kelompok keamanan remote VPC tidak dapat direferensikan oleh AWS Transit Gateway (perlu VPC mengintip).
+ VPCPeering dapat digunakan alih-alih AWS Transit Gateway untuk memfasilitasi komunikasi antaraVPCs, namun, ini akan menambah kompleksitas operasional untuk membangun dan mengelola VPC point-to-point peering dalam skala besar.
+ Jika Inter- VPC komunikasi tidak diperlukan, baik AWS Transit Gateway maupun VPC mengintip tidak diperlukan dalam model konektivitas ini.
# AWS DX — DXGW dengan AWS Transit Gateway, Multi-Wilayah, dan AWS Peering Publik
**Model ini dibangun dari:**
+ Berganda Wilayah AWS.
+ AWS Direct Connect Koneksi Ganda ke lokasi DX independen.
+ Pusat data lokal tunggal dengan koneksi ganda ke AWS.
+ AWS DXGWdengan AWS Transit Gateway.
+ Skala tinggi VPCs per Wilayah.
![\[Diagram yang menunjukkan AWS DX - DXGW dengan AWS Transit Gateway, Multi-Wilayah, dan Publik AWS VIF\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region-public-peering.png)
**Atribut model konektivitas:**
+ AWS DX public VIF digunakan untuk mengakses sumber daya AWS publik seperti S3 langsung melalui koneksi AWS DX.
+ Menyediakan kemampuan untuk terhubung ke VPCs dan/atau koneksi DX di Wilayah lain di masa mendatang.
+ Dengan AWS Transit Gateway terhubung keVPCs, konektivitas mesh penuh atau sebagian dapat dicapai antaraVPCs.
+ VPCKomunikasi antar VPC dan antar wilayah difasilitasi oleh peering. AWS Transit Gateway
+ Menawarkan opsi desain yang fleksibel untuk mengintegrasikan keamanan pihak ketiga dan peralatan SDWAN virtual AWS Transit Gateway. Lihat: [Keamanan jaringan terpusat untuk VPC-to-VPC dan lokal untuk VPC](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html) lalu lintas.
**Pertimbangan skala:**
+ Jumlah rute ke dan dari AWS Transit Gateway terbatas pada jumlah rute maksimum yang didukung melalui Transit VIF (nomor masuk dan keluar bervariasi). Lihat [AWS Direct Connect kuota](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) untuk informasi lebih lanjut tentang batas skala dan jumlah rute yang didukung danVIFs.
+ Skala hingga ribuan VPCs per AWS Transit Gateway selama satu BGP sesi.
+ Transit Tunggal VIF per AWS DX.
+ Koneksi AWS DX tambahan dapat ditambahkan sesuai keinginan.
**Pertimbangan lain:**
+ Mengalami biaya AWS Transit Gateway pemrosesan tambahan untuk transfer data antara AWS dan situs lokal.
+ Kelompok keamanan remote VPC tidak dapat direferensikan oleh AWS Transit Gateway (perlu VPC mengintip).
+ VPCPeering dapat digunakan alih-alih AWS Transit Gateway untuk memfasilitasi komunikasi antaraVPCs, namun, ini akan menambah kompleksitas operasional untuk membangun dan mengelola VPC point-to-point peering dalam skala besar.
# AWS DX - DXGW dengan AWS Transit Gateway, Multi-Wilayah (lebih dari 3)
**Model ini dibangun dari:**
+ Beberapa Wilayah AWS (lebih dari 3).
+ Pusat data lokal ganda.
+ AWS Direct Connect Koneksi Ganda melintasi lokasi DX independen per Wilayah.
+ AWS DXGWdengan AWS Transit Gateway.
+ Skala tinggi VPCs per Wilayah.
+ Jaring penuh mengintip antara AWS Transit Gateway s.
![\[Diagram yang menunjukkan AWS DX - DXGW dengan AWS Transit Gateway, Multi-Wilayah (lebih dari tiga)\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region.png)
**Atribut model konektivitas:**
+ Overhead operasional terendah.
+ AWS DX public VIF digunakan untuk mengakses sumber daya AWS publik, seperti S3, langsung melalui koneksi AWS DX.
+ Menyediakan kemampuan untuk terhubung ke VPCs dan koneksi DX di Wilayah lain di masa depan.
+ Dengan AWS Transit Gateway terhubung keVPCs, konektivitas mesh penuh atau sebagian dapat dicapai antaraVPCs.
+ VPCKomunikasi antar wilayah difasilitasi dengan mengintip. AWS Transit Gateway
+ Menawarkan opsi desain yang fleksibel untuk mengintegrasikan keamanan pihak ketiga dan peralatan SDWAN virtual AWS Transit Gateway. Lihat: [Keamanan jaringan terpusat untuk VPC-to-VPC dan lokal untuk VPC](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html) lalu lintas.
**Pertimbangan skala:**
+ Jumlah rute ke dan dari AWS Transit Gateway terbatas pada jumlah rute maksimum yang didukung melalui Transit VIF (nomor masuk dan keluar bervariasi). Lihat [AWS Direct Connect kuota](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) untuk informasi lebih lanjut tentang batas skala. Pertimbangkan ringkasan rute jika diperlukan untuk mengurangi jumlah rute.
+ Skala hingga ribuan VPCs per AWS Transit Gateway satu BGP sesi per per DXGW (dengan asumsi kinerja yang disediakan oleh koneksi AWS DX yang disediakan sudah cukup).
+ Hingga enam AWS Transit Gateway detik dapat dihubungkan perDXGW.
+ Jika lebih dari tiga Wilayah perlu dihubungkan menggunakan AWS Transit Gateway, maka tambahan DXGWs diperlukan.
+ Transit Tunggal VIF per AWS DX.
+ Koneksi AWS DX tambahan dapat ditambahkan sesuai keinginan.
**Pertimbangan lain:**
+ Menimbulkan biaya AWS Transit Gateway pemrosesan tambahan untuk transfer data antara situs lokal dan. AWS
+ Kelompok keamanan remote VPC tidak dapat direferensikan oleh AWS Transit Gateway (perlu VPC mengintip).
+ VPCPeering dapat digunakan sebagai pengganti AWS Transit Gateway untuk memfasilitasi komunikasi antaraVPCs, namun, ini akan menambah kompleksitas operasional untuk membangun dan mengelola VPC point-to-point peering dalam jumlah besar dalam skala besar.
Pohon keputusan berikut mencakup pertimbangan skalabilitas dan model komunikasi:
![\[Diagram yang menunjukkan pohon keputusan model skalabilitas dan komunikasi\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/scalability-communication-model-decision-tree.png)
**catatan**
Jika jenis koneksi yang dipilih adalahVPN, biasanya pada pertimbangan kinerja, keputusan harus dibuat apakah titik VPN terminasi AWS VGW atau koneksi AWS Transit Gateway AWS S2S. VPN Jika belum dibuat, maka Anda dapat mempertimbangkan model komunikasi yang diperlukan antara VPC bersama dengan jumlah yang diperlukan VPC untuk dihubungkan ke VPN koneksi untuk membantu Anda membuat keputusan.
# Keandalan
## Definisi
Keandalan mengacu pada kemampuan layanan atau sistem untuk melakukan fungsi yang diharapkan bila diperlukan. Keandalan suatu sistem dapat diukur dengan tingkat kualitas operasionalnya dalam jangka waktu tertentu. Bandingkan ini dengan ketahanan, yang mengacu pada kemampuan sistem untuk pulih dari gangguan infrastruktur atau layanan, secara dinamis dan andal.
Untuk detail lebih lanjut tentang bagaimana ketersediaan dan ketahanan digunakan untuk mengukur keandalan, lihat [Pilar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) Keandalan Kerangka Well-Architected AWS .
## Pertanyaan kunci
### Ketersediaan
Ketersediaan adalah persentase waktu ketika beban kerja tersedia untuk digunakan. Target umum termasuk 99% (3.65 hari downtime diperbolehkan per tahun), 99,9% (8,77 jam), dan 99,99% (52,6 menit), dengan singkatan dari jumlah sembilan dalam persentase (“dua sembilan” untuk 99%, “tiga sembilan” untuk 99,9%, dan seterusnya). Ketersediaan solusi jaringan antara AWS dan pusat data lokal mungkin berbeda dari solusi keseluruhan atau ketersediaan aplikasi.
Pertanyaan kunci untuk ketersediaan solusi jaringan meliputi:
+ Dapatkah AWS sumber daya saya terus beroperasi jika sumber daya tidak dapat berkomunikasi dengan sumber daya lokal saya? Begitu juga sebaliknya?
+ Haruskah saya mempertimbangkan waktu henti terjadwal untuk pemeliharaan terencana sebagai disertakan atau dikecualikan dari metrik ketersediaan?
+ Bagaimana saya mengukur ketersediaan lapisan jaringan, terpisah dari kesehatan aplikasi secara keseluruhan?
[Bagian Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) dari Pilar Keandalan Kerangka Well-Architected memiliki saran dan rumus untuk ketersediaan perhitungan.
### Ketahanan
Ketahanan adalah kemampuan beban kerja untuk pulih dari gangguan infrastruktur atau layanan, secara dinamis memperoleh sumber daya komputasi untuk memenuhi permintaan, dan memitigasi gangguan, seperti kesalahan konfigurasi atau masalah jaringan sementara. Jika komponen jaringan yang berlebihan (tautan, perangkat jaringan, dan sebagainya) tidak memiliki ketersediaan yang cukup untuk menyediakan fungsi yang diharapkan sendiri, maka ia memiliki ketahanan yang rendah terhadap kegagalan. Konsekuensinya adalah pengalaman pengguna yang buruk dan terdegradasi.
Pertanyaan kunci untuk ketahanan solusi jaringan meliputi:
+ Berapa banyak kegagalan simultan dan diskrit yang harus saya izinkan?
+ Bagaimana saya bisa mengurangi satu titik kegagalan dengan solusi konektivitas dan jaringan internal saya?
+ Apa kerentanan saya terhadap peristiwa penolakan layanan (DDoS) terdistribusi?
## Solusi teknis
Pertama, penting untuk dicatat bahwa tidak setiap solusi konektivitas jaringan hybrid memerlukan tingkat keandalan yang tinggi, dan bahwa peningkatan tingkat keandalan memiliki peningkatan biaya yang sesuai. Dalam beberapa skenario, situs utama mungkin memerlukan koneksi yang andal (berlebihan dan tangguh) karena downtime memiliki dampak yang lebih tinggi pada bisnis, sementara situs regional, mungkin tidak memerlukan tingkat keandalan yang sama karena dampak yang lebih rendah pada bisnis jika terjadi peristiwa kegagalan. Disarankan untuk merujuk pada [Rekomendasi AWS Direct Connect Ketahanan](https://aws.amazon.com/directconnect/resiliency-recommendation/) karena menjelaskan praktik AWS terbaik untuk memastikan ketahanan tinggi dengan desain. AWS Direct Connect
Untuk mencapai solusi konektivitas jaringan hybrid yang andal dalam konteks ketahanan, desain perlu mempertimbangkan aspek-aspek berikut:
+ **Redundansi:** Bertujuan untuk menghilangkan satu titik kegagalan dalam jalur konektivitas jaringan hybrid, termasuk namun tidak terbatas pada koneksi jaringan, perangkat jaringan tepi, redundansi di seluruh Availability Zones, dan lokasi DX Wilayah AWS, dan sumber daya perangkat, jalur serat, dan sistem operasi. Untuk tujuan dan ruang lingkup whitepaper ini, redundansi berfokus pada koneksi jaringan, perangkat tepi (misalnya, perangkat gateway pelanggan), lokasi AWS DX, dan Wilayah AWS (untuk arsitektur Multi-wilayah).
+ **Komponen failover yang andal:** Dalam beberapa skenario, sistem mungkin berfungsi, tetapi tidak menjalankan fungsinya pada tingkat yang diperlukan. Situasi seperti itu biasa terjadi selama peristiwa kegagalan tunggal di mana ditemukan bahwa komponen redundan yang direncanakan beroperasi secara non-redundan - beban jaringan mereka tidak memiliki tempat lain untuk dituju karena penggunaan, yang mengakibatkan kapasitas yang tidak mencukupi untuk seluruh solusi.
+ **Failover time:** Failover time adalah waktu yang dibutuhkan komponen sekunder untuk sepenuhnya mengambil alih peran komponen utama. Failover time memiliki beberapa faktor — berapa lama waktu yang dibutuhkan untuk mendeteksi kegagalan, berapa lama untuk mengaktifkan konektivitas sekunder, dan berapa lama untuk memberi tahu sisa jaringan tentang perubahan. Deteksi kegagalan dapat ditingkatkan menggunakan Dead Peer Detection (DPD) untuk VPN tautan, dan Deteksi Penerusan Dua Arah () untuk tautan. BFD AWS Direct Connect Waktu untuk mengaktifkan konektivitas sekunder bisa sangat rendah (jika koneksi ini selalu aktif), mungkin jendela waktu yang singkat (jika VPN koneksi pra-konfigurasi perlu diaktifkan), atau lebih lama (jika sumber daya fisik perlu dipindahkan atau sumber daya baru dikonfigurasi). Memberitahu sisa jaringan biasanya terjadi melalui protokol routing di dalam jaringan pelanggan, yang masing-masing memiliki waktu konvergensi yang berbeda dan pilihan untuk konfigurasi — konfigurasi ini berada di luar lingkup whitepaper ini.
+ **Rekayasa Lalu Lintas:** Rekayasa lalu lintas dalam konteks desain konektivitas jaringan hibrida yang tangguh bertujuan untuk mengatasi bagaimana lalu lintas harus mengalir melalui beberapa koneksi yang tersedia dalam skenario normal dan kegagalan. Disarankan untuk mengikuti konsep *desain untuk kegagalan*, di mana Anda perlu melihat bagaimana solusi akan beroperasi dalam skenario kegagalan yang berbeda dan apakah itu akan dapat diterima oleh bisnis atau tidak. Bagian ini membahas beberapa kasus penggunaan teknik lalu lintas umum yang bertujuan untuk meningkatkan tingkat ketahanan keseluruhan dari solusi konektivitas jaringan hibrida. [AWS Direct Connect Bagian tentang routing dan BGP](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) berbicara tentang beberapa opsi rekayasa lalu lintas untuk mempengaruhi arus lalu lintas (komunitas, preferensi BGP lokal, AS Path length). Untuk merancang solusi rekayasa lalu lintas yang efektif, Anda harus memiliki pemahaman yang baik tentang bagaimana masing-masing komponen AWS jaringan menangani perutean IP dalam hal evaluasi dan pemilihan rute, serta mekanisme yang mungkin untuk mempengaruhi pemilihan rute. Rinciannya berada di luar cakupan dokumen ini. Untuk informasi selengkapnya, lihat [Urutan Evaluasi Rute Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview), [Prioritas Site-to-Site VPN Rute](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html#vpn-route-priority), dan [Perutean dan BGP dokumentasi Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) sesuai kebutuhan.
**catatan**
Dalam tabel VPC rute, Anda dapat mereferensikan daftar awalan yang memiliki aturan pemilihan rute tambahan. Untuk informasi selengkapnya tentang kasus penggunaan ini, lihat [prioritas rute untuk daftar awalan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-tables-priority). AWS Transit Gateway tabel rute juga mendukung daftar awalan, tetapi setelah diterapkan mereka diperluas ke entri rute tertentu.
## Site-to-SiteVPNKoneksi ganda dengan contoh rute yang lebih spesifik
Skenario ini didasarkan pada situs lokal kecil yang terhubung ke satu Wilayah AWS melalui VPN koneksi redundan melalui internet ke. AWS Transit Gateway Desain teknik lalu lintas yang digambarkan pada Gambar 10 menunjukkan bahwa dengan rekayasa lalu lintas Anda dapat memengaruhi pemilihan jalur yang meningkatkan keandalan solusi konektivitas hibrida dengan:
+ Konektivitas hybrid tangguh: VPN Koneksi redundan masing-masing memberikan kapasitas kinerja yang sama, mendukung failover otomatis dengan menggunakan protokol perutean dinamis (BGP), dan mempercepat deteksi kegagalan koneksi dengan menggunakan deteksi rekan mati. VPN
+ Efisiensi kinerja: Mengkonfigurasi ECMP di kedua VPN koneksi untuk AWS Transit Gateway membantu memaksimalkan bandwidth VPN koneksi secara keseluruhan. Atau, dengan mengiklankan rute yang berbeda, lebih spesifik, bersama dengan rute ringkasan situs, beban dapat dikelola secara independen di dua koneksi VPN
![\[Diagram yang menunjukkan Site-to-Site VPN koneksi ganda dengan contoh rute yang lebih spesifik\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dual-s2s-example.png)
## Situs lokal ganda dengan beberapa contoh koneksi DX
Skenario yang diilustrasikan pada Gambar 11 menunjukkan dua situs pusat data lokal yang terletak di Wilayah geografis yang berbeda, dan terhubung AWS menggunakan model konektivitas Ketahanan Maksimum (dijelaskan dalam Rekomendasi [AWS Direct Connect Ketahanan](https://aws.amazon.com/directconnect/resiliency-recommendation/)) menggunakan dengan dan. AWS Direct Connect DXGW VGW Kedua situs lokal ini saling berhubungan satu sama lain melalui tautan interkoneksi () DCI pusat data. Awalan IP lokal (192.168.0.0/16) milik situs cabang jarak jauh diiklankan dari kedua situs pusat data lokal. Jalur utama untuk awalan ini harus pusat data 1. Lalu lintas ke dan dari situs cabang jarak jauh akan gagal ke pusat data 2 jika terjadi kegagalan pusat data 1 atau kedua lokasi DX. Juga, ada awalan IP khusus situs untuk setiap pusat data. Awalan ini perlu dicapai secara langsung, dan melalui situs pusat data lainnya jika terjadi kegagalan kedua lokasi DX.
Dengan mengaitkan atribut BGP Komunitas dengan rute yang diiklankan AWS DXGW, Anda dapat memengaruhi pemilihan jalur keluar dari samping. AWS DXGW Atribut komunitas ini mengontrol AWS atribut Preferensi BGP Lokal yang ditetapkan ke rute yang diiklankan. Untuk informasi selengkapnya, lihat [kebijakan dan AWS BGP komunitas DX Routing](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html).
Untuk memaksimalkan keandalan konektivitas pada Wilayah AWS tingkat tersebut, setiap pasangan koneksi AWS DX mengkonfigurasi ECMP sehingga keduanya dapat digunakan pada saat yang sama untuk transfer data antara setiap situs lokal dan. AWS
![\[Diagram yang menunjukkan situs lokal ganda dengan beberapa contoh koneksi DX\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/dual-dx-example.png)
Dengan desain ini, arus lalu lintas yang ditujukan ke jaringan lokal (dengan panjang awalan dan BGP komunitas yang diiklankan yang sama) akan didistribusikan di seluruh koneksi DX ganda per situs yang digunakan. ECMP Namun, jika tidak ECMP diperlukan di seluruh koneksi DX, konsep yang sama dibahas sebelumnya dan dijelaskan dalam [kebijakan Routing dan dokumentasi BGP komunitas](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) dapat digunakan untuk lebih merekayasa pemilihan jalur pada tingkat koneksi DX.
Catatan: Jika ada perangkat keamanan di jalur dalam pusat data lokal, perangkat ini perlu dikonfigurasi untuk memungkinkan arus lalu lintas meninggalkan satu tautan DX dan berasal dari tautan DX lain (kedua tautan digunakanECMP) dalam situs pusat data yang sama.
## VPNkoneksi sebagai cadangan ke contoh koneksi AWS DX
VPNdapat dipilih untuk menyediakan koneksi jaringan cadangan ke AWS Direct Connect koneksi. Biasanya, model konektivitas jenis ini didorong oleh biaya, karena memberikan tingkat keandalan yang lebih rendah untuk solusi konektivitas hybrid secara keseluruhan karena kinerja indeterministik melalui internet, dan tidak ada SLA yang dapat diperoleh untuk koneksi melalui internet publik. Ini adalah model konektivitas yang valid dan hemat biaya, dan harus digunakan ketika biaya adalah pertimbangan prioritas utama dan ada anggaran terbatas, atau mungkin sebagai solusi sementara sampai DX sekunder dapat disediakan. Gambar 12 menggambarkan desain model konektivitas ini. Salah satu pertimbangan utama dengan desain ini, di mana koneksi VPN dan DX berakhir di AWS Transit Gateway, adalah bahwa VPN koneksi dapat mengiklankan jumlah rute yang lebih tinggi dibandingkan dengan yang dapat diiklankan melalui koneksi DX yang terhubung ke. AWS Transit Gateway Hal ini dapat menyebabkan situasi routing suboptimal. Opsi untuk mengatasi masalah ini adalah mengonfigurasi pemfilteran rute di perangkat gateway pelanggan (CGW) untuk rute yang diterima dari VPN koneksi, yang memungkinkan hanya rute ringkasan yang akan diterima.
Catatan: Untuk membuat rute ringkasan pada AWS Transit Gateway, Anda perlu menentukan rute statis ke lampiran arbitrer dalam tabel AWS Transit Gateway rute sehingga ringkasan dikirim sepanjang rute yang lebih spesifik.
Dari sudut pandang tabel AWS Transit Gateway perutean, rute untuk awalan lokal diterima baik dari koneksi AWS DX (viaDXGW) maupun dariVPN, dengan panjang awalan yang sama. Mengikuti [logika prioritas r oute AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview), rute yang diterima melalui Direct Connect memiliki preferensi yang lebih tinggi daripada yang diterima Site-to-SiteVPN, dan dengan demikian jalur di atas AWS Direct Connect akan lebih disukai untuk menjangkau jaringan lokal.
![\[Diagram yang menunjukkan VPN koneksi sebagai cadangan ke contoh koneksi AWS DX\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/vpn-as-backup-to-dx.png)
Pohon keputusan berikut memandu Anda membuat keputusan yang diinginkan untuk mencapai konektivitas jaringan hybrid yang tangguh (yang akan menghasilkan konektivitas jaringan hybrid yang andal). Untuk informasi lebih lanjut, lihat [AWS Direct Connect Resiliency](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) Toolkit.
![\[Diagram yang menunjukkan pohon keputusan reliabilitas\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/hybrid-connectivity/images/reliability-decision-tree.png)
# Dikelola pelanggan VPN dan SD- WAN
## Definisi
Konektivitas ke internet merupakan komoditas dan bandwidth yang tersedia terus meningkat setiap tahunnya. Beberapa pelanggan memilih untuk membangun virtual WAN di atas internet daripada membangun dan mengoperasikan pribadiWAN. Sebuah software-defined wide area network (SD-WAN) memungkinkan perusahaan untuk dengan cepat menyediakan dan mengelola secara terpusat virtual ini WAN melalui penggunaan perangkat lunak yang cerdas. Pelanggan lain memilih untuk mengadopsi situs tradisional yang dikelola sendiri ke situsVPNs.
## Dampak pada keputusan desain
SD- WAN dan yang dikelola pelanggan VPNs dapat berjalan melalui internet atau. AWS Direct Connect SD- WAN (atau VPN overlay perangkat lunak apa pun) dapat diandalkan seperti transportasi jaringan yang mendasarinya. Oleh karena itu, keandalan dan SLA pertimbangan yang dibahas sebelumnya dalam whitepaper ini berlaku di sini. Misalnya, membangun WAN hamparan SD melalui internet tidak akan menawarkan keandalan yang sama dibandingkan jika dibangun di atas. AWS Direct Connect
## Definisi persyaratan
+ Apakah Anda menggunakan SD- WAN di jaringan lokal Anda?
+ Apakah ada fitur khusus yang Anda perlukan yang hanya tersedia pada peralatan virtual tertentu yang digunakan untuk VPN penghentian?
## Solusi teknis
AWS merekomendasikan mengintegrasikan SD- WAN dengan AWS Transit Gateway, dan menerbitkan daftar [vendor yang mendukung](https://aws.amazon.com/transit-gateway/network-manager/) integrasi. AWS Transit Gateway AWS dapat bertindak sebagai hub untuk WAN situs SD atau sebagai situs bicara. AWS Backbone dapat digunakan untuk menghubungkan berbagai SD- WAN hub yang digunakan AWS dengan jaringan yang sangat andal dan berkinerja. WANSolusi SD mendukung failover otomatis melalui jalur yang tersedia, pemantauan tambahan, dan kemampuan observabilitas dalam satu panel manajemen. Penggunaan konfigurasi dan otomatisasi otomatis yang ekstensif memungkinkan penyediaan dan visibilitas yang cepat dibandingkan dengan tradisional. WANs Namun, penggunaan overhead tunneling dan enkripsi tidak sebanding dengan tautan serat khusus berkecepatan tinggi yang digunakan dalam konektivitas pribadi.
Dalam beberapa kasus, Anda dapat memilih untuk menggunakan alat virtual dengan VPN kemampuan. Alasan memilih alat virtual yang dikelola sendiri mencakup fitur teknis dan kompatibilitas dengan jaringan Anda yang lain. Ketika Anda memilih solusi yang dikelola sendiri VPN atau WAN solusi SD yang menggunakan alat virtual yang digunakan dalam sebuah EC2 instance, Anda bertanggung jawab atas pengelolaan alat tersebut. Anda juga bertanggung jawab atas ketersediaan dan kegagalan yang tinggi antara peralatan virtual. Desain seperti itu meningkatkan tanggung jawab operasional Anda; Namun, itu bisa memberi Anda lebih banyak fleksibilitas. Fitur dan kemampuan solusi tergantung pada alat virtual yang Anda pilih.
AWS Marketplace berisi banyak peralatan VPN virtual yang dapat digunakan pelanggan di AmazonEC2. AWS merekomendasikan memulai dengan S2S AWS terkelola VPN dan lihat opsi lain jika tidak memenuhi persyaratan Anda. Overhead manajemen peralatan virtual adalah tanggung jawab pelanggan.