2

Amazon Web Services – Breadth and Depth

Understanding a cloud provider’s core benefits and the pace of innovation around the services you are about to use is crucial for your business strategy. When migrating to the cloud, you establish a long-term relationship with the cloud provider, and your business technology will depend on the provider’s security, stability, investment, innovation, and fair pricing model.

Imagine migrating to a cloud provider and, suddenly, the provider changes the pricing model or license, directly influencing your final service offering. Of course, you don’t want that. Right?

Amazon Web Services (AWS) has constantly been reducing service pricing; since 2006, it has reduced prices 107 times. For example, in November 2021, AWS reduced prices by 31% in three Simple Storage Service (S3) storage classes for existing and new customers.

In this chapter, we’ll learn about the pace of innovation around Windows containers on AWS and how AWS Nitro supercharges Windows container performance. Next, we’ll have a high-level overview of all AWS container orchestrators that support Windows and their use cases.

The chapter will cover the following topics:

• Why AWS for Windows containers?
• Understanding how AWS Nitro impacts container performance
• Learning about AWS container orchestrators

Why AWS for Windows containers?

A lot of people ask me: Marcio, why should I choose AWS to run Windows containers if Microsoft is the one that built and owns the technology? I prefer to let you choose a cloud provider that addresses your needs and requirements based on your due diligence. In this first topic, we’ll learn about the pace of innovation around Windows containers on AWS.

AWS started supporting Windows containers in December 2017. From there, it learned about the technology, hired experts in the subject, and launched over 11 features and services in almost 5 years. The following list contains the most notable launches around Windows containers, with a drastic increase in pace in 2022:

• Amazon Elastic Container Service (ECS) support for Windows, December 2017: AWS started supporting Amazon ECS with Windows Server 2016 and Docker 17.06 Enterprise.
• Amazon Elastic Kubernetes Service (EKS) support for Windows, October 2019: AWS started supporting Amazon EKS with Windows Server 2019 and Kubernetes 1.14.
• Amazon ECS support for Amazon FSx for Windows tasks, November 2020: This solution is excellent for legacy Windows apps that save files into local drives or network shares.
• AWS Fargate for Windows, October 2021: This launch brought serverless Windows containers into the picture, enabling customers to run containers without needing to deploy and manage Elastic Compute Cloud (EC2) Windows hosts.
• ECS Exec for Amazon ECS Windows tasks, November 2021: A fantastic daily operation feature allows customers to easily collect diagnostic information and troubleshoot by directly interacting with containers without first interacting with the host container operating system, opening inbound ports, or managing Secure Shell (SSH) keys.
• Amazon ECS Anywhere support for Windows, March 2022: This feature brought Amazon ECS Windows tasks to anywhere, on-prem, and in any other cloud. In addition, Amazon ECS Anywhere allows customers who have already containerized Windows applications to migrate on-prem dependencies to the cloud. With ECS Anywhere, customers deploy on-prem Windows containers through the Amazon ECS console in the same way in the cloud.
• Amazon Elastic Block Store (EBS) Container Storage Interface (CSI) Driver support for Windows, March 2022: Until this release, the Amazon EBS storage provider-specific code was kept in the Kubernetes project, referred to as in-tree drivers. The CSI was designed to replace in-tree drivers, drastically accelerating cloud vendor innovations in the Kubernetes storage space.
• Amazon EKS supports container runtime for Windows, March 2022: Dockershim removal in Kubernetes 1.24 was published in late 2020. AWS started the containerd test since the alpha version for Windows, ensuring it would pass through all the AWS security compliances to be included as a supported runtime.
• ECS Exec for Amazon ECS Fargate Windows tasks, April 2022: ECS Exec was made available for Fargate Windows tasks, an excellent addition for daily operations, mainly because AWS Fargate is a serverless solution where you don’t have access to the underlay operational system.
• Amazon EKS supports CSI Proxy for Windows nodes, April 2022: CSI Proxy was introduced on EKS-optimized Windows Amazon Machine Images (AMIs) in April 2022, allowing customers to run CSI drivers such as EBS and Server Message Block (SMB) drivers on Amazon EKS.

