How to Transfer a Domain from GoDaddy (or Any Registrar) to Route 53

You bought a domain on GoDaddy, but your infrastructure lives in AWS — managing DNS in two separate consoles is friction you don't need. Transferring your domain to Route 53 consolidates registrar and DNS management under one roof, enabling tighter IAM-based access control and unified billing.

TL;DR

StepActionWho Does It
1Unlock domain & disable privacy at current registrarYou (GoDaddy console)
2Get the Authorization (EPP/Auth) CodeYou (GoDaddy console)
3Initiate transfer in Route 53You (AWS Console / CLI)
4Confirm transfer via emailYou (email from ICANN/registrar)
5Wait for transfer completion (up to 10 days)Registrars + ICANN
6Verify hosted zone & DNS recordsYou (Route 53 console)

Prerequisites & Key Rules

  • 60-day lock rule: ICANN prohibits transferring a domain that was registered or previously transferred within the last 60 days.
  • Domain must be unlocked: The registrar-lock (also called transfer lock) must be disabled at GoDaddy before initiating the transfer.
  • Valid WHOIS email: The registrant email on file must be reachable — ICANN sends a confirmation email to this address.
  • TLD support: Not all top-level domains (TLDs) can be transferred to Route 53. Verify your TLD is supported in the Route 53 TLD reference.
  • Fee: Route 53 charges a transfer fee (which includes a 1-year registration extension). The exact price varies by TLD — always check the Route 53 domain pricing page for current rates.
Analogy: Think of this like porting your mobile number to a new carrier. You need to unlock your account, get a transfer PIN (Auth Code), and the new carrier (Route 53) handles the rest — but the number (domain) keeps working throughout.

Transfer Flow: Architecture Overview

sequenceDiagram participant You participant GoDaddy participant Route53 participant ICANN You->>GoDaddy: Unlock domain and get Auth Code GoDaddy-->>You: Auth Code via email You->>Route53: Submit transfer request with Auth Code Route53->>ICANN: Notify transfer initiated ICANN-->>You: Send confirmation email You->>ICANN: Approve transfer ICANN->>GoDaddy: Request release GoDaddy-->>Route53: Release domain (auto after 5 days) Route53-->>You: Transfer complete notification
  1. GoDaddy (Losing Registrar): You unlock the domain and retrieve the EPP/Auth Code from the GoDaddy dashboard.
  2. Route 53 (Gaining Registrar): You submit the transfer request with the Auth Code via the AWS Console or CLI.
  3. ICANN Confirmation: An automated email is sent to the registrant email address. You must approve the transfer.
  4. GoDaddy Approval Window: GoDaddy has up to 5 days to approve or reject. If no action is taken, it auto-approves.
  5. Transfer Complete: Route 53 becomes the authoritative registrar. A hosted zone is created (or linked) for DNS management.

Step-by-Step: Detailed Implementation

Step 1 — Unlock the Domain at GoDaddy

  1. Log in to your GoDaddy account.
  2. Navigate to My Products → Domains.
  3. Select your domain → click Domain Settings.
  4. Under Additional Settings, disable Domain Lock.
  5. If WHOIS Privacy is enabled, temporarily disable it so the registrant email is visible and reachable.

Step 2 — Get the Authorization (EPP) Code

  1. In GoDaddy Domain Settings, click Get authorization code. GoDaddy emails this code to the registrant address.
  2. Keep this code ready — it expires and is single-use.

Step 3 — Initiate Transfer in Route 53 (Console)

  1. Open the Route 53 console.
  2. In the left nav, choose Registered domains → Transfer domain.
  3. Enter your domain name and click Check.
  4. If the domain is eligible, click Add to cart → Continue.
  5. Enter the Authorization code from Step 2.
  6. Review or update registrant contact details.
  7. Choose whether to auto-renew and enable privacy protection.
  8. Complete the purchase — Route 53 charges the transfer fee to your AWS account.

Step 3 (Alternative) — Initiate Transfer via AWS CLI

🔽 [Click to expand] AWS CLI: Transfer Domain 
# Transfer a domain to Route 53 using the CLI
# Replace all placeholder values before running

aws route53domains transfer-domain \
  --region us-east-1 \
  --domain-name "example.com" \
  --duration-in-years 1 \
  --auth-code "YOUR_EPP_AUTH_CODE" \
  --auto-renew \
  --admin-contact file://contact.json \
  --registrant-contact file://contact.json \
  --tech-contact file://contact.json \
  --privacy-protect-admin-contact \
  --privacy-protect-registrant-contact \
  --privacy-protect-tech-contact

Note: Route 53 domain registration APIs are only available in the us-east-1 region, regardless of where your other resources reside.

// contact.json — sample registrant contact 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"
}

