Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Memilih kebijakan perutean Saat Anda membuat catatan, Anda memilih kebijakan perutean, yang menentukan bagaimana Amazon Route 53 merespons kueri: + **Kebijakan perutean sederhana** – Gunakan untuk satu sumber daya yang menjalankan fungsi tertentu untuk domain Anda, misalnya, server web yang menyajikan konten untuk situs web example.com. Anda dapat menggunakan perutean sederhana untuk membuat catatan di zona host pribadi. + **Kebijakan perutean failover** – Gunakan ketika Anda ingin mengonfigurasi failover aktif-pasif. Anda dapat menggunakan perutean failover untuk membuat catatan di zona host pribadi. + **Kebijakan perutean geolokasi**– Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi pengguna Anda. Anda dapat menggunakan perutean geolokasi untuk membuat catatan di zona host pribadi. + **Kebijakan perutean geoproximity** - Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi sumber daya Anda dan, secara opsional, mengalihkan lalu lintas dari sumber daya di satu lokasi ke sumber daya di lokasi lain. Anda dapat menggunakan perutean geoproximity untuk membuat catatan di zona host pribadi. + **Kebijakan perutean latensi** — Gunakan saat Anda memiliki sumber daya dalam beberapa Wilayah AWS dan Anda ingin merutekan lalu lintas ke Wilayah yang memberikan latensi terbaik. Anda dapat menggunakan perutean latensi untuk membuat catatan di zona host pribadi. + **Kebijakan perutean berbasis IP** — Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi pengguna Anda, dan dapatkan alamat IP tempat lalu lintas berasal. + **Kebijakan perutean jawaban multinilai** – Gunakan saat Anda ingin Route 53 merespons kueri DNS dengan hingga delapan catatan sehat yang dipilih secara acak. Anda dapat menggunakan routing jawaban multivalue untuk membuat catatan di zona host pribadi. + **Kebijakan perutean berbobot** – Gunakan untuk merutekan lalu lintas ke beberapa sumber daya dalam proporsi yang Anda tentukan. Anda dapat menggunakan perutean tertimbang untuk membuat catatan di zona host pribadi. **Topics** + [Perutean sederhana](routing-policy-simple.md) + [Perutean failover](routing-policy-failover.md) + [Perutean geolokasi](routing-policy-geo.md) + [Perutean geoproksimitas](routing-policy-geoproximity.md) + [Perutean berbasis latensi](routing-policy-latency.md) + [Perutean berbasis IP](routing-policy-ipbased.md) + [Perutean jawaban multinilai](routing-policy-multivalue.md) + [Perutean tertimbang](routing-policy-weighted.md) + [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md) # Perutean sederhana Perutean sederhana memungkinkan Anda mengonfigurasi data DNS standar, tanpa perutean Route 53 khusus seperti tertimbang atau latensi. Dengan perutean yang sederhana, Anda biasanya mengarahkan lalu lintas ke sumber daya tunggal, misalnya, ke server web untuk situs web Anda. Anda dapat menggunakan kebijakan perutean sederhana untuk catatan di zona host pribadi. Jika Anda memilih kebijakan perutean sederhana di konsol Route 53, Anda tidak dapat membuat beberapa catatan yang memiliki nama dan jenis yang sama, tetapi Anda dapat menentukan beberapa nilai dalam catatan yang sama, seperti beberapa alamat IP. (Jika Anda memilih kebijakan perutean sederhana untuk catatan alias, Anda hanya dapat menentukan satu AWS sumber daya atau satu catatan di zona yang dihosting saat ini.) Jika Anda menentukan beberapa nilai dalam catatan, Route 53 mengembalikan semua nilai ke resolver rekursif dalam urutan acak, dan resolver mengembalikan nilai ke klien (seperti perambabn web) yang mengirimkan kueri DNS. Klien kemudian memilih nilai dan mengirim ulang kueri. Dengan kebijakan routing sederhana, meskipun Anda dapat menentukan beberapa alamat IP, alamat IP ini tidak diperiksa kesehatan. Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean sederhana untuk membuat rekaman, lihat topik berikut ini: + [Nilai khusus untuk catatan sederhana](resource-record-sets-values-basic.md) + [Nilai khusus untuk catatan alias sederhana](resource-record-sets-values-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) # Perutean failover Perutean failover memungkinkan Anda merutekan lalu lintas ke sumber daya saat sumber daya sehat atau ke sumber daya lain saat sumber daya pertama tidak sehat. Catatan primer dan sekunder dapat merutekan lalu lintas ke apa pun dari bucket Amazon S3 yang dikonfigurasi sebagai situs web ke pohon catatan yang kompleks. Untuk informasi selengkapnya, lihat [Failover active-passive](dns-failover-types.md#dns-failover-types-active-passive). Anda dapat menggunakan kebijakan perutean failover untuk catatan di zona host pribadi. Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean failover untuk membuat catatan, lihat topik berikut ini: + [Nilai khusus untuk catatan failover](resource-record-sets-values-failover.md) + [Nilai khusus untuk catatan alias failover](resource-record-sets-values-failover-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) # Perutean geolokasi Perutean geolokasi memungkinkan Anda memilih sumber daya yang melayani lalu lintas Anda berdasarkan lokasi geografis pengguna Anda, yang berarti lokasi asal kueri DNS. Misalnya, Anda mungkin ingin semua kueri dari Eropa dialihkan ke penyeimbang beban Elastic Load Balancing di Wilayah Frankfurt. Saat Anda menggunakan perutean geolokasi, Anda dapat melokalkan konten Anda dan menyajikan beberapa atau semua situs web Anda dalam bahasa pengguna Anda. Anda juga dapat menggunakan perutean geolokasi untuk membatasi distribusi konten hanya ke lokasi di mana Anda memiliki hak distribusi. Penggunaan lain yang mungkin adalah untuk menyeimbangkan beban di seluruh titik akhir dengan easy-to-manage cara yang dapat diprediksi, sehingga setiap lokasi pengguna secara konsisten diarahkan ke titik akhir yang sama. Anda dapat menentukan lokasi geografis menurut benua, negara, atau negara bagian di Amerika Serikat. Jika Anda membuat catatan terpisah untuk wilayah geografis yang tumpang tindih—misalnya, satu rekaman untuk Amerika Utara dan satu untuk Kanada—prioritas masuk ke wilayah geografis terkecil. Ini memungkinkan Anda untuk merutekan beberapa kueri untuk suatu benua ke satu sumber daya dan untuk merutekan kueri untuk negara yang dipilih di benua itu ke sumber daya yang berbeda. (Untuk daftar negara di setiap benua, lihat [Lokasi](resource-record-sets-values-geo.md#rrsets-values-geo-location).) Geolokasi berfungsi dengan memetakan alamat IP ke lokasi. Namun, beberapa alamat IP tidak dipetakan ke lokasi geografis, jadi meskipun Anda membuat catatan geolokasi yang mencakup ketujuh benua, Amazon Route 53 akan menerima beberapa kueri DNS dari lokasi yang tidak dapat diidentifikasi. Anda dapat membuat catatan default yang menangani kedua kueri dari alamat IP yang tidak dipetakan ke lokasi mana pun dan kueri yang berasal dari lokasi yang data geolokasinya belum Anda buat. Jika Anda tidak membuat catatan default, Route 53 menghasilkan respons "tidak ada jawaban" untuk kueri dari lokasi tersebut. Anda dapat menggunakan perutean geolokasi untuk catatan di zona host publik dan pribadi. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md). Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean geolokasi untuk membuat catatan, lihat topik berikut ini: + [Nilai khusus untuk catatan geolokasi](resource-record-sets-values-geo.md) + [Nilai khusus untuk catatan alias geolokasi](resource-record-sets-values-geo-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) # Perutean geolokasi di zona host pribadi Untuk zona yang dihosting pribadi, Route 53 merespons kueri DNS berdasarkan VPC Wilayah AWS tempat kueri tersebut berasal. Untuk daftar Wilayah AWS, lihat [Wilayah dan zona](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) di panduan *pengguna Amazon EC2*. Jika kueri DNS berasal dari bagian lokal dari jaringan hybrid, itu akan dianggap berasal dari tempat VPC berada. Wilayah AWS Jika menyertakan pemeriksaan kesehatan, Anda dapat membuat catatan default untuk: + Alamat IP yang tidak dipetakan ke lokasi geografis. + Kueri DNS yang berasal dari lokasi yang belum Anda buat catatan geolokasi. Jika catatan geolokasi untuk wilayah kueri DNS tidak sehat, catatan default akan dikembalikan (jika sehat). Dalam konfigurasi contoh pada gambar berikut, kueri DNS yang berasal dari us-east-1 Wilayah AWS (Virginia) akan dialihkan ke titik akhir 1.1.1.1. ![\[Tangkapan layar yang menunjukkan catatan geolokasi untuk zona host pribadi.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # Perutean geoproksimitas Perutean geoproximity memungkinkan Amazon Route 53 merutekan lalu lintas ke sumber daya Anda berdasarkan lokasi geografis pengguna dan sumber daya Anda. Ini mengarahkan lalu lintas ke sumber daya terdekat yang tersedia. *Anda juga dapat memilih untuk mengarahkan lebih banyak lalu lintas atau lebih sedikit lalu lintas ke sumber daya tertentu dengan menentukan nilai, yang dikenal sebagai bias.* Bias memperluas atau mengecilkan ukuran wilayah geografis tempat lalu lintas dirutekan ke sumber daya. Anda membuat aturan geoproximity untuk sumber daya Anda dan menentukan salah satu nilai berikut untuk setiap aturan: + Jika Anda menggunakan AWS sumber daya, tentukan Wilayah AWS atau Grup Zona Lokal tempat Anda membuat sumber daya. + Jika Anda menggunakan AWS non-sumber daya, tentukan garis lintang dan bujur sumber daya. Untuk menggunakan AWS Local Zones, Anda harus mengaktifkannya terlebih dahulu. Untuk informasi selengkapnya, lihat [Memulai Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) di *Panduan Pengguna AWS Local Zones*. Untuk mempelajari perbedaan antara Wilayah AWS dan Local Zones, lihat [Wilayah dan Zona](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) di *Panduan Pengguna Amazon EC2*. Untuk mengubah ukuran wilayah geografis dari mana Route 53 route lalu lintas ke sumber daya, tentukan nilai yang berlaku untuk bias: + Untuk memperluas ukuran wilayah geografis tempat Route 53 merutekan lalu lintas ke sumber daya, tentukan bilangan bulat positif dari 1 hingga 99 untuk bias. Route 53 menyusutkan ukuran wilayah yang berdekatan. + Untuk menyusutkan ukuran wilayah geografis yang lalu lintasnya dirutekan oleh Route 53 ke sumber daya, tentukan bias negatif -1 sampai -99. Route 53 memperluas ukuran wilayah yang berdekatan. **catatan** Kami memperbarui konsol Arus Lalu Lintas untuk Route 53. Selama masa transisi, Anda dapat terus menggunakan konsol lama. Pilih tab untuk konsol yang Anda gunakan. + [Konsol baru](#traffic-flow-geoprox-routing-map-new) + [Konsol lama](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] Peta berikut menunjukkan empat Wilayah AWS (nomor 1 sampai 5): 1. AS Barat (Oregon) 1. Eropa (Frankfurt) 1. Asia Pasifik (Tokyo) 1. Africa (Cape Town) 1. Timur Tengah (Bahrain) **catatan** Peta hanya tersedia dengan Arus Lalu Lintas. ![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda memiliki catatan geoproximity untuk sumber daya Wilayah AWS di AS Barat (Oregon), Eropa (Frankfurt), Asia Pasifik (Tokyo), Afrika (Cape Town) dan Timur Tengah (Bahrain).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) Peta berikut menunjukkan apa yang terjadi jika Anda menambahkan bias \$125 untuk Wilayah Barat AS (Oregon) (nomor **1** di peta). Lalu lintas diarahkan ke sumber daya di Wilayah itu dari sebagian besar Amerika Utara dan dari seluruh Amerika Selatan daripada sebelumnya. ![\[Peta dunia yang menunjukkan bagaimana lalu lintas dirutekan saat Anda menambahkan bias +25 di Wilayah US East (Northern Virginia).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) Peta berikut menunjukkan apa yang terjadi jika Anda mengubah bias menjadi -25 untuk Wilayah Barat AS (Oregon). **Lalu lintas dialihkan ke sumber daya di Wilayah itu dari bagian yang lebih kecil di Amerika Utara dan Selatan daripada sebelumnya, dan lebih banyak lalu lintas diarahkan ke sumber daya di wilayah yang berdekatan **2**, **3**, dan 4.** ![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda menambahkan bias -25 di Wilayah AS Barat (Oregon).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] Peta berikut menunjukkan empat Wilayah AWS (nomor 1 sampai 4) dan lokasi di Johannesburg, Afrika Selatan yang ditentukan oleh garis lintang dan bujur (5). **catatan** Peta hanya tersedia dengan Arus Lalu Lintas. ![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda memiliki catatan geoproximity untuk sumber daya Wilayah AWS di AS Barat (Oregon), AS Timur (Virginia N.), Eropa (Paris), dan Asia Pasifik (Tokyo), dan Anda memiliki catatan untuk AWS non-sumber daya di Johannesburg, Afrika Selatan.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) Peta berikut menunjukkan apa yang terjadi jika Anda menambahkan bias \$125 untuk Wilayah AS Timur (Virginia N.) (nomor **2** di peta). Lalu lintas dialihkan ke sumber daya di Wilayah itu dari sebagian besar Amerika Utara daripada sebelumnya, dan dari seluruh Amerika Selatan. ![\[Peta dunia yang menunjukkan bagaimana lalu lintas dirutekan saat Anda menambahkan bias +25 di Wilayah US East (Northern Virginia).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) Peta berikut menunjukkan apa yang terjadi jika Anda mengubah bias menjadi -25 untuk Wilayah AS Timur (Virginia N.). Lalu lintas dirutekan ke sumber daya di Wilayah itu dari bagian yang lebih kecil di Amerika Utara dan Selatan daripada sebelumnya, dan lebih banyak lalu lintas diarahkan ke sumber daya di wilayah yang berdekatan **1**, **3**, dan **5**. ![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda menambahkan bias -25 di Wilayah AS Timur (Virginia N.).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ Efek mengubah bias untuk sumber daya Anda bergantung pada sejumlah faktor, termasuk berikut ini: + Jumlah sumber daya yang Anda miliki. + Seberapa dekat sumber daya satu sama lain. + Jumlah pengguna yang Anda miliki di dekat area perbatasan antar wilayah geografis. Misalnya, Anda memiliki sumber daya di Wilayah AWS AS Timur (Virginia N.) dan AS Barat (Oregon), dan Anda memiliki banyak pengguna di Dallas, Austin, dan San Antonio, Texas, AS. Kota-kota itu kira-kira berjarak sama antara sumber daya Anda, sehingga perubahan kecil dalam bias dapat mengakibatkan perubahan besar dalam lalu lintas dari sumber daya satu Wilayah AWS ke yang lain. Kami menyarankan Anda mengubah bias secara bertahap untuk mencegah sumber daya Anda yang berlebihan, karena perubahan lalu lintas yang tidak terduga. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md). ## Bagaimana Amazon Route 53 menggunakan bias untuk merutekan lalu lintas Berikut rumus yang digunakan Amazon Route 53 untuk menentukan cara merutekan lalu lintas: **Bias** `Biased distance = actual distance * [1 - (bias/100)]` Ketika nilai bias positif, Route 53 memperlakukan sumber kueri DNS dan sumber daya yang Anda tentukan dalam catatan geoproximity (seperti instance EC2 dalam an Wilayah AWS) seolah-olah mereka lebih dekat daripada yang sebenarnya. Misalnya, anggap Anda memiliki catatan geoproximity berikut: + Catatan untuk web server A, yang memiliki bias positif 50 + Catatan untuk server web B, yang tidak memiliki bias Saat catatan geoproximity memiliki bias positif sebesar 50, Route 53 membagi dua jarak antara sumber kueri dan sumber daya untuk rekaman tersebut. Kemudian Route 53 menghitung sumber daya mana yang lebih dekat dengan sumber kueri. Misalkan web server A berjarak 150 kilometer dari sumber kueri dan web server B berjarak 100 kilometer dari sumber kueri. Jika tidak ada catatan yang bias, Route 53 akan merutekan kueri ke server web B karena lebih dekat. Namun, karena catatan untuk server web A memiliki bias positif sebesar 50, Route 53 memperlakukan server web A seolah-olah berjarak 75 kilometer dari sumber kueri. Akibatnya, Route 53 merutekan kueri ke server web A. Berikut perhitungan untuk bias positif 50: ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # Perutean berbasis latensi Jika aplikasi Anda di-host dalam beberapa Wilayah AWS, Anda dapat meningkatkan kinerja untuk pengguna Anda dengan menyajikan permintaan mereka dari Wilayah AWS yang menyediakan latensi terendah. **catatan** Data tentang latensi antara pengguna dan sumber daya Anda didasarkan sepenuhnya pada lalu lintas antara pengguna dan pusat data AWS . Jika Anda tidak menggunakan sumber daya dalam file Wilayah AWS, latensi aktual antara pengguna dan sumber daya Anda dapat sangat bervariasi dari data AWS latensi. Ini benar bahkan jika sumber daya Anda terletak di kota yang sama dengan Wilayah AWS. Untuk menggunakan perutean berbasis latensi, Anda membuat catatan latensi untuk sumber daya Anda dalam beberapa. Wilayah AWS Saat Route 53 menerima kueri DNS untuk domain atau subdomain Anda (example.com atau acme.example.com), Route 53 menentukan untuk mana Wilayah AWS Anda telah membuat catatan latensi, menentukan Wilayah mana yang memberikan latensi terendah kepada pengguna, dan kemudian memilih catatan latensi untuk Wilayah tersebut. Route 53 merespons dengan nilai dari catatan yang dipilih, seperti alamat IP untuk server web. Misalnya, Anda memiliki penyeimbang beban Elastic Load Balancing di Wilayah AS Barat (Oregon) dan di Wilayah Asia Pasifik (Singapura). Anda membuat catatan latensi untuk setiap penyeimbang beban. Inilah yang terjadi saat pengguna di London memasukkan nama domain Anda di peramban: 1. DNS merutekan kueri ke server nama Route 53. 1. Route 53 mengacu pada datanya tentang latensi antara London dan Wilayah Singapura dan antara London dan Wilayah Oregon. 1. Jika latensi lebih rendah antara Wilayah London dan Oregon, Route 53 merespons kueri dengan alamat IP untuk penyeimbang beban Oregon. Jika latensi lebih rendah antara London dan Wilayah Singapura, Route 53 merespons dengan alamat IP untuk penyeimbang beban Singapura. Latensi antara host di internet dapat berubah seiring waktu sebagai akibat dari perubahan konektivitas jaringan dan perutean. Perutean berbasis latensi didasarkan pada pengukuran latensi yang dilakukan selama periode waktu tertentu, dan pengukuran mencerminkan perubahan ini. Permintaan yang dialihkan ke Wilayah Oregon minggu ini mungkin akan dialihkan ke Wilayah Singapura minggu depan. **catatan** Ketika browser atau penampil lain menggunakan DNS resolver yang mendukung edns-client-subnet ekstensi EDNS0, DNS resolver mengirimkan Route 53 versi terpotong dari alamat IP pengguna. Jika Anda mengonfigurasi perutean berbasis latensi, Route 53 mempertimbangkan nilai ini saat merutekan lalu lintas ke sumber daya Anda. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md). Anda dapat menggunakan kebijakan perutean latensi untuk catatan di zona host pribadi. Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean latensi untuk membuat catatan, lihat topik berikut ini: + [Nilai khusus untuk catatan latensi](resource-record-sets-values-latency.md) + [Nilai khusus untuk catatan alias latensi](resource-record-sets-values-latency-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) # Perutean berbasis latensi di zona host pribadi Untuk zona yang dihosting pribadi, Route 53 menjawab kueri DNS dengan titik akhir yang sama Wilayah AWS, atau jaraknya paling dekat dengan VPC Wilayah AWS tempat kueri berasal. **catatan** Jika Anda memiliki titik akhir keluar yang diteruskan ke titik akhir masuk, catatan akan diselesaikan berdasarkan di mana titik akhir masuk berada, bukan titik akhir keluar. Jika Anda menyertakan pemeriksaan kesehatan, dan catatan dengan latensi terendah ke asal kueri tidak sehat, titik akhir yang sehat dengan latensi terendah berikutnya akan dikembalikan. Dalam konfigurasi contoh pada gambar berikut, kueri DNS yang berasal dari us-east-1, atau yang paling dekat dengannya Wilayah AWS, akan dirutekan ke titik akhir 1.1.1.1. Kueri DNS dari us-west-2, atau yang paling dekat dengannya, akan dirutekan ke titik akhir 2.2.2.2. ![\[Tangkapan layar yang menunjukkan dua catatan latensi untuk zona host pribadi.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/latency-phz.png) # Perutean berbasis IP Dengan perutean berbasis IP di Amazon Route 53, Anda dapat menyempurnakan perutean DNS Anda dengan menggunakan pemahaman Anda tentang jaringan, aplikasi, dan klien Anda untuk membuat keputusan perutean DNS terbaik bagi pengguna akhir Anda. Perutean berbasis IP memberi Anda kontrol granular untuk mengoptimalkan kinerja atau mengurangi biaya jaringan dengan mengunggah data Anda ke Route 53 dalam bentuk pemetaan. user-IP-to-endpoint Perutean berbasis geolokasi dan latensi didasarkan pada data yang dikumpulkan dan diperbarui oleh Route 53. Pendekatan ini bekerja dengan baik untuk sebagian besar pelanggan, tetapi perutean berbasis IP menawarkan Anda kemampuan tambahan untuk mengoptimalkan perutean berdasarkan pengetahuan khusus tentang basis pelanggan Anda. Misalnya, penyedia konten video global mungkin ingin merutekan pengguna akhir dari penyedia layanan internet (ISP) tertentu. Beberapa kasus penggunaan umum untuk perutean berbasis IP adalah sebagai berikut: + Anda ingin merutekan pengguna akhir dari titik akhir tertentu ISPs ke titik akhir tertentu sehingga Anda dapat mengoptimalkan biaya atau kinerja transit jaringan. + Anda ingin menambahkan penggantian ke jenis perutean Route 53 yang ada, seperti perutean geolokasi, berdasarkan pengetahuan Anda tentang lokasi fisik klien Anda. **Mengelola rentang IP dan mengaitkannya ke kumpulan catatan sumber daya () RRSet** Untuk IPv4, Anda dapat menggunakan blok CIDR dengan panjang antara 1 dan 24 bit, inklusif, sedangkan untukIPv6, Anda dapat menggunakan blok CIDR dengan panjang antara 1 dan 48 bit, inklusif. Untuk menentukan blok CIDR nol bit (0.0.0.0/0 atau: :/0), gunakan lokasi default (“\$1”). Untuk kueri DNS dengan CIDR yang lebih panjang dari yang ditentukan dalam koleksi CIDR, Route 53 akan mencocokkannya dengan CIDR yang lebih pendek. Misalnya, jika Anda menentukan 2001:0DB8: :/32 sebagai blok CIDR dalam koleksi CIDR Anda dan kueri berasal dari 2001:0DB8: 0000:1234: :/48, itu akan cocok. Jika, di sisi lain, Anda menentukan 2001:0DB8: 0000:1234: :/48 dalam koleksi CIDR Anda dan kueri berasal dari 2001:0DB8: :/32, ini tidak akan cocok dan Route 53 akan menjawab dengan catatan untuk lokasi default (“\$1”). Anda dapat mengelompokkan kumpulan blok CIDR (atau rentang IP) ke dalam lokasi CIDR, yang pada gilirannya dikelompokkan ke dalam entitas yang dapat digunakan kembali yang disebut koleksi CIDR: **Blok CIDR** Rentang IP dalam notasi CIDR, misalnya, 192.0.2.0/24 atau 2001:: :/32. DB8 **Lokasi CIDR** Daftar bernama blok CIDR. Misalnya, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:: :/32]. DB8 Blok dalam daftar lokasi CIDR tidak harus berdekatan atau rentang yang sama. Satu lokasi dapat memiliki keduanya IPv4 dan IPv6 blok, dan lokasi ini dapat dikaitkan dengan set rekor A dan AAAA, masing-masing. Nama lokasi sering merupakan lokasi berdasarkan konvensi, tetapi dapat berupa string apa pun, misalnya, *Perusahaan-A*. **Koleksi CIDR** Koleksi lokasi bernama. Misalnya, mycollection = [example-isp-seattle, example-isp-tokyo]. Set catatan sumber daya perutean berbasis IP mereferensikan lokasi dalam sebuah koleksi, dan semua set catatan sumber daya untuk nama dan tipe set catatan yang sama harus mereferensikan koleksi yang sama. Misalnya, jika Anda membuat situs web di dua Wilayah dan ingin mengarahkan kueri DNS dari dua lokasi CIDR yang berbeda ke situs web tertentu berdasarkan alamat IP asal, maka kedua lokasi tersebut harus terdaftar dalam koleksi CIDR yang sama. Anda tidak dapat menggunakan kebijakan perutean berbasis IP untuk catatan di zona host pribadi. Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean berbasis IP untuk membuat catatan, lihat topik berikut: + [Nilai khusus untuk catatan berbasis IP](resource-record-sets-values-ipbased.md) + [Nilai khusus untuk catatan alias berbasis IP](resource-record-sets-values-ipbased-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) **Topics** + [Membuat koleksi CIDR dengan lokasi dan blok CIDR](resource-record-sets-creating-cidr-collection.md) + [Bekerja dengan lokasi dan blok CIDR](resource-record-sets-working-with-cidr-locations.md) + [Menghapus koleksi CIDR](resource-record-sets-delete-cidr-collection.md) + [Memindahkan geolokasi ke perutean berbasis IP](resource-record-sets-move-geolocation-to-cidr.md) # Membuat koleksi CIDR dengan lokasi dan blok CIDR Untuk memulai, buat koleksi CIDR dan tambahkan blok dan lokasi CIDR ke dalamnya. **Untuk membuat koleksi CIDR menggunakan konsol Route 53** 1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. **Di panel navigasi, pilih **perutean berbasis IP**, lalu koleksi CIDR.** 1. Pilih **Buat koleksi CIDR**. 1. Di panel **Buat koleksi CIDR**, di bawah **Detail**, masukkan nama untuk koleksi. 1. Pilih **Buat koleksi** untuk membuat koleksi kosong. - atau - Di bagian **Buat lokasi CIDR**, masukkan nama untuk lokasi CIDR di kotak lokasi **CIDR.** Nama lokasi dapat berupa string pengidentifikasi, misalnya**company 1**, atau**Seattle**. Tidak harus menjadi lokasi geografis yang sebenarnya. **penting** Nama lokasi CIDR memiliki panjang maksimum 16 karakter. Masukkan blok CIDR di kotak **blok CIDR** satu per baris. Ini bisa berupa IPv4 atau IPv6 alamat mulai dari /0 hingga /24 untuk IPv4 dan /0 hingga /48 untuk. IPv6 1. Setelah Anda memasukkan blok CIDR, pilih **Buat koleksi CIDR**, atau **Tambahkan lokasi lain untuk tetap memasukkan lokasi** dan blok CIDR. Anda dapat memasukkan beberapa lokasi CIDR per koleksi. 1. Setelah Anda memasukkan lokasi CIDR, pilih **Buat koleksi CIDR.** # Bekerja dengan lokasi dan blok CIDR **Untuk bekerja dengan lokasi CIDR dengan menggunakan konsol Route 53** 1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. **Di panel navigasi, pilih **perutean berbasis IP**, **koleksi CIDR** dan kemudian, di bagian **koleksi CIDR**, klik tautan ke koleksi CIDR di daftar nama Koleksi.** Pada halaman **lokasi CIDR**, Anda dapat membuat lokasi CIDR, menghapusnya, atau mengedit lokasi dan bloknya. + Untuk membuat lokasi, pilih **Buat lokasi CIDR.** + **Di panel **Buat lokasi CIDR**, masukkan nama untuk lokasi, blok CIDR yang terkait dengan lokasi, lalu pilih Buat.** + Untuk melihat lokasi CIDR dan blok di dalamnya, pilih tombol radio di sebelah lokasi untuk menampilkan nama dan blok CIDR di panel lokasi. Di panel ini, Anda juga dapat memilih **Edit** untuk memperbarui nama lokasi atau blok CIDR-nya. Pilih **Simpan** setelah Anda selesai mengedit. + Untuk menghapus lokasi CIDR dan blok di dalamnya, pilih tombol radio di sebelah lokasi yang ingin Anda hapus, lalu pilih **Hapus**. Untuk mengonfirmasi penghapusan, masukkan nama lokasi di bidang input teks dan pilih **Hapus** lagi. **penting** Menghapus lokasi CIDR tidak dapat dibatalkan. Jika Anda memiliki catatan DNS yang terkait dengan lokasi, domain Anda mungkin tidak dapat dijangkau. # Menghapus koleksi CIDR **Untuk menghapus koleksi CIDR, lokasinya, dan bloknya dengan menggunakan konsol Route 53** 1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. **Di panel navigasi, pilih **perutean berbasis IP** dan kemudian koleksi CIDR.** 1. Di bagian **koleksi CIDR**, klik nama yang ditautkan dari koleksi yang ingin Anda hapus. 1. Pada halaman **lokasi CIDR**, pilih setiap lokasi satu per satu, pilih **Hapus**, masukkan namanya di kotak dialog, lalu pilih **Hapus**. Anda harus menghapus setiap lokasi yang terkait dengan koleksi CIDR sebelum Anda dapat menghapus koleksi. 1. **Setelah penghapusan setiap lokasi CIDR selesai, pada halaman **lokasi CIDR**, pilih tombol radio di sebelah koleksi yang ingin Anda hapus, lalu pilih Hapus.** # Memindahkan geolokasi ke perutean berbasis IP Jika Anda menggunakan kebijakan perutean geolokasi atau geoproximity, dan Anda secara konsisten melihat klien tertentu dirutekan ke titik akhir yang tidak optimal berdasarkan lokasi fisik atau topologi jaringan mereka, Anda dapat menargetkan rentang IP publik klien ini dengan lebih baik dengan menggunakan IP berbasis routing. Tabel berikut berisi contoh konfigurasi geolokasi untuk perutean geolokasi yang ada yang akan kami sempurnakan untuk rentang IP California. | Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi | | --- | --- | --- | | contoh.com | Geolokasi-routing (AS) | `198.51.100.1` | | contoh.com | Perutean geolokasi (UE) | `198.51.100.2` | Untuk mengganti rentang IP dari California untuk pergi ke titik akhir aplikasi baru, pertama-tama buat ulang perutean geolokasi di bawah nama set catatan baru. | Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi | | --- | --- | --- | | geo.example.com | Geolokasi-routing (AS) | `198.51.100.1` | | geo.example.com | Perutean geoloaction (UE) | `198.51.100.2` | Kemudian, buat catatan perutean berbasis IP dan catatan default yang menunjuk ke kumpulan rekaman perutean geolokasi yang baru saja dibuat ulang. | Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi | | --- | --- | --- | | contoh.com | Perutean berbasis IP (default) | Alias merekam ke titik akhir aplikasi geo.example.com yang ingin Anda jadikan default. Misalnya, `198.51.100.1`. | | contoh.com | Perutean berbasis IP (rentang IP California) | `198.51.100.3` | # Perutean jawaban multinilai Perutean jawaban multinilai memungkinkan Anda mengonfigurasi Amazon Route 53 untuk mengembalikan beberapa nilai, seperti alamat IP untuk server web Anda, sebagai respons terhadap kueri DNS. Anda dapat menentukan beberapa nilai untuk hampir semua catatan, tetapi perutean jawaban multinilai juga memungkinkan Anda memeriksa kondisi setiap sumber daya, jadi Route 53 hanya mengembalikan nilai untuk sumber daya yang sehat. Ini bukan pengganti penyeimbang beban, tetapi kemampuan untuk mengembalikan beberapa alamat IP yang dapat diperiksa kondisinya adalah cara menggunakan DNS untuk meningkatkan ketersediaan dan penyeimbangan beban. Untuk merutekan lalu lintas secara kira-kira secara acak ke beberapa sumber daya, seperti server web, Anda membuat satu catatan jawaban multinilai untuk setiap sumber daya dan, secara opsional, mengaitkan pemeriksaan kondisi Route 53 dengan setiap catatan. Route 53 merespons kueri DNS dengan hingga delapan catatan yang sehat dan memberikan jawaban yang berbeda untuk DNS resolver yang berbeda. Jika server web menjadi tidak tersedia setelah resolver men-cache respons, perangkat lunak klien dapat mencoba alamat IP lain dalam respons. Perhatikan hal-hal berikut: + Jika Anda mengaitkan pemeriksaan kondisi dengan catatan jawaban multinilai, Route 53 merespons kueri DNS dengan alamat IP yang sesuai hanya saat pemeriksaan kondisi yang baik. + Jika Anda tidak mengaitkan pemeriksaan kondisi dengan catatan jawaban multinilai, Route 53 selalu menganggap catatan tersebut sehat. + Jika Anda memiliki delapan catatan kondisi baik atau kurang dari itu, maka Route 53 menanggapi semua kueri DNS dengan semua catatan kondisi baik. + Saat semua catatan tidak sehat, Route 53 akan merespons kueri DNS dengan hingga delapan catatan yang tidak sehat. Anda dapat menggunakan kebijakan perutean jawaban multivalue untuk catatan di zona host pribadi. Untuk informasi tentang nilai yang Anda tentukan saat Anda menggunakan kebijakan perutean jawaban multivalue untuk membuat catatan, lihat dan. [Nilai khusus untuk catatan jawaban multivalue](resource-record-sets-values-multivalue.md) [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) # Perutean tertimbang Perutean tertimbang memungkinkan Anda mengaitkan beberapa sumber daya dengan satu nama domain (example.com) atau nama subdomain (acme.example.com) dan memilih berapa banyak lalu lintas yang diarahkan ke setiap sumber daya. Ini dapat berguna untuk berbagai tujuan, termasuk penyeimbangan beban dan pengujian perangkat lunak versi baru. Untuk mengonfigurasi perutean berbobot, Anda membuat catatan yang memiliki nama dan jenis yang sama untuk setiap sumber daya Anda. Anda menetapkan setiap catatan bobot relatif yang sesuai dengan berapa banyak lalu lintas yang ingin Anda kirim ke setiap sumber daya. Amazon Route 53 mengirimkan lalu lintas ke sumber daya berdasarkan bobot yang Anda tetapkan ke catatan sebagai proporsi dari total bobot untuk semua catatan dalam grup: ![\[Rumus untuk berapa banyak lalu lintas yang dirutekan ke sumber daya yang diberikan: bobot untuk catatan tertentu/jumlah bobot untuk semua catatan.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/WRR_calculation.png) Misalnya, jika Anda ingin mengirim sebagian kecil lalu lintas ke satu sumber daya dan sisanya ke sumber daya lain, Anda dapat menentukan bobot 1 dan 255. Sumber daya dengan bobot 1 mendapat 1/256 lalu lintas (1/(1\$1255)), dan sumber daya lainnya mendapat 255/256 (255/(1\$1255)). Anda dapat secara bertahap mengubah keseimbangan dengan mengubah bobot. Jika Anda ingin berhenti mengirim lalu lintas ke sumber daya, Anda dapat mengubah berat untuk catatan tersebut ke 0. Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean berbobot untuk membuat catatan, lihat topik berikut ini: + [Nilai khusus untuk catatan tertimbang](resource-record-sets-values-weighted.md) + [Nilai khusus untuk catatan alias tertimbang](resource-record-sets-values-weighted-alias.md) + [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md) + [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md) Anda dapat menggunakan kebijakan perutean tertimbang untuk catatan di zona host pribadi. ## Pemeriksaan kesehatan dan perutean tertimbang Jika Anda menambahkan pemeriksaan kondisi ke semua catatan dalam grup catatan tertimbang, tetapi Anda memberikan bobot non-nol ke beberapa catatan dan bobot nol untuk catatan lainnya, pemeriksaan kondisi bekerja seperti ketika semua catatan memiliki bobot non-nol dengan pengecualian berikut: + Route 53 awalnya hanya mempertimbangkan catatan tertimbang non-nol, jika ada. + Jika semua catatan yang memiliki bobot lebih besar dari 0 dalam kondisi tidak sehat, Route 53 mempertimbangkan catatan tertimbang nol. Tabel berikut merinci perilaku ketika catatan 0-berat mencakup pemeriksaan kesehatan: | | Rekam 1 | Rekam 2 | Rekam 3 | | --- |--- |--- |--- | | Bobot | 1 | 1 | 0 | | Termasuk pemeriksaan kesehatan? | Ya | Ya | Ya | | | | --- | | Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | Sehat | | Kueri DNS dijawab? | Tidak | Tidak | Ya | | | | --- | | Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | Tidak sehat | | Kueri DNS dijawab? | Ya | Ya | Tidak | | | | --- | | Status pemeriksaan kondisi | Tidak sehat | Sehat | Tidak sehat | | Kueri DNS dijawab? | Tidak | Ya | Tidak | | | | --- | | Status pemeriksaan kondisi | Sehat | Sehat | Tidak sehat | | Kueri DNS dijawab? | Ya | Ya | Tidak | | | | --- | | Status pemeriksaan kondisi | Sehat | Sehat | Sehat | | Kueri DNS dijawab? | Ya | Ya | Tidak | Tabel berikut merinci perilaku ketika catatan 0-berat tidak termasuk pemeriksaan kesehatan: | | Rekam 1 | Rekam 2 | Rekam 3 | | --- |--- |--- |--- | | Bobot | 1 | 1 | 0 | | Termasuk pemeriksaan kesehatan? | Ya | Ya | Tidak | | | | --- | | Status pemeriksaan kondisi | Sehat | Sehat | N/A | | Kueri DNS dijawab? | Ya | Ya | Tidak | | | | --- | | Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | N/A | | Kueri DNS dijawab? | Tidak | Tidak | Ya | | | | --- | | Status pemeriksaan kondisi | Tidak sehat | Sehat | N/A | | Kueri DNS dijawab? | Tidak | Ya | Tidak | # Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna Untuk meningkatkan akurasi perutean geolokasi, geoproximity, berbasis IP, dan latensi, Amazon Route 53 mendukung perpanjangan. edns-client-subnet EDNS0 (EDNS0 menambahkan beberapa ekstensi opsional ke protokol DNS.) Route 53 edns-client-subnet hanya dapat digunakan ketika resolver DNS mendukungnya: + Ketika browser atau penampil lain menggunakan resolver DNS yang tidak mendukung edns-client-subnet, Route 53 menggunakan alamat IP sumber dari DNS resolver untuk memperkirakan lokasi pengguna dan merespons kueri geolokasi dengan catatan DNS untuk lokasi resolver. + Ketika browser atau penampil lain menggunakan DNS resolver yang mendukung edns-client-subnet, DNS resolver mengirimkan Route 53 versi terpotong dari alamat IP pengguna. Route 53 menentukan lokasi pengguna berdasarkan alamat IP yang terpotong daripada alamat IP sumber dari DNS resolver; ini biasanya memberikan perkiraan lokasi pengguna yang lebih akurat. Route 53 kemudian merespons kueri geolokasi dengan catatan DNS untuk lokasi pengguna. + EDNS0 tidak berlaku untuk zona host pribadi. Untuk zona yang dihosting pribadi, Rute 53 menggunakan data dari Resolver VPC di tempat zona host pribadi berada untuk membuat keputusan perutean geolokasi dan latensi. Wilayah AWS Untuk informasi selengkapnya edns-client-subnet, lihat EDNS Client Subnet RFC, Client Subnet in DNS [Requests](https://www.rfc-editor.org/rfc/rfc7871).