How to Transfer a Domain from Another Registrar to Route 53 (GoDaddy & Others)

If you purchased a domain on GoDaddy — or any other registrar — and now run your infrastructure on AWS, consolidating DNS management under Route 53 eliminates the context-switching tax of juggling two consoles. Transferring a domain to Route 53 is a multi-step process governed by ICANN rules, registrar-specific unlock procedures, and AWS account prerequisites that, if missed in order, will silently stall your transfer for days.

TL;DR: Domain Transfer to Route 53 at a Glance

PhaseWho ActsWhat HappensTypical Duration
1. Unlock & get auth codeYou (at current registrar)Disable transfer lock, retrieve EPP/auth codeMinutes to hours
2. Initiate transfer in Route 53You (AWS Console or CLI)Submit domain name, auth code, contact info, pay feeMinutes
3. Email confirmationYou (registrant email)Approve transfer via ICANN confirmation emailUp to 24 hours
4. Losing registrar approvalCurrent registrar (auto or manual)GoDaddy and most registrars auto-approve after 5 days unless you expediteUp to 5 days
5. Transfer completesAWSRoute 53 becomes authoritative registrar; DNS continues uninterruptedUp to 10 days total

How Domain Transfers Work in Route 53

A domain transfer is not a DNS change — it is a registrar change. Your DNS records (the hosted zone) are a separate concern from who holds the registration. Route 53 handles both, but they are independent resources. During a transfer, Route 53 contacts the current registrar via the Registry (the authoritative body for the TLD, e.g., Verisign for .com) using the EPP authorization code you provide. ICANN mandates a 5-day window during which the losing registrar can object; if no objection is filed, the transfer proceeds. The domain's expiration date is extended by one year from the transfer date, and the transfer fee covers that renewal year.

sequenceDiagram participant You as Registrant (You) participant GD as GoDaddy participant R53 as Route 53 (AWS) participant REG as TLD Registry participant ICANN as ICANN Email You->>GD: Unlock domain + request EPP auth code GD-->>You: EPP auth code via email You->>R53: Initiate transfer (domain + auth code + contacts) R53->>REG: Submit transfer request REG->>GD: Notify of pending transfer REG->>ICANN: Trigger registrant confirmation email ICANN-->>You: Confirmation email (click to approve) You->>ICANN: Approve transfer GD-->>REG: Auto-approve after 5-day window (or expedite) REG->>R53: Update sponsoring registrar R53-->>You: Transfer complete — Route 53 is now registrar
  1. Registrant (You) unlocks the domain at GoDaddy and retrieves the EPP auth code.
  2. Route 53 receives your transfer request and submits it to the TLD Registry.
  3. Registry notifies the losing registrar (GoDaddy) of the pending transfer.
  4. ICANN confirmation email is sent to the registrant email address — you must click Approve.
  5. After the 5-day objection window (or earlier if GoDaddy expedites), the Registry updates the sponsoring registrar to Route 53.
  6. Route 53 creates or associates a hosted zone; DNS resolution continues without interruption if nameservers are preserved.

Prerequisites Before You Start the Route 53 Domain Transfer

  • Domain age: ICANN prohibits transfers within 60 days of initial registration or a previous transfer.
  • Registrant email must be reachable: The ICANN confirmation email goes to the address on the current WHOIS record. If that inbox is inaccessible, the transfer will time out.
  • No expired domain: Route 53 cannot accept a transfer for an expired domain.
  • TLD must be supported: Route 53 supports a specific list of TLDs for registration and transfer. Verify your TLD at the Route 53 TLD reference before starting.
  • AWS account in good standing: Billing must be active; Route 53 charges the transfer fee immediately.
  • IAM permissions: The IAM principal initiating the transfer needs route53domains:TransferDomain and route53domains:CheckDomainTransferability at minimum.
🔽 Minimum IAM policy for domain transfer 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Route53DomainTransfer",
      "Effect": "Allow",
      "Action": [
        "route53domains:CheckDomainTransferability",
        "route53domains:TransferDomain",
        "route53domains:GetDomainDetail",
        "route53domains:ListDomains",
        "route53domains:GetOperationDetail",
        "route53domains:ListOperations"
      ],
      "Resource": "*"
    }
  ]
}
Think of the EPP auth code as the combination to a safe. The Registry is the bank vault room — it won't let Route 53 touch your domain until GoDaddy hands over that combination and steps aside.

Step 1: Unlock the Domain and Get the Auth Code at GoDaddy

