Route 53 vs Route 53 Resolver: What Each One Does

Route 53 is Amazon's DNS service for the internet at large — it registers domains, holds your hosted zones, and decides which server answers when someone types your website address. Route 53 Resolver is a completely different, free component that lives inside every Amazon VPC and answers DNS questions asked from inside your AWS network — by your EC2 instances, your Lambda functions, anything running in that VPC. And here's the part almost nobody has caught up on yet: as of late 2025, AWS quietly renamed the service you're probably thinking of when you say "Route 53 Resolver" to Route 53 VPC Resolver — because it launched a third, unrelated service called Route 53 Global Resolver, and needed to tell the two apart.

Jake got a $340 invoice from the freelance network guy he hired to "fix the DNS" for his shop's new online repair-booking site. Three of those hours were spent trying to figure out why he couldn't add a CNAME record inside something called "Resolver" — a service that, it turns out, doesn't have records, zones, or a console page for adding a CNAME to anything. He'd found Resolver, not Route 53, and spent an afternoon in the wrong service entirely.

That mix-up is common enough that it's worth walking through slowly, in plain English, with the actual documentation behind every claim — not "trust me," but the setting names, the rule types, and the exact behavior AWS publishes. By the end you'll know which of these three services (yes, three) you actually need, which you can ignore completely, and what to check first when one of them starts acting up.

What Route 53 actually is

Route 53 is AWS's public-facing DNS product. Amazon's own documentation describes it as performing four jobs: domain registration (buying and renewing a name like jakesphonefix.com), DNS routing (hosted zones full of records — A, CNAME, MX, and so on — that tell the internet where your domain's traffic should go), health checking (so Route 53 can stop sending traffic to a server that's down), and traffic policies that combine multiple routing strategies — weighted, latency-based, failover, geolocation, geoproximity, IP-based, and multivalue — into one configuration you can apply across several records at once.

If you've ever pointed a custom domain at a CloudFront distribution for HTTPS, that's the same Route 53 doing the same job — a hosted zone, an alias record, done. If you want the walkthrough for that specific setup, this earlier post covers wiring a custom domain to CloudFront through Route 53. None of what follows in this post touches that workflow at all — Resolver has nothing to do with your public website's DNS.

What Route 53 Resolver actually is

Every Amazon VPC gets a recursive DNS resolver automatically, at no extra charge, with no setup required. AWS documentation calls this the "VPC+2" address — take your VPC's base network address and add 2, and that's the IP your instances are already pointed at by default. It answers three kinds of questions: local VPC domain names for things like EC2 instances, records inside any private hosted zone you've associated with the VPC, and for everything else — regular public internet domains — it does a normal recursive lookup against the public DNS system, the same way any DNS resolver would.

This is the service that used to be called, plainly, "Route 53 Resolver," and before that carried an even plainer name most engineers never hear anymore. It is regional, meaning it operates independently in each AWS Region, and it exists whether or not you ever open its console page. Jake's freelancer never needed to touch it at all — his booking site's public DNS lived entirely in a Route 53 hosted zone.

Wait — didn't this get renamed? Twice, actually

