Running Windows Containers with Amazon ECS on AWS Fargate

At AWS, customers are running their most mission-critical workloads on Amazon Elastic Container Service (Amazon ECS) with Windows as their compute layer. Still, the undifferentiated heavy lifting of managing the underlying host OS, patching, scaling, and hardening when running Windows containers are time-consuming tasks. Therefore, customers can choose to use the optimized AMIs, which are preconfigured with the necessary components and tested by AWS engineers. These enable customers to reduce the time spent to get started and get their containers running on AWS quickly.

Once customers could deploy quickly, they wanted to focus on building applications without managing servers. Specifically, they wanted a serverless option to run applications based on Windows containers.

Today, we are excited to announce AWS Fargate now supports Amazon ECS Windows containers. With this latest release, customers can take advantage of the serverless, pay-as-you-go compute engine for running their Microsoft Windows applications. By choosing vCPU and memory resources, customers can launch Windows containers without the burden of managing and maintaining the Windows servers.

In this blog post, we will walk through the following steps to deploy a Windows container to Amazon ECS on AWS Fargate:

1. Creating a Fargate for Windows task definition.
2. Launching a Fargate for Windows task from the task definition.
3. Collecting and analyzing task logs with Amazon CloudWatch Logs.
4. Monitoring performance with CloudWatch Container Insights

Getting started

Prerequisites and assumptions:

• You have properly installed and configured the latest version of AWS CLI.
• You have properly created an Amazon ECS cluster in Networking only mode.
• Amazon ECS cluster created on a VPC with a public subnet or private subnet with a NAT gateway.

1. Creating an Amazon ECS Fargate for Windows task definition

To prepare your application to run on Fargate, you must create a task definition. A task definition describes one or more containers (up to a maximum of ten) that form your unit of deployment and scaling. For example, these parameters can be used to indicate which containers image should be used, which ports should be opened on the containers, and what log driver should be used with the containers in the task.

When architecting your application to run on Fargate, the main question is: When should you put multiple containers into the same task definition versus deploying containers separately in multiple task definitions? See task definition application architecture.

Let’s create our first Fargate for Windows task.

1.1) In the Amazon ECS console, click task definition, and Create new task definition.

1.2) Select Fargate as the launch type compatibility.

1.3) On Configure task and container definitions, specify the task definition name, task role, and select Windows Server 2019 through Operating system family. Note: There is no technical difference or limitation between Windows Server 2019 Core or Windows Server 2019 Full when running Windows containers. The proposal for both choices is to give customers a seamless transition to match the exact Windows operating system (OS) installation used before the application containerization. AWS encourages customers to test the Windows container image in both options and recommends Windows Server 2019 Core for maximum performance and resources availability. Amazon ECS on AWS Fargate does not support direct access to the underlying OS through Remote Desktop Service (RDP) or remote PowerShell execution.

The task definition operating system family must be the same when running the task. See Step 2.3.

1.4) The next step is to choose a task size. The following sizes are available for Fargate for Windows-based tasks.

In the following example, let’s choose 2GB of memory and 1 vCPU to be available for the task.

1.5) Container Definition is used in task definitions to describe the different containers that are launched as part of a task. You can specify how many containers will be running as part of the same task, sharing the task size resources (vCPU, memory, and disk) between the containers. For example, we’ll be running a single container within the task, dedicating the entire task size (resources) to it.

1.6) To keep things simple, we’re not going to add any additional customization in the task definition. However, rolling the console down on Storage and Logging, you can configure the containers in your tasks to send log information to CloudWatch Logs. When registering a task definition in the Amazon ECS console, you have the option to allow Amazon ECS to auto-configure your CloudWatch Logs. This option creates a log group on your behalf using the task definition family name with ecs as the prefix.

This is an excellent option for log visibility within the container, which we will cover in more detail on step 3. Select Auto-configure CloudWatch Logs.

1.7) Select Add in the right bottom of the page.

1.8) Select Create on the Task Definition page.

2. Launching a Fargate for Windows task from the task definition

When you run your tasks and services with the Fargate launch type, you specify the vCPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and does not share the underlying kernel, vCPU resources, memory resources, or elastic network interface with another task.

2.1) In the Task Definition console, find the task you just created.

2.2) Select the task and choose Run Task.

2.3 Select Fargate as a Launch type and the Operating system family, The Platform version should be 1.0.0 for Fargate for Windows. Select the cluster you already created as mentioned in the “prerequisites and assumption” section for Cluster.

2.4) For VPC and Security Groups, select the VPC and subnets related to your existing Fargate cluster.

2.5) Select Run Task

2.6) Wait until your task reaches Running status. This can take few minutes depending on container image size.

2.7) Congratulations, you have launched your first Fargate for Windows task. At this point, you might also want run the same task definition as part of an Amazon ECS service. An Amazon ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. If any of your tasks should fail or stop for any reason, the Amazon ECS service scheduler launches another instance of your task definition to replace it. This will maintain the desired number of tasks in the service. In addition to maintaining the desired number of tasks in your service, you can optionally run your service behind a load balancer. The load balancer distributes traffic across the tasks that are associated with the service.

In the following example, we created an Amazon ECS service with two Fargate for Windows tasks. As part of the Amazon ECS service wizard, we also created an Application Load Balancer with external access to expose the application to the internet.

