Microsoft Workloads on AWS
Reducing the operational cost of containerized Windows applications with AWS App2Container support for Windows on AWS Fargate
In July of 2020, AWS announced support for automating the conversion and deployment of IIS-based Windows applications to Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), or AWS App Runner using the AWS App2Container tool. In the time since that initial announcement, App2Container has been enhanced to support more complex architectures consisting of multiple IIS applications and also Windows services. To run these applications, customers needed to provision Amazon Elastic Compute Cloud (Amazon EC2) instances to serve as the Windows container hosts on which the tasks (or pods) ran. Fortunately, App2Container provided the ability to automatically provision this infrastructure, but customers still have the operational overhead of maintaining these container host instances.
Since the launch of AWS Fargate, that operational overhead could be avoided by selecting Fargate as the launch type when deploying an application’s containers. AWS would manage the provisioning and management of hosts, allowing developers to adopt a serverless approach for their container-based applications. However, until recently Fargate only offered support for Linux-based container images. This prevented Windows-based applications from being deployed to Fargate and instead required deployment to Amazon ECS or Amazon EKS clusters containing Amazon EC2 hosts.
With the announcement of support for Windows on Fargate, this ability to run serverless containers has now become available to Windows container developers, and the App2Container tool has been enhanced to support automating deployments to AWS Fargate for Windows applications. In this article, I will explore this new support and walk through how customers can leverage Fargate for deploying their Windows applications.
Selecting AWS Fargate for your application’s deployment
To deploy to Fargate, we must first containerize an existing application in preparation for deployment. If you are new to App2Container, refer to the documentation and walkthrough blog for App2Container to familiarize yourself with the process of containerizing a .NET application on Windows using App2Container. If you already have the tool installed, run the app2container upgrade command to automatically update to the latest version to use this new feature.
Following the App2Container steps to containerize your Windows application, you will first open a command prompt with administrative permissions, select an application using the inventory command, examine the application’s configuration using the analyze command, and generate a container image using the containerize command.
As part of the container creation step, App2Container generates a few files to define the container image and how to deploy this image to AWS. In particular, we are interested in the deployment.json file. This file provides the opportunity for customers to customize aspects of their application’s deployment to AWS by modifying the values in the JSON document:
- Whether to use Amazon ECS, Amazon EKS or AWS App Runner
- Whether to use an existing Virtual Private Cloud
- What launch type to use for the container hosts
If App2Container detects that your application targets Windows Server 2019 and does not need to use Group Managed Service Accounts (gMSA), App2Container will automatically select AWS Fargate in a new Amazon VPC created for the application as the default configuration in the deployment.json file. For all other configurations, App2Container will use Amazon ECS with Amazon EC2 hosts. If you need to modify this, it can be changed prior to deployment by updating the value of the deployTarget property of the ecsParameters object to “EC2” or “FARGATE”.
Setting the deployment type to AWS Fargate
It is important to note that Windows support for Fargate also includes the ability to use the awsvpc network mode. Using this mode will attach an Elastic Network Interface to your Fargate task that enables the ability to access to other resources hosted in a VPC, such as databases or other application servers hosted in private subnets. If you select Fargate as the deployment target for your application, App2Container will automatically configure your task to use this mode. In cases where you intend to have your Fargate application access VPC-hosted resources, you will need to modify deployment.json to support this. To indicate the VPC you intend to use, update the configuration of the reuseResources object and set the vpcId property to the ID of the existing VPC. Do also be aware that a new security group will be created by the application deployment named “EnvironmentSecurityGroup” that may need to be added to inbound access rules on your existing resources’ security groups.
Configuring the deployment to use an existing VPC
Deploying to Fargate
After making these modifications, we are ready to deploy our application using the generate app-deployment command to generate the CloudFormation templates necessary to provision the application’s hosting infrastructure. If we specify the –deploy switch to this command, App2Container will also automatically deploy a Stack using the generated template. After performing a successful deployment, App2Container will provide you with a URL for your application’s load balancer, and you can navigate to that URL with your browser to see your application.
You can also inspect the configuration of your application’s task is Amazon ECS, and verify that it is now hosted as a Fargate task.
Viewing our Fargate task in the ECS dashboard
Current Limitations
As of the writing of this article, there are a few limitations for applications targeting Fargate as the hosting platform. Currently, Fargate only supports Windows Server 2019-based hosts, and therefore only images using Windows Server 2019-based base images are supported. In addition, Fargate container hosts do not currently support the ability to be joined to an Active Directory domain. This prevents the use of Group Managed Service Accounts, also preventing the use of Windows-integrated authentication to other Windows-based resources.
Also, in the current release of App2Container, the base image used in the Dockerfile App2Container generates for your container will include support for ASP.NET 4.7.2 and all prior versions of ASP.NET. If your application is using the newer 4.8 ASP.NET runtime, you will need to modify your Dockerfile to reference a base image (e.g. aspnet:4.8-windowsservercore-ltsc2019) that includes support for that version. After you make these modifications you will need to re-build your container image using app2container containerize with the –build-only switch. Using this switch informs the App2Container tool to use the existing Dockerfile and prevent overwriting your modifications.
Conclusion
In this article, we introduced App2Container’s newly-added support for deployment to Fargate. We walked through an example deployment process and illustrated the changes necessary to the deployment.json file to select Fargate as the hosting mechanism for an application’s containers. Finally, we covered the limitations that a developer must take into consideration when using this deployment target.
To get started using this new capability, either download or upgrade to the latest version of the App2Container tool and follow the above instructions to target Fargate as the deployment platform before deploying your application.
For more information, refer to the following links:
AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.