Home » api-gateway
Tag:

api-gateway

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 AWS Lambda AWS APIGW Image
Tutorials

How To Deploy To AWS Via The Serverless Framework

by corey.walker
written by corey.walker 5 minutes read

So, you’ve heard all the hype around serverless and wanted to delve in to see what all the hype is about? Here’s a quick simple way to get started in serverless using the Serverless Framework. We’ll be using AWS Cloud using AWS API Gateway, AWS DynamoDB, and AWS Lambda.

Initial Setup

The first thing you will need to do is make sure you have Node.js version ≥ 8 and npm installed. To check whether it is installed, run the following command inside a terminal shell.

node -v
npm -v

If you do not have Node.js version ≥ 8 installed, there are a couple of ways to install it. The first and easier way is visiting the Node.js download web page and download the version you wish to install.

The other way, which is just a little more involved, is to use NVM (Node Version Manager). NVM allows you use have multiple versions of Node.js running on a single system and easily switch between them. To install NVM, run the following in a terminal shell:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

This will install NVM into the current user’s profile instead of being system wide. You will need to quit and restart the terminal application in order for the terminal to pick up the nvm command. Now we need to install Node.js using NVM by doing the following:

nvm install {node version}
nvm use {node version}

Installing AWS CLI

The next to do is install the AWS Command Line Interface (CLI). To do that, you can follow this guide to get that setup. Now let’s setup our AWS credentials so we can actually deploy this sample application to AWS. If you don’t already have AWS IAM credentials pair, you will need to get that. Make sure it has the permissions to create/update/delete CloudFormation templates, API Gateway resources, and Lambda functions. Once you have AWS credentials, follow this guide to setup your credentials so that the Serverless Framework can use them.

Installing Serverless Framework CLI

The next thing you’ll want to do is install the Serverless Framework. You do this by running the following command inside a Terminal shell:

npm install serverless -g

This will install the Serverless Framework as a global package for your machine. If you wish to just install it inside a project’s directory as a dependency of a node application, you can leave off the -g part of the command when you are inside a node project directory.

Creating the Serverless Framework Application

Next, you will want to create a serverless application. There are many different parameters to customize the serverless project for using different languages, cloud providers, etc. However we will be using values to create a Node.js/Typescript based application with AWS as cloud provider. To create and initialize this project, we will run the following commands inside the terminal shell:

serverless create --template aws-nodejs-typescript --path {my-service}
cd {my-service} && npm install

Now open the new {my-service} directory. You should see a project structure that looks like the following:

File listing for new serverless framework project
File listing for new serverless framework project

The Serverless Framework packages your application into a zip package that is deployed via a AWS CloudFormation stack. If you open the serverless.yml file, you will see something like the following:

service:
  name: my-service
#app: your-app-name
#tenant: your-tenant-name# Add the serverless-webpack plugin
plugins:
  - serverless-webpackprovider:
  name: aws
  runtime: nodejs10.xfunctions:
  hello: 
    handler: handler.hello
    events:
      - http:
          method: get
          path: hello

Let’s go over the different pieces of this default template.

  • service: This will be used to create the name of your AWS CloudFormation stack. The default naming convention of the Serverless Framework is to use {service.name}-{stage}. The stage value can be passed in via CLI argument or default value of production.
  • plugins: This section allows you to extend functionality of the Serverless Framework using multiple plugins from a list of available plugins. There are plugins for many different tasks. These include adding tags to numerous AWS resources, using versioning in AWS Lambda along with auto pruning old versions, and many many others.
  • provider: This section specifies all configuration for the cloud provider you wish to deploy your Serverless application to. As of this writing, they support deploying to AWS, Microsoft Azure, Google Cloud, IBM OpenWhisk, Kubeless, Cloudflare, spotinst, and fn as can be seen here. We will be using AWS, whose Serverless config file options are all listed here.
  • functions: This section is where we configure our AWS Lambda function specification. This section will tell serverless where to find the code in your local project. As well as what AWS API Gateway endpoints will use the Lambda function, what tags and environment variables to assign to the Lambda function, etc.

To deploy this sample application to AWS, run the following command:

serverless deploy -v [-r {desired region}]

Conclusion

Congratulations! You have deployed a Serverless based application to AWS API Gateway and AWS Lambda! In order to test this out, sign into the AWS Cloud Console, select the region you deployed your application to form the upper right menu, then go to the API Gateway service page. You should see your serverless application API listed on the left menu. Click that API, click Stages in the left sub-menu, and then click on the deployed stage. You should now see an Invoke URL link for your API in the right half of the page. Copy that link, paste it in your browser and append /hello to the end of that URL and hit Enter/Return. You should get the desired response that was created in your handler.ts file from the template application!

Now that you have a feeling for how easy it is to deploy Serverless applications to AWS, leave your feedback in the responses section and let me know what you all do with this framework and what you all think of this tutorial!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail