Post Syndicated from aostan original https://aws.amazon.com/blogs/compute/automating-notifications-for-future-dated-amazon-ec2-capacity-reservation-state-changes/

This post is written by Ballu Singh, Principal Solutions Architect at AWS, Sandeep Rohilla, Senior Solutions Architect at AWS and Pranjal Gururani, Senior Solutions Architect at AWS.

AWS customers are able to proactively reserve future-dated Amazon EC2 On-Demand Capacity Reservations (known as future-dated CRs) to get capacity assurance for workloads and events. Because reservations can be created weeks in advance, customers are able to ensure that they can monitor their real-time status. Future-dated CRs can transition through various state of a Capacity Reservation, based on capacity availability. Over the course of several weeks, the status of a reservation might only change 1 or 2 times. Even with the low frequency of changes, most customers don’t want to manually poll the state of their reservations, instead they want to be proactively notified when something changes.

Amazon EventBridge is a serverless event bus service that facilitates the routing of events and EventBridge rules establish how events are processed, allowing you to filter events and route them to one or more targets for action. Amazon Simple Notification Service (SNS) is a fully managed messaging service that enables you to send messages or notifications to a variety of endpoints, facilitating scalable, and decoupled communication between different components of your application or with end-users.

In this blog post, we guide you through the process of automating notifications for future-dated CR state changes using AWS services such as Amazon EventBridge and Amazon Simple Notification Service (SNS).

Pre-requisites

• Existing future-dated Capacity Reservation. To learn how to create future-dated CRs, visit our blog post here.
• IAM access to create Amazon EventBridge rules
• IAM access to create Amazon SNS topic and subscription

Architecture

Amazon EC2 continuously monitors the state of your Capacity Reservations and sends events to Amazon EventBridge when Capacity Reservation states change. Using Amazon EventBridge, you can create rules that trigger notifications through Amazon SNS in response to these events. Amazon SNS then pushes these notifications to a variety of supported endpoint types such as Amazon Data Firehose, Amazon Simple Queue Service (SQS), AWS Lambda, HTTP, email, mobile push notifications, and mobile text messages (SMS). In our example, we will send notification to our email address.

Walkthrough

To automate the notification process for future-dated CR state changes, we will use the following AWS services:

1. Amazon Simple Notification Service (SNS): We will use SNS to send email notifications to the designated recipients.
2. Amazon EventBridge: We will create an EventBridge rule to capture the state change events of future-dated CRs.

AWS Console Walkthrough

Step 1: Set Up Amazon SNS Topics and Subscriptions

• Create a new topic for future-dated CR state change notifications.
  • Navigate to Amazon SNS console. On the Topics page, choose Create topic
  • In the Details section, for Type, choose Standard and enter the name of Topic (ex: Subscriber)

• • Choose rest of details as is. Choose Create topic.

• Create a subscription for the desired recipients, such as email addresses to receive the notifications.
  • Navigate to Amazon SNS console. In the left navigation pane, choose Subscriptions. Choose Create subscription.
  • On the Create subscription page, in the Details section, for Topic ARN, choose the Amazon Resource Name (ARN) of a topic enter topic ARN noted above. For Protocol, choose Email/Email-JSON
  • For Endpoint, enter your email address. Keep rest of details as is.

• • Choose Create subscription
  • Navigate to your email and choose Confirm subscription in the email from Amazon SNS.

Step 2: Create an Amazon EventBridge Rule

• Next open the Amazon EventBridge console and navigate to the Rules
• Click on Create rule and provide a name (ex: EC2CapacityReservationStateChange) and description for the rule. Keep all other setting as it is. Select
• For Event source, choose AWS events or EventBridge partner events.
• In the Creation method section, for Method, choose Use pattern form.
• For Event source, choose AWS services. Under AWS Service, choose EC2 and then choose EC2 Capacity Reservation.
• Optionally, you can narrow down the state and reservation ID you want to be alerted for by selecting Specific Capacity Reservation State and Specific Capacity reservation ID. Select Next.

• In the Target section, under Target Type, select AWS Service.
• For Select Target, choose SNS topic, under Topic, select SNS Topic you created in Step 1. Select
• On Configure Tags page, select Next.
• On Review and create page, select Create Rule.

CloudFormation Walkthrough

To simplify the setup process and make it easier for you to implement the automated notification solution, we have provided a CloudFormation template. This template automates the creation of the necessary Amazon EventBridge rule and Amazon SNS topic, along with the required configurations and permissions.

