- Creating the basic form
- Integrating with AWS
- Integrating with S3
- Adding background tasks
- Sending emails and creating download links
This article will go through the process of integrating the file transfer application with AWS. More specifically, this means:
- Using an MSSQL database from the AWS RDS service;
- Using the Parameter Store to keep our keys safe;
- Deploying the application to Elastic Beanstalk.
Setting up the IAM user
In order to interact with AWS resources from Visual Studio and from our application, we will need an IAM user – this will tell AWS what resources and actions we are allowed to access. Watch the following video to see how to setup an IAM user:
Save the access key ID and secret access key for now, as you’ll need to set them up in Visual Studio – this is the only time you’ll be able to see the secret one.
Setting up AWS Toolkit for Visual Studio
We will need the AWS Toolkit in order to deploy the application to Elastic Beanstalk, as well as working with the Parameter Store – for local applications, the credentials set up with the AWS Toolkit will be assumed by the application. Download it from the Visual Studio marketplace and install it.
Once you are done, you can follow the guide from the AWS documentation to set up your credentials in Visual Studio. Once you create your user locally, you don’t need the credentials anymore; get rid of them if you saved them somewhere else, as they can be used to access your account.
Connecting to a remote database
Connecting to a remote database will be needed when we deploy our application to the cloud. For this series, we will use the AWS RDS service to create an MSSQL database. Watch the following video to see how to create the database and make it accessible from your computer:
Save the password temporarily, as this is the only time you can see it (without resetting it) and you will need it twice during the following steps.
Once it’s successfully created, you can connect to it through Visual Studio by right clicking on ‘SQL Server’ in the ‘SQL Server Object Explorer’ and choosing ‘Add SQL Server’:
Once you have connected to the server, right click on the ‘Databases’ directory inside it, and choose ‘Add New Database’; this will create the actual database we will use for the application, as by default you only have the ‘rdsadmin’ one:
Now you can right click on it and choose ‘Properties’ to grab the connection string, just like you did during the previous tutorial:
You can replace your local connection string from the ‘appsettings.json’ file with this one, but we’re not going to do that yet; instead, let’s look at the parameter store from AWS.
Working with the Parameter Store
We just added a connection string to a remote database to our code – this contains not only our database URI, but also our master username and password for it. And since we are going to push this code to GitHub, this will clearly be a problem.
The solution here is to keep our connection string in the Parameter Store, and retrieve it by using a key at runtime; this way, no one looking at the code will have any idea what the connection string looks like. Follow the next video to see how to add the connection string to the parameter store:
Let’s install the NuGet package that allows us to access the Parameter Store. Right click on your project, click ‘Manage NuGet Packages’, and search for ‘Amazon.SimpleSystemsManagement’:
Finally, let’s create a class that encapsulates the functionality for retrieving a parameter. Create a folder called ‘Services’ and a class called ‘AwsParameterStoreClient’ inside it. To keep things generic, I made the constructor take a ‘RegionEndpoint’ parameter, that specifies which AWS region it should get the resources from. Feel free to omit this if all your resources are located in the same region:
The method created a ‘AmazonSimpleSystemsManagementClient’ object, which it then uses to return the parameter with the specified ‘Name’, and decrypting them if necessary (if you are storing it as a secure string). Finally, it returns the value. There is also a synchronous version of the method, with no ‘await’ calls, which will be used from Startup.
Let’s now jump into the ‘Startup’ class and use the parameter store to get our connection string. Below the ‘Configuration’ property, add a new property that returns an AwsParameterStoreClient object; then, when creating the DB context, use this client instead of getting the connection string from the ‘appsettings.json’ file:
You can keep your local connection string in the JSON file if you would like to test some things locally before using the remote database, or you can delete it if you don’t think that will be the case.
Once you are done, don’t forget to run the ‘Update-Database’ command again, as you need to apply the migrations to your new remote database.
Deploying to Elastic Beanstalk
Now that we have our connection to the database established, we can deploy our application to Elastic Beanstalk and have it run on a remote server. To start the process, right click on the project in the ‘Solution Explorer’ and choose ‘Publish to AWS Elastic Beanstalk’:
Next, choose your local profile and region; since you have not created any environment in Elastic Beanstalk previously, choose the ‘Create a new application environment’ option:
Next, choose the application and environment names. You can have different environments for the same application, such as a development and a production one. For this case, I’m calling the environment ‘Transferzor-dev’:
On the next screen, you have to choose the type of server you want to create. Since this is a .NET Core application, you can deploy to either a Windows or a Linux server. For this example, I chose the default IIS option. Make sure to change the instance type to ‘t2.micro’ in order to avoid large costs. Finally, select the security group associated with your RDS in the list from the bottom of the screen; this will give the instance access to the database:
Next, you have to choose the role that your application will assume. You can choose ‘Power User Access’ for now, as it will give the application access to any service we might use (S3, SSM, RDS, etc.):
And finally, choose the configuration of your application. You can leave it to ‘Debug’ so you can get additional information on exceptions, but choose ‘Release’ when you are ready to make your application public:
Click the ‘Next’ button, then ‘Deploy’, and wait for the process to finish. Once finished, you can open the Elastic Beanstalk service in the AWS Console and see your application’s URI.