canonical: https://jentic.com/apis/amazonaws.com/amazon-route-53

# AWS Amazon Route 53

Jentic publishes the only available OpenAPI specification for Amazon Route 53, keeping it validated and agent-ready. Amazon Route 53 is AWS's authoritative DNS, domain registration, and traffic-routing service. It manages public and private hosted zones, lets you create DNS records with health checks and failover policies, supports advanced traffic routing (weighted, latency-based, geolocation, geoproximity), and offers DNSSEC signing for zones. The same API also handles domain registration and CIDR-based traffic routing.

## For AI agents

Manage DNS records, hosted zones, health checks, and domain registrations on AWS's authoritative DNS, with weighted, latency, and geolocation routing.

## Scope

Does not handle email delivery, web application firewalling, or VPC routing - use for authoritative DNS, hosted zones, health checks, and DNS-based traffic routing only.

## Capabilities

- Create and manage public and private hosted zones for authoritative DNS
- Apply batch record-set changes with ChangeResourceRecordSets including CREATE, UPSERT, and DELETE actions
- Configure DNS health checks and failover policies tied to record sets
- Apply traffic routing policies including weighted, latency-based, geolocation, and geoproximity
- Manage CIDR collections and CIDR-locations for IP-block-based DNS routing
- Enable and manage DNSSEC for hosted zones via key-signing-key activation

## Use cases

### Authoritative DNS for production services

Platform teams use Route 53 hosted zones as the authoritative DNS for production traffic, creating A and AAAA alias records that point at load balancers, CloudFront distributions, and API Gateway endpoints. ChangeResourceRecordSets applies record changes atomically and returns a change ID that can be polled until INSYNC, which keeps deployments deterministic.

Example prompt: Submit ChangeResourceRecordSets with an UPSERT action to create an alias A record api.example.com pointing at the prod ALB, then poll GetChange until status is INSYNC.

### Multi-region failover and traffic routing

Reliability teams use Route 53 health checks combined with failover routing policies to direct traffic away from unhealthy regions. CreateHealthCheck registers an endpoint to monitor; record sets reference the health check and apply Failover, Weighted, or Latency policies to route around failure. The same primitives enable canary releases by adjusting record weights.

Example prompt: Create a health check on https://prod-eu.example.com/health, then upsert two A records api.example.com with Failover routing - primary in eu-west-1, secondary in us-east-1 - both referencing the health check.

### Private DNS for VPC-internal services

Networking teams use private hosted zones to give VPC-internal services memorable names that only resolve inside associated VPCs. CreateHostedZone with a VPC parameter creates the zone; AssociateVPCWithHostedZone extends resolution to additional VPCs. This avoids exposing internal service names to public DNS.

Example prompt: Create a private hosted zone internal.example.com tied to vpc-abc123, then call AssociateVPCWithHostedZone to extend resolution to vpc-def456.

### Agent-driven DNS automation through Jentic

AI agents that manage infrastructure-as-code workflows use Jentic to call ChangeResourceRecordSets, GetChange, and CreateHealthCheck without holding raw AWS credentials. Jentic stores the agent's keys in your Jentic One instance, signs each request with SigV4, and returns the structured response - letting the agent confirm propagation status before declaring the change complete.

Example prompt: Search Jentic for 'create a Route 53 DNS record', load ChangeResourceRecordSets, and execute it with an UPSERT action for a new staging subdomain, then poll GetChange until INSYNC.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /2013-04-01/hostedzone | Create a hosted zone |
| POST | /2013-04-01/hostedzone/{Id}/rrset/ | Apply batch record-set changes |
| POST | /2013-04-01/healthcheck | Create a DNS health check |
| POST | /2013-04-01/hostedzone/{Id}/associatevpc | Associate a VPC with a private hosted zone |
| POST | /2013-04-01/keysigningkey/{HostedZoneId}/{Name}/activate | Activate a DNSSEC key-signing key |
| POST | /2013-04-01/cidrcollection | Create a CIDR collection for IP-block routing |
| POST | /2013-04-01/tags/{ResourceType}/{ResourceId} | Apply tags to a Route 53 resource |