1. Download yaml sample template.
2. Navigate to AWS CloudFormation console and click on Create stack.
3. Choose Upload a template file and select the downloaded template. Choose Next
4. Provide a name for the stack under Stack Name. For CapacityReservationId, enter ID of the EC2 Capacity Reservation to monitor, (e.g., cr-1234567890abcdef0), for EmailAddress, enter email address you want to subscribe to the SNS topic, and for MonitoredStates enter comma-separated list of Capacity Reservation states to monitor (e.g. failed, expired, cancelled, pending). Choose Next

5. On Configure stack options, keep defaults. Choose

6. On Review and create page, choose

Clean up

To avoid ongoing charges, clean up your environment, by following these steps to delete the resources you created by following this blog, if they are no longer needed:

If you followed setup for AWS Console, please follow the below steps:

1. Delete the Amazon EventBridge Rule
   1. Navigate to Amazon EventBridge console and choose to the Rules from left pane.
   2. Choose the rule you created earlier and click on Delete.
   3. Confirm the deletion by clicking Delete in the confirmation dialog.
2. Delete the Amazon SNS Topic and Subscriptions
   1. Navigate to Amazon SNS console and navigate to the Topics from left pane.
   2. Choose the topic you created earlier and click on Delete.
   3. Confirm the deletion by clicking Delete in the confirmation dialog.

If you created any subscriptions for the topic (e.g., email or SMS), they will be automatically deleted along with the topic.

If you deployed CloudFormation template, please follow the below steps:

• Navigate to AWS CloudFormation console
• On the Stacks page, choose the stack that you created. Choose Delete.

Conclusion

In this blog post we walked you through setting up an EventBridge rule to capture the state change events of your future-dated CRs and configure SNS to send notifications to the designated recipients. This automated approach eliminates the need for manual monitoring and ensures that you stay informed about the status of your capacity reservations.

By proactively managing your future-dated CRs through automated notifications, you can make informed decisions, adjust your reservation plans if need, and take corrective actions to ensure you have the necessary resources available for your critical events.

This solution enhances your operational efficiency, reduces the risk of capacity shortages, and allows you to focus on other important aspects of your business.

We encourage you to implement this automated notification system for your future-dated Amazon EC2 On-Demand Capacity Reservations and experience the benefits of streamlined monitoring and proactive capacity management.

Post Syndicated from aostan original https://aws.amazon.com/blogs/compute/reduce-your-microsoft-licensing-costs-by-upgrading-to-4th-generation-amd-processors/

This post is written by Jeremy Girven, Solutions Architect at AWS. 

Amazon Web Services (AWS) and AMD have collaborated since 2018 to deliver cost effective performance for a broad variety of Microsoft workloads, such as Microsoft SQL Server, Microsoft Exchange Server, Microsoft SharePoint Server, Microsoft Systems Center suite, Active Directory, and many other Microsoft workload use cases. This post shows how the performance improvements of the latest generation AMD-powered Amazon Elastic Compute Cloud (Amazon EC2) instances can help you reduce licensing costs on Microsoft workloads running on AWS.

AWS has been running Microsoft workloads for over 16 years. The most common of these workloads are those running Microsoft Windows Server and Microsoft SQL Server. Both can be brought to AWS using the Bring Your Own License (BYOL) or License Included (provided by AWS) licensing models. Many BYOL licensing restrictions need workloads to be run on dedicated tenancy and need Dedicated Hosts. For these workloads, a license would be needed to cover each physical core of the Dedicated Host (for example if the Dedicated Host has 96 physical cores, 96 licenses would be necessary to cover the host). For License Included EC2 instances, the cost of the associated Microsoft licenses is a per-vCPU fee bundled into the total price of the EC2 instance.

Regardless of which licensing option works best for you, the licensing cost is directly related to the number of virtual cores (vCPUs) or physical cores used by your workloads. Using high-performance processors allows you to potentially reduce the total number of cores necessary to run a workload. Reducing the total number of cores subsequently reduces your total cost of ownership (TCO) by reducing the number of licenses. One potential option available for running Microsoft workloads on AWS are EC2 instances, which use fourth generation processors.

The AWS Nitro EC2 instance families using fourth generation AMD EPYC processors are M7a, C7a, R7a, and Hpc7a. These fourth generation AMD EC2 instances use DDR5 memory to deliver 2.25x more memory bandwidth and up to 50% higher performance as compared with previous generation AMD EC2 instances. For performance-per-watt improvements across integer performance, floating point, and natural language processing (NLP) throughout, these fourth generation AMD EPYC processors offer up to 2.7x greater results than those of previous generation AMD EC2 instances.

AMD has publicly available performance testing comparing the General Purpose M7a instances with the previous generation M6a instances. You can find the information in this link. We wanted to expand their testing to Compute Optimized and Memory Optimized EC2 instances to observe if their results hold true for different instance families.

