Estimation et optimisation des coûts de DNS Armor

Ce document fournit des informations de base sur l'estimation des coûts de DNS Armor. Il fournit également des méthodes pour optimiser vos coûts lorsque vous utilisez DNS Armor.

Pour obtenir des informations générales sur les tarifs de Cloud DNS, consultez Tarifs de Cloud DNS.

Pour en savoir plus sur les tarifs de DNS Armor, consultez Tarifs de la détection avancée des menaces.

Estimation des coûts

Vous pouvez utiliser la métrique dns.googleapis.com/query/response_count filtrée sur target_type=external et source_type==gce-vm pour estimer vos coûts.

Optimisation des coûts

Pour réduire vos coûts DNS Armor, vous pouvez configurer les ressources suivantes afin d'exclure leur trafic de l'inspection des menaces.

Exclusion des API et services Google

Par défaut, les requêtes adressées à googleapis.com sont récursives sur Internet, ce qui signifie qu'elles sont considérées comme des requêtes external et sont donc incluses dans le champ d'application de DNS Armor. Pour éviter ce scénario, capturez ce trafic dans une zone privée Cloud DNS et routez-le vers les adresses IP virtuelles (VIP) internes de Google. Cela les marquera comme internal et elles ne seront pas inspectées par DNS Armor.

Pour exclure les appels d'API du traitement DNS Armor, configurez l'accès privé à Google ou Private Service Connect pour les API Google. Pour en savoir plus, consultez Configurer l'accès privé à Google et À propos de l'accès aux API Google via des points de terminaison.

Exclure vos propres domaines

DNS Armor traite les requêtes des charges de travail internes vers les domaines publics comme du trafic externe, ce qui entraîne leur traitement par le détecteur de menaces. Pour éviter cela, assurez-vous que le domaine de votre entreprise est résolu de manière privée à l'aide de zones privées gérées, de zones d'appairage ou de zones de transfert. Tant que Cloud DNS n'effectue pas de récursivité des requêtes vers Internet, DNS Armor ne les traite pas.

Zone privée gérée

Utilisez cette option si vous souhaitez conserver une copie complète et distincte de vos zones DNS internes dans Cloud DNS (souvent appelées DNS "split-brain" ou "split-horizon").

Par exemple, si vous créez une zone privée Cloud DNS pour example.com et que vous la remplissez avec vos enregistrements DNS, vous pouvez ensuite associer la zone à votre réseau VPC. Cette approche signifie que lorsqu'une charge de travail interroge api.example.com, Cloud DNS vérifie d'abord la zone privée associée, trouve l'enregistrement interne et répond immédiatement. La requête ne quitte jamais le VPC et est taguée comme internal, ce qui l'aide à éviter le traitement DNS Armor.

Règles de réponse Cloud DNS

Utilisez cette option si vous n'avez besoin de résoudre que quelques noms d'hôte spécifiques (tels que api.example.com ou db.example.com) en adresses IP internes, mais que vous souhaitez que le reste de votre domaine continue à être résolu publiquement sur Internet.

Par exemple, vous pouvez créer une règle de stratégie de réponse pour api.example.com qui renvoie votre adresse IP interne et l'associe à votre VPC. Il intercepte vos requêtes fiables à fort volume et y répond localement. Les requêtes provenant d'autres domaines (comme www.example.com) seront toujours résolues publiquement et traitées par DNS Armor.

Zone de transfert

Utilisez cette méthode si vous exploitez des serveurs DNS sur site (tels qu'Active Directory, InfoBlox ou BIND) qui font autorité pour vos zones DNS internes et qui sont connectés à Google Cloud à l'aide de Cloud VPN ou d'une interconnexion dédiée.

Par exemple, vous pouvez créer une zone de transfert Cloud DNS pour example.com et la configurer pour qu'elle pointe directement vers les adresses IP internes (généralement des adresses RFC 1918) de vos serveurs DNS sur site. Cette méthode envoie la requête sur votre réseau privé à vos serveurs internes. Comme la destination est une adresse IP privée, la requête est taguée comme forwarding-zone et n'est pas traitée par DNS Armor.

Pour en savoir plus, consultez Utiliser les zones de transfert pour interroger les serveurs sur site.

Serveurs DNS personnalisés sur les VM Compute Engine

Si vous exécutez vos propres serveurs DNS (par exemple, BIND, Active Directory, dnsmasq) sur des VMGoogle Cloud , votre utilisation de DNS Armor dépend de la topologie de routage que vous utilisez.

  • Transfert Cloud DNS vers votre VM. Les requêtes d'entreprise envoyées à l'aide d'une zone de transfert Cloud DNS à l'adresse IP interne de votre VM DNS personnalisée seront considérées comme internes et ne seront donc pas traitées par DNS Armor.
  • Charges de travail interrogeant directement votre VM Si vos charges de travail sont configurées pour contourner Cloud DNS et interroger directement votre VM DNS personnalisée, Cloud DNS ne traite pas la requête initiale. Les requêtes ne sont donc pas traitées par DNS Armor au niveau de la charge de travail.

  • Votre VM est transférée vers Cloud DNS. Si vous acheminez tout le trafic DNS Internet de votre entreprise via une VM de serveur DNS central, qui est ensuite transféré vers Cloud DNS, la plate-forme ne voit que les requêtes provenant de cette source unique. La VM rend les environnements à volume faible à moyen moins coûteux, car DNS Armor facture en fonction de GREATEST(Workloads, Queries / 150). Cette méthode ramène la référence des charges de travail à 1.

Résolution des zones privées

Des frais peuvent être facturés pour les requêtes adressées à des domaines qui devraient être résolus en interne, mais qui sont divulgués par inadvertance sur Internet et sont donc résolus à l'aide du DNS public et traités par DNS Armor.

Pour optimiser vos coûts dans ce cas, gérez la résolution de ces domaines en interne dans votre VPC. Vous pouvez utiliser des zones privées ou des zones de transfert Cloud DNS pour rediriger ces requêtes vers vos résolveurs internes. Cela permet de s'assurer que les requêtes ne sont plus marquées comme liées à Internet et ne seront donc pas inspectées par DNS Armor.

Étapes suivantes