Dieses Dokument enthält einige grundlegende Informationen zum Schätzen der Kosten für DNS Armor. Außerdem werden einige Methoden zur Optimierung der Kosten bei der Verwendung von DNS Armor beschrieben.
Allgemeine Informationen zu den Cloud DNS-Preisen finden Sie unter Cloud DNS-Preise.
Weitere Informationen zu den DNS Armor-Preisen finden Sie unter Preise für die erweiterte Bedrohungserkennung.
Kostenschätzung
Mit dem nach target_type=external und source_type==gce-vm gefilterten Messwert dns.googleapis.com/query/response_count können Sie Ihre Kosten schätzen.
Kostenoptimierung
Sie können Ihre DNS Armor-Kosten senken, indem Sie die folgenden Ressourcen so konfigurieren, dass ihr Traffic nicht auf Bedrohungen untersucht wird.
Google-APIs und ‑Dienste ausgenommen
Standardmäßig werden Abfragen an googleapis.com an das Internet weitergeleitet. Das bedeutet, dass diese Abfragen als external-Abfragen betrachtet werden und daher von DNS Armor verarbeitet werden können. Um dieses Szenario zu vermeiden, erfassen Sie diesen Traffic in einer privaten Cloud DNS-Zone und leiten Sie ihn an interne virtuelle IP-Adressen (VIPs) von Google weiter.
Dadurch werden diese Abfragen als internal gekennzeichnet und die DNS Armor-Prüfung wird umgangen.
Wenn Sie die API-Aufrufe von der DNS Armor-Verarbeitung ausschließen möchten, konfigurieren Sie den privater Google-Zugriff oder Private Service Connect für Google APIs. Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren und Über Endpunkte auf Google APIs zugreifen.
Eigene Domains ausschließen
DNS Armor behandelt Anfragen von internen Arbeitslasten an öffentliche Domains als externen Traffic, was dazu führt, dass sie vom Bedrohungsdetektor verarbeitet werden. Um dies zu vermeiden, muss die Domain Ihres Unternehmens privat aufgelöst werden. Verwenden Sie dazu verwaltete private Zonen, Peering-Zonen oder Weiterleitungszonen. Solange Cloud DNS die Abfragen nicht rekursiv an das Internet weiterleitet, werden sie nicht von DNS Armor verarbeitet.
Verwaltete private Zone
Verwenden Sie diese Option, wenn Sie eine vollständige und separate Kopie Ihrer internen DNS-Zonen in Cloud DNS verwalten möchten (oft als „Split-Brain“- oder „Split-Horizon“-DNS bezeichnet).
Wenn Sie beispielsweise eine private Cloud DNS-Zone für example.com erstellen und sie mit Ihren DNS-Einträgen füllen, können Sie die Zone an Ihr VPC-Netzwerk anhängen.
Wenn eine Arbeitslast api.example.com abfragt, prüft Cloud DNS zuerst die angehängte private Zone, findet den internen Eintrag und antwortet sofort. Die Anfrage verlässt die VPC nie und wird mit internal getaggt, wodurch die Anfrage nicht von DNS Armor verarbeitet wird.
Cloud DNS-Antwortrichtlinien
Verwenden Sie diese Option, wenn Sie nur einige bestimmte Hostnamen (z. B. api.example.com oder db.example.com) in interne IP-Adressen auflösen müssen, der Rest Ihrer Domain aber weiterhin öffentlich über das Internet aufgelöst werden soll.
Sie können beispielsweise eine Antwortrichtlinienregel für api.example.com erstellen, die Ihre interne IP-Adresse zurückgibt, und sie an Ihre VPC anhängen. Dadurch werden Ihre vertrauenswürdigen Anfragen mit hohem Volumen abgefangen und lokal beantwortet. Abfragen von anderen Domains (z. B. www.example.com) werden weiterhin öffentlich aufgelöst und von DNS Armor verarbeitet.
Weiterleitungszone
Verwenden Sie diese Methode, wenn Sie lokale DNS-Server (z. B. Active Directory, InfoBlox oder BIND) betreiben, die für Ihre internen DNS-Zonen autoritativ sind und über Cloud VPN oder Dedicated Interconnect mit Google Cloud verbunden sind.
Sie können beispielsweise eine Cloud DNS-Weiterleitungszone für example.com erstellen und so konfigurieren, dass sie direkt auf die internen IP-Adressen (in der Regel RFC 1918-Adressen) Ihrer lokalen DNS-Server verweist. Mit dieser Methode wird die Anfrage über Ihr privates Netzwerk an Ihre internen Server gesendet. Da das Ziel eine private IP-Adresse ist, wird die Anfrage mit forwarding-zone gekennzeichnet und nicht von DNS Armor verarbeitet.
Weitere Informationen finden Sie unter Weiterleitungszonen zum Abfragen lokaler Server verwenden.
Benutzerdefinierte DNS-Server auf Compute Engine-VMs
Wenn Sie Ihre eigenen DNS-Server (z.B. BIND, Active Directory, dnsmasq) aufGoogle Cloud -VMs ausführen, hängt die Verwendung von DNS Armor von der verwendeten Routingtopologie ab.
- Cloud DNS-Weiterleitung an Ihre VM: Unternehmensabfragen, die über eine Cloud DNS-Weiterleitungszone an die interne IP-Adresse der benutzerdefinierten DNS-VM gesendet werden, gelten als intern und werden daher nicht von DNS Armor verarbeitet.
- Arbeitslasten, die Ihre VM direkt abfragen: Wenn Ihre Arbeitslasten so konfiguriert sind, dass Cloud DNS umgangen und Ihre benutzerdefinierte DNS-VM direkt abgefragt wird, verarbeitet Cloud DNS die ursprüngliche Anfrage nicht. Die Abfragen werden daher nicht auf Arbeitslastebene von DNS Armor verarbeitet.
Ihre VM leitet an Cloud DNS weiter. Wenn Sie den gesamten Internet-DNS-Traffic Ihres Unternehmens über eine zentrale DNS-Server-VM weiterleiten, die dann an Cloud DNS weiterleitet, sieht die Plattform nur die Anfragen, die von dieser einzelnen Quelle stammen. Die VM macht Umgebungen mit geringem bis mittlerem Volumen kostengünstiger, da DNS Armor auf Grundlage von
GREATEST(Workloads, Queries / 150)abgerechnet wird und die Workloads-Baseline auf 1 sinkt.
Auflösung privater Zonen
Gebühren können durch Anfragen an Domains entstehen, die intern aufgelöst werden sollten, aber versehentlich ins Internet gelangen und daher über öffentliches DNS aufgelöst und von DNS Armor verarbeitet werden.
Um Ihre Kosten in diesem Fall zu optimieren, sollten Sie die Auflösung für diese Domains intern in Ihrer VPC vornehmen. Sie können entweder private Cloud DNS-Zonen oder Weiterleitungszonen verwenden, um diese Anfragen an Ihre internen Resolver weiterzuleiten. So wird sichergestellt, dass die Abfragen nicht mehr als internetgebunden gekennzeichnet sind und daher nicht von DNS Armor geprüft werden.
Nächste Schritte
- Weitere Informationen zu DNS Armor finden Sie unter Erweiterte Bedrohungserkennung.