Home » route53
Tag:

route53

AWS Cloudwatch and Route53 logos image
Tutorials

How To Setup Multi-Region DNS Fail-over In AWS

by corey.walker
written by corey.walker 7 minutes read

Do you have an API hosted on AWS API Gateway? Do you wonder how you can deploy that API into multiple regions around the globe and have automatic fail-over protection in case one region goes offline so that your API keeps on working without any intervention? Well, you came to the right blog post. In this post, I will show you how to set up and configure your AWS Route53 DNS entries, health checks, and AWS API Gateway APIs in order to have that automatic multi-region DNS fail-over protection you’re looking for.

Initial Multi-Region DNS Fail-over Configuration

The first thing we need to do is have a domain setup in AWS Route 53. Once you have a domain, we also need to set up a hosted zone in Route 53 for that domain. Inside this hosted zone is where we will add the DNS records we need as part of our automatic DNS fail-over configuration. Once you have a domain name and hosted zone setup, let’s get going on configuring automatic DNS fail-over!

First things first, we need to have the desired API deployed to AWS API Gateway in each of the AWS regions we want in our setup. If you do not have that yet, you can follow this guide as an example of how to create an API using HTTP front-end with AWS Lambda as the back-end for processing the requests. You will need an endpoint on your API that will respond to GET requests and be able to return a status code of 2XX in order for our health checks to know that our API is healthy in each region.

Creating An SSL/TLS Certificate

Once you have that, you will need to create an SSL certificate on AWS Certificate Manager in each of the same regions to use with your domain which we will use in the next step. You will need to verify the entries you add to your SSL certificate. If you are using Route 53 as we have discussed in this article, you can expand each of the domain name listings and add it to Route 53. We then just need to wait on the verification to be complete before moving on to the next step.

Now that you have your API deployed to AWS API Gateway and we have an SSL certificate for our domain, we need to set up a custom domain name in AWS API Gateway in each of our AWS regions. Go to the AWS API Gateway console and click Create Custom Domain Name. It will open up a form to create a new custom domain which you should fill out as follows:

  • For Domain Name, fill in your desired domain for this API. (e.g. examplecorp.com)
  • Choose HTTP Protocol
  • Security Policy: TLS 1.2 (1.2 is the latest and most secure as of this writing. If there is a newer version as you’re reading this, choose it instead)
  • Endpoint Configuration: Regional (this selection is important!)
  • Choose the SSL certificate you created in the previous steps, then click Save

Cool. Now we have everything configured in API Gateway. Let’s move on to Route 53 to finish up our automatic multi-region DNS fail-over!

Configuring Health Checks

We now need to set up the health checks that allow us to automatically determine if a certain region is unavailable. We will use this to route our traffic accordingly. Visit the AWS Route 53 Console then click on Health Checks in the left-hand menu and then click Create health check.

Under the first section under Configure health check, give this health check a name that would specify the region, service, and environment this is being used for so we can keep things organized and easy to know what health check is monitoring what. A good name may be something like Production — US-East-1 — API for example. For What to monitor, select Endpoint.

Monitor Endpoint Configuration

Now, in the Monitor an endpoint section, use the following configuration:

  • Specify endpoint by: Domain Name
  • Protocol: HTTPS (this is required to be HTTPS because we use API Gateway API stage generated URLs which are HTTPS)
  • Domain Name: This will be the Invoke URL generated for the API stage in API Gateway such as dev, prod, etc after deploying an API. Template URL for where you can find it is https://console.aws.amazon.com/apigateway/home?region=us-east-1#/apis/{{API_ID}}/stages/dev and an example URL is dk0bnnfwn2.execute-api.us-east-1.amazonaws.com
  • Leave Port as default since it is determined by the protocol you selected
  • For Path, enter the stage name for the URL you copied above (e.g. dev, production, etc) followed by the endpoint path you want the health check to monitor. (The one I mentioned earlier that needed to have a GET method and return a 2XX status code). For example, a valid path could be dev/health

You can expand the Advanced Configuration section and change some of the options if you wish. One I would possibly really consider modifying is the list of Health Checker Regions. You have to choose at least 3 regions, choose 3 for development APIs, and additional for my production APIs.

CloudWatch Alarms

Click Next and on the next screen, you can set up CloudWatch alarms when the health check fails for the number of consecutive times specified in the Advanced Configuration section on the first page. Continue on and create the health check.

Repeat the above steps for each of the regions you wish to deploy your API, remembering to grab the correct Invoke URL for the API in each region. Now you should have all of your health checks in place. Let’s move on to the last piece of the puzzle, the DNS entries in your hosted zone for your domain.

Creating Route53 Record Sets

Let’s get the last piece configured now. Head over to the AWS Route 53 Console once again, and click on Hosted Zones in the left menu, then click on the hosted zone for your domain. Click on Create Record Set and enter the following details:

  • Name: desired domain/subdomain mapping you want for this API (e.g. api.examplecorp.com).
  • Record type: CNAME
  • Alias: No
  • TTL: 300 (5m)
  • Value: This is the value of Target Domain Name generated when you created the custom domain in API Gateway. Copy that value and paste it here
  • Routing Policy: Latency
  • Select the region that matches the custom domain Target Domain Nameyou just pasted, and then give this policy a name that distinguishes it from the other regions and environments you may use.
  • Associate With Health Check: Yes then select the health check that corresponds with the same region and environment that matches the other values for this CNAME record
  • Click Create
  • Follow the same steps for all other regions you deployed your API to

Conclusion

