# REL02-BP03 Pastikan alokasi subnet IP menjelaskan ekspansi dan ketersediaan
Rentang alamat IP Amazon VPC harus cukup besar untuk mengakomodasi persyaratan beban kerja, termasuk pertimbangan ekspansi mendatang dan alokasi alamat IP ke subnet di seluruh Zona Ketersediaan. Ini mencakup penyeimbang beban, instans EC2, dan aplikasi berbasis kontainer.
Ketika Anda merencanakan topologi jaringan Anda, langkah pertama yang harus dilakukan adalah menetapkan ruang alamat IP itu sendiri. Rentang alamat IP privat (mengikuti pedoman RFC 1918) harus dialokasikan untuk masing-masing VPC. Akomodasikan persyaratan berikut sebagai bagian dari proses ini:
+ Berikan ruang alamat IP untuk lebih dari satu VPC untuk setiap Wilayah.
+ Di dalam sebuah VPC, berikan ruang untuk beberapa subnet sehingga Anda dapat mencakup beberapa Zona Ketersediaan.
+ Pertimbangkan untuk membiarkan ruang blok CIDR yang tidak digunakan di dalam sebuah VPC untuk melakukan ekspansi di masa mendatang.
+ Pastikan ada ruang alamat IP untuk memenuhi kebutuhan armada sementara instans Amazon EC2 yang mungkin Anda gunakan, seperti Armada Spot untuk machine learning, klaster Amazon EMR, atau klaster Amazon Redshift. Pertimbangan serupa sebaiknya diberikan ke klaster Kubernetes, seperti Amazon Elastic Kubernetes Service (Amazon EKS), karena setiap pod Kubernetes diberi alamat yang dapat dirutekan dari blok CIDR VPC secara default.
+ Perlu diperhatikan bahwa empat alamat IP pertama dan alamat IP terakhir di setiap blok CIDR subnet sudah terpesan dan tidak tersedia untuk Anda gunakan.
+ Perlu diperhatikan bahwa blok CIDR VPC awal yang dialokasikan ke VPC Anda tidak dapat diubah atau dihapus, tetapi Anda dapat menambahkan tambahan blok CIDR yang tidak tumpang tindih ke VPC. CIDR IPv4 subnet tidak dapat diubah, tetapi CIDR IPv6 dapat diubah.
+ Blok CIDR VPC terbesar yang memungkinkan adalah /16, dan yang terkecil adalah /28.
+ Pertimbangkan untuk menggunakan jaringan terkoneksi lain (VPC, on-premise, atau penyedia cloud lainnya) dan pastikan ruang alamat IP tidak tumpang tindih. Untuk informasi selengkapnya, lihat [REL02-BP05 Terapkan rentang alamat IP privat yang tidak tumpang tindih di semua ruang alamat privat tempat semuanya saling terhubung.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html)
**Hasil yang diinginkan:** Sebuah subnet IP yang dapat diskalakan dapat membantu Anda mengakomodasi pertumbuhan yang mungkin terjadi di masa depan dan menghindari pemborosan yang tidak perlu.
**Anti-pola umum:**
+ Jika Anda gagal mempertimbangkan pertumbuhan yang mungkin terjadi di masa depan, maka hal itu akan mengakibatkan blok CIDR yang terlalu kecil dan membutuhkan konfigurasi ulang, serta berpotensi menyebabkan waktu henti.
+ Salah memperkirakan jumlah alamat IP yang dapat digunakan oleh satu penyeimbang beban elastis.
+ Melakukan deployment banyak penyeimbang beban lalu lintas tinggi ke subnet yang sama
+ Menggunakan mekanisme penskalaan otomatis tetapi gagal memantau pemakaian alamat IP.
+ Menentukan rentang CIDR yang terlalu besar melampaui ekspektasi pertumbuhan yang mungkin terjadi di masa depan, sehingga menyebabkan adanya kesulitan untuk melakukan peering dengan jaringan lain dengan rentang alamat yang tumpang tindih.
**Manfaat menerapkan praktik terbaik ini:** Ini akan memastikan bahwa Anda dapat mengakomodasi pertumbuhan beban kerja Anda dan akan terus memberikan ketersediaan saat Anda menaikkan skala.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Rencanakan jaringan Anda untuk mengakomodasi pertumbuhan, kepatuhan terhadap peraturan, dan integrasi dengan jaringan yang lain. Pertumbuhan mungkin saja lebih besar dari yang diperkirakan, kepatuhan terhadap peraturan dapat berubah, dan koneksi jaringan privat atau akuisisi bisa jadi akan sulit diimplementasikan tanpa melakukan perencanaan yang baik.
+ Pilih Akun AWS dan Wilayah yang relevan berdasarkan persyaratan layanan, latensi, peraturan, dan pemulihan bencana (DR) Anda.
+ Identifikasi kebutuhan Anda untuk deployment VPC regional.
+ Identifikasi ukuran VPC.
+ Tentukan apakah Anda akan melakukan deployment konektivitas multi-VPC.
+ [Apa Itu Gateway Transit?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Konektivitas Multi-VPC Satu Wilayah](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Tentukan apakah Anda membutuhkan jaringan terpisah (segregated) untuk persyaratan berdasarkan regulasi.
+ Buat VPC dengan blok CIDR yang mempunyai ukuran yang sesuai untuk mengakomodasi kebutuhan Anda saat ini dan kebutuhan di masa depan.
+ Jika Anda memiliki proyeksi pertumbuhan yang tidak diketahui, maka Anda sebaiknya melakukan kesalahan di sisi blok CIDR yang lebih besar untuk mengurangi potensi konfigurasi ulang di masa depan
+ Pertimbangkan untuk menggunakan [pengalamatan IPv6](https://aws.amazon.com/vpc/ipv6/) untuk subnet sebagai bagian dari VPC tumpukan ganda. IPv6 sangat cocok untuk digunakan di subnet privat yang memuat armada instans sementara atau kontainer yang seharusnya membutuhkan alamat IPv4 dalam jumlah besar.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [REL02-BP05 Terapkan rentang alamat IP privat yang tidak tumpang tindih di semua ruang alamat privat tempat semuanya saling terhubung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html)
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda merencanakan jaringan Anda](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace untuk Infrastruktur Jaringan](https://aws.amazon.com/marketplace/b/2649366011)
+ [Laporan Resmi Pilihan Konektivitas Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Konektivitas jaringan ketersediaan tinggi (HA) beberapa pusat data](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Konektivitas Multi-VPC Satu Wilayah](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [Apa yang Dimaksud Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [IPv6 di AWS](https://aws.amazon.com/vpc/ipv6)
+ [IPv6 di arsitektur referensi](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf)
+ [Amazon Elastic Kubernetes Service meluncurkan dukungan IPv6](https://aws.amazon.com/blogs/containers/amazon-eks-launches-ipv6-support/)
+ [ Rekomendasi untuk VPC Anda - Penyeimbang Beban Klasik ](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-backend-instances.html#set-up-ec2)
+ [ Subnet Zona Ketersediaan - Penyeimbang Beban Aplikasi ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#availability-zones)
+ [ Zona Ketersediaan - Penyeimbang Beban Jaringan ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#availability-zones)
**Video terkait:**
+ [AWS re:Invent 2018: Desain VPC Tingkat Lanjut dan Kemampuan Baru untuk Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: Arsitektur referensi AWS Transit Gateway untuk berbagai VPC (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
+ [AWS re:Invent 2023: AWS Siap dengan yang berikutnya? Merancang jaringan untuk pertumbuhan dan fleksibilitas (NET310)](https://www.youtube.com/watch?v=FkWOhTZSfdA)