In the following section we dive into our performance testing methodologies, and we review our results.

Method 1: CPU calculation speed

The following is the configuration of the EC2 instances used for testing:

• Instance Types: C6a.large and C7a.large (2 vCPUs, 4 GiB Memory, and 30 GiB (3000 IOPS, 125 MB/s) GP3 EBS volume)
• Operating System: Microsoft Windows Server 2022 Datacenter (10.0.20348 N/A Build 20348)
• Installed Software: AWS device drivers (NVMe 1.5.1 & ENA 2.7.0), Amazon EC2 Launch Agent v2 (2.0.1981.0), Amazon SSM Agent (3.3.551.0), and PowerShell 7.4.5 (all non-essential software has been removed)
• AWS Region and AZ: us-west-2 / us-west-2a (usw2-az1)

We performed a direct, yet CPU-intensive math test by calculating prime numbers in a range of 2 through 10,000 using Windows PowerShell (version 7 needed). This runs in a loop ten times, which allows us to use the processing time over all the runs. The following is the code used for testing:

Function Start-PrimeNumberTest {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory = $True)][Int32]$TestRunLimit, #The number of times the test will run in a loop
        [Parameter(Mandatory = $True)][Int32]$UpperNumberRange #The upper number of the range to find prime numbers in (larger the number the longer it takes to process)
    )
    $DoCount = 0
    $NumberRange = 2..$UpperNumberRange
    [System.Collections.ArrayList]$TimeArray = @()
    [System.Collections.ArrayList]$OutputArray = @()
    $vCPUCount = Get-CimInstance -ClassName 'Win32_Processor' | Select-Object -ExpandProperty 'NumberOfLogicalProcessors'
    Do {
        $Time = Measure-Command {
            $Range = $NumberRange
            $Count = 0
            $Range | ForEach-Object -Parallel {
                $Number = $_
                $Divisor = [Math]::Sqrt($Number)
                2..$Divisor | ForEach-Object {
                    If ($Number % $_ -eq 0) {
                        $Prime = $False
                    } Else {
                        $Prime = $True
                    }
                }
                If ($Prime) {
                    $Count++
                    If ($Count % 10 -eq 0) {
                        $Null
                    }
                }
            } -ThrottleLimit $vCPUCount
        }
        $DoCount++
        [void]$TimeArray.Add($Time.TotalSeconds)
        Start-Sleep -Seconds 5
    } Until ($DoCount -eq $TestRunLimit)
    $Output = $TimeArray | Measure-Object -Average -Maximum -Minimum | Select-Object -Property 'Count', 'Average', 'Maximum', 'Minimum'
    [void]$OutputArray.Add("Number of runs                     : $($Output.Count)")
    [void]$OutputArray.Add("Average time to complete (seconds) : $($Output.Average)")
    [void]$OutputArray.Add("Maximum time to complete (seconds) : $($Output.Maximum)")
    [void]$OutputArray.Add("Minimum time to complete (seconds) : $($Output.Minimum)")
    Write-Output $Output
}

To run the code, invoke the function and specify the Test Run Limit and Upper Number Range. For example, the following code mimics our test by finding prime numbers up to 10,000 and run the test 10 times:

Start-PrimeNumberTest -TestRunLimit 10 -UpperNumberRange 10000

Test results: CPU calculation speed

Figure 1. C7a.large and C6a.large performance results over ten tests

Although this is a direct CPU performance test, it demonstrates a clear performance advantage of using the latest generation of AMD powered instances as compared with previous generations:

• Slowest test: The C7a.large was over seven seconds faster than the quickest run on the C6a.large. This is a delta of more than 25% faster in the worst-case scenario for the C7a.large.
• Fastest test: The C7a.large completed over 13 seconds faster than the C6a.large, showing a 47% faster processing time.
• Average: There is an 11 second difference in processing time between the two instances. The C7a.large is averaging over 38% faster than the C6a.large.

Price-performance

The latest generation of AMD instances is more expensive than the previous generation. However, when we consider the performance delta between the two instances, using the average test duration length and the on-demand price of both instances in us-west-2, the C7a.large cost $0.000957791 per run to process the workload while the C6a.large cost $0.001352344. The C6a.large costs approximately $0.0004 per second more to process the same workload. Although that might sound small, this cost delta is greater than $12,000 over a 1-year period. These results show the value using the latest generation of AMD powered instances, especially with CPU bound workloads.

Method 2: SQL Server performance

We wanted our second testing method to focus more on real-world applications related to Microsoft workloads. For this test, we wanted to measure SQL Server performance.

