- Newest
- Most votes
- Most comments
My opinion here (and it is opinion - there are going to be different views) is to use API Gateway and Lambda as a back-end. The primary reason is that both technologies are serverless meaning that you pay for what you use; and if you aren't using them then you don't pay for them.
With ALB (which is an excellent service) it is always on - you pay for it whether your application is receiving requests or not - even when it is idle. This is not true of API Gateway and Lambda; when they are idle the cost is zero. You can have hundreds of Lambda functions and API Gateway routes defined and the cost is still zero.
If you choose to go with API Gateway and a "traditional" EC2 instance as the application server then you'll need to use a load balancer anyway (to connect API Gateway to the app server) - in that case, using ALB is better because you're going to pay that cost anyway. Adding API Gateway is nice (it has good tools for validating and modifying requests) but it adds complexity for you - it's something else to manage.
So consider whether you want to change the entire architecture and get rid of the app server in favour of Lambda. In addition to potential costs savings it can also make it easier to scale up and down.
Relevant content
- asked 3 months ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 3 years ago
Thank you for your overview and opinion. It was very informative! It seems to come down to whether we want to change the entire architecture and get rid of the app server in favor of Lambda. If we decide that we want to keep app-server as a traditional EC2, we will go with ALB. However, if we decide to go the lambda route, would it make sense to use lambda@edge ? I have heard a lot of people mention this but have not been able to understand when it is helpful or not. Should we just stick with the API gateway + lambda as a backend or would lambda@edge be better? Also, I have heard people suggest using cloudfront functions for this. It seems like there are many options and I'm having trouble wading through them to find the right solution
Lambda@Edge is specifically designed to inspect and modify in-flight requests within CloudFront. Can you use it as a complete application front-end? Yes. But (and this is a big but!) there are constraints on function size and execution time that may impact your ability to deliver the application. It is definitely lower latency than API Gateway/Lambda (because there are less things happening across the entire stack) but that lack of flexibility may be an issue for you.
Thanks for all your advice. We decided to keep the app server on EC2, not having the workforce and time to transition it to lambda. So, our frontend web app will be on S3 and Cloudfront and our backend server will be on a single EC2 instance. We are planning on using CloudFront origins/behaviors to route default to the s3 frontend and /api/* to the ec2 app server. So, my last question is: Do I need an Application Load Balancer even if I just have a single EC2 server hosting my backend? Does routing /api/* through Cloudfront to EC2 require a load balancer? If so, is ALB the right kind? Having trouble finding a best practice example for this type of architecture so would really appreciate your thoughts. Thank you!
You don't have to use a load balancer; with a single instance it would be a little overkill. But: There is a benefit here. You can set the instance up so that it automatically recovers in case of failure (there's a few ways of doing this but an auto-scaling group with a minimum and maximum of 1 instance is one way to do that). Using the load balancer means that it will direct traffic to the instance even after a failure. There is extra cost here; but it can give you slightly higher reliability. If you're going to go down the path of using a load balancer I'd recommend that you architect the instance to auto-scale properly anyway.