Absolutely! Let’s create a complete, structured blog-style explanation that ties together DNS, Route 53, A vs CNAME records, AWS vs Kubernetes, LocalStack, Spring Boot, and failover, in a clear, step-by-step narrative. I’ll make it educational, blog-ready, and thorough.
π Understanding DNS, Route 53, and Failover: From AWS API Gateway to Kubernetes Spring Boot
In modern cloud architecture, DNS and failover are crucial for building highly available services. This post explains everything from the basics of DNS records to how AWS Route 53 works with both managed API Gateways and your own Kubernetes-based Spring Boot services.
We’ll cover:
What DNS is
A records vs CNAME
AWS API Gateway and why it provides a DNS name
Route 53 failover
LocalStack simulation
Kubernetes + Spring Boot failover setup
Differences and best practices
1️⃣ What Is DNS?
DNS (Domain Name System) translates human-readable domain names into machine-readable IP addresses.
Example:
api.example.com → 93.184.216.34
Without DNS, we’d have to remember IP addresses for every server.
Key Records
| Record Type | Maps To | Example |
|---|
| A (Address) | IPv4 Address | api.example.com → 192.168.1.100 |
| CNAME (Canonical Name) | Another DNS name | api.example.com → my-gateway.example.com |
2️⃣ Understanding A Records
An A record maps a domain name directly to an IP address.
api.hello.com → 192.168.49.2
When to use A record:
You control the IP
Service is reachable via IP (e.g., Kubernetes NodePort, LoadBalancer)
Health checks and failover operate directly on IP
Example in Kubernetes
If you run a Spring Boot service in Kubernetes:
NodePort: 192.168.49.2:30001 → app-a
NodePort: 192.168.49.2:30002 → app-b
You can create an A record in Route 53:
api.hello-localstack.com → A → 192.168.49.2
DNS resolves directly to the node IP, and Route 53 health checks can monitor it.
3️⃣ Understanding CNAME Records
A CNAME record maps a domain name to another domain name, not directly to an IP.
api.example.com → CNAME → abc123.execute-api.us-east-1.amazonaws.com
Resolution flow:
Client queries api.example.com
DNS returns abc123.execute-api.us-east-1.amazonaws.com
DNS resolves that hostname to an IP
Client connects to the resolved IP
When to use CNAME:
The target is a managed service with no fixed IP (e.g., AWS API Gateway)
You want a friendly custom domain pointing to an existing service
You need automatic IP updates handled by the service provider
4️⃣ AWS API Gateway and DNS Names
When you create an API Gateway in AWS:
abc123.execute-api.us-east-1.amazonaws.com
This is why, in the LocalStack Python tutorial:
12345.hello-localstack.com → CNAME → 12345.execute-api.localhost.localstack.cloud
You cannot use an A record here because there is no stable IP — only a managed hostname.
Key Difference: AWS vs Your Own Gateway
| Feature | AWS / LocalStack | Spring Boot / K8s |
|---|
| IP | Managed, dynamic | Known (Node/LB IP) |
| DNS | Provided | Optional |
| Scaling | AWS handles | You handle pods & replicas |
| Failover | AWS internal | You configure health checks |
5️⃣ Route 53 Failover
Route 53 is AWS’s DNS service. It allows:
Mapping domain names → IPs or other DNS names
Health-check–based failover
Weighted routing or latency-based routing
Failover Example
api.hello-localstack.com
├── PRIMARY → 192.168.49.2 (app-a) Health: OK
└── SECONDARY → 192.168.49.2 (app-b) Health: OK
If app-a fails, Route 53 automatically returns the secondary IP.
6️⃣ LocalStack: Simulate AWS Locally
LocalStack allows you to run AWS services locally, including:
Route 53
API Gateway
Lambda
It’s perfect for testing failover without touching AWS.
Example Command
awslocal route53 change-resource-record-sets \
--hosted-zone $HOSTED_ZONE_ID \
--change-batch '{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "12345.hello-localstack.com",
"Type": "CNAME",
"TTL": 60,
"ResourceRecords": [
{"Value": "12345.execute-api.localhost.localstack.cloud"}
]
}
}
]
}'
This creates a CNAME pointing to LocalStack’s API Gateway.
7️⃣ Kubernetes + Spring Boot Failover Setup
Instead of using API Gateway:
Deploy multiple Spring Boot services in Kubernetes (app-a, app-b)
Expose them using NodePort or LoadBalancer
Use Route 53 A records pointing to node or load balancer IPs
Add health checks to enable failover
Example
NodePort: 192.168.49.2:30001 → app-a
NodePort: 192.168.49.2:30002 → app-b
DNS in Route 53:
api.hello-localstack.com → A → 192.168.49.2
Route 53 evaluates health and returns the healthy backend’s IP.
8️⃣ Why Not CNAME in K8s?
Pods/services have direct IPs
Using A records is simpler and faster
CNAME is only needed if your service already has a hostname
9️⃣ Choosing Between A Record and CNAME
| Scenario | Recommended Record | Reason |
|---|
| API Gateway (AWS/LocalStack) | CNAME | Managed DNS name, no fixed IP |
| Kubernetes NodePort / LoadBalancer | A | IP known, health checks operate on IP |
| CloudFront / ALB | Alias | AWS-managed DNS pointing to AWS resource |
| Your own host with hostname | CNAME | Alias to another DNS name |
π Summary
DNS translates domain names to IPs or other domain names.
A records → IP, CNAME → DNS name.
AWS API Gateway gives a DNS name → use CNAME.
Your Spring Boot/K8s API Gateway exposes IP → use A record.
Route 53 failover switches traffic based on health checks.
LocalStack lets you simulate all this locally.
Mental rule: “If the service provides an IP → use A record; if it provides a hostname → use CNAME.”
This is everything from the basics to a full Route 53 failover setup — from Python AWS API Gateway to Java Spring Boot in Kubernetes.
If you want, I can create a diagram-rich version of this blog with:
This makes it visually compelling for readers.
Do you want me to do that next?