Log in to GoDaddy, navigate to My Products → Domains, select your domain, and open Domain Settings. Two actions are required here, and skipping either one will cause Route 53 to reject the transfer immediately rather than after a delay — which is the better failure mode.

  1. Disable the Domain Lock (Registrar Lock): Toggle "Domain Lock" to OFF. This removes the EPP status code clientTransferProhibited from the Registry record.
  2. Retrieve the Authorization (EPP) Code: Under "Transfer domain away from GoDaddy", request the auth code. GoDaddy emails it to the registrant address. The code is time-limited — use it promptly.
  3. Disable WHOIS Privacy (if enabled): Some privacy services mask the registrant email. If the ICANN confirmation email cannot reach you, the transfer will expire. Temporarily disable privacy protection or confirm the underlying email is forwarded.

Step 2: Check Transferability in Route 53

Before paying, verify Route 53 can accept the transfer. This step catches the 60-day ICANN lock, unsupported TLDs, and Registry-level holds before you commit funds.

aws route53domains check-domain-transferability \
  --domain-name example.com \
  --region us-east-1

Route 53 domain registration APIs are only available in us-east-1 regardless of where your other resources live. This is a hard requirement — all route53domains CLI calls must target us-east-1.

A TRANSFERABLE result in the response means you can proceed. Any other status (e.g., DOMAIN_IN_OWN_ACCOUNT, PREMIUM_DOMAIN, TLD_NOT_SUPPORTED) requires resolution before continuing.

Step 3: Initiate the Transfer in Route 53

You can initiate via the AWS Console or CLI. The Console wizard is more forgiving for first-timers because it validates contact fields inline. The CLI is preferable for scripted or bulk transfers.

Option A: AWS Console

  1. Open the Route 53 console → Registered domains → Transfer domain.
  2. Enter your domain name and click Check.
  3. Enter the EPP authorization code from GoDaddy.
  4. Configure or confirm registrant, administrative, and technical contact details. These must be accurate — ICANN uses them for the confirmation email.
  5. Choose whether to use the Route 53 name servers or keep your existing name servers. If you already have a Route 53 hosted zone with your DNS records, select it here. If not, Route 53 will create one.
  6. Review the transfer fee and complete the purchase.

Option B: AWS CLI

The CLI requires a JSON contact block. Prepare a file named contacts.json with your registrant details, then run:

🔽 contacts.json structure 
{
  "FirstName": "Jane",
  "LastName": "Doe",
  "ContactType": "PERSON",
  "OrganizationName": "Example Corp",
  "AddressLine1": "123 Main St",
  "City": "Seattle",
  "State": "WA",
  "CountryCode": "US",
  "ZipCode": "98101",
  "PhoneNumber": "+1.2065550100",
  "Email": "jane@example.com"
}
aws route53domains transfer-domain \
  --region us-east-1 \
  --domain-name example.com \
  --duration-in-years 1 \
  --auth-code "YourEPPCodeHere" \
  --auto-renew \
  --registrant-contact file://contacts.json \
  --admin-contact file://contacts.json \
  --tech-contact file://contacts.json \
  --privacy-protect-registrant-contact \
  --privacy-protect-admin-contact \
  --privacy-protect-tech-contact

The response returns an OperationId. Save it — you'll use it to poll transfer status.

aws route53domains get-operation-detail \
  --region us-east-1 \
  --operation-id "your-operation-id-here"

Step 4: Approve the ICANN Confirmation Email

Within minutes of submitting the transfer, ICANN sends a confirmation email to the registrant address. This is not optional — if you do not click the approval link, the transfer will be automatically rejected after a set period. Check spam folders. The link is time-limited.

If the email never arrives, the most common cause is WHOIS privacy masking the registrant address. Return to GoDaddy, confirm the underlying email, and contact Route 53 support to resend the confirmation if needed.

Step 5: Monitor Transfer Progress

Poll the operation status periodically. A transfer in progress will show IN_PROGRESS; completion shows SUCCESSFUL.

aws route53domains list-operations \
  --region us-east-1 \
  --submitted-since 2024-01-01T00:00:00Z

You can also monitor from the Route 53 console under Registered domains → Requests. The transfer typically completes within 5–7 days, though it can take up to 10 days per ICANN policy.

Is There a Fee? Route 53 Domain Transfer Pricing

Yes — Route 53 charges a transfer fee per domain, which also covers a one-year renewal extension added to your current expiration date. The fee varies by TLD. For example, .com transfers have a different price than .io or .co.uk transfers. Pricing and limits vary — always check the official Route 53 domain pricing page before initiating a transfer. The charge is applied immediately to your AWS account upon transfer initiation and is non-refundable once the transfer is accepted by the Registry.