But in fact, it isn’t only about launching new features and services. AWS must ensure that reliable documentation is available and curated to help customers run, manage, and apply best practices when running Windows containers on AWS. To avoid an extensive list of these blogs and whitepapers here, check out the Appendix section of the book for more information.

When choosing a cloud provider to run Windows containers, you will need to consider how close it is to the open source community and how much support you will have, even if it is out of scope. Although the Windows container community is still pretty small compared to Linux communities, and the shortage of experts on the topic is a challenge, both conditions play an essential role when choosing one cloud provider over another.

I can tell from my experience working at AWS that they are customer-obsessed. For example, there was a time I had to jump into a call with AWS cloud support engineers, software development engineers, and the customer to fix a Calico plugin issue in the customer Amazon EKS with Windows node groups. Now, if you think about that for a second, AWS made support engineers, software engineers, and solution architects available to fix an issue in an open source network plugin that AWS didn’t even develop. This demonstrates the commitment and best effort a customer will have if they decide to run Windows containers on AWS. I could spend pages just talking about other cases related to Fluentd, Fluent Bit, Terraform, and more out-of-AWS-scope activities, but I want to ensure we are right on track with what is most essential—the core of the book.

Understanding how AWS Nitro impacts container performance

When we think about Windows containers, the last thing that comes to mind is the hardware under the hood that powers the container. However, the combination of the hypervisor, hardware, and software directly affects the network packet flow, network jitter, latency, memory buffer, connections per second, and processing performance within the Windows container.

AWS has built a system called the AWS Nitro System from scratch—a combination of a hypervisor, built-purpose hardware, and software that provides unmatched performance. The AWS Nitro System is divided into five components:

• The Nitro Hypervisor
• Nitro Cards
• The Nitro Security Chip
• Nitro Trusted Platform Module (Nitro TPM) 2.0
• Nitro Enclaves

We’ll focus only on the most impactful components for Windows containers: the Nitro Hypervisor and Nitro Cards.

The Nitro Hypervisor is a Kernel-based Virtual Machine (KVM)-based lightweight hypervisor that manages memory and CPU allocations, delivering almost the same performance as a bare-metal instance. The AWS Nitro System offloads most hypervisor execution such as encryption, network, and storage I/O to Nitro Cards, resulting in almost the entire physical CPUs being dedicated to EC2 instances running on the hardware.

Nitro Cards are composed of three different physical cards:

• Nitro Card for VPC: This is responsible for encapsulation, decapsulation, security groups, limiters, and routing. One of the most significant benefits of the Nitro Card for VPC is that if you are running a Windows container host on an Amazon EC2 c5 instance type that provides up to 25 GB of network throughput and decide to upgrade to an EC2 instance that provides network throughput up to 100 GB (such as c5n), the only thing you need to do is turn it off, change the instance type, and turn it on again. Your task is done; there is no need for driver re-installation.
• This gives you flexibility and freedom to move between different Amazon EC2 instances that best address your Windows container performance requirements without the need to maintain multiple EC2 AMIs, each one with a set of network drivers.
• Nitro Card for EBS: This is responsible for mounting/unmounting EBS volumes to an Amazon EC2 instance. It uses Non-Volatile Memory Express (NVMe) over the fabric with the proprietary AWS protocol. The Nitro Card for EBS encrypts data before sending it to the network-attached storage (NAS) for encrypted EBS volumes. The benefit is that your Windows container host performance isn’t penalized by the encryption/decryption of the block storage, which frees up CPU and storage I/O for the containers.
• Nitro Card for Instance Storage: This is responsible for mounting/unmounting and transparent encryption on local ephemeral NVMe block storage. Having Instance Storage disks is very appealing for Windows containers as you can save and process temporary data until the Windows container host gets terminated, instead of using Amazon EBS volumes for temporary data processing.