This is the part that trips up even people who've used AWS for years, because it's genuinely recent, and it's not even the first rename. AWS's own documentation notes that the resolver was originally called the "Amazon DNS server" (you'll still see it called that, or "AmazonProvidedDNS," in older Amazon VPC documentation), and was renamed to "Route 53 Resolver" once Resolver rules and inbound/outbound endpoints were introduced. Then, at re:Invent in late November 2025, AWS previewed a new, unrelated product called Route 53 Global Resolver — an internet-reachable, anycast DNS resolver meant for branch offices and remote clients that need to resolve both public domains and your private hosted zones from anywhere, not just from inside a VPC. To keep the two from being confused, AWS renamed the original resolver again, from "Route 53 Resolver" to "Route 53 VPC Resolver," at the same time. Global Resolver reached general availability on March 9, 2026, across 30 Regions.

Nothing about how inbound endpoints, outbound endpoints, or Resolver rules behave changed in either rename — only the label on the box. The rest of this post uses "Resolver" to mean the VPC-scoped one unless it says "Global Resolver" explicitly.

How Resolver actually answers a query

Two IP addresses matter here, both documented: the VPC+2 address inside your own VPC's CIDR range, and a fixed link-local address, 169.254.169.253 (with fd00:ec2::253 for IPv6), which is how the resolver is reachable regardless of which VPC you're in. AWS documents two components behind it, both transparent to you as the customer: a local Nitro Resolver service running on the instance's own hardware, which keeps a short-lived cache to answer repeat queries fast, and — for anything not already cached — a Zonal Resolver fleet in the same Availability Zone that does the actual recursive lookup work.

One behavior from that design is worth knowing before you assume something is broken: if the Resolver hits query timeouts, refused connections, or SERVFAIL responses from a domain's name servers, AWS documents that it may answer from its cache even past that record's normal time-to-live, specifically to keep resolution working through a transient upstream failure. A "stale" answer during an outage is often the resolver protecting you, not malfunctioning.

Inbound endpoints: letting your network ask your VPC

An inbound Resolver endpoint allows DNS queries to reach your VPC from your on-premises network or from another VPC. Picture a client at your office needing to resolve internal-app.example.com, a name that only exists in a private hosted zone attached to your VPC. Without an inbound endpoint, that office client has no way to ask VPC Resolver anything — VPC Resolver only listens inside its own VPC by default.

An inbound endpoint gives you IP addresses, inside your VPC, that your on-premises DNS server can be configured to forward those specific queries to. AWS's documented flow is: the on-premises resolver has a forwarding rule pointing at the inbound endpoint's IPs, the query travels over a private connection (Direct Connect or Site-to-Site VPN), the inbound endpoint hands it to VPC Resolver, and the answer comes back the same path in reverse.

Two details the console will make you deal with immediately: every endpoint needs a security group with inbound rules allowing TCP and UDP on port 53, and AWS requires at least two IP addresses per endpoint even though the field technically accepts one — spread across different Availability Zones for resilience.

Outbound endpoints: letting your VPC ask your network

An outbound endpoint is the mirror image: it allows DNS queries from your VPC to reach your on-premises network (or another VPC). Say an EC2 instance needs to resolve payroll.internal.example.com, and the authoritative answer only exists on a DNS server sitting in your office. VPC Resolver, on its own, has no idea that name exists — it only knows AWS-side names and public internet names.

The outbound endpoint is what forwards that specific query out, over Direct Connect or Site-to-Site VPN, to your on-premises resolver, and relays the answer back. Like inbound endpoints, outbound endpoints need a security group — this time with outbound rules permitting TCP and UDP on whatever port your on-premises DNS server actually listens on for queries.

An outbound endpoint alone does nothing, though. It's a highway with no signs telling traffic where to exit — that's what Resolver rules are for.

Resolver rules: the part that decides what actually gets forwarded

A Resolver rule tells VPC Resolver which domain names to route through an outbound endpoint, and where. You attach the rule to a VPC, name a domain (say, example.com), and give it the target IP addresses of your on-premises DNS server. From that point, any query for that domain — or a subdomain of it — gets forwarded instead of resolved normally.

The rule that matters most in practice is what happens when two rules could both match. If you have a FORWARD rule for example.com and another for the more specific acme.example.com, AWS's documentation is explicit: Resolver always picks the most specific match and forwards accordingly — the general rule doesn't win just because it was created first.

Scaling and performance: why endpoints throttle under load

Resolver endpoint security groups use connection tracking by default — AWS's standard behavior for monitoring traffic state through security groups — and each endpoint network interface has a maximum number of connections it can track. A sustained high volume of DNS queries can exceed that tracking limit and cause throttling and dropped queries, even though nothing looks visibly "wrong" in the console. AWS's documented guidance is to watch queries-per-second per network interface using CloudWatch metrics, and if your peak rate exceeds 50% of a single interface's capacity, add more network interfaces to the endpoint rather than waiting for it to fail outright.

There's a floor worth knowing if you're diagnosing a sudden slowdown rather than an outright failure: when connection tracking is enforced by restrictive security group rules, or queries route through something like a Network Load Balancer, the maximum queries per second per IP address on an inbound endpoint can drop as low as 1,500 — a real capacity ceiling, not a bug.

DNS Firewall: filtering, not forwarding

Here's a place popular advice gets muddled: Resolver rules and DNS Firewall sound like they might do overlapping jobs, and they don't. Resolver rules decide where a query goes. DNS Firewall decides whether a query is allowed at all.

DNS Firewall is a feature of VPC Resolver, and it needs no additional Resolver setup to turn on. You build a rule group — a named, reusable set of filtering rules — and populate each rule with a domain list (your own, or one of AWS's managed lists) plus an action: allow, block, or alert. You associate the rule group with a VPC, and from that point every outbound DNS query from that VPC passes through DNS Firewall for filtering before it's answered. AWS documents two starting philosophies for this: a strict "walled garden" that denies all outbound DNS queries except an approved allow-list, for organizations with tight exfiltration requirements, or a looser default-allow posture that only blocks known-malicious domains using AWS Managed Domain Lists aimed at malware and command-and-control infrastructure.

Rule groups can be shared between AWS accounts using AWS Resource Access Manager, and if you're managing this across an entire AWS Organization, AWS Firewall Manager can push consistent DNS Firewall rule-group associations to every account and VPC in scope automatically, rather than you configuring each one by hand.

Query logging: two logs, same-sounding name

This is the second place the shared "Route 53" name causes real confusion, because there are genuinely two separate query-logging features that get called "Route 53 query logs" interchangeably.

1. Route 53 hosted zone query logging — logs queries that Route 53 receives for one of your public hosted zones: which edge location answered, what domain was requested, the record type, and the response code. This has a specific, easy-to-miss requirement: the CloudWatch Logs log group must be created in the us-east-1 Region, regardless of where your hosted zone or resources actually live, and the log group and hosted zone must belong to the same AWS account.
2. VPC Resolver query logging — logs DNS queries that originate inside VPCs you specify, queries arriving through an inbound endpoint, queries going out through an outbound endpoint, and queries evaluated by DNS Firewall rules. This one can be sent to a CloudWatch Logs log group, an S3 bucket, or a Kinesis Data Firehose delivery stream, and AWS specifically recommends S3 for high-query-volume workloads so logs aren't throttled.

One behavior worth knowing before you go looking for a query in either log: VPC Resolver caches answers for the record's time-to-live, and query logging only records unique queries — not ones VPC Resolver was able to answer straight from cache. If an instance asks for the same name twice inside the TTL window, you'll typically see one log entry, not two, which looks like missing data until you know why.

Privacy and safety: what a Resolver setup exposes

VPC Resolver query logs are more revealing than people expect the first time they read one: AWS documents that the logged fields include the AWS Region, the originating VPC ID, the source IP address of the resource that made the query, and the specific instance ID it came from, along with the domain requested and the response code. Anyone with read access to that log bucket can build a fairly detailed picture of which instances are talking to which domains and when — which is exactly the audit trail security teams want, and exactly why access to that bucket or log group deserves the same care as any other sensitive log source.

On the outbound side, this is also the actual point of DNS Firewall: AWS frames it explicitly as protection against DNS-based data exfiltration, where malware or a compromised process tries to smuggle stolen data out encoded in DNS queries to a domain it controls. A tight allow-list rule group closes that path far more effectively than trying to catch it after the fact in traffic logs.

Edge cases: Outposts, shared VPCs, and older accounts

Resolver on AWS Outposts works the same way conceptually — inbound and outbound endpoints, same rule types — but you create and manage them under a separate "Outposts" area in the console, scoped to the Outpost's own operational state rather than a standard VPC.

If you're working in a shared VPC you don't own — common in multi-account setups where a central networking account owns the VPC and application accounts get subnets in it — remember that endpoints, rules, and DNS Firewall associations are resources tied to that VPC, and changing them may require permissions or ownership you don't have as a spoke-account user. If your DNS problem in that setup traces back to a throttled endpoint or a missing rule, the fix is a request to whoever owns the VPC, not something you can patch from your own account. Naming that limit plainly: if you can't see or edit the Resolver rules in your own account's console for a shared VPC, that's not a bug in your permissions — it's by design, and the request goes to the VPC owner.

One older-account caveat AWS still documents: VPCs created before October 2016 may not resolve private DNS hostnames correctly if the VPC's IPv4 range falls outside the standard RFC 1918 private address ranges, and enabling that support requires contacting AWS Support directly rather than a console setting. And regardless of VPC age, both enableDnsHostnames and enableDnsSupport need to be set to true on the VPC if you're using a private hosted zone or private DNS with interface VPC endpoints (AWS PrivateLink) — a setting that's easy to miss because it lives on the VPC itself, not anywhere in Resolver's own console pages.

Automating it: CLI and infrastructure as code

Past the first endpoint or two, clicking through the console stops scaling. The AWS CLI's route53resolver command group covers the whole workflow — creating endpoints, creating rules, and associating rules with VPCs — as documented calls you can script or fold into a deployment pipeline instead of repeating by hand for every new environment.

If you're already using AWS CDK, the resolver endpoint is modeled directly as CfnResolverEndpointProps, which takes the direction (INBOUND, OUTBOUND, or INBOUND_DELEGATION), the IP addresses and subnets, and the security group IDs as first-class properties — meaning your endpoint configuration lives in version control next to the rest of your network stack instead of as a one-off console click nobody remembers making six months later.

Route 53 Global Resolver: the third service, briefly

Since it's the reason the rename happened at all, Global Resolver deserves a plain-language description rather than being left as a mystery. It's an internet-reachable, anycast DNS resolver — meaning it publishes a single set of IPv4 and IPv6 addresses that route a client to whichever supported AWS Region is closest to them — built for authorized clients that aren't sitting inside a VPC at all: branch offices, remote employees, on-premises data centers. It can resolve both ordinary public internet domains and names in your Route 53 private hosted zones, supports DNS Firewall-equivalent filtering, and offers centralized logging, all without you having to build inbound/outbound endpoint pairs and Resolver rules yourself for that use case.

If your DNS problem is entirely inside one or a few VPCs, or entirely about hybrid connectivity over a Direct Connect or VPN link you already have, you almost certainly want VPC Resolver, inbound/outbound endpoints, and Resolver rules — not Global Resolver. Global Resolver is aimed at a narrower situation: authenticated clients scattered outside AWS's network entirely that need one consistent, secure resolution path.

All three, side by side

Setting up hybrid DNS: the order that actually works

If your actual need is two-way DNS between a VPC and an on-premises network, the pieces above go together in a specific order. Skipping ahead is the fastest way to end up with an endpoint that has nothing pointing at it.

1. Confirm the private connection exists first. Direct Connect or Site-to-Site VPN needs to already be up between your VPC and your on-premises network — endpoints don't create that connectivity, they use it.
2. Create the outbound endpoint if your VPC resources need to resolve on-premises names, or the inbound endpoint if your on-premises clients need to resolve VPC/private-hosted-zone names — or both, for two-way resolution.
3. Attach security groups allowing TCP and UDP port 53 inbound (for inbound endpoints) or outbound on your DNS port (for outbound endpoints).
4. Create the Resolver rule for each domain you want forwarded, pointing at your outbound endpoint and the target on-premises DNS server IPs.
5. Associate the rule with the VPC(s) that should use it — a rule does nothing until it's attached somewhere.
6. Configure your on-premises DNS server to forward the relevant domain's queries to your inbound endpoint's IP addresses — this half is outside AWS entirely, and AWS's documentation is explicit that you'll need to refer to your own DNS software's forwarding instructions for it.

Test each direction independently. A query failing outbound (VPC-to-network) and a query failing inbound (network-to-VPC) point at completely different steps in that list, and troubleshooting both at once just wastes time.

Failure modes, by symptom

An endpoint that shows a status other than "Operational" is telling you something specific, not just "broken." AWS's own status descriptions distinguish a few states worth knowing: the endpoint can be actively being created or configured, actively associating or disassociating network interfaces, attempting to recover an unhealthy network interface (during which it runs at reduced query capacity because of the per-IP query limit), or in a state AWS labels "Action needed," which it can't recover from automatically — that one means checking every IP address associated with the endpoint yourself, adding a replacement for any that's unavailable, and removing the bad one, since an endpoint must always keep at least two IP addresses.

When you can ignore all of this entirely

Ethan's take is blunt on this one: "If everything you run lives inside AWS and nothing on your home or office network needs to resolve an AWS-internal name, you don't need endpoints, rules, or DNS Firewall at all. VPC Resolver is already running and already answering your instances' queries for free. People go looking for a Resolver tutorial because the name sounds important, and it's usually a solution to a problem they don't have."

The signal that you do need this machinery is specific: a genuine need for names to cross the boundary between AWS and a network AWS doesn't control — an office, a data center, a home lab connected over VPN. Without that boundary, the free, automatic resolver every VPC already has is the entire answer.

Quotas, cost, and what to check before you build

VPC Resolver's default per-VPC resolution is free. Inbound and outbound endpoints, Resolver rules, and DNS Firewall are separate billable resources with their own current rates and limits, which change often enough that quoting a specific dollar figure or quota number here would go stale fast — check the Route 53 pricing page and the Resolver quotas page in the console for what applies to your account today, since quotas can also be raised on request.

Two structural limits are worth planning around regardless of pricing: every endpoint needs a minimum of two IP addresses, in different Availability Zones, for resilience, and the link-local Amazon DNS address itself is subject to a documented 1,024 packet-per-second cap per network interface — budget for both from the start rather than retrofitting them later.

Frequently asked questions

What is the difference between Route 53 and Route 53 Resolver?

Route 53 manages public DNS — hosted zones, records, domain registration, and traffic routing for domains anyone on the internet can look up. Route 53 Resolver (officially Route 53 VPC Resolver) is the free, automatic recursive DNS server every Amazon VPC gets by default, answering queries from resources inside that VPC.

Is Route 53 Resolver the same as the VPC's default DNS server?

Yes. It's reachable at the "VPC+2" address, which is your VPC's base network address plus 2, and your instances are typically pointed at it automatically without you configuring anything.

Do I need Resolver endpoints if I only use AWS resources?

No. Endpoints exist to connect VPC Resolver with DNS resolvers outside AWS. If nothing outside AWS needs to be part of your DNS resolution, the default VPC Resolver already handles everything with no extra setup.

What's the difference between an inbound and outbound Resolver endpoint?

An inbound endpoint lets DNS queries reach your VPC from your on-premises network or another VPC. An outbound endpoint lets queries from your VPC reach resolvers on your on-premises network. They're used together for two-way hybrid DNS but each solves one direction only.

How many IP addresses does a Resolver endpoint need?

At least two, spread across different Availability Zones. AWS enforces this minimum so the endpoint can keep functioning if one IP address becomes unavailable.

What is a Resolver rule, and what's the difference between FORWARD and SYSTEM rules?

A Resolver rule tells VPC Resolver which domain to forward and where. A FORWARD rule sends a domain's queries to specific IP addresses through an outbound endpoint. A SYSTEM rule carves out a subdomain of a forwarded domain and tells Resolver to handle that piece itself instead of forwarding it.

What happens if two Resolver rules match the same domain?

Resolver always uses the most specific match. If you have rules for both example.com and acme.example.com, a query for acme.example.com follows the more specific rule, regardless of which rule was created first.

Is Resolver DNS Firewall the same as AWS Network Firewall?

No. DNS Firewall filters DNS queries by domain name at the resolver level and is a feature of VPC Resolver. AWS Network Firewall is a separate, broader network traffic inspection service. They can be used together but do different jobs.

Do I need DNS Firewall if I already use Resolver rules?

They solve different problems. Resolver rules decide where a query is forwarded. DNS Firewall decides whether a query is allowed at all, based on domain lists and allow/block/alert actions. Using rules doesn't give you any filtering, and DNS Firewall doesn't give you any forwarding.

What's the difference between Resolver query logs and Route 53 hosted zone query logs?

Resolver query logging covers DNS activity inside your VPCs, through inbound and outbound endpoints, and through DNS Firewall. Route 53 hosted zone query logging covers queries Route 53 receives for your public hosted zones, and its CloudWatch log group must be created specifically in the us-east-1 Region.

Why isn't my Route 53 query logging log group visible in my region?

Because it isn't there. Route 53 hosted zone query logging requires the CloudWatch Logs log group to be created in us-east-1 no matter which Region your hosted zone or resources are in — check us-east-1 specifically.

What is Route 53 Global Resolver and how is it different from Route 53 Resolver?

Global Resolver is a newer, separate AWS service that provides internet-reachable, anycast DNS resolution for authorized clients located anywhere — branch offices, remote workers, on-premises data centers — resolving both public domains and Route 53 private hosted zone records. Route 53 VPC Resolver, by contrast, only serves resources inside a specific VPC (plus anything connected through its endpoints).

Can I share Resolver rules and DNS Firewall rule groups across AWS accounts?

Yes. Resolver rules can be shared across accounts, and DNS Firewall rule groups can be shared using AWS Resource Access Manager. For organization-wide consistency, AWS Firewall Manager can also centrally manage DNS Firewall rule-group associations across every account and VPC in scope.

Does Resolver query logging log every single DNS query?

No. It logs unique queries only. If VPC Resolver answers a repeat request straight from its cache within the record's time-to-live, that repeat isn't logged again, which can make log volume look lower than actual query volume.

Why does my Resolver endpoint throttle or drop queries under heavy load?

Resolver endpoint security groups use connection tracking by default, and each network interface has a maximum number of trackable connections. A high sustained query volume can exceed that limit and cause throttling. AWS recommends monitoring queries per second per interface in CloudWatch and adding more network interfaces once you pass roughly 50% of a single interface's capacity.

What is 169.254.169.253 and why does my instance's DNS point there?

That's the fixed link-local address for the Amazon DNS server (Route 53 VPC Resolver), available in every VPC alongside the IPv6 address fd00:ec2::253 and the VPC-specific "VPC+2" address. It's a normal, expected part of how DNS resolution reaches your VPC, not a misconfiguration.

Revision note. Written September 2026, covering Route 53, Route 53 VPC Resolver (the service most people still call "Route 53 Resolver"), and the newly renamed-around Route 53 Global Resolver. As for Jake's $340 invoice — once he saw that the CNAME he needed had been three clicks away in Route 53's own console the entire time, he paid it anyway, mostly for the lesson. This naming will likely keep shifting as Global Resolver matures and more documentation and console labels catch up to it — if you're reading this months later and something here looks stale, that's probably why. Wherever you landed from, we hope this cleared up which service actually needs your attention today.