Accelerate Amazon EC2 Auto Scaling for Microsoft Windows workloads

In this blog post, we will present a sample solution and provide recommendations on how to reduce both the cost and time associated with a Microsoft Windows Server instance joining an Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group up to 78%. Customers using Amazon EC2 Auto Scaling often desire faster scale-out times to minimize the scaling event duration and avoid additional charges for the compute resources during the bootstrapping process. By implementing these suggestions, you can optimize your scaling process, achieve quicker scale-outs, and benefit from cost savings while maintaining efficient resource allocation.

Solution overview

Our sample solution simulates an application that deploys infrastructure to run a .NET e-commerce application, Bob’s Used Books, and is built to be:

• Scalable – Uses Amazon EC2 Auto Scaling group and fast launch technologies. The fast launch technologies optimize the boot process that a standard Windows Server operating system (OS) launch takes, which includes several reboots and typically takes 15 minutes or longer to complete.
• Reliable – Provides the mechanism to improve reliability though load balancing and multiple Availability Zone deployment.
• Secure – Uses least privilege AWS Identity and Access Management (IAM) roles and security groups.

The architecture of this sample solution is shown in Figure 1:

Figure 1 – Architectural diagram

This solution includes a GitHub repository containing an AWS CloudFormation template that can be deployed multiple times in one or more AWS accounts. The AWS CloudFormation template will provision the following resources:

• Application Load Balancer
• Amazon EC2 Auto Scaling with a launch template and lifecycle hook
• Amazon EC2
• EC2 Image Builder
• AWS Directory Service for Microsoft Active Directory
• Amazon Relational Database Service (Amazon RDS) for SQL Server
• AWS Systems Manager documents
• Amazon EventBridge rules
• AWS Secrets Manager and AWS Systems Manager Parameter Store parameters
• IAM roles and Amazon EC2 instance profile
• AWS Lambda function

As illustrated in Figure 1, the solution is using an Amazon EC2 Auto Scaling group in two different subnets for high availability and reliability. Amazon EC2 Auto Scaling will use the configuration settings from the launch template parameters: Amazon Machine Image (AMI) ID, IAM instance profile, instance type, and other settings. Finally, the AWS CloudFormation template will invoke a Lambda function to execute the new AMI build by EC2 Image Builder and set the new AMI as the default version in the launch template.
After deploying using CloudFormation, the solution will create a new AMI using EC2 Image Builder. EC2 Image Builder will go through a process of creating a custom AMI based on the latest Windows Server public AMI. Within the EC2 Image Builder recipe, various preconfigured components are selected such as update-windows for zero day vulnerabilities, chocolatey for package management, and windows-server-iis to install IIS Web Server, among several other components. To customize the image further, a custom component is developed. A custom component document executes a series of PowerShell commands using the ExecutePowerShell action to install Git, clone the Bob’s Used Books repository from GitHub, and then make various code modifications, such as updating the website view with instance metadata to pull the region and instance ID. Finally, the .NET application is published with the tailored changes.

The AMI created from EC2 Image Builder contains all the prerequisites to run the .NET application. Upon completion, the EC2 Image Builder distribution configuration updates the launch template configuration with the new AMI with the fast launch option enabled. Fast launch is an AMI configuration option to reduce the Windows Server operating system (OS) lengthy boot process. This will allow the Amazon EC2 Auto Scaling group to use the new AMI with every new scaling action.
During the scale-out event, the Amazon EC2 Auto Scaling lifecycle hook will place the instance(s) into Pending:Wait status. For more information, refer to the Amazon EC2 Auto Scaling instance lifecycle documentation. The lifecycle hook will invoke the Amazon EventBridge rule to trigger an AWS Systems Manager automation document that will join the computer to the domain and place the Amazon EC2 instance into InService status.

When the scale-in event happens, the instance will disjoin the computer from the domain, set the computer object in Active Directory (AD) to a disabled state, and terminate the instance. The .NET application uses Microsoft SQL Server to store the book data and the customer shopping cart. The end user accesses the application using the application load balancer’s DNS address and the request is routed to an instance in the Amazon EC2 Auto Scaling group.

Test setup

We will test this solution by comparing the potential cost and time savings of optimized Amazon EC2 instances to non-optimized Amazon EC2 instances during the scale-out events. The test consists of launching 250 optimized and 250 non-optimized instances for the following instance types:

• large (8GiB and 2vCPU)
• xlarge (16GiB and 4vCPU)
• 2xlarge (16GiB and 8vCPU)
• 4xlarge (128GiB and 16vCPU)
• 8xlarge (128GiB and 32vCPU)

Figure 2 – EC2 instance scale out times – X-axis is the # of instances and the Y-axis is the time

As Figure 2 illustrates, the optimized AMIs scaled out at the same rate (Y-axis) despite the instance types or number of instances (X-axis). In contrast, the non-optimized AMIs took longer during the scale-out event and varied based on the Amazon EC2 instance type.

The reduction in runtime is directly proportional to the cost savings. For partial hours, Amazon EC2 for Windows instances are billed in one-second increments with a minimum of 60 seconds. Depending on the instance type, decreasing the bootstrap process time by 65%-78% percent saves the cost of that bootstrap time by the same  percent.

Test Results

