Route 53
What is DNS?
Route 53
Global service
A highly available, scalable, fully managed and Authoritative DNS (customer can update the DNS records and have full control over the DNS)
Route 53 is also a Domain Registrar (for registering domain names)
It has ability to check the health of your resources.
It is the only AWS service with 100% SLA.
53 in Route 53 refers to the traditional DNS port.
Affected by client's DNS caching (not suitable for Blue-Green Deployment if the client caches DNS queries)
Route 53 - Records
How you want to route traffic for a domain.
Each record contains:
Domain/sub-domain name - ex: example.com
Record Type - ex: A, AAAA, etc.
Value - ex: 12.34.56.78
Routing Policy - how Route 53 responds to queries
TTL (Time To Live) - amount of time the record cached at DNS Resolvers
Route 53 supports the following DNS record types:
(must know) A / AAAA / CNAM / NS
(advanced) CAA / DS / MX / NAPTR / PTR / SOA / TXT / SPF / SRV
Route 53 - Record Types
A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
The target is a domain name which must have an A or AAAA record
Cannot point to root domains (Zone Apex) Ex: you can’t create a CNAME record for
example.com, but you can create forsomething.example.com
NS - Name Servers for the Hosted Zone
- Control how traffic is routed for a domain
Route 53 - Hosted Zones
A container for DNS records that define how to route traffic to a domain and its subdomains.
Hosted zone is queried to get the IP address from the hostname.
There are 2 types of Hosted Zones:
Public Hosted Zones
contains records that specify how to route traffic on the internet (public domain names)
resolves public domain names
can be queried by anyone on the internet
Private Hosted Zones
contains records that specify how you route traffic within one or more VPCs (private domain names)
resolves private domain names
can only be queried from within the VPC
You pay $0.50 per month per hosted zone.
Route 53 - Records TTL
High TTL - ex: 24hr
Less traffic on Route 53
Possibly outdated records
Low TTL - ex: 60sec
More traffic on Route 53 (more cost)
Records are outdated for less time
Easy to change records
Except for Alias records, TTL is mandatory for each DNS record
CNAME vs Alias
AWS resource (Load Balancer, CloudFront, etc.) expose on AWS hostname:
We have 2 options:
CNAME
Alias
Points a hostname to an AWS resource (app.mydomain.com => xyz.amazonaws.com)
Works for root and non-root domain (mydomain.com)
Free of charge
Native health check
Route 53 - Alias Records
AWS proprietary
Can point to root (zone apex) and non-root domains
Maps a hostname to an AWS resource
Automatically recognizes changes in the resource's IP addresses
Alias Record is always of type A/AAAA (IPv4/IPv6)
You can't set the TTL
Targets can be
Elastic Load Balancers
CloudFront Distributions
API Gateway
Elastic Beanstalk environments
S3 Websites
VPC Interface Endpoints
Global Accelerator accelerator
Route 53 record in the same hosted zone
Target cannot be EC2
Route 53 - Routing Policy
Define how Route 53 responds to DNS queries.
Don't get confused by the word 'Routing'.
It is not the same as Load Balancer routing which routes the traffic.
DNS does not route any traffic, it only responds to the DNS queries.
Route 53 supports the following Routing Policies
Simple
Weighted
Failover
Latency based
Geolocation
Multi-Value Answer
Geoproximity (using Route 53 Traffic Flow feature)
Routing Policy - Simple
Route to one or more resources
If multiple values are returned, client chooses one at random (client-side load balancing)
When Alias enabled, specify only one AWS resource.
No health check (if returning multiple resources, some of them might be unhealthy)
Routing Policy - Weighted
Control the % of the requests that go to each specific resource.
Assign each record a relative weight:
traffic (%) = Weight for a specific record / Sum of all the weights for all records
Weights don't need to sum up to 100
DNS records must have the same name and type.
Health Checks.
Use cases: load balancing between regions, testing new application versions, etc.
Assign a weight of 0 to a record to stop sending traffic to a resources.
If all records have weight of 0, then all records will be returned equally.
Can be used for Active-Active failover strategy
Routing Policy - Latency based
Redirect to the resource that has the least latency close to us (Super helpful when latency for users is a priority0
Redirect to the resource that has the lowest latency
Health checks
Can be used for Active-Active failover strategy
Routing Policy - Failover
Primary & Secondary Records (if the primary application is down, route to secondary application)
Health check must be associated with the primary record
Used for Active-Passive failover strategy
Routing Policy - Geolocation
Different from Latency-based, this routing is based on user/client location.
Specify location by Continent, Country or by US State (if there's overlapping, most precise location is selected).
Should create a Default record (in case there's no match on location).
Use cases: website localization, restrict content distribution, load balancing, etc.)
Health Checks
Routing Policy - Geoproximity
Route traffic to your resources based on the geographic location of users/clients and resources.
Ability to shift more traffic to resources based on the defined bias.
To change the size of the geographic region, specify bias values:
To expand (1 to 99) → more traffic to the resource
To shrink (-1 to -99) → less traffic to the resource
Resources can be :
AWS resources (specify AWS region)
Non-AWS resources (specify Latitude and Longitude)
Uses Route 53 Traffic Flow
Routing Policy - IP based
Routing is based on clients IP addresses.
You provide a list of CIDRs for your clients and the corresponding endpoints/locations (user-IP-to-endpoint mapping).
Use cases: Optimize performance, reduce network costs, etc.
Ex: route end users from a particular ISP to s specific endpoint.
Routing Policy - Multi Value
Use when routing traffic to multiple resources.
Health Checks (return only values for healthy resources).
Up to 8 healthy records are returned for each Multi-Value query.
Multi-Value is not a substitute for having an ALB
Route 53 - Health Checks
HTTP Health Checks are only for public resources.
Health Check => Automated DNS Failover (Allows for Automated DNS Failover):
Health checks that monitor an endpoint (application, server, other AWS resource)
Health checks that monitor other health checks (Calculated Health Checks)
Health checks that monitor that monitor CloudWatch Alarms (full control) - ex: throttles of Dynamo DB, alarms on RDS, custom metrics, etc. (helpful for private resources)
Health Checks are integrated with CloudWatch Metrics.
Health Checks - Monitor an Endpoint
About 15 global health checkers will check the endpoint health
Healthy/Unhealthy Threshold - 3 (default)
Interval - 30 sec (can set to 10 sec - higher cost)
if >18% of health checkers report the endpoint is healthy, Route 53 considers it Healthy. Otherwise it's Unhealthy.
Ability to choose which locations you want Route 53 to use.
Health Checks pass only when the endpoint responds with the 2xx and 3xx status codes.
Health Checks can be setup to pass/fail based on the text in the first 5120 bytes of the response.
Configure your router/firewall to allow incoming requests from Route 53 Health Checkers.
Health Checks - Calculated Health Checks
Combine the results of multiple health checks into a single health check.
You can use AND, OR or NOT.
Can monitor up to 256 child health checks.
Specify how many of the health checks need to pass to make the parent pass.
Usage: performance maintenance to your website without causing all the health checks to fail.
Health Checks - Private Hosted Zones
Route 53 health checkers are outside the VPC.
They can't access private endpoints (private VPC or on-premises resource)
You can create a CloudWatch Metric and associate a CloudWatch Alarm, then create a health check that checks the alarm itself.
Domain Registrar VS DNS Service
You can buy or register your domain name with a Domain Registrar typically by paying annual charges (ex: GoDaddy, Amazon Registrar, etc.)
The Domain Registrar usually provides you with a DNS Service to manage your DNS Records.
But you can use another DNS service to manage your DNS records.
Ex: Purchase the domain from GoDaddy and use Route53 to manage your DNS records.
3rd Party Registrar with Amazon Route 53
If you buy your domain on a 3rd party registrar, you can still use Route 53 as the DNS service provider.
Create a public hosted zone in Route 53.
Update NS records on 3rd party website to use Route 53 Name Servers.
Domain Registrar != DNS Service
But every Domain Registrar usually comes with some DNS features.
GoDaddy with Route 53
Use GoDaddy as registrar and Route 53 as DNS
- Once we register a hostname at GoDaddy, we need to update the name servers (NS) of GoDaddy to match the name servers of a public hosted zone created in Route 53. This way, GoDaddy will use Route 53’s DNS.
DNS Resolution in Hybrid Cloud
To resolve DNS queries for resources in the VPC from the on-premises network, create an inbound endpoint on Route 53 Resolver and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint.
To resolve DNS queries for resources in the on-premises network from the VPC, create an outbound endpoint on Route 53 Resolver and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint. To conditionally forward queries, create Resolver rules that specify the domain names for the DNS queries that you want to forward (such as example.com) and the IP addresses of the DNS resolvers on the on-premises network that you want to forward the queries to.