Say that I have 5000 requests hitting an application every 5 seconds and I need to consume an object and write it to a database. Would a lambda with an http trigger that does an insert be more cost effective than having an ec2 instance that does the same thing?
Edit: Just want to say you all are awesome! I am coming from MSFT world and never experienced so many folks being so helpful. Makes me think I should have switched to AWS ages ago. Thanks everybody.
Please help me work out the math here, as I think I am doing this wrong.
A Lambda of 128mb costs $0.0000000021/ms, this works out $0.00756/hour. A Lambda of 512mb costs $0.0000000083/ms, this works out $0.02988/hour.
Now if you look at EC2:
t4g.nano $0.0042/hour (0.5 GiB ram) t4g.micro $0.0084/hour (1GiB ram).
But... the Lambda will likely not run 100% of the time, and will stay warm for 10 minutes (not sure here?). And the RAM usage would be much better utilized if you got a function running, rather than an entire VPC.
Given all that, if the function can run with 128mb or less, it seems like a no-brainer to use Lambda.
However, if the function is bigger, it would only make sense to put it in an EC2 if it runs more than 30% of the time ($0.0084/hour cost of t4g.micro divided by 0.02988/h cost of 512mb lambda).
So why is everyone against Lambdas citing costs as the primary reason...?
Based on the discussion in the comments I'm now adding a complete answer to this, as this is not really suitable for a comment.
You mentioned that your current service is already running on EC2 and you'd like to move that over to a Serverless solution. Furthermore you mention the options of "Lambda or Serverless exposed via API-Gateway". Then you add some additional information about expecting a response time of 500ms and the Lambda doing 2 DynamoDB calls.
I'll address these points in order:
EC2 vs Serverless Solution:
You seem to have already decided on trying the Serverless route, which works quite well in principle for a Microservice-Type architecture you're describing. I'm not going to focus too much on the merits of the EC2 solution here. Going serverless can have the following benefits (among others):
- Cost effectiveness: You pay only for the resources your code consumes while it's running and not for idle times
- Scalability: Lambda scales horizontally, fast and effortlessly - you basically don't worry about it (up to 1000 parallel "instances")
- Lower operational overhead: No need to patch operating systems - AWS takes care of that for you
- Focus on your business logic, leave the heavy lifting of managing the infrastructure to AWS
Lambda or Serverless exposed via API-Gateway
Serverless isn't really an AWS Service but a paradigm or architectural pattern so these options don't completely make sense - you'd use the API Gateway to trigger Lambda functions whenever an Event (read: HTTP-Request) occurs. This means you'll setup a fully-managed REST-Endpoint (API-Gateway) to call your code (Lambda) on demand.
On Performance
A response time of 500ms is realistic for the use case you're describing - DynamoDB advertises single-digit-millisecond latency, so two calls to it within 500ms shouldn't be a problem. Unfortunately Lambda cold-start is a thing. Lambda scales out with parallel requests, meaning a new Micro-VM gets provisioned if there aren't enough warm instances of your function available to serve your request. This takes time, but in your use-case this shouldn't be an issue, since you don't need access to a VPC (in that case it would take multiple seconds).
Lambda is limited in performance compared to EC2 instances, you scale the amount of performance Lambda provides by specifying the amount of RAM the function gets allocated (CPU resources are provided based on the RAM). For a simple Login-Service this shouldn't be an issue as well.
I suggest you read up on the points I mentioned in the Lambda documentation (which is quite good).
If you want your events driven service managed use AWS Lambda, you just provide the code in the required language, and Amazon AWS does the rest. If you want to customise for your own needs and use whatever coding language you prefer Amazon EC2 offers flexibility and a whole range of EC2 Instance types to choose from, in conjunction with Elastic Beanstalk services for deploying onto Amazon EC2.
AWS Lambda is a service for running code in response to events, such as changes to data in an Amazon S3 bucket and Amazon DynamoDB tables, or as compute services to run your code in response to HTTP requests using Amazon API gateway or API calls made by using AWS SDKs. This is an ideal computing platform for applications when running within the standard runtime environment.
Lambda should be your best bet.