A Route 53 hosted zone isn’t just a list of DNS records; it’s a distributed system with its own internal resource limits that can surprisingly impact your application’s availability.
Let’s see this in action. Imagine you have a large, dynamic application with thousands of subdomains that are created and destroyed frequently. You’re using Route 53 to manage these, and suddenly, new subdomains aren’t resolving. You check your application logs, your EC2 instances, everything seems fine. But the DNS resolution is failing.
This is likely a hosted zone limit. Route 53 has quotas on the number of records within a single hosted zone. When you hit this limit, Route 53 stops accepting new record creations, effectively making your dynamically generated subdomains inaccessible. The surprising part is that Route 53 doesn’t throw a loud, obvious error for this at the API level; it simply fails to create the record, and your application might not even notice until it tries to resolve a non-existent subdomain.
The primary limit you’ll encounter is the Record Set Limit per Hosted Zone. For public hosted zones, this is typically 10,000 record sets by default. For private hosted zones, it’s 1,000 record sets. This count includes all record types (A, CNAME, MX, TXT, etc.) and also special records like SOA and NS.
Diagnosis:
The most direct way to check your current record count is via the AWS CLI. Run this command, replacing YOUR_HOSTED_ZONE_ID with the actual ID of your hosted zone:
aws route53 list-resource-record-sets --hosted-zone-id YOUR_HOSTED_ZONE_ID --query "length(ResourceRecordSets)"
This will output a single number representing the total count of record sets in that zone. If this number is close to or at the limit, you’ve found your culprit.
Workarounds:
-
Split into Multiple Hosted Zones: This is the most common and recommended solution. If you have a single, massive hosted zone, break it down into smaller, more manageable zones.
- How: Create new hosted zones in Route 53. Then, within your parent hosted zone (e.g.,
example.com), create NS records for the child zones (e.g.,app1.example.com,app2.example.com). - Example: If you have
app.example.comand want to split it, create a new hosted zone forapp.example.com. Then, in yourexample.comhosted zone, create an NS record forapp.example.compointing to the NS servers of the newapp.example.comzone. - Why it works: Each hosted zone has its own independent limit, effectively giving you more capacity.
- How: Create new hosted zones in Route 53. Then, within your parent hosted zone (e.g.,
-
Use Wildcard Records (with caution): If your subdomains follow a predictable pattern, a wildcard record can reduce the number of individual records.
- How: Instead of creating a record for
*.app.example.com, create a single*.app.example.comrecord. - Example: In your hosted zone, create an A record with the name
*.app.example.comand point it to your application’s load balancer. - Why it works: A single wildcard record can match an unlimited number of subdomains, drastically reducing your record count. Caveat: Wildcards don’t match subdomains that have their own specific records. For example, if you have
db.app.example.comand*.app.example.com, thedbsubdomain will not be matched by the wildcard.
- How: Instead of creating a record for
-
Leverage Alias Records for AWS Resources: Alias records are a Route 53-specific feature that can sometimes consume fewer "record set" slots internally, especially when pointing to certain AWS resources.
- How: When creating records for AWS resources like ELBs, CloudFront distributions, or S3 buckets, use Alias records instead of CNAMEs or A records.
- Example: When creating an A record for
api.example.comthat points to an Application Load Balancer, select "Alias" and choose your ALB from the dropdown. - Why it works: Alias records are a more efficient way for Route 53 to resolve AWS resources, and while they still count as a record set, they can simplify management and sometimes avoid issues related to CNAME depth limits.
-
Delete Stale Records: Regularly audit and remove records that are no longer in use.
- How: Implement a process to identify and delete DNS records when the associated resources are deprovisioned.
- Example: If your application automatically creates DNS records for new instances, ensure it also deletes them when instances are terminated. Use scripts or lifecycle policies.
- Why it works: Frees up slots within the existing hosted zone, allowing new records to be created.
-
Request a Quota Increase: For extremely large, single-zone requirements, you can request an increase to the record set limit.
- How: Open a support ticket with AWS Support and request an increase for the
RECORD_SET_PER_HOSTED_ZONEquota for your account. - Example: State your use case and the desired limit (e.g., "We need to support 50,000 records in our primary domain hosted zone for a multi-tenant application").
- Why it works: AWS can manually adjust these quotas for specific accounts, though splitting zones is generally preferred for architectural reasons.
- How: Open a support ticket with AWS Support and request an increase for the
-
Consider a Custom DNS Solution (Advanced): If your needs are exceptionally complex and exceed even increased Route 53 limits, you might explore running your own DNS servers or using a managed DNS provider that offers different scaling models.
- How: This involves significant architectural changes, potentially deploying DNS servers on EC2 instances or integrating with third-party DNS services.
- Example: Setting up BIND or PowerDNS on EC2 instances and managing zone replication.
- Why it works: Gives you complete control over scaling and limits, but at the cost of operational overhead.
The next challenge you’ll likely face after managing your record set count is understanding the impact of DNS propagation delays when you’re making frequent changes across multiple hosted zones.