Overall, Amazon EC2 optimization provides cost and time reduction in Amazon EC2 Auto Scaling environments. The test demonstrated cost savings by running Amazon EC2 instances in an optimized mode during scaling events across a range of instance types. The results show up to 78% savings compared to non-optimized instances. The primary technologies used to gain these optimizations are :

• Fast Launch – The standard launch process for Amazon EC2 for Windows instances involves multiple reboots and can often take 15 minutes or longer to complete. Windows AMIs optimized for faster launching mitigates this by completing some of the initial launch steps and reboots.
• EC2 Image Builder – Streamlines the process of building, testing, and deploying virtual machine (VM) and container images for use on AWS or on-premises environments.

Further optimizations are possible by leveraging one or more of the following recommendations:

• Scheduled scaling – Proactively scale based on predictable traffic patterns.
• Warm pools – Reduce latency by pre-launching instances.
• Dynamic scaling – Scales the capacity of Amazon EC2 Auto Scaling groups as traffic changes occur.
• Spot Instances – Leverage unused Amazon EC2 capacity for cost savings.

Walkthrough

Configure AWS CloudFormation

1. Download the AWS CloudFormation template from the GitHub repository.
2. Navigate to the AWS CloudFormation console in the AWS account chosen to test the solution.
3. For Create Stack, select With new resources (standard).
4. For Template source, select Upload a template file. Select Choose file and select the template downloaded in step 1. Select Next.
5. For Stack name, enter a stack name to identify this CloudFormation stack.
6. In the Parameters section, provide the following:
   1. VPC: select the VPC where the subnets are located. Select Next.
   2. PublicSubnets: select two public subnets in different AZs to be used with the application load balancer. Select matching AZs for both the private and public subnet.
   3. PrivateSubnets: select two private subnets in different Availability Zones (AZs) to be used with AWS Managed Active Directory, Amazon EC2 Auto Scaling, and Amazon RDS. Select matching AZs for both the private and public subnets.
   4. InstanceType: select Amazon EC2 instance type for the Amazon EC2 Auto Scaling group.
   5. KeyPair: select the Amazon EC2 key pair to be use with Amazon EC2 Auto Scaling launch template.
   6. MicrosoftADDomainName: enter the FQDN of the AWS Managed Active Directory.
7. In the Configure stack options page, select Next.
8. Select I acknowledge that AWS CloudFormation might create IAM resources with custom names, then select Submit.
9. Navigate back to the AWS CloudFormation console, select the new stack, and select Outputs, as shown in Figure 3.

Figure 3 – CloudFormation outputs

Note the BobsBookstoreALBDNSName, BobsBookstoreASG, and BobsBookstoreIBPipeline values. They will be referenced later in the demo. These values will differ from the values shown in Figure 3.

As illustrated in Figure 4, navigate to the EC2 Image Builder console (1), select Image pipelines (2), select the pipeline that matches the value of BobsBookstoreIBPipeline (3), select Output images (4), and confirm the Image status is Available (5).

Figure 4 – EC2 Image Builder pipeline

Next, navigate to the Auto Scaling groups under the Amazon EC2 console. Find the Auto Scaling group. The Amazon EC2 Auto Scaling group name will begin with the CloudFormation stack name used to deploy it. Select this group, then select the Instance management tab. Initially, there will be no instances. On the Details tab, choose Edit. Change the Desired capacity and Minimum capacity to “1”. Choose Update.

A new instance will be launched in the Amazon EC2 Auto Scaling group. View the progress on the Instances tab (Figure 4) as the lifecycle moves from Pending:Wait (as shown in Figure 5) to InService (as shown in Figure 6). It will take several minutes for the instance to launch into the Amazon EC2 Auto Scaling group.

Figure 5 – Auto scaling group – Pending:Wait

Figure 6 – Auto scaling group – InService

Now, use the BobsBookstoreALBDNSName value (refer to Figure 3), and paste that URL in a web browser. The webpage should display Bob’s Used Books as the website header. If there are multiple instances in the Amazon EC2 Auto Scaling group, it will create instances in multiple availability groups. Refresh the page multiple times and watch the instance ID and Availability Zone name change, as shown in Figure 7.

Figure 7 – Sample website

Cleanup

Deploying this solution will provision AWS resources and incur costs. Once you complete testing and no longer need the scaling mechanism,there are two steps that you would need to follow to cleanup your resources.

1. Remove all the instances by navigate to the Auto Scaling groups under the Amazon EC2 console. Find the Auto Scaling group. The Amazon EC2 Auto Scaling group name will begin with the CloudFormation stack name used to deploy it. Select this group, then select the Instance management tab. On the Details tab, choose Edit. Change the Desired capacity and Minimum capacity to “0”. Choose Update.
2. Remove the provisioned resources by deleting the AWS CloudFormation stack created as a part of this example. Navigate to the CloudFormation console and select the stack created as part of this walkthrough. Choose Delete, and then choose Confirm when prompted. Any instances that are running as part of the Amazon EC2 Auto Scaling group will be terminated and all resources originally created by the AWS CloudFormation template will be removed.

Conclusion

In this blog post, we presented a sample solution and recommendations to speed up the process of a Windows Server instance launching into an Amazon EC2 Auto Scaling group. Optimizing the Amazon EC2 Auto Scaling group configuration and streamlining the Windows Server launch process will reduce the scaling duration and provide cost optimization. Automating image building, warm pools, and scheduled scaling are some of the key techniques covered to enable faster scale-outs.