Step 4 — Confirm the Transfer via Email

  • Check the registrant email inbox for a confirmation email from either ICANN or Route 53.
  • Click the confirmation link within the specified window (typically 5–7 days, but act promptly).
  • Failure to confirm will cause the transfer to be cancelled automatically.

Step 5 — Monitor Transfer Status

# Check transfer status via CLI
aws route53domains get-domain-detail \
  --region us-east-1 \
  --domain-name "example.com"

# Or list all operations to find your transfer operation ID
aws route53domains list-operations \
  --region us-east-1

Transfer typically completes within 5–10 days. You can also monitor status in the Route 53 console under Registered domains → Pending requests.

Step 6 — Verify Hosted Zone & DNS Records

  • Route 53 automatically creates a public hosted zone for your domain upon transfer completion.
  • Critically: DNS records are NOT automatically migrated from GoDaddy. You must manually recreate your A, CNAME, MX, TXT, and other records in the new hosted zone.
  • Before the transfer completes, export your existing DNS records from GoDaddy and pre-populate the Route 53 hosted zone to minimize downtime.
  • After transfer, verify the NS records in Route 53 match the nameservers now listed in the WHOIS for your domain.

DNS Record Migration Strategy (Zero-Downtime)

graph LR A[Export DNS from GoDaddy] --> B[Create Hosted Zone in Route 53] B --> C[Replicate all DNS Records] C --> D[Lower TTLs at GoDaddy] D --> E[Initiate Domain Transfer] E --> F[Transfer Completes] F --> G[Route 53 NS becomes Authoritative] G --> H[Restore TTLs to Normal]
  1. Export DNS records from GoDaddy before initiating the transfer.
  2. Create a hosted zone in Route 53 and replicate all records.
  3. Lower TTLs on critical records at GoDaddy (e.g., to 60 seconds) 24–48 hours before transfer.
  4. Once the transfer completes and Route 53 nameservers are authoritative, your pre-populated records serve traffic immediately.
  5. Restore TTLs to normal values (e.g., 300–3600 seconds) after confirming resolution.

IAM Permissions Required

The IAM principal initiating the transfer needs the following minimum permissions. Route 53 domain registration is a global service but its API endpoint is in us-east-1.

🔽 [Click to expand] IAM Policy: Route 53 Domain Transfer 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDomainTransfer",
      "Effect": "Allow",
      "Action": [
        "route53domains:TransferDomain",
        "route53domains:GetDomainDetail",
        "route53domains:ListOperations",
        "route53domains:CheckDomainTransferability"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowHostedZoneManagement",
      "Effect": "Allow",
      "Action": [
        "route53:CreateHostedZone",
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets",
        "route53:GetHostedZone"
      ],
      "Resource": "*"
    }
  ]
}

Common Pitfalls & How to Avoid Them

PitfallImpactPrevention
Not pre-populating DNS records in Route 53DNS outage after transferReplicate records before transfer completes
Registrant email unreachableTransfer confirmation fails, auto-cancelledVerify email access before starting
Domain transferred within last 60 daysTransfer blocked by ICANN policyCheck registration date first
Unsupported TLDRoute 53 rejects the transferCheck TLD support list before initiating
High TTLs on DNS recordsSlow propagation after cutoverLower TTLs 24–48 hrs before transfer

Glossary

TermDefinition
EPP/Auth CodeExtensible Provisioning Protocol authorization code — a secret token required to authorize a domain transfer between registrars.
Registrar LockA security flag set by the registrar that prevents unauthorized transfers. Must be disabled before initiating a transfer.
Hosted ZoneA Route 53 container for DNS records for a specific domain. Created automatically upon transfer completion.
TTL (Time to Live)The duration (in seconds) that DNS resolvers cache a record. Lower TTLs reduce propagation delay during cutover.
ICANNInternet Corporation for Assigned Names and Numbers — the governing body that mandates transfer confirmation policies.

Next Steps

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more

EC2 SSH Connection Timeout: The Exact Security Group Rules You Need to Fix It

You've launched a fresh EC2 instance, fired up your terminal, and run ssh ec2-user@<your-ip> — only to watch the cursor hang until Connection timed out kills your hope. This is one of the most common EC2 onboarding blockers, and it almost always traces back to a misconfigured Security Group inbound rule. TL;DR Check What to Verify Correct Value Protocol Security Group inbound rule protocol TCP Port Destination port in the inbound rule 22 Source Allowed source CIDR or IP Your public IP (e.g., 203.0.113.10/32 ) or 0.0.0.0/0 for testing Instance State EC2 instance status checks 2/2 checks passed Subnet Route Table Route to Internet Gateway (public subnet) 0.0.0.0/0 → igw-xxxxxxxx Public IP / EIP Instance has a reachable public address Public IPv4 or Elastic IP assigned Why "Connection Timed Out" Specifically? A timeout (as opposed to Connection refused ) means your TC...
Read more