Heroku are getting rid of their free tier, which was problematic at first since my sample projects are hosted there. However, seeing as how I will be working with AWS in my new job, I thought now is a good a time as any to try another platform.
Deploying the projects to AWS wasn't as straightforward as I initially hoped, but I got there in the end after much trial and error. This post is to highlight a few key steps in the migration process. I'm currently using Elastic Beanstalk for the applications and RDS for the databases.
BadImageFormatException
Firstly, you need to make sure the build is compatible with the target platform. I have initially chosen the t4g.nano, which are ARM64 environments, therefore I needed to change the platform inside Visual Studio to ARM64.
Build >> Configuration Manager >> Project Platform
Deployment
It's important to keep cleaning and building your solution before you deploy to AWS.
The only way I could get a project to deploy properly was to use the AWS Visual Studio tools, right click the project then publish to AWS. Using the legacy publish to Elastic Beanstalk didn't work well, neither did uploading the code through the AWS browser console.
It worked best when I published to a new Elastic Beanstalk environment straight from Visual Studio, then later created the RDS database afterwards in the Elastic Beanstalk browser console.
RDS
Access the environment variables was different to Heroku, so I had to rewrite some of the code (ConnectionService). I also ended up making a service specifically for secret strings, so that the application will automatically retrieve these variables from either the secrets file stored locally, or the AWS environment variables.
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.db.html
Importantly, I don't think you can have a hash # character in the environment variables, which became a problem for my passwords. When creating a user on first application run, you need a special character in your password, so make sure you include one. This error wasn't the clearest to debug, but using the @ symbol now instead of # works.
Annoyingly, to make matters inconsistent, the password for the database connection cannot have a @ character in it when you create the database.
Schedule
With AWS, you're charged per hour for your usage. You can set timings of your Elastic Beanstalk (EB) environments using the scheduled actions in the capacity configuration, by setting the instances to 0. This turns out to be not that beneficial for me currently, as I am hosting the environments on t4g.nano and when they're not in use you get an hourly charge for keeping the IP address which costs more than when the instance is just left running. For the time being I have decided to let them run 24/7.
For the RDS instances, which are more expensive to run per hour, I tried what felt like every tutorial, including official AWS guides, but couldn't get the instances to deactivate automatically at a specified time.
However the following tutorial works for me:
https://www.youtube.com/watch?v=goonVi9X7Yo
You create a stack with CloudFormation, using an AWS template:
It's then possible to customise the hours and add your own parameters in the config table (hosted on DynamoDB), so that each RDS instance can be automatically controlled individually. Currently I'm using 3 types of hours, ranging from on most of the day, to only 1 hour per day.
However, the EB app only seemed to respond to the Lambda functions when I created and deployed the environment directly from Visual Studio. When I created a demo app from the browser console, and then uploaded the code from Visual Studio to update the existing environment, the RDS solution would not see any lambda requests to stop the instances.
Another note is that the hours in the config tables on DynamoDB seem to be UTC+1, where as the capacity config within Elastic Beanstalk are UTC. Both say they are UTC but if you pop the exact same ours in, the database schedule will be out by an hour.
When the RDS instance is offline, but your application is running you'll either get a 503 bad gateway message, or if your app had already been running prior to Db going offline, you'll get an error at runtime but it shouldn't crash the app.
I will cover importing the Heroku Postgres database to RDS in another post.