SQL Server can be tested with an open source load testing tool called HammerDB. SQL Server is primarily used for OLTP workloads, thus we used the TPROC-C benchmark from HammerDB because it is specifically tailored for OLTP database testing.

The following is the configuration of the EC2 instances used for testing:

• Instance Types:8xlarge and R6a.8xlarge (32 vCPUs, 256 GiB Memory)
• Storage: io2 EBS volumes w/ 40,000 IOPS (EC2 instance maximum)
• SQL Server: Microsoft SQL Server 2022 (RTM-CU14) (KB5038325) – 16.0.4135.4 (X64) Jul 10 2024 14:09:09 Copyright (C) 2022 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2022 Datacenter 10.0 <X64> (Build 20348: ) (Hypervisor)
  • Maximum Server Memory: 240 GB
  • Database File Size: 220 GB
  • Database Data Size: 2000 warehouses (~200 GB)
  • MAXDOP: 1

HammerDB creates a test database based on “warehouses.” Each warehouse is approximately 100 MB of data. Our test server used 2000 warehouses, leaving approximately 20 GB for overhead in the 220 GB database file size. The total database size was also purposely sized smaller than the total memory allocated to our SQL Server. This allows SQL Server to cache as much of the database as possible in memory to avoid latency reading from disk.

When testing with Hammer DB, it uses “virtual users” as a method of applying load to the database. Our testing on each EC2 instance started with a small load of 32 virtual users to match the number of virtual users to vCPUs. Tests used a warmup time of five minutes and five minutes of processing. Then, the virtual users were increased by logarithmic scale to apply a larger performance load on the servers. Testing continued until we saw a decline of the of the total Transactions Per Minute (TPM). Three full runs were completed on each EC2 instance to create an average TPM at each level of virtual users.

Test results: SQL Server performance

Figure 2. R7a.8xlarge and R6a.8xlarge average TPM

Figure 3. R7a.8xlarge and R6a.8xlarge average TPM

The R7a.8xlarge consistently outperformed the R6a.8xlarge, even on tests with low load. The most notable difference was a 34% increase in TPM at peak performance. These results are similar to the 32% difference that AMD published when testing the M7a.8xlarge and M6a.8xlarge instances using another OLTP benchmark, TPROC-E.

Cost savings

Our test results are good news if you’re running SQL Server workloads. The ability to process more transactions with the same number of vCPUs translates into needing fewer vCPUs to run your current workloads, thereby lowering the total number of SQL Server licenses in your environment. With SQL Server Enterprise Edition licensing costing over $15,000 per 2-core pack as of this writing, being able to reduce your SQL Server licensing costs could save you hundreds of thousands of dollars for your total cost of ownership.

Conclusion

When evaluating the cost of CPU license-based workloads, such as those available with Microsoft workloads, the results show looking at the price alone isn’t optimal for selecting instances to use for your workloads. Commercial software such as Microsoft’s Windows Server or SQL Server are typically licensed at the vCPU level or the physical core level (BYOL). When dealing with CPU-bound workloads, choosing the instance with the highest performance to price ratio is the best evaluation method.

Author Bio