That’s it! Now whenever one of your regions is unavailable for whatever reason, it will take just a few minutes (<5 minutes) for your other regions to pick up the load. The response times may be a little slower than the desired region since these are latency-based routing rules. However, your application should keep on working after the health checks fail the specified number of times and fail-over occurs! Congratulations! You have now set up automatic multi-region DNS fail-over using AWS Route53 and API Gateway!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail
Serverless Framework Tutorials Image
Tutorials

How To Deploy Multiple Environments Using Serverless

by corey.walker
written by corey.walker 4 minutes read

Do you currently use a serverless configuration for any applications or interested in migrating a current application to use serverless? Have you wondered how you can easily configure your CI/CD pipeline to easily deploy to multiple environments such as development, staging, and all production environments? With the Serverless Framework you can do just that. Continue reading to find out how.

Intro To Serverless Framework

Currently, I use the Serverless Framework to deploy to multiple environments and regions on the AWS cloud. I deploy to our development, staging, and production environments. Our development and staging environments are deployed in 2 different regions. Our production environment is deployed to 4 regions. So I have a serverless.yml file with many properties found in the docs for serverless.yml found here.

Configuration

  • All properties that remain the same for all environments and/or regions go into the serverless.yml base file
  • For all properties that are different between each environment such as development, staging, and production, I have another config file with the following naming convention under my config/ directory (the same naming I have is not required, but just what i use):
  • config/config.dev.yml, config/config.stg.yml, config/config.prod.yml, etc

Following this guide, I add all the needed custom properties to those environment-specific config files, and then in the main serverless.yml file, I create the same property but then reference the property from the environment/stage specified on the serverless deploy -s {stage}CLI command. I use a combination of both the stage CLI parameter and setting an ENV variable in a bash script before calling serverless deploy. Then I can also use ${env:ENV} to reference that value inside serverless.yml .

Environment Specific Configurations

Here’s an example of an environment-specific YAML configuration file I have for environment-specific variables:

stageSuffix: -${self:provider.stackSuffix, 'dev'}
lambda:
  versioning: false
prune:
  automatic: ${self:lambda.versioning}
  number: 5
api:
  domain: api.dev.${self:custom.domain}
storage:
  bucket: dev.${self:provider.region}.${self:custom.domain}
slackChannel: 'dev-slack-channel'

And inside serverless.yml, I reference those values by doing the following:

environment:
  ENV: ${env:ENV, 'dev'}
  STAGE: ${opt:stage, 'dev'}
  REGION: ${opt:region, 'us-east-1'}
  SLACK_CHANNEL: ${file(./config/config.${self:provider.stage}.yml):slackChannel}

Also, using a lot of shell environment-based variables allows you to make your serverless config even more decoupled away from specific projects/microservices since you then can just create a .env file specific to each project, create a bash script to run your serverless deploycommands, and before running serverless deploy, run source .env and many values can be populated easily by just supplying your .env file

Lastly, here’s an example of the bash script we use to run our serverless deploy commands that will supply many of our values in serverless.ymlwith values from a .env file instead of manually finding and replacing all the values between all our different microservices:

set -evif [[ -e "./secret.env" ]]; then
    source "./secret.env"
fi
if [[ -e "./.env" ]]; then
    source "./.env"
fiBRANCH="${CIRCLE_BRANCH:-$BRANCH}"if [[ $# -gt 0 ]]; then
    REGION="$1"
fiif [[ -n "$REGION" ]]; then
    REGION="$REGION"
else
    REGION="us-east-1"
fiif [[ "$BRANCH" == "development" ]] || [[ "$BRANCH" =~ ^issue-* ]]; then
    ENV="dev"
elif [[ "$BRANCH" == "staging" ]]; then
    ENV="stg"
elif [[ "$BRANCH" == "master" ]]; then
    ENV="prod"
fiif [[ "$BRANCH" =~ ^issue-* ]]; then
    export STAGE="feature"
    export STACK_SUFFIX="$BRANCH"
    export API_BASE_PATH_SUFFIX="-$BRANCH"
    "$(dirname "$0")"/create_domain.sh -s "$STAGE" -r "$REGION"
    "$NODE_MODULES_CLI_DIR"/serverless deploy -v -s "$STAGE" -r "$REGION"
else
    export STACK_SUFFIX="$ENV"
    "$(dirname "$0")"/create_domain.sh -s "$ENV" -r "$REGION"
    "$NODE_MODULES_CLI_DIR"/serverless deploy -v -s "$ENV" -r "$REGION"
fi

and the .env file we use to supply the variable values:

export BRANCH="$(git branch | grep \* | cut -d ' ' -f2)"
export ENV="dev"
export STACK_PREFIX="{STACK_PREFIX_HERE}"
export STACK_SUFFIX="$ENV"
export APP="{APP_ID_HERE}"
export APP_NAME="{APP_NAME_HERE}"
export COMPONENT="{COMPONENT_NAME_HERE}"
export REGION="us-east-1"
export DYNAMODB_ENDPOINT="dynamodb.$REGION.amazonaws.com"
export GITHUB_USERNAME="{GITHUB_USERNAME_HERE}"
export DB_TABLE_NAME="$COMPONENT"
export DOMAIN="{DOMAIN_NAME_HERE}"
export EMAIL_SUPPORT="support@${DOMAIN}"
export NODE_PRESERVE_SYMLINKS=1
export TEST_DEPLOYMENT_SUFFIX="-test"
export SLACK_CHANNEL="slack-channel-${ENV}"
export API_VERSION="v1"
export API_BASE_PATH=""
export API_BASE_PATH_PREFIX=""
export API_BASE_PATH_SUFFIX=""
export NODE_MODULES_CLI_DIR="./node_modules/.bin"

Conclusion

Let me know what you think and if you also see any improvement I myself could make to this process!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail