I am not sure if 'Full Guide' in title of the article made me smiling or maybe it was recall of my experiences related to configuration of AWS Lambda and AWS API Gateway in CloudFormation. There is a lot of things which has not been mentioned in this article and it is what I am looking forward to - even trivial things which looks easy at the first glance, i.e.:
* How to configure caching and caching rules - please note there are few ways (query strings, headers, parameters, cache enabled only on single method etc.) to specify how to cache responses.
* Attach your REST API on custom domain as a regional endpoint (instead of edge-optimized, since regional endpoints are more configurable)- create ACM certificate (per each region, and one for CloudFront), create own CloudFront distribution (think: multi region deployment), add DNS record in Route53 and configure WAF (some magic DDoS protection).
I took me a lot of time with CloudFormation to get through where I am today and yet I think I would be grateful if someone will share his knowledge gained on more sophisticated use-cases than just 'Hello World'.
I were using SAM for month or two and then switched back to CloudFormation, because I felt limited (not all features of API Gateway were implemented, duplicated stages, problems with instrict functions). However, I watch their GitHub repository for changes and I noticed many missing features are implemented on AWS re:invent basis (duration between next conference). The worth-noting feature of SAM is definetely aws-sam-cli (former: aws-sam-local) [1], which is a tool for developers to parse SAM template and invoke Lambda function in the docker on local machine. It was great to test simple APIs (start-api mode), but when some API started using custom authorizers or response was a compressed payload of png image it was not very helpful. Personally, I am working on a fork of aws-sam-cli to implement it to work with CloudFormation.
Yes, it adds a new custom types AWS::Serverless::* [1] and new Globals section [2] and it is really pleasant to work with for basic, not complicated API. It is transformed into CF template via samtranslator [3] (recently open-sourced) so it inherits a lot from CloudFormation but also that's why I encountered differences between SAM and CF types.
Basically, caching allows you to cut your costs if you do it right. Also it is worth to note after 12 months API Gateway stops being free and caching may decrease amount on your bill. However, caching cluster is paid on hourly-basis and you must know if it will be worth to use it.
Personally, I don't imagine to provide aaaaaaaaa.execute-api.eu-west-1.amazonaws.com/v1/transactions/XXXX/cancel as a API endpoint in the documentation of some product. Well.. It'd definitely made my day if I will see such endpoint in i.e. Stripe docs. Everyone uses short like address like api.example.com so there is definitely use for custom domain name as a feature of API Gateway. Custom domains allows you to separate an API by base paths (i.e. Transactions API, Notifications API, Refunds API) and it easier to upgrade/shutdown... basically maintain your API. Also if you are interested from requests made in two AWS regions and you also care about latency regional endpoints might be way better. Of course, if you will use it with WAF and CloudFront you have a lot of things to configure, which for some companies might be important.
* How to configure caching and caching rules - please note there are few ways (query strings, headers, parameters, cache enabled only on single method etc.) to specify how to cache responses.
* Attach your REST API on custom domain as a regional endpoint (instead of edge-optimized, since regional endpoints are more configurable)- create ACM certificate (per each region, and one for CloudFront), create own CloudFront distribution (think: multi region deployment), add DNS record in Route53 and configure WAF (some magic DDoS protection).
I took me a lot of time with CloudFormation to get through where I am today and yet I think I would be grateful if someone will share his knowledge gained on more sophisticated use-cases than just 'Hello World'.