AWS Shop example: API Gateway (2) Architecture with certificates and DNS 2

AWS Shop example: API Gateway (2)


Last time, I talked about the API Gateway [1]. The URL that we used last time has randomness in it: it looks like When you destroy the API Gateway objects and redeploy them, you will get another URL. That’s not nice: we don’t want to change the URL in all our cashing machines when we deploy a new version of our software… The objects we used in the last blog are shown in the next image:

AWS Shop example: API Gateway (2) Architecture without certificates and DNS 3

Today, I will use the domain (which is running in Route53, the DNS of AWS) to show you what you need to configure to get the nicely formed url (like When I really would own a shop, I would most probably call it something like But well, in this example I added AMIS as a prefix for everything, so I will use it for my URL as well.

Here’s the image that shows the objects that we will look at today:

AWS Shop example: API Gateway (2) Architecture with certificates and DNS 1


First, we need to have a certificate for our domain. Go to the certificate manager service, and click on the arrow next to the checkbox of the certificate.

AWS Shop example: API Gateway (2) 01 Certificate manager arrow

You can now see the details of the certificate:

AWS Shop example: API Gateway (2) 02 Certificate details

The name of the certificate is *, which means that I can use this certificate for any name that ends with The certificate is issued by Amazon (I also could have uploaded a certificate that is issued by someone else).

When you request a certificate from Amazon, there are two ways that Amazon can verify that you really are the owner of the domain. The first way, is to verify by e-mail. The disadvantage is that this is slow: you are dependent on people to read the e-mail, press a link etc.

A much faster way, is to check via DNS. Amazon asks you to add an alias (CNAME) record to your domain, which will point to an AWS address. You can see how this works, by clicking on the “Export DNS configuration to a file” link.

AWS Shop example: API Gateway (2) 03 CNAME record

When you open the file, you can see that there has to be a record in the DNS with the name “” and that record has to point at “” When AWS verifies the domain (sometimes this is done within minutes, sometimes it takes more then two days), they will use the url to check if they are routed to

Before we go and look at Route53, I’d like to point to a nice detail in this screen. You see, that when the certificate is in use, this screen will show you where it is used (“Associated resources”). Though I never implemented a load balancer anywhere (see the architecture image), my certificate is used in three load balancers. It seems that the API Gateway uses multiple load balancers to do its job…

Route 53

Let’s look at the CNAME record: go to the Route53 service. In the dashboard, you can see that I have three public domain names, and six hosted zones. That means that I use three private zones and three public zones.

AWS Shop example: API Gateway (2) 04 Route53 dashboard

Click on the “Hosted zones” link, you will see the domain name in this list (normally you would see all six domain names here, I removed the other domain names from the image because they are not used in the shop example and some of them can be confusing). Click on the link with your domain name (in this case:

AWS Shop example: API Gateway (2) 05 Hosted zones

In this screen, you see all the DNS records for the domain. When you click on the CNAME record that we talked about, then the details are shown on the right part of the screen:

AWS Shop example: API Gateway (2) 06 CNAME record in Route53

You can already see the entry. But before we look into that, we have to change the configuration of the API Gateway.

API Gateway

Go to the API Gateway, and choose Custom domain names in the left menu:

AWS Shop example: API Gateway (2) 07 Custom domain names

Click on the domain name

AWS Shop example: API Gateway (2) 08 Custom domain name details

This might be confusing: we need to specify the full domain name (including the amis part) here, where only is a domain name. When you scroll down, you see API mappings:

AWS Shop example: API Gateway (2) 09 API mappings

You can see that will use the prod stage, and that it will not have a path. This means that when 1we use, we always will use the prod stage and that we will have to specify the /shop resource when we use this URL.

It is possible to have multiple “nice URL’s” to the same API Gateway. Let’s try this out: let’s make a new URL that points to the same API Gateway. Click on Create:

AWS Shop example: API Gateway (2) 10 Create custom domain names

Enter the name of the end point (in our case: and add the certificate:

AWS Shop example: API Gateway (2) 11 and certificate 1

You also see the option to create a regional endpoint or an edge-optimized endpoint. A regional endpoint assumes that the people who use this URL will be in the neighborhood of the AWS region that this solution is deployed in (in my case: Frankfurt, AWS region eu-central-1).

When you would use an API Gateway to provide information (REST GET requests) and your company is a global company, then you could use the edge locations of AWS. These edge locations are in the neighborhood of your clients, and will cache the results of the API calls. This will speed up the process. In our case, Regional is good.

Now, scroll to the bottom of the screen and press save.

We have to do one more thing: scroll down, and look at the API mappings: they are empty now. Press on Configure API mappings:

AWS Shop example: API Gateway (2) 11a Configure API mappings

In this screen, click on Add new mapping:

AWS Shop example: API Gateway (2) 11b Add new mapping

Click on the drop down windows for API and Stage, and choose the AMIS_api_gateway for API and prod for Stage. Leave the path empty. After that, press Save.

AWS Shop example: API Gateway (2) 11c Configure API mappings


Now we have configured in the API gateway, we can configure the DNS entry: go back to the Route53 screen, and click on Create record set:

AWS Shop example: API Gateway (2) 12 Create record set

You might get confused here. We will need to create an A record. An A record in the DNS points to an IP address. But in the main screen, you see that has an A record that points to an AWS address. That magic is done by clicking on the “Yes” radio button from the Alias:

AWS Shop example: API Gateway (2) 13 A record

You now can choose the Alias Target. When you scroll down, you see the API Gateway API. Choose it:

AWS Shop example: API Gateway (2) 14 Alias target

You can select Evaluate yes for Target Health: in that way, AWS will check regularly if the target (the load balancers of the API Gateway) are present and only point to healthy load balancers. After that, click Create:

AWS Shop example: API Gateway (2) 15 Target health

But wait… We are talking about an A record. A records point to IP adresses, they are not supposed to point to other services. Is really an A record? Let’s wait a few minutes and then find out by checking the DNS:

AWS Shop example: API Gateway (2) 16 nslookup

You see that it is indeed a normal A record, giving back only IP addresses. Route53 has put the IP addresses from the load balancers of the API Gateway in this DNS record. We could also check this from within AWS: click on the record, and then on Test record set:

AWS Shop example: API Gateway (2) 18 Test record set

In the next screen, you can simulate to check from another location than you are now, by specifying an IP address to test from. In our case, this isn’t necessary, so we will leave the Resolver IP address as it is and press the Get response button, you will see the response on the right part of the screen:

AWS Shop example: API Gateway (2) 17 Get response 1

And, because the proof of the pudding is in the eating, let’s use our new record to send a message to the API gateway:

[vagrant@localhost client]$ ./ AMIS1

Shop id = AMIS1

Key alias = alias/KeyL-AMIS1


Data = {“shop_id”: “AMIS1”, “content_base64”: “KW4JaTQy3R4kOvJsK669coHgPspVuTUwBve5v9D4m2OpsXWTx+u3adAR70Oi8CCEMA+Tits7PzjuBNQBwNZg0Iyn0yMW4LeEFrcaJh84+m8DOECmVuYLdmyHmpKzVOl4XkiQ4w4wEnf3NgrE67hmolpOL4zxfTS7DFzpXeusc6rDfXLPHSSQ8kHkXx9/S6y6yovQM4yWQHXx6CdvJ9+dzynTLew5B/ClAPKon3XPeB5S7uNHWyoTPDH0GP9CI6rungnLyY52l3H17d7StsWa5en1EYHTHBQ5Jpsb4ini5TqAiFtfah8oZuU4VuWBtC3k4aLIli0LwEPgIyOIuZfRHQ==”}

request_number = 1

Status code = 200

Content = b'”OK”‘

[vagrant@localhost client]$

Play along

AWS Shop example: API Gateway (2) bke 5

I scripted the solution [2]. You can follow along and create this solution in your own environment, see the file in the vagrant directory and see the introduction blog for more information. For this specific blog, you need your own domain. Replace by your own domain name. A domain name for .nl in AWS costs about $10 per year.


[1] This is the fifth blog about this shop. Links to the previous blogs:

– Introduction:

– Lambda and IAM:

– SNS:

– DynamoDB:

– API Gateway (1):

[2] , directory shop-1