Deploy HTTP API With CDK to same domain and subdomain

View deploy http api Source code on github

Before we get started with difference I would recommend to develop CDK project inside docker container.

So we no longer have the issue of "this works on my computer". And it will not mess with your existing workflow.

So checkout my blog post for detailed video explanation. Then checkout CDK development container settings on github

Deploy HTTP API to subdomain

So let's start with part 1

We are getting access to hosted zone and creating SSL certificate for subdomain.

Make sure to deploy this part first before writing further code.

Creating certificate may take significant time. Here I am assuming that you are hosting your domain with route53.

If you are not using route53 then its different for each domain provider.

Then create part 2 as follows

Important see if HTTP api is available on AWS region that you are trying to deploy.

You can see the full list of available regions at HTTP API Pricing Page.

So if your deployment fails then I recommend changing region to available regions.

So using subdomain certificate and subdomain url we set default domain for the API.

If you are consuming api on mobile app then you don't need to setup cors.

But if you are consuming api to main domain or different domain then you need to enable cors to allow access.

In case we are authenticating users I have set allowCredentials to true.

And we are only accepting request that has Content-Type in the header. Most likely content type is going to be application/json.

And I am allowing only CRUD methods. Create is POST, read is GET, edit is PUT and of course delete is DELETE.

Feel free to add more methods. Then only origin that is allowed is our main domain.

Any other domain cannot make request to our API endpoint.

If you want other websites to make request to our api then add their url inside the array.

And I have set human readable name as api name. So if we go to aws console then this api is easy to find based on the name.

The disableExecuteApiEndpoint property will disable api endpoint for aws domain and only use api with your custom domain.

Optionally I am printing out HTTP API id because you will have 100's of api routes and 100's of lambda functions.

And cloudformation stack has limit of 500 resources per stack. Or you might need to refer this api in another stack.

Then you can access your existing api as follows.

Also along with deploying api I have created a sign up lambda function that we will connect to one of the routes later.

Deploy part 2 minus accessing existing api before moving forward.

Then I am adding route53 alias record to connect api to subdomain as follows.

I have added custom domain alias for aws owned api domain. Now your api can be accessed at subdomain.

And I have created my first route on api and connected to lambda function we crated in part 2.

I am giving example with single route but you can add max of 300 routes per HTTP API and this limit can be increased on request. So go to town on this api.

You can see other HTTP API limits in the documentation.

This setup is great for consuming api on mobile or other devices. But when you open cors then you also increase whole lot of security risks.

Especially if you plan to consume api only on main domain then you can deploy api directly to main domain and keep the cors closed and eliminate all related security risks.

Advantage of deploying to subdomain is that it will cost you less than deploying to main domain with cloudfront.

But I prefer not to open cors for unnecessary security risks. So lets look at how to do that.

View Complete Source code on github

Deploy HTTP API to same domain

There is log of similarity between deploying to subdomain and main domain. So I will not repeat what I have already explained.

This time I have created certificate for main domain. NOT for subdomain.

And created HTTP api with just name and skipped cors completely.

Also created single lambda function for demo purposes.

After you deploy part 1 then write the next part.

Just like before I have added route after api has been created and connected already deployed lambda function.

So we are going to tell cloudfront to forward all request for path starting with api/* to our HTTP api.

The main domain will have path example.com/ so I have removed forward slash at the beginning of api.

Cloudfront by default does not forward anything e.g. headers, query string parameter, cookies. Everything is blocked by default.

So this is why I have created origin policy. Where I allows all query string parameter and cookies to pass through.

You cannot pass all the headers if you do that then your api will stop working. Its limitation of cloudfront.

The workaround is to pass limited list of headers but currently I have had no success while deploying a list. So I have disable header forwarding completely.

Also I had no requirement for accessing headers from API so I haven't created issue with AWS CDK

The default behavior of cloudfront is main website. This can be anything you want.

It can be S3 hosted website or somewhere else. So I have set placeholder to HTTP origin.

For API I have allowed all request not limited to Get request. And caching is disabled for API.

Rest of the settings are default for cloudfront distribution.

One last thing before accessing api.

After adding alias for domain then you can now access api at the same domain.

View Complete Source code on github

Conclusion

HTTP API is faster and cheaper than Rest API. And HTTP API is build specifically for serverless integrations like lambda.

So I highly recommend you start using it right away.