DNS Continuity: Hosted Zones and Nameservers During Transfer

The transfer process changes your registrar, not your DNS records. If your domain currently resolves using GoDaddy's nameservers, you have two options:

  • Migrate DNS first (recommended): Create a Route 53 hosted zone, replicate all DNS records, update the nameservers at GoDaddy to point to Route 53 before initiating the transfer. This way, DNS is already on Route 53 when the transfer completes, and there is no nameserver change at transfer time.
  • Keep existing nameservers: During the transfer wizard, choose to keep your current nameservers. Route 53 will still become the registrar, but DNS resolution continues through GoDaddy's nameservers until you manually update them later.
graph TD Start(["Domain Transfer Initiated"]) Start --> Q1{"DNS already on
Route 53?"} Q1 -- Yes --> PathA["Option A: DNS-First
No nameserver change needed"] Q1 -- No --> Q2{"Migrate DNS
before transfer?"} Q2 -- Yes --> CreateHZ["Create Route 53 Hosted Zone
Copy all DNS records"] CreateHZ --> UpdateNS["Update nameservers at GoDaddy
to Route 53 NS values"] UpdateNS --> WaitProp["Wait for NS propagation
(24-48 hrs)"] WaitProp --> PathA Q2 -- No --> PathB["Option B: Registrar-First
Keep GoDaddy nameservers"] PathA --> Transfer["Transfer Completes
Route 53 = Registrar + DNS"] PathB --> Transfer Transfer --> PostB{"Option B only:
Update nameservers post-transfer"} PostB --> Done(["Route 53 manages
registration + DNS"]) Transfer --> Done
  1. Option A (DNS-first): Create the hosted zone and copy records before transfer. At transfer completion, nameservers are already Route 53 — zero DNS disruption.
  2. Option B (Registrar-first): Transfer completes with GoDaddy nameservers still active. You update nameservers post-transfer. Brief propagation window when you switch.
  3. Both paths converge at the same end state: Route 53 as registrar and DNS provider.

Experience Signal: The Transfer That Stalled for 7 Days

A common failure pattern: you initiate the transfer, approve the ICANN email, and then nothing happens for days. The Route 53 console shows IN_PROGRESS indefinitely. The instinct is to blame AWS — but the actual cause is almost always that the domain lock was re-enabled automatically by GoDaddy after you retrieved the auth code.

GoDaddy has a security feature that can re-lock a domain if it detects unusual activity. The observable symptom is that get-operation-detail returns IN_PROGRESS with no status change, and the Registry WHOIS still shows clientTransferProhibited. The fix: return to GoDaddy, confirm the lock is still off, and if GoDaddy offers an "expedite transfer" option in their outgoing transfer dashboard, use it. That instructs GoDaddy to waive the 5-day objection window immediately.

The misdiagnosis is opening an AWS support ticket assuming Route 53 is the bottleneck. Route 53 is waiting on the Registry, which is waiting on GoDaddy. The entire stall lives outside AWS.

Wrap-Up and Next Steps for Route 53 Domain Management

Once the domain transfer to Route 53 completes, you have a single pane of glass for both registration and DNS. From here, consider enabling Route 53 auto-renew (route53domains:EnableDomainAutoRenew) to prevent accidental expiration, and configure Route 53 health checks with DNS failover if your workload requires high availability. For domains with privacy requirements, Route 53 offers WHOIS privacy protection at no additional charge for supported TLDs.

Review the official Route 53 domain transfer documentation for TLD-specific requirements — some ccTLDs have additional steps not covered by the standard flow.

Glossary

TermDefinition
EPP Auth CodeExtensible Provisioning Protocol authorization code — a registrar-issued token required to authorize a domain transfer to a new registrar.
Registrar Lock (Transfer Lock)An EPP status (clientTransferProhibited) set by the registrar that prevents outbound transfers. Must be removed before a transfer can proceed.
TLD RegistryThe authoritative body managing a top-level domain (e.g., Verisign for .com). Registrars communicate with the Registry to execute transfers.
Hosted ZoneA Route 53 container for DNS records for a domain. Separate from domain registration — a hosted zone can exist without Route 53 being the registrar, and vice versa.
ICANN 60-Day LockAn ICANN policy that prohibits domain transfers within 60 days of initial registration or a prior registrar transfer.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more