2.8) Wait until the tasks reach Running status. Through the Application Load Balancer created in the previous step, we’re able to access the “Welcome IIS” webpage in one of the Windows tasks.

At this point, we have created a Windows-based task definition and launched it as a standalone task. We then created an Amazon ECS service to launch and control the tasks lifecycle and exposed it to the internet through an Application Load Balancer. In the following steps, we will cover how to collect and analyze logs, as well as monitor a Fargate for Windows task.

3. Collecting and analyzing task logs with Amazon CloudWatch Logs

In this section, you will learn about collecting and analyzing Fargate for Windows logs. In step 1.6, we setup the container definition to use awslogs driver to send Windows container logs to an Amazon CloudWatch log group.

Unlike Linux applications that log to STDOUT, Windows applications log to Windows locations such as ETW, Event Log, and custom log files. Since many container ecosystem logging solutions are built to pull from the STDOUT pipeline, as standard with Linux, Windows containers app logs historically have not been accessible via these solutions. Microsoft Log Monitor is an open-source tool built by Microsoft that bridges the gap between Windows log locations and STDOUT. In the example, we built a Windows container image to have Log Monitor instrumentation to send IIS logs and System Logs to a STDOUT pipeline created by Log Monitor. These logs are automatically captured by awslogs driver and sent to CloudWatch logs.

To set up LogMonitor as part of a Windows container image, follow the instruction in the official GitHub repository.

To view the CloudWatch Logs data for a container from the Amazon ECS console

3.1) Open the Amazon ECS console

3.2) On the Cluster page, select the cluster that contains the task to view.

3.3) On the Cluster: cluster_name page, choose Tasks and select the task to view.

3.4) On the Task: task_id page, expand the container view by choosing the arrow to the left of the container name.

3.5) In the Log Configuration section, choose View logs in CloudWatch, which opens the associated log stream in the CloudWatch console.

4. Monitoring performance with CloudWatch Container Insights

Using CloudWatch Container Insights you can collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as vCPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can even set CloudWatch alarms on metrics that Container Insights collects.

Container Insights collects data as performance log events using embedded metric format. These performance log events are entries that use a structured JSON schema that enables high-cardinality data to be ingested and stored at scale. From this data, CloudWatch creates aggregated metrics at the cluster, node, pod, task, and service level as CloudWatch metrics. The metrics that Container Insights collects are available in CloudWatch automatic dashboards, and are viewable in the Metrics section of the CloudWatch console.

To help you manage your Container Insights costs, CloudWatch does not automatically create all possible metrics from the log data. However, you can view additional metrics and additional levels of granularity by using CloudWatch Logs Insights to analyze the raw performance log events. Metrics collected by Container Insights are charged as custom metrics. For more information about CloudWatch pricing, see Amazon CloudWatch pricing.

You can enable Container Insights on new and existing Amazon ECS clusters. For existing clusters, use the AWS CLI. For new clusters, use either the Amazon ECS console or the AWS CLI.

For existing Amazon ECS cluster, enable CloudWatch Container Insights by running the following command in the AWS CLI.

aws ecs update-cluster-settings --cluster MYCLUSSTERNAME —settings name=containerInsights,value=enabled

Once CloudWatch Container Insights enabled, metrics will be available in CloudWatch console.

4.1) Open the CloudWatch console.

4.2) In the navigation pane, choose Performance Monitoring.

4.3) Use the drop-down boxes to select the type of resource to view and the specific resource.

Pricing

AWS Fargate for Windows is per-second billing with a 15-minutes minimum for vCPU, memory, and a separate Windows OS license fee per vCPU for each Amazon ECS task. Pricing is based on the resources requested from the time the task starts to download the Windows container image until the Amazon ECS task terminates, rounded up to the nearest second.

You can leverage Compute Savings Plans (CSP) discounts for long-running Fargate for Windows tasks, like web applications and Windows services or On-demand for short-running tasks. Better still, a combination of both depending on the application behavior. Fargate for Windows Spot is not available at this time.

For additional Fargate for Windows pricing details, visit the Pricing webpage.

Fargate for Windows tasks unsupported features

• FireLens
• gMSA integration
• Directly mount Amazon FSx for persistent, shared storage for Windows task definition

Cleaning up

To avoid ongoing charges for resources, you should delete the resources created as a part of this setup.

1. Navigate to the Amazon ECS console and select the Amazon ECS cluster used for this exercise.
2. On the Task tab, select the tasked launched on step 2.6 and select Delete.
3. On the Services tab, select the task launched on step 2.7 and select Delete.

Conclusion

AWS Fargate removes the need to provision, scale, and manage the lifecycle of a compute infrastructure so that you can focus on what matters most: your applications. All the infrastructure abstraction offered by Fargate for Windows, when combined with AWS App2Container, allows customers to containerize and migrate existing applications easily.

Customers can also leverage AWS Copilot, which is designed for both existing and new Amazon ECS users who want to move beyond manual management of lower-level infrastructure and focus on their application and its lifecycle. Copilot creates modern application deployments by default, based on production-ready patterns that include best practices designed by Amazon ECS engineers and customers over the years. Learn how to use AWS Copilot with Fargate for Windows.

Start containerizing your Windows applications today in all commercial AWS Regions except AWS China Regions and AWS GovCloud (US) Regions.