Jeremy Girven Jeremy is a solutions architect specializing in Microsoft workloads on AWS. He has over 16 years’ experience with Microsoft Active Directory and over 25 years of industry experience. One of his fun projects is using SSM to automate the Active Directory build processes in AWS. To see more, check out the Active Directory AWS Partner Solution (https://aws.amazon.com/solutions/partners/active-directory-ds/).

Post Syndicated from aostan original https://aws.amazon.com/blogs/compute/retaining-optimize-cpus-configuration-during-amazon-ec2-scaling-to-save-on-licensing-costs/

Introduction

Amazon Elastic Compute Cloud (Amazon EC2) now lets you modify CPU configurations after an instance has launched. With this new feature, users can change instance CPU settings either by directly modifying the CPU configuration, or when changing instance size or type. You can now specify a custom number of CPUs and/or disable simultaneous multithreading (SMT) also known as hyper-threading (HT), for workloads where HT doesn’t provide performance improvement. These capabilities help Bring Your Own license (BYOL) users to optimize their CPU-based licensing costs. For more details on supported instance types, core count, and threads per core values available for each instance type, refer to the supported CPU options for Amazon EC2 instance type documentation.

Why CPU configuration matters for different workloads?

One of our users recently faced a significant challenge when their SQL Server licensing costs unexpectedly increased after scaling their EC2 instances to the next size up. This increase occurred because the Optimized CPUs feature, which can be configured to enable a custom number of CPUs to disable HT so that they can save on SQL Server BYOL licensing costs, was reset during scaling. As a result, this user quadrupled (as opposed to doubled) their licensing requirements when scaling from r7i.xlarge to r7i.2xlarge. Initially, we recommended creating a new Amazon Machine Image (AMI) and launching a new instance with the desired CPU configurations. But this approach introduced complications such as creating new AMIs, moving Amazon Elastic Block Store (Amazon EBS) volumes, and managing security groups. The user wanted a solution that would allow them to scale their workloads seamlessly without these complexities. After working backward from this and other user requirements, we are excited to bring the capability to retain the Optimized CPU configuration during scaling. This reassures you that your licensing costs are as you would expect (for example increase or decrease linearly with your instance size).

An Optimized CPU can reduce your per-CPU licensing costs by 50% by disabling HT, as long as doing so doesn’t affect application performance. You can save more by selectively disabling additional cores based on your specific workloads. Example workloads include, but are not limited to the following:

• Compute-intensive workloads (for example scientific computing, simulations), which often perform better with one thread per core rather than two threads per core.
• Database workloads (for example SQL Server) where reducing the thread count to one per core typically does not impact performance, because these workloads need more memory and storage but are less dependent on a high number of CPUs. For more details, refer to Optimize CPU best practices for SQL Server workloads.
• High-performance computing (HPC) workloads, which sometimes perform better without HT because it can cause performance degradation because of context switching.

Three ways to set or modify CPU configurations

First, you can modify the EC2 instance configuration on an instance that is stopped after launch by modifying CPU Options:

1. Go to the EC2 Dashboard: Log in to your AWS Management Console and go to the EC2 dashboard.
2. Choose the Instance: Choose the EC2 instance that you want to modify from the list.
3. Stop the Instance: In the Instance State dropdown, choose Stop Instance.
4. Change CPU Options: In the Actions dropdown, choose Instance Settings, and choose Change CPU Options. You should observe the box shown in Figure 1.
5. Configure CPU Settings:

a. Adjust the number of CPU cores (for example the dropdown box to the left of core(s))

b. Set the number of threads per core to 1 so that you disable HT (for example the dropdown box to the left of thread(s) per CPU core)

6. Apply the Changes: When your desired CPU configuration is set, choose Apply to save the settings.

Figure 1: Changing CPU options after instance launch

Second, you can also modify the CPU configuration during an instance size or type change:

1. Select the Instance: From the EC2 dashboard, choose the instance to modify.
2. Stop the Instance: In the Instance State dropdown, choose Stop Instance.
3. Change Instance Type: In Actions, choose Instance Settings, then choose Change Instance Type. You should observe the box shown in Figure 2.
4. Configure CPU Options: While changing the instance type, you can also:

a. Adjust the number of CPU cores (for example the dropdown box to the left of core(s))

b. Set the number of threads per core to 1 so that you disable HT (for example the dropdown box to the left of thread(s) per CPU core)

5. Apply Changes: When configured, apply the changes.

Figure 2: Specifying CPU options during instance size or type change

Finally, you can use the CLI, API, or SDK method to configure the core count and threads per core for your instance using the new command modify-instance-cpu-options:

aws ec2 modify-instance-cpu-options --core-count "2" --threads-per-core "1" --instance-id "i-<your-instance-id>"

License tracking with optimized CPUs in AWS License Manager

You can effectively track your license usage by enabling the vCPU Optimization feature for self-managed license configuration within AWS License Manager. This feature integrates with Amazon EC2 CPU optimization, which lets you track the number of vCPUs on an instance. When the vCPU Optimization rule is set to True, License Manager counts vCPUs based on your customized core and thread count. Otherwise, it counts the default number of vCPUs for the instance type, which may not reflect your optimized CPU settings.

Conclusion

The ability to modify CPU configurations after an EC2 instance launch offers flexibility and efficiency for managing your workloads. You can adjust CPU cores, threads per core, and change instance types or sizes while retaining custom CPU settings without creating a new instance. This feature helps optimize performance, reduce licensing costs, and streamline operations.

Start using this new functionality today to improve the efficiency and scalability of your EC2 instances!

To learn more about CPU options on Amazon EC2, check out this guide, and Optimize CPU best practices for SQL Server workloads.

Author Bio

Rafet Ducic

Rafet Ducic is a Senior Solutions Architect at Amazon Web Services (AWS). He applies his more than 20 years of technical experience to help Global Industrial and Automotive users transition their workloads to the cloud cost-efficiently and with optimal performance. With domain expertise in Database Technologies and Microsoft licensing, Rafet is adept at guiding companies of all sizes toward reduced operational costs and top performance standards.