- Amazon Route 53 is a comprehensive and fully-managed DNS web service provided by AWS; it is an authoritative DNS service, meaning that users have full control over updating and managing their DNS records (this includes configurations for A records, CNAME records, MX records, and more).
- A highly available, scalable, fully
managed and Authoritative DNS
- Authoritative = the customer (we) can update the DNS records.
- Route 53 is also a Domain Registrar.
- Ability to check the health of your resources
- The only AWS service which provides 100% availability SLA
- it distributes DNS queries across multiple locations globally, ensuring low-latency responses and high availability
- Domain name registration. We use Route 53 to register the domain name for your website or application. After you choose a domain name and it is verified, the domain name is registered with Route 53. Route 53 DNS records can also be linked to an existing domain. When a domain has been registered with Route 53, Route 53 becomes the DNS service for the domain and creates a hosted zone for the domain.
- DNS resolution. Route 53 routes Internet traffic to the resources for our domain:
- Public-facing resources. A public hosted zone is required for public-facing resources such as a company website.
- Private-facing resources. Private hosted zones are created to route traffic within a VPC.
- Health checks: Automated health checks can be delivered on a persistent schedule
to cloud services and resources to confirm they are still available and functioning (working).
When resources become unavailable, Route 53 routes requests from unhealthy resources to healthy resources.
- The health of resources: Health checks can monitor selected endpoints based on their DNS name, IP address, or domain name to verify whether resources are reachable and functioning. Humble Bundle Pearson Networking and Security Certification Bundle – © Pearson. Do Not Distribute. 350 AWS Certified Solutions Architect – Associate (SAA-C03) Cert Guide
- The status of other health checks: Health checks can monitor multiple regional workloads to ensure that healthy resources are available across AWS regions or resources located on other public clouds or on premises.
- The status of CloudWatch alarms: Route 53 can monitor the same metrics being monitored by CloudWatch and make decisions without needing to communicate directly with the CloudWatch service.
-
Route 53 supports the following DNS record types:
-
Each record contains:
- Domain / subdomain Name – e.g., example.com
- Record Type – e.g., A or AAAA
- Value – e.g., 12.34.56.78
- Routing Policy – how Route 53 responds to queries
- TTL – amount of time the record is cached at DNS Resolvers
- A hosted zone is similar to a traditional DNS zone file. It represents a container to collect DNS records that can be managed together ,belonging to a single parent domain name. All the DNS record sets within a hosted zone share the same parent domain name. It means that all the DNS records within a hosted zone share the same parent domain name. It means that all the DNS records within a hosted zone must have the hosted zone's domain name as a suffix.
- Each hosted zone has two records:
- We pay $0.50 per month per hosted zone.
- Contains DNS records involving public domain names & public-facing resources such as a company website. These are domain names that are accessible and resolvable globally on the public Internet.
- Contains DNS records involving private domain names & resources within one or more VPCs. These domain names are not accessible from the public Internet and are used for internal communication within an organization’s network.
- The Time-to-Live (TTL) value in DNS records plays a crucial role in how DNS caching and record updates are handled. The choice of TTL depends on the specific requirements and trade-offs between reducing traffic, minimizing outdated records, and the need for quick updates.
- High TTL – e.g., 24 hr
- Less traffic on Route 53 and lower costs.
- Possibly outdated records (slow propagation) when changes are made to DNS records.
- Low TTL – e.g., 60 sec.
- More traffic on Route 53 ($$) and increased costs.
- Records are outdated for less time ensuring that changes to DNS records are propagated quickly.
- Easy to change records.
- Except for Alias records, TTL is mandatory for each DNS record
-
Maps a hostname (domain or subdomain) to an AWS resource, such as an Elastic Load Balancer (ELB), CloudFront distribution, or an S3 bucket extending the traditional DNS functionality by allowing seamless mapping to AWS resources without the need for manual updates.
-
Automatically recognizes changes in the AWS resource’s IP addresses
-
Unlike CNAME, Alias works for both root and non-root domains. It can be used for the top node (top level domain) of a DNS namespace (Zone Apex), e.g.: example.com
-
Alias Record is always of type A / AAAA for AWS resources (IPv4 / IPv6)
-
We cannot set the TTL.
-
Provides native health checks.
-
Free of charge.
-
Alias records cannot be directly used for EC2 instances DNS names.
-
Targets:
- ELB
- CloudFront
- S3 Websites
- Amazon API Gateway
- Elastic Beanstalk
- VPC interface endpoints
- Global Accelerator
- Route 53 record.
- When Route 53 receives a query, a routing policy determines the response.
- Simple DNS response providing the IP address associated with a name. Due is simple (one IP or value) it cannot be associated (no sense) with Health Checks.
- When Alias enabled, specify only one AWS resource.
- If multiple values are returned, a random one is chosen by the client.
- Use case: A single resource, such as a web server, that is serving content for a single domain.
Name | Type | Value | TTL |
---|---|---|---|
simple.axample.com | A | 10.0.0.10 | 60 |
10.0.0.11 | |||
10.0.0.12 |
- Control the % of the requests that go to each specific resource.
- This is used to route traffic to multiple resource properties as defined by us (for example, we want to say 80% traffic to site A and 20% to site B.
- Can be associated with Health Checks
- Use Case: For routing traffic to multiple resources at defined traffic levels. Load balancing between regions, testing new application versions...
Name | Type | Value | Health | Weight |
---|---|---|---|---|
simple.axample.com | A | 10.0.0.10 | ID | 60 |
simple.axample.com | A | 10.0.0.20 | ID | 20 |
simple.axample.com | A | 10.0.0.30 | ID | 20 |
- If the primary resource is not responding, the request is sent to the secondary location.
Name | Type | Value | Health | |
---|---|---|---|---|
simple.axample.com | A | 10.0.0.10 | ID | primary |
simple.axample.com | A | alb-id | secondary |
- This optimizes the best latency for the resources deployed in multiple AWS Regions. Redirect to the resource that has the least latency close to us.
- Latency is based on traffic between users and AWS Regions
- Can be associated with Health Checks (has a failover capability)
Name | Type | Value | Health | Region |
---|---|---|---|---|
simple.axample.com | A | 10.0.0.10 | ID | ap-southeast-1 |
simple.axample.com | A | 10.0.0.20 | ID | us-east-1 |
simple.axample.com | A | alb-id | ID | ap-southeast-2 |
- How is resolved the query ?.
- When a user performs a DNS query, Route 53 evaluates the latency between the user and the configured latency regions.
- It returns the IP associated with the latency region that offers the lowest latency for the user.
- Route 53 does not check whether the IP is actually located in the specified latency region. It simply returns the IP associated with the lowest latency region.
- This routing is based on user location. Specify location by Continent, Country or by US State (if there’s overlapping, most precise location selected).
- Should create a “Default” record (in case there’s no match on location).
- Can be associated with Health Checks.
- Use case: For routing traffic based on the physical location of the end user. Website localization, restrict content distribution, load balancing, ...
Name | Type | Value | Health | Geo-location |
---|---|---|---|---|
simple.axample.com | A | 10.0.0.10 | ID | Singapore |
simple.axample.com | A | 10.0.0.20 | ID | Default |
simple.axample.com | A | alb-id | ID | Oceania |
- This is used to respond to DNS queries with up to eight healthy, randomly selected records. It allows us to specify multiple IP addresses for a resource.
- Using multiple IP addresses with health checks, Route 53 will return records for healthy resources that respond successfully to health checks.
- Use case: For responding with up to eight healthy address records
Name | Type | Value | Health | Multi-value |
---|---|---|---|---|
simple.axample.com | A | 10.0.0.10 | ID | Yes |
simple.axample.com | A | 10.0.0.20 | ID | Yes |
simple.axample.com | A | 10.0.0.30 | ID | Yes |
- Route traffic to our resource based on the geographic locations of our users and requested resources. This routing requires us to create a defined Route 53 traffic policy (traffic flow).
- 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)
- Use case: For routing traffic based on the location of our AWS resources
- Routing is based on clients’ IP addresses.
- We provide a list of CIDRs for our clients and the corresponding resource-ip/endpoints/locations (user-CIDR-to-resourceIP mappings)
- Use cases: Optimize performance, reduce network costs, route end users from a particular ISP to a specific endpoint.
- We can build advanced routing policies by nesting these (explained) primary routing policies into traffic policies; the following diagram shows a nested policy architecture defined using the tool called "Traffic flow".
- If we buy our domain on a 3rd par ty registrar, we can still use Route 53 as the DNS Service provider
- Create a 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
- We can purchase the domain from GoDaddy:
- For internal private DNS (Private Hosted Zone), you must enable the VPC settings enableDnsHostnames and enableDnsSupport
- DNS Security Extensions (DNSSEC)
- A protocol for securing DNS traffic, verifies DNS data integrity and origin
- Protects against Man in the Middle (MITM) attacks
- Route 53 supports both DNSSEC for Domain Registeration and DNSSEC Signing
- Works only with Public Hosted Zones
- Route 53 with 3rd Registrar
- You can buy the domain out of AWS and use Route 53 as the DNS provider
- Update the NS records on the 3rd party Registrar
-
HTTP Health Checks are only for public resources.
-
Health check => Automated DNS failover (conmutación por error / tolerancia a fallos)
- 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 CloudWatch Alarms (full control !!) – e.g., throttles of DynamoDB, alarms on RDS, custom metrics, ... (helpful for private resources)
-
Health Checks are integrated with CloudWatch metrics
- Combine the results of multiple Health Checks into a single Health Check
- You can use OR, AND, or NOT
- Can monitor up to 256 Child Health Checks
- We can specify how many of the health checks need to pass to make the parent pass
- Usage: perform maintenance to your website without causing all health checks to fail
- About 15 global health checkers will check the endpoint health
- Healthy/UnhealthyThreshold–3(default)
- Interval – 30 sec (can set to 10 sec – higher cost)
- Supportedprotocol:HTTP, HTTPSandTCP
- 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 you router/firewall to allow incoming requests from Route 53 Health Checkers
Route 53 health checkers ip address range
- 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