The log parser uses ASP.NET Core, so in theory it can run on Linux. It was tentatively deployed to a Windows IIS environment in AWS Beanstalk; look into migrating to a Linux environment.

To do

• Migrate local environment from IIS Express to Kestrel.
• Look into deploying a self-contained .NET Core app to AWS Beanstalk.

AWS Beanstalk does not have a pre-configured option for .NET Core on Linux. That leaves the options as CloudFormation, as we already mentioned in Discord, as well as using Docker.

Going Docker would look like getting a Dockerfile together that would pull the application from somewhere (GitHub, most likely), and do installation steps, based off of Amazon Linux. Most likely would need to have Docker also install the .NET Core as part of the initial build since I doubt Docker carries around one of the .NET Core options. We would then just launch this Docker container with Elastic Beanstalk and call it a day.

We could get a bit more sophisticated of a setup with CloudFormation and SSM. First, the account would need an SSM role to be able to run Automations. One such Automation would be used to create an updated Linux AMI (just creates a box and runs 'yum update' basically, then images it). This image would then be part of a stack that would create an "autorecovery" Amazon Linux box. This means if the box ever died, it would re-provision it immediately. Once the box was configured, which would require SSHing into it and doing the work manually, we would then image the box at a base state and keep that as a "Golden AMI". This would be the image that would be re-provisioned in the case of an outage.

To use the autorecovery feature, you must have alarms configured and also the following:

• Use a C3, C4, C5, C5d, i3.metal, M3, M4, M5, R3, R4, T2, or X1 instance
• Run in a VPC (not EC2-Classic)
• Use shared tenancy
• Use EBS volumes only

The box would likely be a t2.micro or t2.small, so that takes care of the first requirement (you probably do not see enough traffic to run out of burst credits that the T2 series has) and the rest come easily.

Edit Note: Instead of autorecovery, we could also do an autoscaling group with 1:1 as limits. In this instance, there really wouldn't be a difference.

Edit Note 2: I can also set up yum-cron on the boxes so that they patch themselves automatically.

The web infrastructure was moved to Azure where Windows is only a few dollars more per month, so this is no longer a priority.