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).