Summary of the article's recommendations. Don't use:
- Cognito (authentication). Because: on mobile social login it isn't native. Instead: use Auth0, OneLogin, Okta or roll your own
- Cloudformation (programmatically configure AWS). Because: various complexities. Instead: use Terraform.
- ElastiCache (managed Redis). Because: expensive. Instead: run Docker Redis in EC2.
- KINESIS (queue), as a general-purpose data queue. Good for: streaming data such as video processing/uploading. Bad for: generic data queue, because its's difficult to route each event in the queue to one of multiple workers. Kinesis is meant for every listener to be assured to get the entire stream. Instead: SNS/SQS (SQS FIFO) or a queuing framework that sits on top of Redis or traditional databases.
- Lambda (server-less), to implement a REST API. Good for: Serving/Redirecting requests to CloudFront, also reacting to events from SNS or SQS by running small asynchronous tasks. Bad for: replacement for REST API endpoints, because it's too hard to work with a zillion lambdas. Instead: use a regular web framework (or, other commentators say, route all requests to one lambda and then do more routing within than lambda)
I do not agree or disagree, I'm just summarizing; although I did add in some information from other comments here, too.
- Cognito (authentication). Because: on mobile social login it isn't native. Instead: use Auth0, OneLogin, Okta or roll your own
- Cloudformation (programmatically configure AWS). Because: various complexities. Instead: use Terraform.
- ElastiCache (managed Redis). Because: expensive. Instead: run Docker Redis in EC2.
- KINESIS (queue), as a general-purpose data queue. Good for: streaming data such as video processing/uploading. Bad for: generic data queue, because its's difficult to route each event in the queue to one of multiple workers. Kinesis is meant for every listener to be assured to get the entire stream. Instead: SNS/SQS (SQS FIFO) or a queuing framework that sits on top of Redis or traditional databases.
- Lambda (server-less), to implement a REST API. Good for: Serving/Redirecting requests to CloudFront, also reacting to events from SNS or SQS by running small asynchronous tasks. Bad for: replacement for REST API endpoints, because it's too hard to work with a zillion lambdas. Instead: use a regular web framework (or, other commentators say, route all requests to one lambda and then do more routing within than lambda)
I do not agree or disagree, I'm just summarizing; although I did add in some information from other comments here, too.