

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Konektivitas VPC ke VPC
<a name="vpc-to-vpc-connectivity"></a>

*Pelanggan dapat menggunakan dua pola konektivitas VPC yang berbeda untuk mengatur lingkungan multi-VPC: *banyak ke banyak*, atau hub dan bicara.* Dalam many-to-many pendekatannya, lalu lintas antara setiap VPC dikelola secara individual antara setiap VPC. Dalam hub-and-spoke model, semua lalu lintas antar-VPC mengalir melalui sumber daya pusat, yang merutekan lalu lintas berdasarkan aturan yang ditetapkan. 

# Peering VPC
<a name="vpc-peering"></a>

Cara pertama untuk menghubungkan dua VPCs adalah dengan menggunakan VPC peering. Dalam pengaturan ini, koneksi memungkinkan konektivitas dua arah penuh antara. VPCs Koneksi peering ini digunakan untuk merutekan lalu lintas antara. VPCs VPCs di akun yang berbeda dan Wilayah AWS juga dapat diintip bersama. Semua transfer data melalui koneksi peering VPC yang tetap berada dalam Availability Zone gratis. Semua transfer data melalui koneksi peering VPC yang melintasi Availability Zone dibebankan pada kecepatan transfer data dalam wilayah standar. Jika VPCs diintip di seluruh Wilayah, biaya transfer data antar wilayah standar akan berlaku.

 [VPC peering adalah point-to-point konektivitas, dan tidak mendukung perutean transitif.](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering) Misalnya, jika Anda memiliki koneksi [peering VPC antara VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) A dan VPC B dan antara VPC A dan VPC C, instance di VPC B tidak dapat transit melalui VPC A untuk mencapai VPC C. Untuk merutekan paket antara VPC B dan VPC C, Anda diminta untuk membuat koneksi peering VPC langsung. 

Pada skala besar, ketika Anda memiliki puluhan atau ratusan VPCs, menghubungkan mereka dengan mengintip dapat menghasilkan jaring ratusan atau ribuan koneksi mengintip. Sejumlah besar koneksi bisa sulit untuk dikelola dan ditingkatkan. Misalnya, jika Anda memiliki 100 VPCs dan Anda ingin mengatur peering mesh penuh di antara mereka, dibutuhkan 4.950 koneksi peering [`n(n-1)/2`] di mana jumlah `n` totalnya. VPCs Ada [batas maksimum](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) 125 koneksi peering aktif per VPC.

![\[Diagram yang menggambarkan pengaturan jaringan menggunakan pengintip VPC\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)


Jika Anda menggunakan peering VPC, konektivitas lokal (VPN dan/atau Direct Connect) harus dilakukan ke setiap VPC. Sumber daya dalam VPC tidak dapat menjangkau lokal menggunakan konektivitas hybrid dari VPC peered, seperti yang ditunjukkan pada gambar sebelumnya. 

 Peering VPC paling baik digunakan ketika sumber daya dalam satu VPC harus berkomunikasi dengan sumber daya di VPC lain, lingkungan keduanya VPCs dikendalikan dan diamankan, dan jumlah yang akan dihubungkan kurang dari 10 ( VPCs untuk memungkinkan manajemen individu dari setiap koneksi). VPC peering menawarkan biaya keseluruhan terendah dan kinerja agregat tertinggi jika dibandingkan dengan opsi lain untuk konektivitas antar-VPC. 

# AWS Transit Gateway 
<a name="transit-gateway"></a>

 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)menyediakan desain hub dan spoke untuk menghubungkan VPCs dan jaringan lokal sebagai layanan yang dikelola sepenuhnya tanpa mengharuskan Anda menyediakan peralatan virtual pihak ketiga. Tidak diperlukan hamparan VPN, dan AWS mengelola ketersediaan dan skalabilitas tinggi. 

 Transit Gateway memungkinkan pelanggan untuk menghubungkan ribuan VPCs. Anda dapat melampirkan semua konektivitas hybrid Anda (koneksi VPN dan Direct Connect) ke satu gateway, mengkonsolidasikan dan mengendalikan seluruh konfigurasi AWS perutean organisasi Anda di satu tempat (lihat gambar berikut). Transit Gateway mengontrol bagaimana lalu lintas dirutekan di antara semua jaringan spoke yang terhubung menggunakan tabel rute. hub-and-spokeModel ini menyederhanakan manajemen dan mengurangi biaya operasional karena VPCs hanya terhubung ke instance Transit Gateway untuk mendapatkan akses ke jaringan yang terhubung. 

