Can't read this? Access the online version of our newsletter!

Hi 👋🏽,

We hope that everything's alright on your side - maybe you're already heading into the vacation or you're just enjoying the weather - which is hopefully not too hot! 🏝️

This week we want to talk about Amazon Route 53 📌

For understanding what Route 53 is and how to work with it, we'll go through the fundamentals of the worldwide DNS first. Then we'll talk about Route 53's capabilities and why it's more than just a simple resolver.

This includes a look at all of its simple and advanced routing policies and more great features like health checks that can be tied to your records!

Before diving into this, we'd like to drop you a wrap-up in the form of an infographic ↓

​

The Fundamentals of DNS

Naming is crucial in distributed systems for identifying entities.

The internet's DNS provides...

• 🙋‍♀️ human-friendly hostnames for
• 🤖 computer-friendly IP addresses

A common example to visualize this is to think of it as a phone book for the internet. If you want to call somebody, you need some kind of directory that helps you find their number. 📞

The Domain Name System Is a Decentralized System

DNS management has a unique feature of decentralized control, allowing high scalability and avoiding a single point of failure.

It has a hierarchical structure maintained by registries in different countries, with authoritative name servers at the top holding actual addresses for DNS records, followed by top-level domain servers, root name servers, and recursors as we go down.

Multiple Services on Different Levels Take Part in Resolving Domain Names

When resolving domain names, we need to distinguish between two types of services:

• 👑 Authoritative DNS Service - respond to queries and provide IP address information to clients and recursive services. Owns the records.
• ⚡️ Resolver or Recursive DNS Service - does not own DNS records, but connects to other DNS services as an intermediary to resolve any given record. A record can be immediately provided to a client if it is already cached.

What's caching and why it would be impossible to provide DNS on a global scale without it?

Caching to Speed up Requests and Reduce the Load on Resolvers

Caching is the process of saving information for a short period to reduce the load on up or downstream systems that are part of a request.

Caching is crucial to keep the internet’s DNS resolvers healthy. 🏥

There are different locations where caching takes place. The two most obvious of those caching locations are

• your browser and
• your operating system

The closer the caching is to your browser, the better, as it reduces the number of required processing steps, often through different systems.

​

Now that we understand how DNS works, let's explore Amazon Route 53! 📌

Hosted Zones - A Container For Records

A hosted zone acts as a container for several records that specify how traffic should be routed for the root domain and its subdomains. Hosted zones come in two different flavors: public and private.

• Public-hosted zones do route traffic on the internet and can be resolved from anywhere in the world.
• Private-hosted zones are for DNS records within your private VPC and are not exposed to the internet. The domains can only be resolved from inside your VPC.

Routing Traffic to Your Resources

You can use Route 53 to route traffic to various AWS services, including:

• 🏗️ API Gateway APIs
• 🌎 CloudFront distributions
• 🤖 EC2 instances
• 🔀 Elastic Load Balancers
• 🪣 A statically hosted website at S3

There are different types of routing that you can use for your domain names. Let’s dive into those policies in the paragraph.

Choosing the Right Routing Policy

The type determines how Amazon Route 53 responds to queries for those domain names. The selection of the best-fitting record types highly depends on your requirements.

🔶 Simple Routing - Forward Requests to One or Multiple Resources

The standard DNS record for a single resource.

No multiple records with the same name are allowed.

Specify multiple values for one record. Route53 returns all values and the client selects one by himself.

🔶 Weighted Routing - Allocate Traffic Proportionally between Multiple Targets

You can define multiple records for the same domain name using it and control the traffic distribution among them by assigning a percentage, as the name suggests.

Prominent use cases are load balancing and testing new features or releases.

Weighted routing not only enables you to quickly scale your application but also build blue/green deployments or do traffic shifting that is fully in your control.

🔶 Failover Routing - Send Traffic to a Fallback Resource If the Main Target Is Unhealthy

In a multi-region setup with latency-based routing, if the nearest region for a customer is unavailable, we should avoid routing requests to that region. 🔥

That’s where health checks come in. Health checks in Route 53 allow you to monitor the availability of AWS-native or external endpoints.

Those checks are configurable:

• the time between two independent checks
• from which locations they should origin

