dphang
commented
4 years ago Hey @thevarunraja,
Generally the issues are used for feature requests / bug reports, though I guess there isn't any gitter (or similar) yet, so I'll answer this here.
You can search for Lambda vs. EC2 comparisons, I think there should be many. Lambda@Edge just means it replicates your Lambda function and deploys it to all of AWS's edge locations so that code runs closer to your user (instead of one region like normal Lambda). Here is one comparison of Lambda vs. EC2: https://lumigo.io/blog/aws-lambda-vs-ec2/, it mostly applies to Lambda@Edge as well. I've also summarized based on my experiences:
Advantages of Lambda@Edge:
- Globally distributed, run code closer to user so there are lower network latencies and high-availability
- On-demand, i.e pay based on # requests / CPU time you use
- Don't worry about scaling your applications
Disadvantages of Lambda@Edge:
- Cold start can become an issue especially for SSR (server-side rendered) pages. This is because Lambda@Edge needs to re-initialize container (it doesn't keep it on forever) if there aren't any requests coming to it. Requiring a bunch of dependencies can be slow (in my app, it takes up to 800-1000 ms execution time on cold start). Best way to combat this is to have few SSR pages and reduce # dependencies.
- Not much control of the Lambda containers; you can only choose between a few Node.js runtimes, 128 - 3 GB memory (no control over CPU, although it scales with memory).
- Limits on timeout, code size, etc. (See: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-requirements-limits.html)
- Cannot pre-warm / use provisioned concurrency to reduce impact of cold starts as with Lambda (because it is globally deployed, it would be infeasible/costly to keep all regions' function replications warm, even a single instance in each). But hopefully AWS finds ways to continue to reduce cold start times by optimizing the Node.js runtime.
Advantages of EC2:
- You have complete control of the instance: OS, Node.js runtime, installed software etc and tons of EC2 hardware choices based on your needs
- No cold starts as the instances are always ready to serve traffic
- Can use Docker containers, Elastic Beanstalk to make it easier to manage your code
Disadvantages of EC2:
- You need to manage scaling your EC2 instances, which regions to deploy them to, etc. Also administering them takes time e.g updating/installing software
- Could be costlier if you don't have much traffic
- Lower availability e.g if you only have a couple of instances
- Higher network latency for those users not near your instances
Note that Next.js apps strongly prefer using statically generated (SSG) pages over SSR pages. In which case, they will mostly be served by CloudFront caches and if it hits your Lambda (cache miss), it has very light logic to figure out which page to retrieve based on URL and retrieves it from S3 instead. In my experience, it is around 20-40 ms if cached and around 100-250 ms if uncached (I do live near an edge location).
If you have to SSR render a page, it will need to load all npm dependencies and will easily make the runtime close to a second or more.
So it depends: if most of your pages can be statically generated and you need very little / no SSR pages, then Lambda@Edge is a very good choice. Or if you have few users from many locations then it also works for saving some costs. If you need to SSR many or all pages, then it will probably be much slower than using EC2 (network savings won't offset this).
thevarunraja
Thanks for the great work on this. I would like to know when to choose this approach of serving the app through Lambda@Edge over EC2. I tried to google for an answer but couldn't find any. Thanks in advance.