![\[Diagram yang menggambarkan hub dan desain spoke dengan AWS Transit Gateway\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)


Transit Gateway adalah sumber daya Regional dan dapat menghubungkan ribuan orang VPCs di dalam yang sama Wilayah AWS. Anda dapat menghubungkan beberapa gateway melalui satu koneksi Direct Connect untuk konektivitas hybrid. Biasanya, Anda dapat menggunakan hanya satu instance Transit Gateway yang menghubungkan semua instance VPC Anda di Wilayah tertentu, dan menggunakan tabel perutean Transit Gateway untuk mengisolasinya di mana pun diperlukan. Perhatikan bahwa Anda tidak memerlukan gateway transit tambahan untuk ketersediaan tinggi, karena gateway transit sangat tersedia secara desain; untuk redundansi, gunakan satu gateway di setiap Wilayah. Namun, ada kasus yang valid untuk membuat beberapa gateway untuk membatasi radius ledakan miskonfigurasi, memisahkan operasi bidang kontrol, dan administrasi. ease-of-use

Dengan mengintip Transit Gateway, pelanggan dapat mengintip instans Transit Gateway mereka dalam Wilayah yang sama atau beberapa dan merutekan lalu lintas di antara mereka. Ini menggunakan infrastruktur dasar yang sama seperti pengintip VPC, dan karena itu dienkripsi. Untuk informasi selengkapnya, lihat [Membangun jaringan global menggunakan AWS Transit Gateway Inter-Region peering](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/) dan [AWS Transit Gateway sekarang mendukung](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/) Intra-Region Peering.

 Tempatkan instance Transit Gateway organisasi Anda di akun Layanan Jaringannya. Ini memungkinkan manajemen terpusat oleh insinyur jaringan yang mengelola akun layanan Jaringan. Gunakan AWS Resource Access Manager (RAM) untuk berbagi instans Transit Gateway untuk menghubungkan VPCs beberapa akun di AWS Organization Anda dalam Wilayah yang sama.AWS RAM memungkinkan Anda berbagi AWS sumber daya dengan mudah dan aman dengan apa pun Akun AWS, atau di dalam AWS Organization Anda. Untuk informasi selengkapnya, lihat [lampiran AWS Transit Gateway Otomatis ke gateway transit di posting blog akun pusat](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/). 

Transit Gateway juga memungkinkan Anda untuk membangun konektivitas antara infrastruktur SD-WAN dan AWS menggunakan Transit Gateway Connect. Gunakan lampiran Transit Gateway Connect dengan Border Gateway Protocol (BGP) untuk perutean dinamis dan protokol terowongan Generic Routing Encapsulation (GRE) untuk kinerja tinggi, memberikan bandwidth total hingga 20 Gbps per lampiran Connect (hingga empat rekan Transit Gateway Connect per lampiran Connect). Dengan menggunakan Transit Gateway Connect, Anda dapat mengintegrasikan infrastruktur SD-WAN lokal atau peralatan SD-WAN yang berjalan di cloud melalui lampiran atau Direct Connect lampiran VPC sebagai lapisan transport yang mendasarinya. Lihat [Sederhanakan konektivitas SD-WAN dengan AWS Transit Gateway Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/) untuk arsitektur referensi dan konfigurasi terperinci. 

# Solusi VPC Transit
<a name="transit-vpc-solution"></a>

 [Transit VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) dapat menciptakan konektivitas antara VPCs dengan cara yang berbeda dari peering VPC dengan memperkenalkan desain hub dan spoke untuk konektivitas antar-VPC. Dalam jaringan VPC transit, satu VPC pusat (hub VPC) terhubung dengan setiap VPC lainnya (spoke VPC) melalui koneksi VPN yang biasanya memanfaatkan BGP over. [IPsec](https://en.wikipedia.org/wiki/IPsec) VPC pusat berisi instans [Amazon Elastic Compute Cloud (](https://aws.amazon.com/ec2/)Amazon EC2) yang menjalankan peralatan perangkat lunak yang mengarahkan lalu lintas masuk ke tujuan mereka menggunakan hamparan VPN. Transit VPC peering memiliki keuntungan sebagai berikut: 
+  Perutean transitif diaktifkan menggunakan jaringan VPN overlay — memungkinkan desain hub dan spoke. 
+  Saat menggunakan perangkat lunak vendor pihak ketiga pada EC2 instance di VPC transit hub, fungsionalitas vendor seputar keamanan tingkat lanjut (pengalaman lapisan 7firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) ) can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring. 
+ Arsitektur VPC Transit memungkinkan konektivitas yang mungkin diinginkan dalam beberapa kasus penggunaan. Misalnya, Anda dapat menghubungkan GovCloud instans AWS dan VPC Wilayah Komersil atau instans Gateway Transit ke VPC Transit dan mengaktifkan konektivitas antar-VPC antara kedua Wilayah. Evaluasi persyaratan keamanan dan kepatuhan Anda saat mempertimbangkan opsi ini. Untuk keamanan tambahan, Anda dapat menerapkan model inspeksi terpusat menggunakan pola desain yang dijelaskan nanti dalam whitepaper ini. 

![\[Diagram yang menggambarkan VPC transit dengan peralatan virtual\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)


Transit VPC hadir dengan tantangannya sendiri, seperti biaya yang lebih tinggi untuk menjalankan peralatan virtual vendor pihak ketiga EC2 berdasarkan ukuran/keluarga instans, throughput terbatas per koneksi VPN (hingga 1,25 Gbps per terowongan VPN), dan konfigurasi tambahan, manajemen, dan overhead ketahanan (pelanggan bertanggung jawab untuk mengelola HA dan redundansi instans yang menjalankan peralatan virtual vendor pihak ketiga). EC2

## Pengintip VPC vs Transit VPC vs Gerbang Transit
<a name="peering-vs"></a>

*Tabel 1 - Perbandingan konektivitas*


| Kriteria  | Peering VPC  | Transit VPC | Transit Gateway | PrivateLink | Awan WAN | Kisi VPC | 
| --- | --- | --- | --- | --- | --- | --- | 
|  Cakupan   | Regional/Global | Regional  | Regional  | Regional | Global | Regional | 
| Arsitektur | Jala penuh | Berbasis VPN hub-and-spoke | Berbasis lampiran hub-and-spoke | Model Penyedia atau Konsumen | Berbasis lampiran, multi-wilayah | Konektivitas Aplikasi ke Aplikasi | 
|  Penskalaan   | 125 rekan aktif/VPC  | Tergantung pada router virtual/ EC2  | 5000 lampiran per Wilayah  | Tidak ada batasan | 5000 lampiran per jaringan inti | 500 asosiasi VPC per layanan | 
|  Segmentasi   | Grup keamanan  | Pelanggan dikelola  | Tabel rute Transit Gateway  | Tidak ada segmentasi | Segmen | Kebijakan jaringan layanan dan layanan | 
|  Latensi   | Terendah  | Ekstra, karena overhead enkripsi VPN  | Transit Gateway Hop tambahan  | Lalu lintas tetap berada di tulang punggung AWS, pelanggan harus menguji | Menggunakan jalur data yang sama dengan Transit Gateway | Lalu lintas tetap berada di tulang punggung AWS, pelanggan harus menguji | 
|  Batas bandwidth   | Batas per instance, tidak ada batas agregat  | Tunduk pada batas bandwidth EC2 instance berdasarkan ukuran/keluarga  | Hingga 100 Gbps (burst) /attachment  | 10 Gbps per Availability Zone, secara otomatis menskalakan hingga 100 Gbps | Hingga 100 Gbps (burst) /attachment | 10 Gbps per Zona Ketersediaan | 
|  Visibilitas   | Log Alur VPC  | Log dan Metrik Aliran VPC CloudWatch  | Manajer Jaringan Transit Gateway, Log Aliran VPC, Metrik CloudWatch  | CloudWatch Metrik  | Manajer Jaringan, Log Aliran VPC, Metrik CloudWatch  | CloudWatch Akses Log | 
|  Grup keamanan  referensi silang   | Didukung  | Tidak didukung  | Tidak didukung  | Tidak didukung | Tidak didukung | Tidak berlaku | 
| IPv6 dukungan  | Didukung | Tergantung pada alat virtual  | Didukung | Didukung | Didukung | Didukung | 

# AWS PrivateLink
<a name="aws-privatelink"></a>

[AWS PrivateLink](https://aws.amazon.com/privatelink/)menyediakan konektivitas pribadi antara VPCs, layanan AWS, dan jaringan lokal Anda tanpa mengekspos lalu lintas Anda ke internet publik. Endpoint VPC antarmuka, didukung oleh AWS PrivateLink, memudahkan untuk terhubung ke AWS dan layanan lain di berbagai akun dan VPCs untuk menyederhanakan arsitektur jaringan Anda secara signifikan. Hal ini memungkinkan pelanggan yang mungkin ingin secara pribadi mengekspos layanan/aplikasi yang berada di satu VPC (penyedia layanan) ke yang VPCs lain (konsumen) dengan cara yang hanya VPCs konsumen Wilayah AWS yang memulai koneksi ke VPC penyedia layanan. Contohnya adalah kemampuan aplikasi pribadi Anda untuk mengakses penyedia layanan APIs.

 Untuk menggunakannya AWS PrivateLink, buat Network Load Balancer untuk aplikasi Anda di VPC Anda, dan buat konfigurasi layanan titik akhir VPC yang mengarah ke penyeimbang beban tersebut. Konsumen layanan kemudian membuat titik akhir antarmuka ke layanan Anda. Ini menciptakan elastic network interface (ENI) di subnet konsumen dengan alamat IP pribadi yang berfungsi sebagai titik masuk untuk lalu lintas yang ditujukan untuk layanan. Konsumen dan layanan tidak diharuskan berada dalam VPC yang sama. Jika VPC berbeda, konsumen dan penyedia layanan VPCs dapat memiliki rentang alamat IP yang tumpang tindih. Selain membuat titik akhir VPC antarmuka untuk mengakses layanan di lain VPCs, Anda dapat membuat titik akhir VPC antarmuka untuk mengakses [layanan AWS yang didukung secara pribadi AWS PrivateLink, seperti yang ditunjukkan pada gambar](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) berikut. 

Dengan Application Load Balancer (ALB) sebagai target NLB, Anda sekarang dapat menggabungkan kemampuan routing lanjutan ALB dengan. AWS PrivateLink Lihat [Grup Target Tipe Application Load Balancer untuk Network Load Balancer untuk](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) arsitektur referensi dan konfigurasi terperinci.

![\[Diagram yang menggambarkan AWS PrivateLink konektivitas ke Layanan VPCs AWS lainnya\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)


 Pilihan antara Transit Gateway, VPC peering, dan tergantung pada AWS PrivateLink konektivitas. 
+  **AWS PrivateLink**— Gunakan AWS PrivateLink ketika Anda memiliki klien/server yang diatur di mana Anda ingin mengizinkan satu atau lebih akses VPCs searah konsumen ke layanan tertentu atau serangkaian instance di VPC penyedia layanan atau layanan tertentu. AWS Hanya klien dengan akses di VPC konsumen yang dapat memulai koneksi ke layanan di VPC atau layanan penyedia layanan. AWS Ini juga merupakan pilihan yang baik ketika klien dan server di keduanya VPCs memiliki alamat IP yang tumpang tindih karena AWS PrivateLink menggunakan ENIs dalam VPC klien dengan cara yang memastikan bahwa tidak ada konflik IP dengan penyedia layanan. Anda dapat mengakses AWS PrivateLink titik akhir melalui VPC peering, VPN, Transit Gateway, Cloud WAN, dan. AWS Direct Connect
+  **Peering VPC dan Transit Gateway** — Gunakan peering VPC dan Transit Gateway saat Anda ingin mengaktifkan konektivitas IP layer-3 di antaranya. VPCs 

  Arsitektur Anda akan berisi campuran teknologi ini untuk memenuhi kasus penggunaan yang berbeda. Semua layanan ini dapat digabungkan dan dioperasikan satu sama lain. Misalnya, AWS PrivateLink menangani konektivitas client-server gaya API, peering VPC untuk menangani persyaratan konektivitas langsung di mana grup penempatan mungkin masih diinginkan dalam konektivitas Wilayah atau Antar wilayah, dan Transit Gateway untuk menyederhanakan konektivitas VPCs pada skala serta konsolidasi tepi untuk konektivitas hybrid. 

# Pembagian VPC
<a name="amazon-vpc-sharing"></a>

Berbagi VPCs berguna ketika isolasi jaringan antar tim tidak perlu dikelola secara ketat oleh pemilik VPC, tetapi pengguna dan izin tingkat akun harus. Dengan [VPC Bersama](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html), beberapa akun AWS membuat sumber daya aplikasinya (seperti EC2 instans Amazon) di Amazon bersama yang dikelola secara terpusat. VPCs Dalam model ini, akun yang memiliki VPC (pemilik) berbagi satu atau lebih subnet dengan akun lain (peserta). Setelah subnet dibagikan, peserta dapat melihat, membuat, mengubah, dan menghapus sumber daya aplikasi mereka di subnet yang dibagikan dengan mereka. Peserta tidak dapat melihat, mengubah, atau menghapus sumber daya milik peserta lain atau pemilik VPC. Keamanan antar sumber daya yang VPCs dibagikan dikelola menggunakan grup keamanan, daftar kontrol akses jaringan (NACLs), atau melalui firewall antar subnet.

 Manfaat berbagi VPC: 
+  Desain yang disederhanakan - tidak ada kerumitan seputar konektivitas antar-VPC 
+  Lebih sedikit dikelola VPCs 
+  Pemisahan tugas antara tim jaringan dan pemilik aplikasi 
+  Pemanfaatan IPv4 alamat yang lebih baik 
+  Biaya lebih rendah — tidak ada biaya transfer data antar instans milik akun berbeda dalam Availability Zone yang sama 

**catatan**  
 Ketika Anda berbagi subnet dengan beberapa akun, peserta Anda harus memiliki beberapa tingkat kerja sama karena mereka berbagi ruang IP dan sumber daya jaringan. Jika perlu, Anda dapat memilih untuk berbagi subnet yang berbeda untuk setiap akun peserta. Satu subnet per peserta memungkinkan ACL jaringan untuk menyediakan isolasi jaringan selain kelompok keamanan. 

 Sebagian besar arsitektur pelanggan akan berisi beberapa VPCs, banyak di antaranya akan dibagikan dengan dua atau lebih akun. Transit Gateway dan VPC peering dapat digunakan untuk menghubungkan shared. VPCs Misalnya, Anda memiliki 10 aplikasi. Setiap aplikasi memerlukan akun AWS sendiri. Aplikasi dapat dikategorikan menjadi dua portofolio aplikasi (aplikasi dalam portofolio yang sama memiliki persyaratan jaringan yang sama, Aplikasi 1-5 di 'Pemasaran' dan Aplikasi 6-10 di 'Penjualan'). 

 Anda dapat memiliki satu VPC per portofolio aplikasi ( VPCs total dua), dan VPC dibagikan dengan akun pemilik aplikasi yang berbeda dalam portofolio tersebut. Pemilik aplikasi menyebarkan aplikasi ke VPC bersama masing-masing (dalam hal ini, dalam subnet yang berbeda untuk segmentasi rute jaringan dan penggunaan isolasi). NACLs Keduanya dibagi VPCs terhubung melalui Transit Gateway. Dengan pengaturan ini, Anda bisa beralih dari harus menghubungkan 10 VPCs menjadi hanya dua, seperti yang terlihat pada gambar berikut. 

![\[Diagram yang menggambarkan contoh pengaturan untuk VPC bersama\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)


**catatan**  
 Peserta berbagi VPC tidak dapat membuat semua sumber daya AWS di subnet bersama. Untuk informasi selengkapnya, lihat bagian [Batasan](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) di dokumentasi Berbagi VPC.   
Untuk informasi lebih lanjut tentang pertimbangan utama dan praktik terbaik untuk berbagi VPC, lihat berbagi [VPC: pertimbangan utama](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/) dan praktik terbaik posting blog.

# Gerbang NAT Pribadi
<a name="private-nat-gateway"></a>

Tim sering bekerja secara independen dan mereka mungkin membuat VPC baru untuk sebuah proyek, yang mungkin memiliki blok routing antar-domain (CIDR) tanpa kelas yang tumpang tindih. Untuk integrasi, mereka mungkin ingin mengaktifkan komunikasi antar jaringan dengan tumpang tindih CIDRs, yang tidak dapat dicapai melalui fitur seperti peering VPC dan Transit Gateway. Gateway NAT pribadi dapat membantu kasus penggunaan ini. Gateway NAT pribadi menggunakan alamat IP pribadi yang unik untuk melakukan NAT sumber untuk alamat IP sumber yang tumpang tindih, dan ELB melakukan NAT tujuan untuk alamat IP tujuan yang tumpang tindih. Anda dapat merutekan lalu lintas dari gateway NAT pribadi ke jaringan lain VPCs atau lokal menggunakan Transit Gateway atau gateway pribadi virtual.



![\[Diagram yang menggambarkan contoh pengaturan untuk gateway NAT pribadi\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)


Gambar sebelumnya menunjukkan dua subnet non-routable (tumpang tindih CIDRs,`100.64.0.0/16`) di VPC A dan B. Untuk membuat koneksi di antara keduanya, Anda dapat menambahkan non-overlapping/routable sekunder (subnet CIDRs routable, dan) ke VPC A dan B, masing-masing. `10.0.1.0/24` `10.0.2.0/24` Routable CIDRs harus dialokasikan oleh tim manajemen jaringan yang bertanggung jawab atas alokasi IP. Gateway NAT pribadi ditambahkan ke subnet yang dapat dirutekan di VPC A dengan alamat IP. `10.0.1.125` Gateway NAT pribadi melakukan terjemahan alamat jaringan sumber pada permintaan dari instance di subnet VPC A (`100.64.0.10`) yang tidak dapat dirutekan sebagai`10.0.1.125`, ENI dari gateway NAT pribadi. Sekarang lalu lintas dapat diarahkan ke alamat IP routable yang ditetapkan ke Application Load Balancer (ALB) di VPC B `10.0.2.10` (), yang memiliki target. `100.64.0.10` Lalu lintas dialihkan melalui Transit Gateway. Lalu lintas pengembalian diproses oleh gateway NAT pribadi kembali ke EC2 instans Amazon asli yang meminta koneksi.

Gateway NAT pribadi juga dapat digunakan ketika jaringan lokal Anda membatasi akses ke yang disetujui. IPs Jaringan lokal dari beberapa pelanggan diwajibkan oleh kepatuhan untuk berkomunikasi hanya dengan jaringan pribadi (tanpa IGW) hanya melalui blok bersebelahan terbatas yang disetujui IPs yang dimiliki oleh pelanggan. Alih-alih mengalokasikan setiap instance IP terpisah dari blok, Anda dapat menjalankan beban kerja besar di AWS VPCs belakang setiap IP yang terdaftar yang diizinkan menggunakan gateway NAT pribadi. Untuk detailnya, lihat [Cara mengatasi kelelahan IP Pribadi dengan Posting blog Solusi NAT Pribadi](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/).

![\[Diagram yang menggambarkan cara menggunakan gateway NAT pribadi untuk memberikan persetujuan IPs untuk jaringan lokal\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)


# AWS Awan WAN
<a name="aws-cloud-wan"></a>

 AWS Cloud WAN adalah cara baru untuk menghubungkan jaringan bersama yang sebelumnya dapat kami lakukan dengan Transit Gateways, VPC Peering, dan terowongan VPN IPSEC. Sebelumnya Anda akan mengonfigurasi satu atau lebih VPCs, menghubungkannya bersama dengan salah satu metode sebelumnya, dan menggunakan IPSEC VPN atau Direct Connect untuk terhubung ke jaringan lokal. Anda akan memiliki konstruksi postur jaringan dan keamanan yang ditentukan di satu tempat, dan jaringan Anda di tempat lain. Cloud WAN memungkinkan Anda untuk memusatkan semua konstruksi ini di satu tempat. Berdasarkan kebijakan, Anda dapat mengelompokkan jaringan Anda untuk menentukan siapa yang dapat berbicara dengan siapa, dan mengisolasi lalu lintas produksi melalui segmen ini dari beban kerja pengembangan atau pengujian, atau jaringan di tempat Anda. 

![\[Diagram yang menggambarkan konektivitas AWS Cloud WAN\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)


 Kelola jaringan global Anda melalui antarmuka pengguna AWS Network Manager dan APIs. Jaringan global adalah wadah tingkat root untuk semua objek jaringan Anda; jaringan inti adalah bagian dari jaringan global Anda yang dikelola oleh AWS. Kebijakan jaringan inti (CNP) adalah dokumen kebijakan berversi tunggal yang mendefinisikan semua aspek jaringan inti Anda. Lampiran adalah koneksi atau sumber daya apa pun yang ingin Anda tambahkan ke jaringan inti Anda. Core Network Edge (CNE) adalah titik koneksi lokal untuk lampiran yang mematuhi kebijakan. Segmen jaringan adalah domain routing yang, secara default, memungkinkan komunikasi hanya dalam segmen. 

 Untuk menggunakan CloudWAN: 

1.  Di AWS Network Manager, buat jaringan global dan jaringan inti terkait. 

1.  Buat CNP yang mendefinisikan segmen, rentang ASN, Wilayah AWS dan tag yang akan digunakan untuk melampirkan ke segmen. 

1.  Terapkan kebijakan jaringan. 

1.  Bagikan jaringan inti dengan pengguna, akun, atau organisasi Anda menggunakan pengelola akses sumber daya. 

1.  Buat dan tag lampiran. 

1.  Perbarui rute di lampiran Anda VPCs untuk menyertakan jaringan inti. 

 Cloud WAN dirancang untuk menyederhanakan proses menghubungkan infrastruktur AWS Anda secara global. Ini memungkinkan Anda untuk menyegmentasikan lalu lintas dengan kebijakan izin terpusat dan menggunakan infrastruktur yang ada di lokasi perusahaan Anda. Cloud WAN juga menghubungkan sumber daya Anda VPCsWANs, SD- VPNs, Klien, firewall VPNs, dan pusat data untuk terhubung ke Cloud WAN. Untuk informasi selengkapnya, lihat [postingan blog AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/). 

 AWS Cloud WAN memungkinkan jaringan terpadu yang menghubungkan cloud dan lingkungan lokal. Organizations menggunakan firewall generasi berikutnya (NGFWs) dan sistem pencegahan intrusi () untuk keamanan. IPSs Posting blog [pola migrasi dan interoperabilitas AWS Cloud WAN dan Transit Gateway menjelaskan pola](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/) arsitektur untuk mengelola dan memeriksa lalu lintas jaringan keluar secara terpusat di jaringan Cloud WAN, termasuk jaringan Single-region dan Multi-region, dan mengonfigurasi tabel rute. Arsitektur ini memastikan data dan aplikasi tetap aman sambil mempertahankan lingkungan cloud yang aman. 

 Untuk informasi selengkapnya tentang Cloud WAN, lihat [arsitektur inspeksi keluar terpusat di postingan blog AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/). 

# Kisi VPC Amazon
<a name="vpc-lattice"></a>

 Amazon VPC Lattice adalah layanan jaringan aplikasi yang dikelola sepenuhnya yang digunakan untuk menghubungkan, memantau, dan mengamankan layanan di berbagai akun dan cloud pribadi virtual. VPC Lattice membantu menghubungkan layanan dalam batas logis, sehingga Anda dapat mengelola dan menemukannya secara efisien. 

 Komponen VPC Lattice terdiri dari: 
+  **Layanan** - Ini adalah unit aplikasi yang berjalan pada instance, wadah, atau fungsi Lambda dan terdiri dari pendengar, aturan, dan kelompok target. 
+  **Jaringan layanan** - Ini adalah batas logis yang digunakan untuk secara otomatis mengimplementasikan penemuan layanan dan konektivitas dan menerapkan kebijakan akses dan observabilitas umum ke kumpulan layanan. 
+  **Kebijakan autentikasi - Kebijakan** sumber daya IAM yang dapat dikaitkan dengan jaringan layanan atau layanan individual untuk mendukung otentikasi tingkat permintaan dan otorisasi khusus konteks. 
+  **Direktori Layanan** - Tampilan terpusat dari layanan yang Anda miliki atau yang telah dibagikan kepada Anda melalui AWS Resource Access Manager. 

 Langkah-langkah penggunaan VPC Lattice: 

1.  Buat jaringan layanan. Jaringan layanan biasanya berada di akun jaringan di mana administrator jaringan memiliki akses penuh. Jaringan layanan dapat dibagi di beberapa akun dalam suatu organisasi. Berbagi dapat dilakukan pada layanan individu atau seluruh akun layanan. 

1.  Lampirkan VPCs ke jaringan layanan untuk mengaktifkan jaringan aplikasi untuk setiap VPC, sehingga layanan yang berbeda dapat mulai mengkonsumsi layanan lain yang terdaftar dalam jaringan. Kelompok keamanan diterapkan untuk mengontrol lalu lintas. 

1.  Pengembang mendefinisikan layanan, yang diisi dalam direktori layanan dan terdaftar ke jaringan layanan. VPC Lattice berisi buku alamat semua layanan yang dikonfigurasi. Pengembang juga dapat menentukan kebijakan perutean untuk menggunakan penerapan biru/hijau. Keamanan dikelola pada tingkat jaringan layanan di mana kebijakan otentikasi dan otorisasi didefinisikan dan pada tingkat layanan di mana kebijakan akses dengan IAM diterapkan. 

![\[Diagram yang menggambarkan aliran komunikasi VPC Lattice\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)


 Rincian lebih lanjut dapat ditemukan di panduan [pengguna VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html ). 