Estimasi dan pengoptimalan biaya DNS Armor

Dokumen ini memberikan beberapa informasi dasar tentang perkiraan biaya DNS Armor. Dokumen ini juga memberikan beberapa metode bagi Anda untuk mengoptimalkan biaya saat menggunakan DNS Armor.

Untuk mengetahui informasi harga Cloud DNS umum, lihat Harga Cloud DNS.

Informasi selengkapnya tentang harga DNS Armor dapat ditemukan di Harga deteksi ancaman tingkat lanjut.

Estimasi biaya

Anda dapat menggunakan metrik dns.googleapis.com/query/response_count yang difilter ke target_type=external dan source_type==gce-vm untuk memperkirakan biaya.

Pengoptimalan biaya

Untuk mengurangi biaya DNS Armor, Anda dapat mengonfigurasi resource berikut agar trafficnya tidak diperiksa untuk mendeteksi ancaman.

Mengecualikan Google API dan layanan Google

Secara default, kueri ke googleapis.com direkursi ke internet, yang berarti bahwa kueri ini dianggap sebagai kueri external, dan oleh karena itu termasuk dalam cakupan untuk diproses oleh DNS Armor. Untuk menghindari skenario ini, ambil traffic ini di zona pribadi Cloud DNS dan arahkan ke alamat IP virtual (VIP) internal Google. Dengan melakukannya, kueri ini akan ditandai sebagai internal dan kueri akan melewati pemeriksaan DNS Armor.

Untuk mengecualikan panggilan API dari pemrosesan DNS Armor, konfigurasi Akses Google Pribadi atau Private Service Connect untuk Google API. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Akses Google Pribadi dan Tentang mengakses Google API melalui endpoint.

Mengecualikan domain Anda sendiri

DNS Armor memperlakukan kueri dari beban kerja internal ke domain publik sebagai traffic eksternal, yang mengakibatkan pemrosesan oleh detektor ancaman. Untuk menghindarinya, pastikan domain perusahaan Anda diselesaikan secara pribadi menggunakan zona terkelola pribadi, zona peering, atau zona penerusan. Selama Cloud DNS tidak melakukan rekursi kueri ke internet, DNS Armor tidak akan memproses kueri.

Zona terkelola pribadi

Gunakan opsi ini jika Anda ingin mempertahankan salinan lengkap dan terpisah dari zona DNS internal di Cloud DNS (sering disebut DNS "split-brain" atau "split-horizon").

Misalnya, jika Anda membuat zona pribadi Cloud DNS untuk example.com dan mengisinya dengan data DNS Anda, Anda dapat melampirkan zona tersebut ke jaringan VPC Anda. Dengan pendekatan ini, saat beban kerja membuat kueri api.example.com, Cloud DNS akan memeriksa zona pribadi yang terlampir terlebih dahulu, menemukan data internal, dan langsung memberikan jawaban. Kueri tidak pernah keluar dari VPC dan diberi tag sebagai internal, yang membantu kueri menghindari pemrosesan DNS Armor.

Kebijakan respons Cloud DNS

Gunakan opsi ini jika Anda hanya perlu menyelesaikan beberapa nama host tertentu (seperti api.example.com atau db.example.com) ke alamat IP internal, tetapi Anda ingin domain Anda yang lain terus diselesaikan secara publik melalui internet.

Misalnya, Anda dapat membuat aturan kebijakan respons untuk api.example.com yang menampilkan alamat IP internal Anda dan melampirkannya ke VPC Anda. Fitur ini mencegat kueri tepercaya bervolume tinggi dan menjawabnya secara lokal. Kueri dari domain lain (seperti www.example.com) akan tetap diselesaikan secara publik dan diproses oleh DNS Armor.

Zona penerusan

Gunakan metode ini jika Anda mengoperasikan server DNS lokal (seperti Active Directory, InfoBlox, atau BIND) yang bersifat otoritatif untuk zona DNS internal Anda, dan terhubung ke Google Cloud menggunakan Cloud VPN atau Dedicated Interconnect.

Misalnya, Anda dapat membuat zona penerusan Cloud DNS untuk example.com dan mengonfigurasinya agar langsung mengarah ke alamat IP internal (biasanya alamat RFC 1918) server DNS lokal Anda. Metode ini mengirimkan kueri di seluruh jaringan pribadi ke server internal Anda. Karena tujuannya adalah alamat IP pribadi, kueri ditandai sebagai forwarding-zone dan tidak tunduk pada pemrosesan oleh DNS Armor.

Untuk mengetahui informasi selengkapnya, lihat Menggunakan zona penerusan untuk mengkueri server lokal.

Server DNS kustom di VM Compute Engine

Jika Anda menjalankan server DNS sendiri (misalnya, BIND, Active Directory, dnsmasq) di VMGoogle Cloud , penggunaan DNS Armor Anda bergantung pada topologi perutean yang Anda gunakan.

  • Penerusan Cloud DNS ke VM Anda. Kueri perusahaan yang dikirim menggunakan zona penerusan Cloud DNS ke alamat IP internal VM DNS kustom Anda akan dianggap internal dan oleh karena itu tidak akan diproses oleh DNS Armor.
  • Workload yang membuat kueri langsung ke VM Anda. Jika workload Anda dikonfigurasi untuk melewati Cloud DNS dan langsung membuat kueri VM DNS kustom Anda, Cloud DNS tidak memproses permintaan awal sehingga kueri tidak diproses oleh DNS Armor di tingkat workload.

  • VM Anda meneruskan ke Cloud DNS. Jika Anda merutekan semua traffic DNS internet perusahaan Anda melalui VM server DNS pusat, yang kemudian meneruskan ke Cloud DNS, platform hanya melihat kueri yang berasal dari satu sumber tersebut. VM membuat lingkungan bervolume rendah hingga sedang menjadi lebih murah karena DNS Armor menagih berdasarkan GREATEST(Workloads, Queries / 150) dan metode ini menurunkan dasar pengukuran Beban kerja menjadi 1.

Resolusi zona pribadi

Biaya dapat muncul dari kueri ke domain yang seharusnya diselesaikan secara internal, tetapi secara tidak sengaja bocor ke internet dan oleh karena itu diselesaikan menggunakan DNS publik dan diproses oleh DNS Armor.

Untuk mengoptimalkan biaya dalam instance ini, tangani resolusi untuk domain ini secara internal dalam VPC Anda. Anda dapat menggunakan zona pribadi atau zona penerusan Cloud DNS untuk mengarahkan kueri ini ke resolver internal Anda. Tindakan ini membantu memastikan kueri tidak lagi ditandai sebagai terikat ke internet dan oleh karena itu tidak akan diperiksa oleh DNS Armor.

Langkah berikutnya