50 Shades Of .NET On AWS

You may have no appetite for learning Kubernetes and prefer to use an orchestrator deeply integrated with the AWS platform. If so, you can host your .NET application on Amazon Elastic Container Service with Amazon EC2 Windows instances.

Replatform your .NET Core, .NET 5+ application

If your application is a .NET Core or .NET 5+ application, the question you need to answer is: do you want to run your application on Windows or Linux? There are many reasons for continuing to run your .NET Core/.NET 5+ application on Windows servers. Here are the two most common:

• Your operations and/or development team is highly skilled on Windows operations and has less knowledge on Linux operations.
• Your application has a dependency on a module that can run only on Windows.

In this case, the decision tree you have to walkthrough is basically the same as for .NET Framework applications.

To reduce your need for Windows Server licenses or standardize your operations on one operating system, you may also decide to run your .NET application on Linux. This offers you even more options. If a container is your favorite application packaging format you can continue there. If you are interested by serverless functions, jump directly to the next section.

If container is your choice, the next node in the decision tree is about the nature of your application. If you are building a publicly accessible Web application or API and want to sit in the passenger seat for operating your infrastructure, I would recommend to use AWS App Runner. It is a fully managed service for running your web or API application with no prior infrastructure experience required. Under the hood, it automatically deploys your application, load balances traffic with encryption and scales up and down the number of container instances to meet your traffic needs. But you don’t need to worry about all this.

However, not every .NET application is about public Web application or API. You may want to deploy a private Web application or API. You may want to deploy a background worker process. You may want to deploy batch jobs. Even in these cases you can let AWS manages the infrastructure, health check, scaling, etc. for you.

In this case, you will use AWS Fargate to run your containerized .NET applications and the last question you have to answer is whether you want to use Kubernetes as an orchestrator and thus Amazon EKS or our built-in orchestrator Amazon ECS.

If you have specific hardware or configuration requirements, you may want to consider deploying your .NET containerized application on self-managed compute hosts. It will offer you maximum flexibility on the configuration of your hosts. Here again, you end up by choosing between Amazon EKS or Amazon ECS.

Refactor to serverless functions

Finally, if you want to avoid using containers or want to leverage a fully managed infrastructure or you are developing event-oriented .NET applications, you are a candidate for using serverless functions and AWS Lambda, our serverless, event-driven compute engine.

If you want to leverage the event-driven nature of AWS Lambda compute and still use containers to package your application, you can. AWS Lambda offers you this flexibility.

The .NET Lambda function programming model is pretty straightforward. The code blow shows the default function handler method you get when you create a C# Lambda function for processing Amazon Simple Queue Service (Amazon SQS) events. Amazon SQS is a fully queue service. It can trigger your Lambda function each time a message or a batch of messages reach the queue. Your function handler receives an SQS event that contains the messages and all you have to do is to write the logic for processing the messages.

/// <summary>
/// This method is called for every Lambda invocation. This method takes in
// an SQS event object and can be used to respond to SQS messages.
/// </summary>
/// <param name="evt"></param>
/// <param name="context"></param>
/// <returns></returns>

public async Task FunctionHandler(SQSEvent evt, ILambdaContext context)
{
 foreach(var message in evt.Records)
    {
        await ProcessMessageAsync(message, context);
  }
}

Conclusion

You really have 50 shades of .NET on AWS. Knowing which way to host is the right for you may seem overwhelming at first. If you use the decision tree we have gone through in this article, you will end up with the right option in the vast majority of the use cases.

You may have some use cases that still don’t fit in this decision tree because of hardware, security, compliance, or business requirements. If so, don’t hesitate to reach out to the AWS community or AWS Developer Advocates like myself on social networks or on repost.aws.

If you want to learn more, I encourage you to visit our AWS .NET homepage (https://aws.amazon.com/dotnet) and to read our “Developing and Deploying .NET Applications on AWS” Whitepaper (https://go.aws/39NClk2). If you prefer videos, you can visit our .NET on AWS playlist on the AWS YouTube channel (https://bit.ly/dotnetonaws-youtube).