Every SAP-C02 candidate knows the two-line version of hybrid DNS: an inbound Resolver endpoint lets on-premises resolvers reach your private hosted zones, and an outbound endpoint plus a forwarding rule lets your VPC resolve on-premises names. Our hybrid and edge guide covers that direction table, and the SAP-C02 networking deep dive places it next to Direct Connect and Transit Gateway.
The exam, however, increasingly asks about the layer underneath. Which rule wins when a private hosted zone and a forwarding rule claim the same name? Why does a forwarding rule for . suddenly make EC2 hostnames slow? How do you give 40 accounts the same DNS configuration without 40 copies of it? What breaks when the on-premises resolver is told to forward to the VPC+2 address instead of an endpoint? Where does DNSSEC live, and which half of it is per hosted zone versus per VPC?
This guide is a practitioner’s walk through that layer, written for the AWS Certified Solutions Architect - Professional exam and verified against the current Route 53 documentation. It assumes you already know what a private hosted zone is and focuses on the rules, precedence, quotas and newer features (delegation rules, Route 53 Profiles, DoH endpoints) that turn into distractors.
Naming note. In late 2025 AWS launched Route 53 Global Resolver, an anycast resolver for clients outside your VPCs, and renamed the original service to Route 53 VPC Resolver. The SAP-C02 exam guide still says “Route 53 Resolver”. This article uses both names interchangeably; everything below is about the VPC-side service.
How the VPC Resolver Actually Answers a Query
Every VPC gets a resolver at the VPC CIDR + 2 address (10.0.0.2 for 10.0.0.0/16), also reachable at 169.254.169.253 and, for IPv6, fd00:ec2::253. Two details about its implementation show up in scenario questions.
First, it is not a server you can route to. The current docs describe two components: a Nitro Resolver service that runs on the Nitro card of each instance and consumes packets addressed to the VPC+2 locally, and a Zonal Resolver fleet in the same Availability Zone that does the recursive work. Queries between the two travel over a network outside your VPC. That is why the docs state flatly that forwarding private DNS queries to any VPC CIDR+2 address from on-premises or other VPC DNS servers is not supported and “can cause unstable results”. The exam answer to “on-prem servers must resolve names in our private hosted zone” is always an inbound endpoint, never “point the on-prem forwarder at 10.0.0.2 over the VPN”.
Second, the resolver is a link-local service that scales per network interface. Each ENI allows 1,024 packets per second to link-local services (Resolver, the time service, IMDS and Windows licensing combined); packets beyond that are rejected and show up as linklocal_allowance_exceeded in ethtool output. There is no per-VPC aggregate limit, so an instance hammering DNS is throttled per ENI, not per VPC. A scenario about “DNS timeouts on a single busy instance” is this limit, not an endpoint quota.
The resolver answers three things natively: public names (recursively, from Zonal Resolver fleet public IPs, with no EDNS Client Subnet), VPC-specific names such as ip-10-0-1-5.eu-west-1.compute.internal, and records in private hosted zones associated with the VPC. Everything else is governed by rules and endpoints.
Inbound and Outbound Endpoints: The ENI Layer
An endpoint is a set of elastic network interfaces in subnets you choose. For each combination of Availability Zone, subnet and IP address you specify, Resolver creates one ENI with a private IP that never changes for the life of the endpoint. The IPs are private, so each endpoint needs a private path to the other side: Direct Connect, Site-to-Site VPN, VPC peering, Transit Gateway or, for outbound queries, a NAT gateway.
| Inbound endpoint | Outbound endpoint | |
|---|---|---|
| Direction | Your network → VPC Resolver | VPC Resolver → your network |
| What it holds | Target IPs for on-premises conditional forwarders | Source IPs that forwarded queries originate from |
| Needs rules? | No, it answers whatever the VPC’s resolver can answer (private hosted zones, rules associated with that VPC, public names) | Yes, forward or delegate rules select which domains leave the VPC |
| Minimum IPs | 2 (docs: “a minimum of two IP addresses for redundancy”, in at least two AZs recommended) | 2 |
| Maximum IPs | 6 per endpoint (adjustable quota) | 6 per endpoint (adjustable quota) |
| Protocols | Do53, DoH, DoH-FIPS (FIPS inbound only) | Do53, DoH toward your resolvers |
| Categories | Default (forward to IPs) or Delegation (NS glue for a subdomain) | Standard; delegation is expressed with DELEGATE rules |
| Reuse | One inbound endpoint serves many on-premises sites | One outbound endpoint can be used by rules for many VPCs in the same Region |
| Security group | Must allow inbound TCP and UDP 53 (plus 443 for DoH); cannot be changed after creation | Outbound to your resolvers on 53 (443 for DoH) |
Five endpoint facts carry exam weight.
Capacity is per IP address. Each IP in an endpoint handles up to 10,000 UDP queries per second, and the docs explicitly say actual throughput varies with response size, target health and latency. If any ENI runs above 50 percent of capacity, add more IPs. Resolver also sends redundant outbound queries for each request it receives, so the QPS per outbound ENI never matches the QPS clients sent.
Connection tracking can cut that to 1,500. Security group rules that force connection tracking, or queries that arrive through a Network Load Balancer, drop the inbound maximum to as low as 1,500 QPS per IP. The fix in the docs is untracked connections: allow 0.0.0.0/0 (or ::/0) in both directions for the DNS ports so the rule is not stateful. A “we front the inbound endpoint with an NLB for a static IP” design is therefore a throughput trap, and unnecessary anyway because endpoint IPs are already static.
Endpoints are Regional and VPC-owned. Only the VPC owner can create them, you cannot create them in a VPC with dedicated instance tenancy, and an outbound endpoint in one Region cannot be used by rules in another. Multi-Region designs need endpoints per Region.
Target selection is random with retry. For a forwarding rule with several target IPs, Resolver “chooses a target IP at random” with no preference, and retries a different random target if one does not answer. If none of the targets are reachable, resolution times for all queries matching that rule stretch out. Keep target lists reachable from the endpoint subnets.
Protocol changes are staged. You cannot flip an inbound endpoint from Do53-only straight to DoH-only; you must enable both first, migrate clients, then remove Do53. DoH on outbound endpoints needs the target’s IP address plus a ServerNameIndication value, because the endpoint cannot resolve the DoH resolver’s hostname before it can talk to it.
Centralized DNS: the pattern the exam expects
Because an inbound endpoint answers for its VPC’s resolver, and that resolver sees every private hosted zone and rule associated with the VPC, the standard multi-account design is one shared-services “DNS VPC” holding one inbound and one outbound endpoint, reachable from everything through Transit Gateway. Private hosted zones from every account are associated with that VPC (or delivered through a Profile), forwarding rules are created once and shared with AWS RAM, and on-premises forwarders have a single pair of inbound IPs to point at. Four endpoints per Region per account is the default quota, so “one endpoint pair per account” designs also hit limits that the central pattern avoids.
Rule Types: Forward, System and Delegate
An outbound endpoint does nothing until rules say which domains to send through it. Rules are Regional, associated with VPCs (up to 2,000 rule-to-VPC associations per Region per account, 1,000 rules), and shareable with RAM.
| Rule type | What it does | Needs an outbound endpoint? | Typical cue |
|---|---|---|---|
Forward (FORWARD) | Sends queries for a domain and all its subdomains to up to 6 target IPs on your network | Yes | ”resolve corp.internal against the on-prem DNS servers” |
System (SYSTEM) | Carves an exception out of a broader forwarding rule so Resolver answers that subdomain itself | No | ”forward everything except aws.corp.internal” |
Delegate (DELEGATE) | Honors NS delegation: when a response contains NS records matching the delegation record, Resolver follows them through the outbound endpoint | Yes | ”the sub-zone is authoritative on-prem and the private hosted zone delegates to it with NS records” |
Recursive (autodefined .) | The built-in catch-all; Resolver acts as a recursive resolver for anything no other rule claims | No | Cannot be created by you, only overridden |
Matching and precedence
A rule matches a query when the names are identical or the query name is a subdomain of the rule’s domain. The docs’ example: a rule for acme.example.com matches acme.example.com and zenith.acme.example.com, but not example.com or nadir.example.com. When several rules match, the most specific domain name wins. That single sentence resolves most rule-ordering questions: there is no priority field, no creation-order tie-break, just specificity.
Three precedence facts sit on top of that.
- A Resolver forwarding rule beats a private hosted zone with the same name. The docs state it directly: with a private hosted zone
example.comand a forwarding rule forexample.comboth associated with the VPC, “the VPC Resolver rule takes precedence” and queries are forwarded instead of answered from the zone. A scenario where “records in the private hosted zone stopped resolving after the network team added a forwarding rule” is this. Fix it with a more specific rule or by narrowing the forwarding rule. - Overlapping private hosted zones resolve by most specific match, and a matching zone without a matching record returns NXDOMAIN. If
accounting.example.comandexample.comare both associated, a query forseattle.accounting.example.comis answered only fromaccounting.example.com; if that zone lacks the record, Resolver returns NXDOMAIN rather than falling through to the parent zone or the public internet. The same NXDOMAIN rule applies between a private zone and the public zone of the same name, which is how split-view DNS leaks happen. - Profile-level and VPC-level settings follow the same specificity rule, with the local VPC winning exact ties. More on that below.
The forward-everything trap and system rules
A forwarding rule for . or for com is legal and sometimes required (“all DNS must go through the on-premises security stack”). The documented side effect is that EC2 hostnames, private hosted zones and amazonaws.com names would also be forwarded, except that Resolver protects itself with autodefined rules (next section). The docs still recommend that anyone who creates a . or com forwarding rule also create a system rule for amazonaws.com: it keeps service endpoint resolution local, “reduces the number of queries that are forwarded to your network, and reduces VPC Resolver charges”. A system rule is also the answer to “forward corp.example.com on-prem but let AWS resolve aws.corp.example.com from a private hosted zone”.
Delegation rules (June 2025)
Before mid-2025 the only way to make a VPC resolve an on-premises sub-zone was a forwarding rule naming it. Since June 2025, private hosted zones can contain NS records that delegate a subdomain, and Resolver can honor that delegation in both directions:
- Outbound delegation. You create a rule with
--rule-type DELEGATEand a--delegation-recordsuch ashr.example.com, tied to an outbound endpoint. When a response for a name underhr.example.comcontains NS records that match the delegation record, Resolver follows them through the endpoint to the name servers they point at. The docs distinguish this from forwarding: a forward rule redirects on name match, whereas a delegate rule “only activates when the authoritative name servers in the response match the delegation configuration”. The tutorial shows both in-zone delegation (glue A records in the private hosted zone) and out-of-zone delegation, where the NS target lives in a different domain and therefore still needs a forward rule so Resolver can look up the name server’s address. - Inbound delegation. An inbound endpoint created with the Delegation category delegates authority for a subdomain to VPC Resolver. On the on-premises server you create NS records for, say,
aws.example.compointing at the endpoint’s IPs as glue, and Resolver answers from the associated private hosted zone. Delegation inbound endpoints support Do53 only.
The exam framing to watch for: “the DNS team wants standard NS delegation rather than conditional forwarders, and sub-zones are added frequently”. Delegation rules remove the need to create a forwarding rule per sub-zone.
Autodefined Rules: What Resolver Protects Automatically
When you set enableDnsHostnames to true on a VPC, Resolver creates a set of autodefined system rules and associates them with the VPC, even if you never create an endpoint. They exist so that a sweeping forwarding rule cannot break EC2 and private hosted zone resolution, and so that RFC 6303 locally served zones never leak to the internet.
| Group | Examples | Notes |
|---|---|---|
| Private hosted zones | One Forward rule per private hosted zone association | Created for each VPC the zone is associated with |
| EC2 internal names | eu-west-1.compute.internal, eu-west-1.compute.amazonaws.com; ec2.internal, compute-1.internal, compute-1.amazonaws.com in us-east-1 | Region-specific; us-east-1 uses the legacy names |
| Reverse lookups | 10.in-addr.arpa, 16.172.in-addr.arpa through 31.172.in-addr.arpa, 168.192.in-addr.arpa, 254.169.254.169.in-addr.arpa, plus one rule per VPC CIDR (0.0.10.in-addr.arpa, 1.0.10.in-addr.arpa for a /23) | Some reverse rules can be disabled |
| localhost family | localhost, localdomain, 127.in-addr.arpa, the two IPv6 loopback ip6.arpa names | RFC 6303 |
| Peering / Transit Gateway | Reverse zones for the peer VPC’s CIDRs, and the peer Region’s compute.internal names when DNS support is enabled on the attachment | Added automatically when CIDRs are added |
| Everything else | The . rule of type Recursive | The catch-all |
Two exam rules follow. You override an autodefined rule by creating your own forwarding rule for the same domain name; the explicit rule wins. And the reverse-lookup autodefined rules are why PTR queries for RFC 1918 space never reach your on-premises DNS unless you create a forwarding rule for the relevant in-addr.arpa zone, which is the fix for “reverse lookups of on-premises IPs fail from EC2”.
Cross-Account Building Blocks: RAM, Association Authorizations and Profiles
SAP-C02 Domain 1 lives in multi-account land, and hybrid DNS has three different sharing mechanisms that look alike in a question stem. Our multi-account architecture guide covers RAM itself; this is what RAM does for DNS specifically.
| Need | Mechanism | How it works |
|---|---|---|
| Other accounts’ VPCs use my forwarding rules | AWS RAM shares the Resolver rule | Recipients associate the rule with their own VPCs; queries still exit through the owner’s outbound endpoint. Recipients cannot edit or delete the rule |
| Other accounts’ VPCs use my DNS Firewall rule groups | AWS RAM shares the rule group | Same model; or let Firewall Manager push associations organization-wide |
| Other accounts’ VPCs use my query-logging configuration | AWS RAM shares the configuration | Shared associations count against the recipient’s 100-per-Region quota |
| Another account’s VPC resolves my private hosted zone | VPC association authorization | Zone owner runs create-vpc-association-authorization for the specific VPC; VPC owner runs associate-vpc-with-hosted-zone; owner then deletes the authorization. CLI/API/SDK only, the console cannot do either step. One authorization per VPC, 1,000 pending authorizations per zone, 300 VPC associations per zone |
| Dozens of VPCs need the same bundle of zones, rules, firewall rule groups and settings | Route 53 Profiles | Build the bundle once, associate the Profile with each VPC, share the Profile with RAM |
The association-authorization dance is a classic distractor: “the console shows no option to associate the VPC” is expected behaviour, not a permissions problem. The authorization is also per hosted zone ID, so the zone must exist before you authorize, and the recommended cleanup step (delete the authorization after associating) does not break the association.
Private hosted zones can be associated with VPCs in any Region, which is why a single zone can serve a global footprint while Resolver endpoints and rules remain Regional.
Route 53 Profiles
Profiles are the newest answer to “manage DNS consistently across many VPCs and accounts”. A Profile can carry:
- private hosted zones (and their settings),
- Resolver rules, both forwarding and system,
- DNS Firewall rule groups,
- interface VPC endpoints (for private DNS names),
- Resolver query logging configurations,
plus three VPC-level settings managed on the Profile: reverse DNS lookup for Resolver rules, DNS Firewall failure mode, and DNSSEC validation. You can, for example, force fail-open DNS Firewall on every associated VPC while leaving each VPC’s existing DNSSEC validation setting alone.
The rules that make exam questions:
- One Profile per VPC, up to 5 Profiles per account per Region, up to 1,000 VPCs per Profile, 5,000 private hosted zones and 1,000 Resolver rules per Profile, 5 DNS Firewall rule groups and 2 query-logging configurations per Profile.
- Profiles are shared with RAM to accounts in the same Regions; updates propagate to every associated VPC immediately.
- Precedence: local VPC settings win exact ties, otherwise the most specific match wins. The docs’ table: Profile rule
example.comversus VPC ruleexample.comfor a query toexample.com→ local VPC; Profile ruletest.example.comversus VPC ruleexample.comfortest.example.com→ Profile. - The 300-VPCs-per-private-hosted-zone quota is where the docs tell you to switch to Profiles: “If you want more than 300 associations, we recommend you use Route 53 Profiles.”
- Inventory APIs lie by omission:
ListHostedZonesByVPCandGetHostedZoneonly report direct associations. For the complete picture you must also callListProfileResourceAssociations.
When a stem says “a central team must enforce the same forwarding rules, DNS Firewall policy and private zones on every new VPC across the organization with minimum operational overhead”, Profiles plus RAM (and CloudFormation for new VPCs) is the intended answer. RAM-sharing each resource individually is the older, more laborious distractor.
DNS Firewall: Filtering the Queries Your VPC Makes
Resolver DNS Firewall filters outbound DNS queries that pass through the VPC Resolver. It is a Resolver feature, needs no endpoint, and its primary documented purpose is preventing DNS exfiltration from a compromised instance. The security specialty edge-protection guide covers the DNS Firewall versus Network Firewall decision; the SAP-C02 angle is how the pieces fit a VPC.
- Domain lists are either yours (up to 100,000 domains across all lists per account per Region, or 250,000 in a single S3-imported file) or AWS managed:
AWSManagedDomainsMalwareDomainList,AWSManagedDomainsBotnetCommandandControl,AWSManagedDomainsAggregateThreatListandAWSManagedDomainsAmazonGuardDutyThreatList. Managed lists carry no per-domain fee. - Rules live in rule groups (up to 100 rules per group). Each rule has a unique numeric priority (lowest evaluated first), a domain list or an Advanced protection (DGA, dictionary DGA, DNS tunneling detection with a High / Medium / Low confidence threshold) but not both, an optional query type, and an action: ALLOW, ALERT (log only) or BLOCK.
- BLOCK responses are
NODATA(empty success),NXDOMAIN(name does not exist) orOVERRIDE, which returns a CNAME you specify with a TTL you choose, typically to a sinkhole page. - Domain redirection controls whether the rule inspects only the first name or every name in a CNAME/DNAME chain (the default). With chain inspection, each hop must appear in the list with the action you want.
- A VPC can have up to 5 rule groups associated, each association with its own priority. The classic allow-list design is one rule group that allows the trusted domains and a final rule that blocks
*. - Fail mode is closed by default. If DNS Firewall cannot be reached, Resolver “blocks any queries for which it doesn’t receive a reply from DNS Firewall and sends a
SERVFAIL”. Enabling fail open favors availability. This setting is per VPC (UpdateFirewallConfig/FirewallFailOpen) and can also be set from a Profile. - Firewall Manager can push rule-group associations across an organization and auto-associate new VPCs.
- Resolved IP validation is the newer integration: Network Firewall can check that a connection’s destination IP was actually returned by a VPC Resolver answer for a VPC that has a DNS Firewall rule group, blocking hard-coded-IP evasion.
The discriminator the exam cares about: DNS Firewall sees queries, Network Firewall sees packets. “Block resolution of known-bad domains with minimal cost” is DNS Firewall; “inspect TLS SNI and HTTP Host headers for all egress” is Network Firewall; “both, and prove the IP matches the name” is resolved IP validation.
DNSSEC: Two Features That Sound Like One
Route 53 has two separate DNSSEC switches, and questions routinely conflate them.
| DNSSEC signing | DNSSEC validation | |
|---|---|---|
| Where | Per public hosted zone | Per VPC (Resolver setting) |
| What | Route 53 signs every response for the zone so the world’s validating resolvers can verify it | VPC Resolver verifies signatures on public signed names it resolves recursively for your instances |
| Keys | KSK backed by a KMS asymmetric key you own; ZSK managed entirely by Route 53 | None; it is a validation flag |
| Private hosted zones | Not supported (no KSKs, no signing) | Not applicable to private names |
| Cost | No Route 53 charge; the KMS key is billed | No charge |
Signing internals
- The KSK’s KMS key must be an asymmetric customer managed key with the
ECC_NIST_P256key spec, in us-east-1, used for sign/verify, with key policy statements that let thednssec-route53.amazonaws.comservice principal use it. Route 53 can create the key for you; if you create it yourself, the policy is on you. The signing algorithm the chain of trust must declare is ECDSAP256SHA256 (13) with digest SHA-256 (2). - 2 KSKs per hosted zone is the quota, which is exactly what a KSK rotation needs (add new, activate, update DS, remove old).
- Enabling signing caps every record’s effective TTL at one week; longer TTLs are silently enforced down.
- The documented onboarding sequence: lower the zone’s maximum TTL to one hour and the SOA minimum, verify with
GetChange, enable signing and create the KSK, wait at least the previous maximum TTL, then create the DS record in the parent zone (Route 53 registrar adds it from the public key; a parent zone hosted in Route 53 takes anUPSERTof aDSrecord; a third-party registrar does it on request), then wait the NS TTL before expecting validation. Monitor for two weeks. Rolling back isDisableHostedZoneDNSSECplus reversing the TTL changes. - Multi-vendor (white-label name servers from several providers) configurations are not supported with signing, and a parent zone whose provider cannot serve DS records will make the child zone unresolvable.
- Alarm on the CloudWatch metrics
DNSSECInternalFailureandDNSSECKeySigningKeysNeedingAction; a KSK whose KMS key becomes inaccessible is a zone outage waiting to happen.
Validation internals
- Validation applies only to names VPC Resolver resolves recursively. If a forwarding rule hands the query to an on-premises resolver, that resolver must validate.
- The VPC Resolver ignores the DO and CD bits and does not set the AD bit or return DNSSEC records, so clients cannot perform their own validation through it; validation is all-or-nothing at the VPC level.
- Enabling or disabling takes several minutes and can break resolution of misconfigured public zones, so the docs warn it “could result in an outage”.
A stem that says “customers’ resolvers must be able to verify our public records” is signing; “our instances must be protected from spoofed public answers” is validation; “sign our private zone” is impossible and therefore the wrong answer.
Query Logging: What Is and Is Not Captured
Resolver query logging is configured per Region, associated with VPCs (up to 20 configurations and 100 VPC associations per Region), and delivers to CloudWatch Logs, S3 or Firehose. It records:
- queries from resources in the VPC and the responses,
- queries from on-premises that arrive through an inbound endpoint,
- queries that use an outbound endpoint for recursive resolution,
- DNS Firewall rule actions (the
firewall_rule_actionfield).
The two omissions that make questions: cached answers are not logged (only the first unique query within the Resolver cache TTL), and queries that bypass the VPC Resolver entirely (an instance pointed at its own resolver or at 8.8.8.8 through a NAT gateway) never appear. Route 53 does not charge for query logging itself; the destination service does. Configurations can be shared with RAM and bundled into Profiles.
Pricing Shape
You rarely need exact prices, but the shape of the bill resolves “most cost-effective” distractors.
| Item | Pricing shape |
|---|---|
| Resolver endpoint | Per ENI-hour (about $0.125), so a minimum-size endpoint is two ENIs around the clock |
| Queries through endpoints | Per million (about $0.40, dropping after 1 billion); queries the VPC Resolver answers locally are free |
| Private hosted zone queries | Free; the zone itself is a small monthly fee |
| DNS Firewall | Per custom domain stored per month plus per million queries evaluated; managed lists have no per-domain fee; Advanced rules add an hourly charge per rule group association |
| Profiles | Flat hourly charge per account covering the first 100 Profile-VPC associations per Region, then a small per-association hourly rate |
| DNSSEC | Free in Route 53; pay for the KMS key |
| Query logging | Free in Route 53; pay the destination |
The two cost cues: a system rule for amazonaws.com next to a . forwarding rule is cheaper because local answers are free, and consolidating endpoints in a central DNS VPC is cheaper than per-account endpoints because you pay per ENI-hour, not per VPC.
Quotas Worth Memorizing
| Quota | Value | Why it matters |
|---|---|---|
| Resolver endpoints per Region per account | 4 (adjustable) | Pushes designs toward a central DNS VPC |
| IP addresses per endpoint | 6 (adjustable); minimum 2 | Capacity scales by adding IPs |
| IP addresses per forwarding rule | 6 | Target list size |
| Rules per Region | 1,000; rule–VPC associations 2,000 | Large estates use RAM or Profiles |
| UDP QPS per IP address in an endpoint | 10,000 (as low as 1,500 with connection tracking) | Sizing and the NLB trap |
| Link-local packets per ENI | 1,024 PPS | Single-instance DNS throttling |
| VPCs per private hosted zone | 300 (then use Profiles) | Scale limit for direct association |
| Pending VPC association authorizations per zone | 1,000 | Cross-account association |
| KSKs per hosted zone | 2 | Rotation headroom |
| Profiles per account per Region / VPCs per Profile | 5 / 1,000 | One Profile per VPC |
| DNS Firewall rule groups per VPC | 5 | Association limit |
| Query log configurations / VPC associations per Region | 20 / 100 | Logging scale |
| Resolver API rate | 5 requests per second per account per Region | Automation must back off |
| Resolver on second-generation Outposts | Up to 75,000 QPS | Edge DNS without the Region |
Scenario Drill
| Scenario | Answer | Why |
|---|---|---|
On-prem hosts cannot resolve app.internal.example.com hosted in a private hosted zone | Inbound endpoint; on-prem conditional forwarder for the domain → endpoint IPs | Forwarding to VPC+2 is unsupported |
EC2 cannot resolve corp.local served by on-prem AD DNS | Outbound endpoint + forward rule for corp.local with the AD servers as targets, associated with the VPC | Rules select what leaves |
| Security requires all DNS to traverse the on-prem security stack, but EC2 hostnames became slow and bills rose | Keep the . forward rule, add a system rule for amazonaws.com | Docs’ explicit recommendation |
| Private hosted zone records stopped resolving after a forwarding rule for the same domain was added | Forwarding rule takes precedence over the zone; narrow the rule or add a more specific system rule | Documented precedence |
Two private zones example.com and eng.example.com; host.eng.example.com returns NXDOMAIN though it exists in example.com | Expected: most specific zone answers, no fall-through | Overlap behaviour |
| Account B’s VPC must resolve Account A’s private hosted zone; console shows no option | create-vpc-association-authorization in A, associate-vpc-with-hosted-zone in B, delete the authorization | CLI/API only |
| 40 accounts need the same forwarding rules | Create rules once in the DNS account, share with RAM, recipients associate with their VPCs | Queries still use the owner’s outbound endpoint |
| 400 VPCs across the org need identical zones, rules, DNS Firewall policy and fail-open setting, applied automatically to new VPCs | Route 53 Profiles shared with RAM, Profile association in the VPC CloudFormation template | 300-VPC zone limit and least overhead |
| Same name defined in a Profile rule and directly on the VPC | Local VPC setting wins the exact tie | Profile precedence table |
| Inbound endpoint tops out around 1,500 QPS per IP | Remove stateful security group rules (use untracked 0.0.0.0/0 on the DNS ports) or stop fronting it with an NLB | Connection tracking |
| A single instance sees DNS timeouts while the rest of the VPC is fine | Per-ENI 1,024 PPS link-local allowance; spread load or add ENIs/instances | Not an endpoint issue |
| Sub-zones are added weekly on-prem; the team wants NS delegation instead of a forwarding rule per sub-zone | NS records in the private hosted zone + a DELEGATE rule on the outbound endpoint (plus a forward rule for out-of-zone name servers) | June 2025 feature |
On-prem DNS should delegate aws.example.com to AWS using standard NS records | Delegation category inbound endpoint; endpoint IPs become the NS glue | Do53 only |
| Compliance requires encrypted DNS from on-prem into the VPC with FIPS 140-2 | Inbound endpoint with DoH-FIPS (enable alongside Do53 first, then drop Do53); open 443 | FIPS is inbound-only |
| Prevent data exfiltration over DNS from compromised instances at lowest cost | DNS Firewall rule group with AWS managed threat lists and a BLOCK rule, fail-closed | Queries, not packets |
| DNS Firewall outage must not take production down | Set the VPC (or Profile) firewall failure mode to fail open | Default is closed → SERVFAIL |
| External users must be able to validate our public zone | Enable DNSSEC signing, KMS ECC_NIST_P256 key in us-east-1, add DS at the parent after waiting the old max TTL | Signing, not validation |
| Instances must be protected from spoofed public DNS answers | Enable DNSSEC validation on the VPC; note forwarded domains must be validated by the forwarder | Validation, not signing |
| ”Sign the private hosted zone” | Not possible; distractor | Public zones only |
| Reverse lookups of on-prem 10.x addresses fail from EC2 | Forward rule for the relevant 10.in-addr.arpa zone to on-prem (overrides the autodefined rule) | Autodefined reverse rules |
| Audit which domains instances queried, including blocked ones, into S3 | Resolver query logging configuration → S3, associated with the VPCs | Logs DNS Firewall actions; cached answers not logged |
| Multi-Region hybrid DNS | Endpoints and rules per Region; private hosted zones can be associated with VPCs in any Region | Resolver is Regional, zones are global |
Common Mistakes
- Pointing on-premises forwarders at 10.0.0.2. It is unsupported and unstable. The inbound endpoint exists for this.
- Treating rules as ordered. There is no priority on Resolver rules. Specificity decides, and the local VPC wins exact ties with a Profile.
- Forgetting that a forwarding rule beats a private hosted zone. The most common “it worked yesterday” scenario.
- Fronting an inbound endpoint with an NLB “for a static IP”. The IPs are already static, and the NLB cuts capacity to about 1,500 QPS per IP.
- Confusing the three sharing mechanisms. RAM for rules, rule groups, logging configs and Profiles; association authorizations for private hosted zones; Profiles for bundles.
- Expecting the console to associate a cross-account private hosted zone. CLI, API or SDK only.
- Mixing up signing and validation. Signing is per public hosted zone with a KMS key; validation is a per-VPC resolver flag.
- Assuming cached queries show in query logs. Only unique queries within the cache TTL are logged.
- Creating a
.forwarding rule without anamazonaws.comsystem rule. Slower service endpoints and a bigger bill.
Frequently Asked Questions
Can a Resolver endpoint be shared with other accounts?
Not directly. Endpoints are VPC-level resources only the VPC owner can create. What you share with AWS RAM is the rule that uses the endpoint; recipients associate the rule with their VPCs and their queries exit through your outbound endpoint. For inbound, other accounts simply point their forwarders at your endpoint IPs over Transit Gateway or peering.
Does an inbound endpoint need rules?
No. It hands queries to the VPC’s resolver, which answers from private hosted zones associated with the VPC, any rules associated with the VPC, and public DNS. That is also why the VPC hosting the inbound endpoint must have the private hosted zones (or Profile) associated with it.
What is the difference between a system rule and an autodefined rule?
Both make Resolver answer a domain locally instead of forwarding it. Autodefined rules are created by AWS when enableDnsHostnames is enabled (EC2 names, reverse zones, localhost, private hosted zones); system rules are the same mechanism created by you to carve an exception out of your own forwarding rule.
Which wins: a Route 53 Profile rule or a rule associated directly with the VPC?
The most specific domain wins. If both name exactly the same domain, the local VPC association takes precedence.
Can I use DNSSEC with a private hosted zone?
Signing is public-zone only; you cannot create KSKs for a private hosted zone. DNSSEC validation on the VPC applies to public names the resolver resolves recursively.
How many IP addresses should an endpoint have?
At least two in different Availability Zones. Each IP processes up to 10,000 UDP QPS; when any ENI exceeds 50 percent of that, add IPs. Watch for connection tracking, which can reduce an inbound IP to about 1,500 QPS.
Does DNS Firewall inspect traffic that bypasses the VPC Resolver?
No. It only sees queries that pass through the VPC Resolver. An instance configured to use an external resolver through a NAT gateway is invisible to DNS Firewall; use Network Firewall (and resolved IP validation) to cover that path.
Conclusion
The SAP-C02 exam rarely asks “what is Route 53 Resolver”. It asks you to notice that the on-prem forwarder is pointed at VPC+2, that a forwarding rule has silently overridden a private hosted zone, that the inbound endpoint is throttled by a stateful security group, that 40 accounts should share a rule instead of 40 endpoints, that 400 VPCs need a Profile rather than 400 associations, and that “sign the private zone” is not a thing. Layer on the delegation rule types, the DNS Firewall fail mode and the signing-versus-validation split, and most hybrid DNS questions collapse to one or two eliminations.
The fastest way to make those eliminations automatic is to practise them against realistic distractors. Sailor.sh’s AWS Certified Solutions Architect - Professional (SAP-C02) Mock Exam Bundle includes eight full-length, 75-question exams whose explanations spell out why the VPC+2 answer, the per-account endpoint answer or the “enable DNSSEC on the private zone” answer loses to the one the scenario actually demands. Pair this guide with the SAP-C02 study plan, the Direct Connect internals guide and the Transit Gateway internals guide for the connectivity underneath, then test yourself on the SAP-C02 practice questions before booking the real thing.