Deploying an Application on an AWS Route 53 Domain

A step-by-step walkthrough for giving your application a public, HTTPS URL on a domain you host in AWS Route 53 — and the one add-on every target cluster needs so those URLs actually resolve.

🔑 The one requirement people miss

For a Route 53 domain, every cluster you deploy to must have the “External DNS – AWS” add-on installed. It is what writes and maintains your app’s Route 53 records. The “External DNS – PowerDNS” add-on (used for SeaGit’s managed *.segt.io domains) is not a substitute — a cluster without External DNS – AWS will deploy your app successfully but its URL will silently never resolve.

What you’ll end up with

When this is set up correctly, deploying an application produces a stable public URL on your domain — for example my-app.prod.example.com — served over HTTPS with a certificate issued automatically. You never touch a DNS record or a load-balancer hostname by hand.

This guide is the AWS/Route 53-specific companion to DNS & Domains, Domains, and Applications.

How SeaGit fills in your Route 53 records

Three pieces cooperate to turn a deployment into a working URL on a Route 53 domain:

The ingress controller (Ingress – NGINX or the AWS Load Balancer Controller) — owns the load balancer that receives traffic for the cluster.
SeaGit’s deployer — when your app deploys, it seeds a placeholder DNS record for the deployment’s hostname in your Route 53 hosted zone.
External DNS – AWS — a controller running inside your cluster. It watches the ingress and adopts the placeholder, re-pointing the record at the load balancer that is actually live, and keeping it in sync forever after.

Remove that middle-out controller and the placeholder is never adopted: the record stays absent (or stuck), so the URL doesn’t resolve. Because the deployment itself still reaches started, the failure is easy to miss — which is exactly why this guide leads with it.

Prerequisites

An AWS provider connected to the account that owns your Route 53 hosted zone.
A domain in SeaGit backed by a Route 53 hosted zone (SeaGit can create the zone for you, or you can attach an existing one).
One or more clusters, up and running.

Walkthrough

Step 1 — Connect the provider and domain

Add your AWS provider, then create a domain backed by a Route 53 hosted zone. SeaGit records the zone so it can write to it on your behalf.

Step 2 — Install “External DNS – AWS” on every target cluster

On each cluster that will run the app, open its cluster add-ons and install External DNS – AWS. Point it at the Route 53 domain(s) it should manage.

⚠️ Do not confuse the two External DNS add-ons

External DNS – AWS → for domains in Route 53 (this guide).
External DNS – PowerDNS → for SeaGit’s managed *.segt.io domains only.

Having PowerDNS installed does not cover a Route 53 domain. Match the add-on to where your zone actually lives.

Step 3 — Create an environment on the domain

Create an environment on that Route 53 domain and attach the cluster(s) from Step 2. Every deployment in the environment gets a subdomain on this domain.

Step 4 — Deploy your application

Create your application and deploy it into the environment with the URL exposed. SeaGit authors the deployment, brings up the ingress, seeds the Route 53 placeholder, and issues a TLS certificate in the background.

Step 5 — Verify

The deployment reaches started and shows an access URL such as my-app.prod.example.com.
Within a minute or two, External DNS – AWS adopts the record. The URL resolves and serves your app.
HTTP redirects to HTTPS and the certificate is valid — see Certificates & TLS.

# The record External DNS – AWS creates in your hosted zone
my-app.prod.example.com.        A(alias)  ->  <cluster>-nlb-nginx-....elb.amazonaws.com.
my-app.prod.example.com.        TXT       "heritage=external-dns,external-dns/owner=..."   # ownership marker

The TXT ownership record is the tell-tale sign that External DNS – AWS is managing the record. No TXT owner record for your hostname = the add-on isn’t running on that cluster.

Multi-cluster environments (the subtle one)

An environment can span several clusters. When it does, each deployment gets:

a main URL — my-app.prod.example.com — that routes across the clusters, and
a per-cluster URL for each cluster — my-app-<cluster>.prod.example.com.

⚠️ Every cluster in the environment needs External DNS – AWS

Each cluster manages its own per-cluster record. If one cluster is missing the add-on, its per-cluster URL silently never resolves — while the main URL keeps working through the healthy clusters. The deployment still shows started, so the gap is invisible until someone tries the affected cluster’s URL. Install External DNS – AWS on all of them.

Troubleshooting

My app’s URL doesn’t resolve, but the deployment says “started”

The number-one cause on a Route 53 domain is a target cluster that doesn’t have External DNS – AWS installed. Check:

The cluster’s add-ons include External DNS – AWS (having only External DNS – PowerDNS is the common trap).
Your Route 53 hosted zone has an A/alias and a TXT owner record for the hostname. No records = nothing is managing them.

Install the add-on and the records appear within a minute or two — no redeploy needed.

Only one cluster’s URL fails in a multi-cluster environment

That cluster is the one missing the add-on. Install External DNS – AWS on it; its per-cluster record gets created and the URL comes up.

The URL resolved, then broke after a cluster stop/start

Expected for the first few minutes after a start while the load balancer is rebuilt — External DNS – AWS re-points the record automatically. If it persists, confirm the add-on and ingress controller are healthy on the cluster. See DNS & Domains.

Previous: Multi-Region Clusters Next: Troubleshooting