The exciting part: You can attach the health checks to your Latency-based records. If a location's health check becomes unhealthy, the corresponding target will no longer be propagated for that DNS record.

🔶 Latency-Based Routing - Forwarding Requests to a Resource That Is the Closest to the Customer

In a multi-region setup, you want to route requests to the closest region for faster responses.

With Latency-based routing, create multiple records for a domain, each for a specific region. When queried, Route 53 chooses the record with the lowest latency.

🔶 Geolocation Routing - Redirecting Traffic Based on the Location of the Customer

Geo-Location records allow routing based on the origin of your clients. This enables you to easily localize content or implement geo-restrictions to comply with regulations.

The granularity of locations is either by continent, country, or even US state.

Leveraging Route 53 To Build A Multi-Region Setup for Serverless Architectures

For serverless architectures, deploying your eco-system globally won’t increase your costs significantly. Unused resources don’t contribute to your bill, so adding more regions won’t affect your charges.

To build a multi-region setup with Route 53, follow these steps:

• Configure health checks for each region
• Set up latency-based DNS records for each regional endpoint
• Attach health checks to DNS records

If all regions are healthy, requests go to the region with the lowest latency. Even if a region has little or no traffic, it won’t affect anything.

In case of a regional outage or accidental application breakage due to a faulty deployment, Route 53 quickly fails over. It won't return the unresponsive region for any DNS query, preventing significant outages.

This may cause slower requests for origins with long distances, but it only affects the application's availability for a brief period.

Building your own Canary Deployment System

Canary deployments roll out new app versions to a small user group first to avoid deploying errors to many users. This allows checking for issues before a wider rollout.

Jumping into Networking fundamentals: Services like ALB can route traffic based on headers or cookies, so you can send specific users to a dedicated deployment.

The ALB will terminate the TLS connection. The downstream service, such as an ECS task, communicates with the ALB over a separate HTTP or HTTPS connection, depending on the configuration of the ALB.

Some architectures can't support simple traffic routing, such as those needing secure connections to the application container.

For example, if a TLS connection is terminated within the container (e.g. with an NGINX container) in an ECS cluster, you need to use an ELB instead of an ALB.

ELB works on the transport layer and doesn't terminate the TLS connection, forwarding the request as is. This ensures end-to-end encryption from the client to the application, increasing security.

⚡️ The obvious downside and problem: For HTTPS requests, services in between (including ELB) can't inspect request details to make routing decisions. Instead, we can set weights on target groups to route traffic percentages to each group.

In serverless architectures, we use AWS API Gateway instead of load balancers to route requests to different Lambda function versions.

Setting up routing to different function versions can be challenging if the infrastructure is coupled with the function code. However, with serverless architectures, we can replicate infrastructure without worrying about costs.

To delegate routing decisions to Route 53, use records for weighted routing and run multiple stacks for multiple replications of the application.

Deploy multiple stacks of the application infrastructure, including AWS API Gateway and Lambda function. Another global infrastructure (e.g. SQS and DynamoDB) is independent of the application stack.

Each regional API gateway gets a weighted DNS record, with the inactive stack set to weight zero and the active one set to 100.

To roll out a new code deployment, deploy the inactive stack first. Once completed, adjust weights in the DNS record.

For example, set the new version stack to receive 20% of the traffic while the old one keeps 80%.

After we’ve run this configuration for a while and made sure there are no error spikes or other suspicious behavior in our application, we can switch the rest of the traffic to the new version.

A Word About Costs

Route 53 has very transparent pricing.

• you only pay for what you use.
• no minimum usage commitments or upfront costs.

What you'll be charged for is simple:

• Managed Zones - currently $0.5 per month.
• DNS Queries - currently $0.4 per million, with slightly higher costs for non-trivial records.
• Health Checks - starting from $0.50 for a default HTTP health check for AWS-hosted endpoints.

You don't have to worry about anything when starting to use Route 53.

​

That's it for Amazon Route 53 and for today.

We hope that you've learned something new and you're excited to use Route 53 for yourself! 📚

Have a great week ⭐️
​Sandro & Tobi

​

If you're interested in more, have a look at our
AWS Fundamentals blog 📚