## Key resources

- **HostedZone** — A container for DNS records for a domain - public or private (VPC-scoped)
- **ResourceRecordSet** — An individual DNS record (A, AAAA, CNAME, MX, TXT, alias)
- **HealthCheck** — An endpoint health monitor that record-set routing policies reference
- **TrafficPolicy** — A versioned routing policy that can be applied to record sets
- **CidrCollection** — Named collections of IP CIDR blocks for CIDR-based routing
- **KeySigningKey** — DNSSEC signing key associated with a hosted zone

## Why Jentic

- **Setup:** Wiring Route 53 by hand means computing SigV4 HMAC signatures against its single global endpoint, constructing ChangeBatch payloads, and polling for INSYNC propagation yourself. Through Jentic you install once, import Amazon Route 53 from the API Directory, store your AWS access keys once, and your agent calls it with signing done per request.
- **Permission scoping:** Route 53 puts the hosted zone id in the URL path (/2013-04-01/hostedzone/{Id}/rrset/), so a rule can pin your agent to one hosted zone: it can read and change records for that zone and nothing else. You choose the operations it may call, so destructive ones like DeleteHostedZone or deactivating a key signing key are not included unless you add them.
- **Credential handling:** Your AWS access keys are stored once, encrypted, by your own Jentic One instance and used to produce a SigV4 signature per request. The raw secret access key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a DNS record in a hosted zone', and Jentic returns ChangeResourceRecordSets with its ChangeBatch input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Elastic Load Balancing v2** — ELBs are the most common alias target for Route 53 records
- **AWS Global Accelerator** — Anycast IP-based traffic routing as an alternative to Route 53 latency policies
- **Amazon EC2** — EC2 instances are common backends behind Route 53 records, often via VPC association for private zones

## FAQ

### Why is there no official OpenAPI spec for Amazon Route 53?

AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Amazon Route 53 via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Amazon Route 53 API use?

Route 53 uses AWS Signature Version 4 HMAC signing with an access key ID and secret access key, optionally with a session token. The Route 53 control plane is global, so requests are signed against the us-east-1 endpoint. Through Jentic, your credentials sit in your Jentic One instance and Jentic signs each request server-side.

### Can I create alias records to AWS load balancers with Amazon Route 53?

Yes. Use ChangeResourceRecordSets with an UPSERT or CREATE action and an AliasTarget pointing at the ELB DNS name and hosted zone ID. Alias records are zero-cost lookups and resolve directly to the load balancer's IPs without an extra DNS hop.

### What are the rate limits for the Amazon Route 53 API?

AWS publishes a default of 5 requests per second per account for most Route 53 operations, with higher limits available on request. ChangeResourceRecordSets accepts up to 1,000 changes per call, but only 32,000 changes per hosted zone per 24 hours. Production agents should batch changes and back off on Throttling errors.

### How do I create a DNS record with Amazon Route 53 through Jentic?

Search Jentic for 'create a Route 53 DNS record', load ChangeResourceRecordSets, and call POST /2013-04-01/hostedzone/{Id}/rrset/ with a ChangeBatch containing an UPSERT action and the record details. Then poll GetChange with the returned change ID until status is INSYNC. Install with pip install jentic.

### Can Amazon Route 53 register domain names as well as serve DNS?

Yes - Route 53 includes a domain-registration sub-API for registering, transferring, and renewing domains, separate from the DNS-record APIs covered in this spec. Domain registration calls live on the route53domains endpoint; DNS record management lives on the route53 endpoint.

### Can I limit what my agent is allowed to do with the Amazon Route 53 API?

Yes. Because Route 53 puts the hosted zone ID in the URL path, a rule in your self-hosted Jentic One instance can pin your agent to a single hosted zone, so it can read and change records for that zone and nothing else. You decide which operations it may call, so you can grant ChangeResourceRecordSets and GetChange while leaving out destructive ones like DeleteHostedZone or deactivating a key-signing key. Since Jentic One is self-hosted, your own rules and stored AWS keys determine exactly what the agent can reach.