Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik untuk Amazon Route 53
Bagian ini memberikan praktik terbaik untuk berbagai komponen Amazon Route 53, termasuk:
1. **Praktik terbaik DNS:**
+ Memahami trade-off antara nilai time to live (TTL) dan daya tanggap versus keandalan.
+ Gunakan catatan alias alih-alih catatan CNAME bila memungkinkan untuk meningkatkan kinerja dan penghematan biaya.
+ Konfigurasikan kebijakan perutean default untuk memastikan semua klien menerima respons.
+ Memanfaatkan routing berbasis latensi untuk meminimalkan latensi aplikasi dan routing untuk stabilitas dan geolocation/geoproximity prediktabilitas.
+ Verifikasi propagasi perubahan menggunakan `GetChange` API untuk alur kerja otomatis.
+ Delegasikan subdomain dari zona induk untuk perutean yang konsisten.
+ Hindari respons tunggal yang besar dengan menggunakan routing jawaban multivalue.
1. **Praktik terbaik penyelesai:**
+ Cegah perutean loop dengan menghindari mengaitkan VPC yang sama dengan aturan Resolver dan titik akhir masuknya.
+ Menerapkan aturan grup keamanan untuk mengurangi overhead pelacakan koneksi dan memaksimalkan throughput kueri.
+ Konfigurasikan titik akhir masuk dengan alamat IP di beberapa Availability Zone untuk redundansi.
+ Waspadai potensi serangan berjalan zona DNS dan hubungi AWS Support jika titik akhir Anda mengalami pelambatan.
1. **Health Check Best Practices:**
+ Ikuti rekomendasi untuk mengoptimalkan pemeriksaan kesehatan Amazon Route 53 untuk memastikan pemantauan sumber daya Anda yang andal
Dengan mengikuti praktik terbaik ini, Anda dapat mengoptimalkan kinerja, keandalan, dan keamanan infrastruktur DNS Anda, memastikan perutean lalu lintas yang efisien dan efektif ke aplikasi dan layanan Anda.
**Topics**
+ [Praktik terbaik untuk Amazon Route 53 DNS](best-practices-dns.md)
+ [Praktik terbaik untuk VPC Resolver](best-practices-resolver.md)
+ [Praktik terbaik untuk pemeriksaan kondisi Amazon Route 53](best-practices-healthchecks.md)
# Praktik terbaik untuk Amazon Route 53 DNS
Ikuti praktik terbaik ini untuk mendapatkan hasil terbaik saat menggunakan layanan DNS Amazon Route 53.
**Gunakan fungsi bidang data untuk failover DNS dan pemulihan aplikasi**
Pesawat data untuk Route 53, termasuk pemeriksaan kesehatan, dan kontrol perutean Amazon Application Recovery Controller (ARC) didistribusikan secara global, dan dirancang untuk ketersediaan dan fungsionalitas 100%, bahkan selama kejadian parah. Mereka berintegrasi satu sama lain dan tidak bergantung pada fungsionalitas bidang kontrol. Sementara pesawat kontrol untuk layanan ini, termasuk konsol mereka, umumnya sangat andal, mereka dirancang dengan cara yang lebih terpusat dan memprioritaskan daya tahan dan konsistensi daripada ketersediaan tinggi. Untuk skenario seperti failover selama pemulihan bencana, kami menyarankan Anda menggunakan fitur seperti pemeriksaan kesehatan Route 53 dan kontrol perutean ARC yang mengandalkan fungsionalitas pesawat data untuk memperbarui DNS. Untuk informasi selengkapnya, lihat [Konsep bidang kontrol dan data](route-53-concepts.md#route-53-concepts-control-and-data-plane) dan [Blog: Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/).
**Memilih nilai TTL untuk catatan DNS**
DNS TTL adalah nilai numerik (dalam detik) yang digunakan oleh penyelesai DNS untuk memutuskan berapa lama rekaman dapat di-cache tanpa membuat kueri lain ke Route 53. Semua catatan DNS harus memiliki TTL yang ditentukan untuk mereka. Rentang yang disarankan untuk nilai TTL adalah 60 hingga 172.800 detik.
Pilihan TTL adalah trade-off antara latensi dan keandalan, dan responsif terhadap perubahan. Dengan catatan yang lebih pendek TTLs , penyelesai DNS melihat pembaruan ke rekaman lebih cepat karena mereka harus lebih sering melakukan kueri. Ini meningkatkan volume kueri (dan biaya). Saat Anda memperpanjang TTL, penyelesai DNS menjawab pertanyaan dari cache lebih sering, yang biasanya lebih cepat, lebih murah, dan dalam beberapa situasi, lebih dapat diandalkan, karena menghindari kueri di internet. Tidak ada nilai yang benar, tetapi ada baiknya untuk memikirkan apakah daya tanggap atau keandalan lebih penting bagi Anda.
Hal-hal yang perlu dipertimbangkan ketika Anda menetapkan nilai TTL meliputi:
+ Tetapkan catatan DNS TTLs untuk jangka waktu yang Anda mampu menunggu perubahan diterapkan. Hal ini terutama berlaku pada delegasi (set catatan NS), atau catatan lain yang jarang berubah, misalnya catatan MX. Untuk catatan ini, lebih lama TTLs direkomendasikan. Nilai antara satu jam (3600-an) dan satu hari (86.400 detik) adalah pilihan umum.
+ Untuk catatan yang perlu diubah sebagai bagian dari mekanisme failover cepat (terutama catatan yang diperiksa kesehatan), yang lebih rendah TTLs adalah tepat. Mengatur TTL 60 atau 120 detik adalah pilihan umum untuk skenario ini.
+ Ketika Anda ingin membuat perubahan pada entri DNS kritis, kami sarankan Anda untuk sementara mempersingkat entri DNS. TTLs Kemudian Anda dapat melakukan perubahan, mengamati, dan mengembalikan dengan cepat jika perlu. Setelah perubahan diselesaikan dan berfungsi seperti yang diharapkan, Anda dapat meningkatkan TTL.
Untuk mengetahui informasi selengkapnya, lihat [TTL (detik)](resource-record-sets-values-shared.md#rrsets-values-common-ttl).
**Catatan CNAME**
Catatan DNS CNAME adalah cara untuk mengarahkan satu nama domain ke yang lain. Jika penyelesai DNS menyelesaikan domain-1.example.com dan menemukan CNAME menunjuk ke, penyelesai DNS harus melanjutkan untuk menyelesaikan sebelum dapat merespons. domain-2.example.com domain-2.example.com Catatan ini berguna dalam banyak situasi, misalnya, untuk memastikan konsistensi ketika situs web memiliki lebih dari satu nama domain.
Namun, penyelesai DNS harus membuat lebih banyak pertanyaan untuk dijawab CNAMEs, yang meningkatkan latensi dan biaya. Jika memungkinkan, alternatif yang lebih cepat dan lebih murah adalah dengan menggunakan catatan alias Route 53. Catatan alias memungkinkan Route 53 merespons dengan jawaban langsung untuk AWS sumber daya (misalnya, penyeimbang beban) dan untuk domain lain dalam zona host yang sama.
Untuk informasi selengkapnya, lihat [Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
**Perutean DNS tingkat lanjut**
+ *Saat menggunakan geolokasi, geoproximity, atau perutean berbasis latensi, selalu tetapkan default, kecuali jika Anda ingin beberapa klien tidak menerima tanggapan jawaban.*
+ Untuk meminimalkan latensi aplikasi, gunakan perutean berbasis latensi. Jenis data routing ini dapat sering berubah.
+ Untuk memberikan stabilitas dan prediktabilitas perutean, gunakan perutean geolokasi atau geoproximity.
Lihat informasi selengkapnya di [Perutean geolokasi](routing-policy-geo.md), [Perutean geoproksimitas](routing-policy-geoproximity.md), dan [Perutean berbasis latensi](routing-policy-latency.md).
**Perambatan perubahan DNS**
Saat Anda membuat atau memperbarui rekaman atau zona yang dihosting dengan menggunakan konsol atau API Route 53, perubahan akan tercermin di internet. Ini disebut *propagasi perubahan*. Sementara propagasi biasanya memakan waktu kurang dari satu menit secara global, kadang-kadang ada penundaan, misalnya, karena masalah sinkronisasi ke satu lokasi, atau dalam kasus yang jarang terjadi, masalah dalam bidang kontrol pusat. Jika Anda sedang membangun alur kerja penyediaan otomatis, dan penting untuk menunggu propagasi perubahan selesai sebelum Anda melanjutkan dengan langkah alur kerja berikutnya, gunakan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API untuk memverifikasi bahwa perubahan DNS Anda telah berlaku (). `Status =INSYNC`
**Delegasi DNS**
Saat Anda mendelegasikan beberapa level subdomain di DNS, penting untuk selalu mendelegasikan dari zona induk. Misalnya, jika Anda mendelegasikanwww.dept.example.com, Anda harus melakukannya dari dept.example.com zona, bukan dari example.com zona. Delegasi dari *kakek-nenek* ke zona *anak* mungkin tidak berfungsi sama sekali atau hanya bekerja secara tidak konsisten. Untuk informasi selengkapnya, lihat [Merutekan lalu lintas untuk subdomain](dns-routing-traffic-for-subdomains.md).
**Ukuran respons DNS**
Hindari membuat respons tunggal yang besar. Jika respons lebih besar dari 512 byte, banyak penyelesai DNS harus mencoba lagi melalui TCP alih-alih UDP, yang dapat mengurangi keandalan dan menyebabkan respons yang lebih lambat. Sebaiknya gunakan routing jawaban multivalue, yang memilih delapan alamat IP acak yang sehat untuk menjaga respons dalam batas 512 byte.
Untuk informasi selengkapnya, lihat [Perutean jawaban multinilai](routing-policy-multivalue.md) dan [Server Uji Ukuran Balas DNS](https://www.dns-oarc.net/oarc/services/replysizetest/).
# Praktik terbaik untuk VPC Resolver
Bagian ini memberikan praktik terbaik untuk mengoptimalkan Amazon Route 53 VPC Resolver, yang mencakup topik-topik berikut:
1. **Menghindari Konfigurasi Loop dengan Titik Akhir Resolver:**
+ Cegah perutean loop dengan memastikan bahwa VPC yang sama tidak terkait dengan aturan Resolver dan titik akhir masuknya.
+ Gunakan AWS RAM untuk berbagi VPCs di seluruh akun sambil mempertahankan konfigurasi perutean yang tepat.
Untuk informasi selengkapnya, lihat [Hindari konfigurasi loop dengan titik akhir Resolver](best-practices-resolver-endpoints.md)
1. **Titik akhir Resolver Penskalaan:**
+ Menerapkan aturan grup keamanan yang mengizinkan lalu lintas berdasarkan status koneksi untuk mengurangi overhead pelacakan koneksi
+ Ikuti aturan grup keamanan yang disarankan untuk titik akhir Resolver masuk dan keluar untuk memaksimalkan throughput kueri.
+ Pantau alamat IP unik dan kombinasi port yang menghasilkan lalu lintas DNS untuk menghindari keterbatasan kapasitas.
Untuk informasi selengkapnya, lihat [Penskalaan titik akhir penyelesai](best-practices-resolver-endpoint-scaling.md)
1. **Ketersediaan tinggi untuk titik akhir Resolver:**
+ Buat titik akhir masuk dengan alamat IP di setidaknya dua Availability Zone untuk redundansi.
+ Menyediakan antarmuka jaringan tambahan untuk memastikan ketersediaan selama pemeliharaan atau lonjakan lalu lintas
Untuk informasi selengkapnya, lihat [Ketersediaan tinggi untuk titik akhir Resolver](best-practices-resolver-endpoint-high-availability.md)
1. **Mencegah serangan berjalan zona DNS:**
+ Waspadai potensi serangan berjalan zona DNS, di mana penyerang mencoba mengambil semua konten dari zona DNS yang ditandatangani DNSSEC.
+ Jika titik akhir Anda mengalami pelambatan karena dicurigai berjalan di zona, hubungi AWS Support untuk bantuan.
Untuk informasi selengkapnya, lihat [Zona DNS berjalan](best-practices-resolver-zone-walking.md)
Dengan mengikuti praktik terbaik ini, Anda dapat mengoptimalkan kinerja, skalabilitas, dan keamanan penerapan Resolver VPC Anda, memastikan resolusi DNS yang andal dan efisien untuk aplikasi dan sumber daya Anda.
# Hindari konfigurasi loop dengan titik akhir Resolver
Jangan mengaitkan VPC yang sama ke aturan Resolver dan titik akhir masuknya (apakah itu target langsung titik akhir, atau melalui server DNS on-premise). Ketika titik akhir keluar dalam aturan Resolver menunjuk ke titik akhir masuk yang berbagi VPC dengan aturan, hal ini dapat menyebabkan loop di mana kueri terus diteruskan di antara titik akhir masuk dan keluar.
Aturan penerusan masih dapat dikaitkan dengan lainnya VPCs yang dibagikan dengan akun lain dengan menggunakan AWS Resource Access Manager ()AWS RAM. Zona yang di-hosting secara privat yang terkait dengan hub, atau VPC sentral, masih akan menyelesaikan dari kueri ke titik akhir masuk, karena aturan penyelesai penerusan tidak mengubah resolusi ini.
# Penskalaan titik akhir penyelesai
Grup keamanan titik akhir penyelesai menggunakan pelacakan koneksi untuk mengumpulkan informasi tentang lalu lintas ke dan dari titik akhir. Setiap antarmuka titik akhir memiliki jumlah maksimum koneksi yang dapat dilacak, dan volume kueri DNS yang tinggi dapat melebihi koneksi serta menyebabkan throttling dan kehilangan kueri. Pelacakan koneksi AWS adalah perilaku default untuk memantau keadaan lalu lintas yang mengalir melalui grup keamanan (SGs). Menggunakan pelacakan koneksi SGs akan mengurangi throughput lalu lintas, namun, Anda dapat menerapkan koneksi yang tidak dilacak untuk mengurangi overhead dan meningkatkan kinerja. Untuk informasi selengkapnya lihat Koneksi [yang tidak dilacak](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).
Jika pelacakan koneksi diberlakukan baik dengan menggunakan aturan grup keamanan yang membatasi atau kueri dirutekan melalui Network Load Balancer (lihat [Koneksi yang dilacak secara otomatis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), kueri maksimum keseluruhan per detik per alamat IP untuk titik akhir bisa serendah 1500.
**Rekomendasi aturan Grup Keamanan masuk dan keluar untuk titik akhir Resolver masuk**
****
|
|
| **Aturan masuk** |
| --- |
| Jenis protokol | Nomor port | Sumber IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **Aturan jalan keluar** |
| --- |
| Jenis protokol | Nomor port | IP Tujuan |
| TCP | Semua | 0.0.0.0/0 |
| UDP | Semua | 0.0.0.0/0 |
**Rekomendasi aturan grup keamanan masuk dan keluar untuk titik akhir Resolver keluar**
****
|
|
| **Aturan masuk** |
| --- |
| Jenis protokol | Nomor port | Sumber IP |
| TCP | Semua | 0.0.0.0/0 |
| UDP | Semua | 0.0.0.0/0 |
| **Aturan jalan keluar** |
| --- |
| Jenis protokol | Nomor port | IP Tujuan |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**catatan**
**Persyaratan port grup keamanan:**
**Endpoint inbound** memerlukan aturan ingress yang memungkinkan TCP dan UDP pada port 53 untuk menerima kueri DNS dari jaringan Anda. Aturan keluar dapat mengizinkan semua port karena titik akhir mungkin perlu menanggapi kueri dari berbagai port sumber.
**Titik akhir keluar** memerlukan aturan keluar yang memungkinkan akses TCP dan UDP ke port yang Anda gunakan untuk kueri DNS di jaringan Anda. Port 53 ditunjukkan pada contoh di atas karena ini adalah port DNS yang paling umum, tetapi jaringan Anda mungkin menggunakan port yang berbeda. Aturan Ingress dapat memungkinkan semua port untuk mengakomodasi respons dari server DNS Anda.
**Titik akhir Inbound Resolver**
Untuk klien yang menggunakan titik akhir Resolver masuk, kapasitas antarmuka jaringan elastis akan terpengaruh jika Anda memiliki lebih dari 40.000 alamat IP unik dan port kombinasi yang menghasilkan lalu lintas DNS.
# Ketersediaan tinggi untuk titik akhir Resolver
Saat Anda membuat titik akhir masuk VPC Resolver, Route 53 mengharuskan Anda membuat setidaknya dua alamat IP yang akan diteruskan kueri oleh resolver DNS di jaringan Anda. Anda juga harus menentukan alamat IP di setidaknya dua Availability Zone untuk redundansi.
Jika memerlukan lebih dari satu titik akhir antarmuka jaringan elastis agar tersedia setiap saat, kami sarankan Anda menambahkan setidaknya satu antarmuka jaringan melebihi kebutuhan, untuk memastikan Anda memiliki kapasitas tambahan yang tersedia untuk menangani kemungkinan lonjakan lalu lintas. Antarmuka jaringan tambahan juga memastikan ketersediaan selama operasi layanan seperti pemeliharaan atau peningkatan.
Untuk informasi lebih lanjut, lihat artikel blog terperinci ini: [Cara mencapai ketersediaan tinggi DNS dengan titik akhir Resolver](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) dan. [Nilai yang Anda tentukan ketika membuat atau mengedit titik akhir masuk](resolver-forwarding-inbound-queries-values.md)
# Zona DNS berjalan
Serangan zona DNS berjalan mencoba untuk mendapatkan semua konten dari zona DNS yang ditandatangani DNSSEC. Jika tim VPC Resolver mendeteksi pola lalu lintas yang cocok dengan yang dihasilkan saat zona DNS berjalan di titik akhir Anda, tim layanan akan membatasi lalu lintas di titik akhir Anda. Sebagai konsekuensinya, Anda mungkin melihat persentase tinggi pada batas waktu kueri DNS.
Jika Anda mengamati pengurangan kapasitas pada titik akhir Anda dan yakin bahwa titik akhir telah dibatasi secara keliru, pergilah ke https://console.aws.amazon.com/support/ rumah\$1/ untuk membuat kasus dukungan.
# Praktik terbaik untuk pemeriksaan kondisi Amazon Route 53
Konfigurasi pemeriksaan kesehatan yang efektif sangat penting untuk menjaga infrastruktur yang sangat tersedia dan tangguh. Berikut adalah beberapa praktik terbaik yang perlu dipertimbangkan saat menyiapkan dan mengelola pemeriksaan kesehatan Amazon Route 53:
1. **Gunakan alamat IP elastis untuk titik akhir pemeriksaan kesehatan:**
+ Gunakan alamat IP elastis untuk titik akhir pemeriksaan kesehatan Anda untuk memastikan pemantauan yang konsisten.
+ Jika Anda tidak lagi menggunakan instans Amazon EC2, ingatlah untuk menghapus pemeriksaan kesehatan terkait untuk menghindari potensi risiko keamanan atau kompromi data.
Untuk informasi lebih lanjut, lihat[Nilai yang Anda tentukan saat membuat atau memperbarui pemeriksaan kondisi](health-checks-creating-values.md).
1. **Konfigurasikan interval pemeriksaan kesehatan yang sesuai:**
+ Tetapkan interval pemeriksaan kesehatan berdasarkan persyaratan aplikasi Anda dan kekritisan sumber daya yang dipantau.
+ Interval yang lebih pendek memberikan deteksi kegagalan yang lebih cepat tetapi dapat meningkatkan biaya Route 53 dan memuat sumber daya Anda.
+ Interval yang lebih lama mengurangi biaya dan beban sumber daya tetapi dapat menunda deteksi kegagalan.
Untuk informasi lebih lanjut, lihat[Konfigurasi lanjutan ("Pantau Titik Akhir" saja)](health-checks-creating-values.md#health-checks-creating-values-advanced).
1. **Menerapkan pemberitahuan alarm:**
+ Konfigurasikan Amazon CloudWatchalarms untuk menerima pemberitahuan saat pemeriksaan kesehatan gagal atau pulih.
+ Tetapkan ambang alarm yang sesuai berdasarkan persyaratan aplikasi Anda dan perilaku sumber daya yang diharapkan.
+ Integrasikan notifikasi dengan proses pemantauan dan respons insiden Anda.
Untuk informasi lebih lanjut, lihat[Memantau pemeriksaan kesehatan menggunakan CloudWatch](monitoring-health-checks.md).
1. **Memanfaatkan pemeriksaan kesehatan Daerah secara strategis:**
+ Pilih pemeriksaan kesehatan Wilayah berdasarkan distribusi geografis pengguna dan sumber daya Anda.
+ Pertimbangkan untuk menggunakan beberapa wilayah pemeriksaan kesehatan untuk sumber daya penting guna meningkatkan keandalan dan mengurangi dampak pemadaman regional.
1. **Pantau log dan metrik pemeriksaan kesehatan:**
+ Tinjau log dan CloudWatch metrik pemeriksaan kesehatan Route 53 secara teratur untuk mengidentifikasi potensi masalah atau kemacetan kinerja
+ Menganalisis alasan kegagalan pemeriksaan kesehatan dan mengambil tindakan yang tepat untuk menyelesaikan masalah yang mendasarinya.
1. **Menerapkan Strategi Failover dan Failback:**
+ Manfaatkan kebijakan routing failover Route 53 untuk secara otomatis merutekan lalu lintas ke sumber daya yang sehat jika terjadi kegagalan.
+ Merencanakan dan menguji proses failover dan failback untuk memastikan transisi yang mulus selama pemadaman dan pemulihan.
Untuk informasi lebih lanjut, lihat[Mengonfigurasi failover DNS](dns-failover-configuring.md).
1. **Tinjau dan Perbarui Pemeriksaan Kesehatan Secara Teratur:**
+ Perbarui titik akhir pemeriksaan kesehatan, interval, dan ambang alarm sesuai kebutuhan untuk mempertahankan pemantauan dan kinerja yang optimal.
Dengan mengikuti praktik terbaik ini, Anda dapat secara efektif memanfaatkan pemeriksaan kesehatan Amazon Route 53 untuk memantau kesehatan dan ketersediaan sumber daya kami, memastikan infrastruktur yang andal dan berkinerja tinggi untuk aplikasi dan layanan Anda.