Creating AWS Lambdas with Visual Studio

Fair warning
AWS Services are in constant change and evolution. Check the date of this post as in the last 18 months there's been new stuff added to those services and I expect more to come in the next 18, so if the post is a bit out of date be careful it may not be accurate.

Installing and using the AWS plugin

Need to install “AWS Toolkit for Visual Studio 2017 and 2019” plugin into Visual Studio. Then, you should have an “AWS Explorer” tab on the sidebar next to the Solution Explorer and the rest where you can set up your credentials and log into Amazon. That panel will also show you all the lambdas and rest of stuff you already have in Amazon. You can also add more profiles at the top clicking on “Add new profile” so that if you have different AWS accounts you can move from one to the other just using the select option.

Creating a Lambda

I won’t get into many details so basically now that the toolkit was installed you should be able to create a new type of project which already has access to the lambda libraries. So Add New project > Visual C# > AWS Lambda > AWS Lambda Project.

It’s useful to create your project with tests so you already have a sample to start adding them later, so I prefer to just pick that option, unless this Lambda is part of a group in which case I may prefer to have all the tests in the same project (to avoid having 100 projects) and not add an extra project for each lambda tests.

Uploading Lambda to Amazon

If you logged into Amazon using the sidebar this should be as easy as right click on the project to upload and select “Publish to AWS Lambda”. Now, the first time you do this you need to configure everything, if you already have a sample from other lambdas you can use it as most of it should be the same, if not this Wizard will create the aws-lambda-tools-defaults.json file for you before uploading (which will save these details to use on later uploads). If you modify anything on the Wizard it basically overwrites the file.

Now it doesn’t look like AWS expects you to have dev/staging/production versions but just production ones and that works with default, but if you want to save different setups for different versions just add more files apart from default and remember to copy and paste the one you need into default before starting the upload. I wish the Wizard actually allowed me to have more setup files and select the one I want but it doesn’t. Yet.

If you didn’t log into Amazon using the sidebar (which you should) you can also manually upload the lambda codes to AWS and do all this using their UI, but I don’t recommend that and I didn’t go that way.

Configuring the Lambda to upload

This part can be a bit time consuming but luckily you shouldn’t need to do this more than once.

First thing is to set the profile and region, be careful with this as while I only have one profile if having multiple you don’t want to mess it up. Though we have different regions and this is important, for the roles, rules and other stuff added in a region are not necessarily existent in the other (and if they are they are a copy, not the same) so make sure you get it into the right region. Note that lambdas are accessible from any region, I’m just talking about internal setups like rules, roles, logs, warnings, etc.

The name must be unique, it acts as an identifier of the lambda and can’t be repeated. So just add suffixes like _dev, _stg or so if you have different versions.

Rest should be auto-filled, just note that while there’s a default class (type) and method that it will call, and if you didn’t change it is already as it is, you can actually change that but then be careful and make sure you change it here too or the lambda won’t work (I think it doesn’t even allow you to upload it, but not sure).

Click Next and there’s more settings:

Role: You can create a new one or use an existing one, better to use the same role for all lambdas that are at the same level of permissions so you don’t end up with unmanagable hundreds of roles. In my case they already existed as we had more lambdas so I can’t tell much more than that.

Execution: This part is important. Lambdas have some limits on how many resources they take or how long they can operate, and the more resources you use the more expensive it becomes. More memory can quicken up the lambda but runtime is also important. The maximum time the lambda can be executing consecutively at this moment is 900 seconds (15 minutes), but this may change as not long ago it was 300 (5min). Check this out and be careful for these limits could affect the execution of your lambda if it must do a slow and time-consuming process or one that requires handling huge amounts of data (memory).

VPC: Similar to the role, some of your services may be inside a VPC subnet and/or security group, if that’s the case, you need to config all that in AWS and add them here (the select already preloads them from AWS if you are connected). You can add as many as you need. This was already done for me so I just added the right VPC depending on the environment (dev, stag, prod).

Environment: If you need to access any environment variable this would be the place to add it, was not my case so no tips here.

Adding a Step Function

Now, I just said while configuring the lambda to upload it that there are limits on the memory it can take and the total time it can be executing. Due to that, sometimes one lambda is not enough and you need to create a Step Function which basically is a State Machine that will handle the execution between different lambdas or just the one. To create a Step Function is as easy as writing a txt with it, which you can do at AWS going to Services > Step Functions > “Create State Machine” (there’s a button at the top).

When you write it you have a panel on the side displaying the current diagram, if you click on Refresh in that panel it will not only refresh the diagram but also validate your current step function.

Once you finish it, you don’t need to have it in VS, but I thought it would be better to save a copy so I just added a folder and saved them there in a txt (also diff ones for each environment).

AWS Serverless Application

There is a new way of doing this in Visual Studio which allows you to create a project that will include the step functions and lambdas required for it. This sort of project is called “AWS Serverless Application” and would basically include all the things we were doing in one project only plus another for the tests, which looks nicer. This said, creating Step Functions automatically requires special permissions and our current roles didn’t allow it, as we were not into this just yet we decided to abort and so I didn’t find out much of what this option offers, but it is there if you prefer a less manual approach.

Adding a Time Watch

For this particular scenario, we needed our lambda to be executed each morning, though the lambda ended up becoming a step function with 3 lambdas the watch was exactly the same: go to Services > CloudWatch > Rules > Create Rule and set when do you want it to be executed with a Cron expression. Then on the sidebar you can add “targets” and you can select as many as you want so if for example we want to run this each day at 6am but there’s other services that also need to be executed at that time every day, you can add them all together in the same Watch.

When adding a target, you need to select if the target is a Lambda, a Step Function, or any of the many other options available at AWS, then you will have those added in your profile in this region (remember the region was important) and select the one you need.