This is an old question (somewhat), but I'll add my 2 cents:
First - AWS Lambda functions run in Linux containers under the hood, and currently support .NET Core 2.2. So you would have to port your code to .NET Core. However, .NET Core 2.2 implements the .NET Standard 2.0 APIs, so if you're not making use of Windows-only libraries (manipulating images, for instance), and instead doing mostly CRUD operations, it may not be so difficult. You can use the .NET Portability Analyzer (free from Microsoft) to analyze your solution to see how much code would need to be refactored.
As someone else pointed out, the dependencies on 3rd-party libraries could be a problem, if those libraries don't adhere to the .NET Standard 2.0 standard (or at least, if the functions you use in them use APIs not in .NET Standard 2.0). The portability analyzer can check those DLLs also (it works against binaries).
As a general strategy, for a Web API project to Lambda, I'd suggest carving off individual APIs at a time, implementing them as ASP.NET Core Web APIs (with either a single controller, or a small number) per Lambda, to keep the Lambda size small (improves start-up times). If your repository code is talking to a relational database (ie, SQL Server), you'll either need to have your database be publicly accessible (not recommended) or run your Lambda function in a VPC (where it gets its own IP address), which means cold-start times will be even slower. However, you there are ways to keep Lambda containers "warm" (using CloudWatch events, for example).
I have deployed basic ASP.NET Core MVC and Web API projects both to AWS Lambda, but I started them out in .NET Core. As a way to start, try creating a new ASP.NET Core Web API project using the AWS Toolkit for Visual Studio (an extension), using the project types under "Lambda", and choosing "Serverless application", then picking the Web API template. This will also create the API Gateway API, and associate it with your Lambda, when you deploy it.