All these benefits, combined with the latest Intel and AMD CPU chipsets available on Amazon EC2 instances, positively affect your Windows container host performance by increasing network packets, CPU cycles, and faster memory access, resulting in better application performance.

Note

I do recommend watching the following deep-dive session on YouTube if you are interested in learning about it in greater detail: AWS re:Invent 2021 - Powering next-gen Amazon EC2: Deep dive on the Nitro System (https://www.youtube.com/watch?v=2uc1vaEsPXU).

Learning about AWS container orchestrators

On AWS, customers have an AWS container orchestrator variety, each addressing a different customer need. In contrast, you may also be undecided regarding the many options during the architecture phase. Let’s understand what the AWS container orchestrator options for Windows containers in more detail are:

• Amazon ECS is a fully managed container orchestrator that is highly secure and reliable and has deep integration with AWS services. It provides built-in monitoring and logging capabilities, and adoption is easy, as the learning curve isn’t long. In contrast, it isn’t multi-cloud and doesn’t offer the same flexibility and control you will find in Kubernetes. We will dive deeper into this in Chapter 3, Amazon ECS – Overview.

Website: https://aws.amazon.com/ecs/

• Amazon ECS Anywhere enables customers to run and manage container workloads on customer infrastructure or any other cloud. Amazon ECS Anywhere makes it easy for customers to run Windows containers on-premises, leveraging the same Amazon ECS instance in the cloud. One of Amazon ECS Anywhere’s benefits is shown when you need to run applications near the user due to latency or compliance requirements. We will dive deeper into Amazon ECS Anywhere in Chapter 4, Deploying a Windows Container Instance.

Website: https://aws.amazon.com/ecs/anywhere/

• Amazon EKS is a managed Kubernetes orchestration service that is robust, highly secure, and a mature orchestrator for Windows containers. It supports Group Managed Service Accounts (gMSAs), CSI drivers, CNI plugins, and EKS Blueprints. Windows build servers, online game servers, and integration with existing Amazon EKS clusters are just some of the many use cases you can carry out with Windows. We will dive deeper into Amazon EKS and Windows support in Chapter 7, Amazon EKS – Overview.

Website: https://aws.amazon.com/eks/

• AWS Fargate is a serverless compute for containers. It runs on top of Windows Server 2019 and provides kernel isolation without using Hyper-V isolation mode. AWS Fargate is an excellent option for customers who don’t have in-house Windows Server expertise, allowing them to solely focus on the application and forget about Windows Server management, such as patching, hardening, monitoring, inventory, and so on. We will dive deeper into AWS Fargate and Windows support in Chapter 6, Deploying a Fargate Windows-Based Task.

Website: https://aws.amazon.com/fargate/

With all these options, choosing one AWS orchestrator over another when running Windows containers depends on many factors; let’s explore some of them:

• Easy adoption: Easy adoption is an exciting topic, and I’ll make it provocative. This is all about what you really need versus what you think you need. I often talk with many customers who choose Amazon EKS as their primary container orchestrator—a decision to have in-depth control and flexibility at the expense of simplicity, which is acceptable. However, when asked why Amazon EKS, usually the answer is because of a multi-cloud strategy, but there isn’t one in place. I then take a step further and ask which Kubernetes controls and flexibility they plan to use that won’t be available in a simpler orchestrator. Usually, the answer is null.

The main point here is that, typically, legacy Windows applications such as intranet/extranet websites, external APIs, and other .NET Framework applications are very predictable and won’t use all the container benefits such as scale-out/in, service meshes, and so on. There are a few exceptions, such as building servers and calculation systems, but in general, legacy Windows applications are very predictable. If you are in doubt about which AWS container orchestrator should be adopted for Windows containers, this is the question you will need to ask yourself:

Do you need in-depth control and flexibility at the expense of simplicity?

• Features and integrations: Let’s put the solution architect hat aside and think through a DevOps engineer or site reliability engineer (SRE) lens for a minute; deploying Windows containers will require a lot of research to define which tools are supported on Windows. For example, Prometheus and its node-exporter just work on Linux; however, on Windows, things aren’t that straightforward. First, it requires a win-exporter, which is another community solution. How a Windows container exports metrics needs to be combined in a way you can easily visualize in Grafana.

Another example is Amazon Elastic Container Registry (ECR) image scanning, which helps identify vulnerabilities in your container images; however, it doesn’t support Windows images. One more example: let’s say you are running AWS App Mesh, which is a service mesh based on Envoy; again, there is no Envoy build for Windows on AWS App Mesh.

As you can see, additional tools may be needed to manage a Windows container cluster, and defining the bare minimum of what you need is fundamental when you don’t have an ocean of options as you do in the Linux world. So, again, this is the question you will need to ask yourself:

Do you need all the container ecosystems surrounding your Windows containers?

• Open source community: The open source community plays a significant role when choosing which container orchestrator to use. As we are talking about Windows containers, we need to know which open source containers are available and how much you can rely on the community and community size. Until now, I have had great experiences working with the Kubernetes and the SIG-Windows communities; people are friendly, there is no cloud competition, and everyone there is willing to help. However, production environments have service-level agreements (SLAs) that need to be met, and implementing an open source community solution for Windows containers where you won’t have a hotline to dial in when needed puts you in a bad spot.

I worked with some customers who faced an Amazon EKS and Windows node groups roadblock implementation when working with an open source plugin that didn't work as expected on Windows. Meanwhile, on Linux, it wasn’t a problem. As a result, the customer had three options:

• Use a third-party vendor solution
• Develop the code to adjust the open source plugin to their needs
• Migrate to Amazon ECS, which offers native monitoring and logging integration

Some customers have enough in-house expertise to overcome the blocker, develop their workaround, and support it. This shows how prepared they are to handle Kubernetes and Windows situations; others will need to step back and re-evaluate their container orchestrator choice and restart. The question you will need to ask yourself is this:

Would you rely on community support or implement a third-party vendor solution in your production workload?

• Support: Support is the hotline I mentioned earlier; when working with Amazon EKS, AWS support is limited to the Amazon EKS control plane and its components such as worker nodes, the VPC CNI plugin, EBS CSI drivers, and so on. However, community-developed plugins won’t be part of the support scope and may be part of best-effort support. AWS offers five support plans:
  • Basic
  • Developer
  • Business
  • Enterprise On-Ramp
  • Enterprise

Each one has a different price, case severity, and response time. Check out the following link to learn more: https://aws.amazon.com/premiumsupport/plans/.

When in doubt about which support plan you should buy, ask yourself the following:

How much downtime can my business afford without impacting the business revenue?

This will directly answer which type of support plan you need.

After you have read all these factors, the odds are probably not on the side of Amazon EKS. Kubernetes is a robust, highly scalable orchestrator that supports Windows very well; the drawback is the ecosystem, within which Windows containers aren’t first-class citizens. But, on the other hand, I’ve seen many customers successfully running Windows containers on Amazon EKS; they developed or adjusted all the necessary sidecar containers, purchased third-party plugins, and ran thousands of Windows Pods.

In a nutshell, the right AWS container orchestrator is the one that addresses your needs by taking into consideration all the factors you have learned about.

Summary

In this chapter, we learned why customers choose AWS to run Windows containers and the pace of innovation; then, we delved into the AWS Nitro Hypervisor and Nitro Cards and how they directly affect Windows container performance. Finally, we discussed some factors that need to be considered when choosing an AWS container orchestrator for Windows containers.

Until now, we have been setting the stage by understanding Windows container fundamentals. In Chapter 3, Amazon ECS – Overview, we will start the technical deep-dive. First, you will learn Amazon ECS principles, such as container instances, task definitions, and services, which will prepare you for the upcoming chapters.