# What is Microsoft SQL Server on Amazon EC2?
You can run Microsoft SQL Server on Amazon EC2. Microsoft SQL Server is a relational database management system (RDBMS) whose primary purpose is to store and retrieve data. SQL Server includes additional services, such as Analysis Services (SSAS), Reporting Services (SSRS), Integration Services (SSIS), and Machine Learning (ML). AWS provides a comprehensive set of services and tools to deploy Microsoft SQL Server on the reliable and secure AWS Cloud infrastructure. The benefits of running SQL Server on AWS include cost savings, scalability, high availability and disaster recovery, improved performance, and ease of management. For more information, see [Learn why AWS is the best cloud to run Microsoft Windows Server and SQL Server workloads](https://aws.amazon.com/blogs/compute/learn-why-aws-is-the-best-cloud-to-run-microsoft-windows-server-and-sql-server-workloads/) on the AWS Compute blog.
Amazon Elastic Compute Cloud (Amazon EC2) supports a self-managed SQL Server. That is, it gives you full control over the setup of the infrastructure and the database environment. Running SQL Server on Amazon EC2 is very similar to running SQL Server on your own server. You have full control of the database and operating system-level access, so you can use your choice of tools to manage the operating system, database software, patches, data replication, backup, and restoration. You are responsible for data replication and recovery across your instances in the same or different AWS Regions. For more information, refer to the [AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/).
**Topics**
+ [Features](#sql-server-on-ec2-features)
+ [Pricing](#sql-server-on-ec2-pricing)
+ [Options to run SQL Server](sql-server-on-ec2-options.md)
+ [Concepts and terminology](sql-server-on-ec2-concepts.md)
+ [SQL Clustering best practices](aws-sql-ec2-clustering.md)
## Microsoft SQL Server on Amazon EC2 features
SQL Server on Amazon EC2 provides the following features:
+ **Flexible licensing options** — When you use Amazon EC2 instances with the license included, you are using instances with fully-compliant Windows Server and SQL Server that are licensed through AWS. Flexible BYOL options include default tenant EC2 for products that are eligible for [Microsoft License Mobility through Software Assurance](https://aws.amazon.com/windows/resources/licensemobility/), as well as [Amazon EC2 Dedicated Hosts](https://aws.amazon.com/ec2/dedicated-hosts/) and [Amazon EC2 Dedicated Instances](https://aws.amazon.com/ec2/pricing/dedicated-instances/). You can use [AWS License Manager](https://docs.aws.amazon.com/license-manager/latest/userguide/license-manager.html) to track the usage of software licenses and reduce the risk of non-compliance. For more information, see [Licensing](https://aws.amazon.com/windows/faq/#licensing) in the *Amazon Web Services and Microsoft Frequently Asked Questions*.
+ **High performance block storage** — [Amazon Elastic Block Store](https://aws.amazon.com/ebs) provides multiple options for high-performance block storage for Microsoft SQL Server. EC2 Instances using [io2 Block Express](https://aws.amazon.com/ebs/provisioned-iops/) give you the highest block storage performance with a single storage volume. Other SSD-backed Amazon EBS options include io2 volumes for business-critical applications and gp3 volumes for general purpose applications. Amazon EBS also offers crash-consistent snapshots, and enables application-consistent snapshots through Windows VSS (Volume Shadow Copy Services) to help protect your SQL Server deployments.
+ **Fully-managed shared storage** — [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx) and Amazon FSx for NetApp ONTAP offer fully-managed shared storage for high-availability SQL Server failover cluster instances (FCI) workloads.
+ **Windows-based services** — [Directory Service](https://aws.amazon.com/directoryservice) offers managed Microsoft Active Directory with identity and access management.
+ **Scalable processors** — [Intel Xeon Scalable Processors on AWS](https://pages.awscloud.com/gc-500-Running-Windows-Workloads-learn.html) provide you with better data protection, faster processing of more data volumes, and increased service flexibility for Amazon EC2.
+ **Migration programs** — AWS offers programs for migration for customers looking to migrate SQL Server workloads to AWS. AWS [Migration Acceleration Program (MAP) for Windows](https://aws.amazon.com/windows/map-for-windows/) provides services, best practices, and tools to help you save costs and accelerate your migration on AWS.
+ **Windows workload optimization** — After you move your SQL Server workloads to AWS, you can continue to optimize costs, usage, and licenses to suit your business requirements. With [Cost Explorer Service](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), you can visualize, understand, and manage your AWS costs and usage over time. [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) recommends optimal AWS compute resources for your workloads so that you can reduce costs up to 25% by analyzing historical utilization data. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html) can check that your EC2 instances have the required amount of SQL Server licenses and that the EC2 instance vCPU count doesn’t exceed what is permitted for the SQL Server edition. [AWS Managed Services](https://aws.amazon.com/managed-services/) can help operate your cloud environment post-migration by analyzing alerts and responding to incidents, reducing operational overhead and risk. You can use [AWS Systems Manager](https://aws.amazon.com/systems-manager) to automate operational tasks across your AWS resources and better manage your infrastructure at scale.
AWS can help you to modernize you Windows-based applications with AWS open source services if you want to reduce the high cost of commercial licensing. Options include running SQL Server database applications on Linux, moving workloads to [Amazon Aurora](https://aws.amazon.com/rds/aurora), containerizing your Windows applications with [Amazon EKS](https://aws.amazon.com/eks), going serverless with [AWS Lambda](https://aws.amazon.com/lambda), or taking advantage of micro-services based architecture.
For more features specific to Amazon EC2, see [Features of Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/concepts.html#ec2-features).
## Microsoft SQL Server on Amazon EC2 pricing
For information about pricing for Amazon EC2, see the [Amazon EC2 pricing](https://aws.amazon.com/ec2/pricing/) page.
For information about creating a price estimate for Microsoft Windows Server and Microsoft SQL Server, see [Tutorial: Using Windows Server and SQL Server on Amazon EC2 calculator](https://docs.aws.amazon.com/pricing-calculator/latest/userguide/estimate-workload-tutorial.html) in the *AWS Pricing Calculator User Guide*.
# Options to run SQL Server on the AWS Cloud
AWS provides the option to run Microsoft SQL Server in a cloud environment. For developers and database administrators, running SQL Server in the AWS Cloud is similar to running SQL Server databases in a data center. There are three primary options to run SQL Server on AWS:
+ Microsoft SQL Server on Amazon EC2
+ Amazon RDS for Microsoft SQL Server
+ Amazon RDS Custom for Microsoft SQL Server
Your application requirements, database features, functionality, growth capacity, and overall architecture complexity will determine which option to choose. Many AWS customers run multiple SQL Server database workloads across Amazon RDS and Amazon EC2. For more information on how to choose how to run SQL Server on the AWS Cloud, see [Decision matrix](https://docs.aws.amazon.com/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/matrix.html) on the AWS Prescriptive Guidance website.
If you are migrating multiple SQL Server databases to AWS, some of them might be a great fit for Amazon RDS, whereas others might be better suited to run directly on Amazon EC2. You might have databases that are running on SQL Server Enterprise edition but are a good fit for SQL Server Standard edition. You may also want to modernize your SQL Server database running on Windows to run on a Linux operating system to save on cost and licenses.
**Topics**
+ [SQL Server on Amazon EC2](#sql-server-on-ec2-options-ec2)
+ [RDS for SQL Server](#sql-server-on-ec2-options-rds)
+ [Amazon RDS Custom](#sql-server-on-ec2-options-rds-custom)
## Microsoft SQL Server on Amazon EC2
When to choose Microsoft SQL Server on Amazon EC2:
+ You want full control over the database and access to its underlying operating system, database installation, and configuration.
+ You want to administer your database, including backups and recovery, patching the operating system and the database, tuning the operating system and database parameters, managing security, and configuring high availability or replication.
+ You want to use features and options that aren’t currently supported by Amazon RDS. For more information, see [ Features not supported and features with limited support](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) in the Amazon RDS documentation.
+ You require a specific SQL Server version that isn’t supported by Amazon RDS. For a list of supported versions and editions, see [SQL Server versions on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport) in the *RDS for Microsoft SQL Server User Guide*.
+ Your database size and performance requirements exceed the current RDS for Microsoft SQL Server offerings. For more information, see [Amazon RDS DB instance storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) in the *Amazon RDS User Guide*.
+ You want to avoid automatic software patches that might not be compliant with your applications.
+ You want to bring your own license instead of using the RDS for Microsoft SQL Server license-included model.
+ You want to achieve higher IOPS and storage capacity than the current limits. For more information, see [Amazon RDS DB instance storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) in the *Amazon RDS User Guide*.
## Amazon RDS for Microsoft SQL Server
RDS for Microsoft SQL Server is a managed database service that simplifies the provisioning and management of SQL Server on AWS. With Amazon RDS, you can quickly deploy multiple versions and editions of SQL Server , with cost-efficient and resizeable compute capacity. You can provision Amazon RDS for SQL Server DB instances with either General Purpose SSD or Provisioned IOPS SSD storage. Provisioned IOPS SSD is optimized for I/O-intensive, transactional (OLTP) database workloads.
Amazon RDS manages database administration tasks, including provisioning, backups, software patching, monitoring, and hardware scaling. Amazon RDS also offers Multi-AZ deployments and read replicas (for SQL Server Enterprise edition) to provide high availability, performance, scalability, and reliability for production workloads. For more information, see [Amazon RDS for Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html).
When to choose RDS for Microsoft SQL Server:
+ You want to focus on your business and applications, and you want AWS to take care of undifferentiated heavy lifting tasks, such as the provisioning of the database, management of backup and recovery tasks, management of security patches, minor SQL Server version upgrades, and storage management.
+ You want a highly available database solution, and you want to take advantage of the push-button, synchronous Multi-AZ replication offered by Amazon RDS, without having to manually set up and maintain database mirroring, failover clusters, or Always On availability groups.
+ You want to pay for the SQL Server license as part of the instance cost on an hourly basis, instead of making a large, up front investment.
+ Your database size and IOPS requirements are supported by Amazon RDS for SQL Server. See [Amazon RDS DB Instance Storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) in the AWS documentation for the current maximum limits.
+ You don’t want to manage backups or point-in-time recoveries of your database.
+ You want to focus on high-level tasks, such as performance tuning and schema optimization, instead of the daily administration of the database.
+ You want to scale the instance type up or down based on your workload patterns without being concerned about licensing complexities.
## Amazon RDS Custom for SQL Server
Amazon RDS Custom for SQL Server is a managed database service for legacy, custom, and packaged applications that require access to the underlying operating system and database environment. Amazon RDS Custom for SQL Server automates setup, operation, and scaling of databases in the AWS Cloud while granting you access to the database and underlying operating system on Amazon EC2 to configure settings, install patches, and enable native features to meet the dependent application's requirements. For more information, see [Working with RDS Custom for SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-sqlserver.html) in the *Amazon Relational Database Service User Guide*.
When to choose Amazon RDS Custom for SQL Server:
+ You want the benefits of Amazon RDS, but your requirements include the need to customize the underlying operating system and database environment for legacy, custom, and packaged applications.
+ You need administrative rights to the database and underlying operating system.
+ You need to install custom database and OS patches and packages.
+ You need to configure file systems to share files directly with their applications.
# Microsoft SQL Server on Amazon EC2 concepts and terminology
The following concepts introduce you to the fundamental terminology used when working with Microsoft SQL Server on Amazon EC2 instances:
+ [Amazon Machine Images (AMIs)](#ami)
+ [Backup](#backup)
+ [Billing](#billing)
+ [High availability and disaster recovery (HADR)](#ha)
+ [Instance](#instance)
+ [Instance types](#instance-types)
+ [Launching](#launching)
+ [Security](#sec)
+ [Storage](#storage)
**Amazon Machine Images (AMIs)**
SQL Server on Amazon EC2 instances are created from Amazon Machine Images (AMIs). AMIs are similar to templates. SQL Server on Amazon EC2 AMIs are pre-installed with an operating system, typically Microsoft Windows Server, and other software. Together, these determine the operating environment. You can select an AMI provided by AWS, create your own AMI, or select an AMI from the AWS Marketplace. To find a SQL Server on Amazon EC2 AMI, see the options under [Find a Windows AMI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/finding-an-ami.html) in the *Amazon EC2 User Guide*.
**Backup**
Your backup and recovery design for SQL Server on Amazon EC2 is flexible, depending on your RTO and RPO requirements. AWS provides the ability to perform server-level backups using Windows Volume Shadow Copy Service (VSS)-enabled Amazon Elastic Block Store (Amazon EBS) snapshots and with AWS Backup. You can also perform database-level backups using [native backup and restore procedures](https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver16) for SQL Server databases. Database-level backups can be stored on Amazon EBS, FSx for Windows File Server, or Amazon Simple Storage Service using AWS Storage Gateway. For more information about backing up SQL Server on Amazon EC2, see [Backup and restore options for SQL Server on Amazon EC2](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/welcome.html) on the AWS Prescriptive Guidance website.
**Billing**
A SQL Server on Amazon EC2 instance is charged by the second, with a minimum of 1 minute. Applied rates are based on the type and size of the selected instance, the edition of SQL Server when using a license-included instance, along with the cost of any additional services, such as storage or networking. AWS provides a variety of instance families that are favorable to the performance requirements of SQL Server workloads.
You can rent an instance based on your unique CPU, memory, and storage throughput requirements. You can also stop or terminate an instance at any time to pause or stop billing for the instance. The main advantage of the On-Demand model is the ability to save on CAPEX when an instance is no longer required.
**Warning**
Any data on [Amazon EC2 instance store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) volumes are lost if your instance is stopped or terminated. You'll still incur costs for EBS volumes when your instance is stopped. For more information, see [Stop and start your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) in the *Amazon EC2 User Guide*.
**High availability and disaster recovery (HADR)**
You can take advantage of Windows Server Failover Cluster for high availability and disaster recovery (HADR) with SQL Server on Amazon EC2. SQL Server on Amazon EC2 supports both failover cluster instances (SQL FCIs) and Always On availability groups (AG). For more information see [How do I create a SQL Server Always On availability group cluster in the AWS Cloud?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-windows-sql-server-always-on-cluster/) in the AWS knowledge center.
**Instance**
A SQL Server on Amazon EC2 instance is a virtual (or bare metal) server that runs in the AWS Cloud and can be provisioned on demand. The subscriber rents the virtual server by the hour/minute/second, and can use it to deploy specific configurations of SQL Server. For more information about On-Demand instances, see [On-Demand instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-on-demand-instances.html) in the *Amazon EC2 User Guide*.
An Amazon EC2 Dedicated Hosts is a physical server with EC2 instance capacity that is fully dedicated to your use. Dedicated Hosts allow you to use your existing per-socket, per-core, or per-VM Microsoft SQL Server software licenses. For more information about Dedicated Hosts, see [Dedicated Hosts](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/dedicated-hosts-overview.html) in the *Amazon EC2 User Guide*.
**Instance types**
AWS provides various types of instances with different CPU, memory, storage, and networking configurations to support your application requirements. Each instance type is available in various sizes to address specific workload requirements. Instance types are grouped into families according to target application profiles, such as general purpose, compute-optimized, memory-optimized, and storage-optimized. The memory-optimized family of instances is a popular choice for SQL Server on Amazon EC2 because instances in this family have a high memory to CPU ratio for optimal performance. You can choose bare metal instances to support capabilities such as [Always Encrypted with secure enclaves on Amazon EC2 bare metal instances](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-always-encrypted-with-secure-enclaves/). For more information about individual and families of instance types, see [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/) in the AWS product pages.
Some instance types support instance store volumes, which provide temporary block-level storage for the instance. If your instance has instance store volumes, we recommend that you place tempdb on an instance store volume. This can improve performance and decrease costs. For more information, see [Place tempdb in an instance store](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-ec2-best-practices/tempdb.html).
**Launching SQL Server on Amazon EC2**
SQL Server on Amazon EC2 instances can be launched directly from the [Amazon EC2 console](https://console.aws.amazon.com/ec2), with AWS CloudFormation, by using [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/index.html), or by using the [AWS CLI](https://docs.aws.amazon.com/cli/index.html). For a guided deployment of Microsoft SQL Server, use [AWS Launch Wizard](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sql.html).
**Security**
AWS supports all security standards and compliance certifications, such as PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS, FIPS 140-2, and more. These standards enable you to build a fully compliant application on Amazon EC2. AWS also supports all SQL Server security features such as [Transparent Data Encryption](https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver16) (TDE) and [Always Encrypted with Secure Enclaves](https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-enclaves?view=sql-server-ver16) (when using bare metal instances).
Security and compliance is a shared responsibility between you and AWS. This shared model helps to relieve your operational burden because AWS operates, manages, and controls the components from the host operating system and virtualization layer to the physical security of the facilities in which the service operates.
For SQL Server on Amazon EC2, you assume responsibility and management of the guest operating system, including updates and security patches, other associated application software, and the configuration of AWS provided security group firewalls.
For more information about the shared responsibility model, see [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/).
**Storage**
AWS provides many storage options to host your database files. In addition to EBS volume types, you can attach volumes to SQL Server on Amazon EC2 instances using an Amazon FSx managed file system service, such as FSx for Windows File Server and Amazon FSx for NetApp ONTAP. Some instance types provide an Amazon EC2 instance store which provides temporary block level storage on NVMe solid state drive (SSD) disks that are physically attached to the host computer. For more information, see [Best practices for deploying Microsoft SQL Server on Amazon EC2](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-ec2-best-practices/welcome.html) on the *AWS Prescriptive Guidance* website.
# Best practices and recommendations for SQL Server clustering on Amazon EC2
You can configure Microsoft SQL Server on Amazon EC2 instances for high availability. SQL Server Always On availability groups offer high availability without the requirement for shared storage. The list of best practices in this topic, in addition to the prerequisites listed at [Prerequisites, Restrictions, and Recommendations for Always On availability groups](https://msdn.microsoft.com/en-us/library/ff878487.aspx), can help you optimize operating a SQL Server Always On availability groups on AWS. The practices listed in this topic also offer a method to gather logs.
**Note**
When nodes are deployed in different Availability Zones, or in different subnets within the same Availability Zone, they should be treated as a multi-subnet cluster. Keep this in mind as you apply these best practices and when you address possible failure scenarios.
**Topics**
+ [Assign IP addresses](#sql-ip-assignment)
+ [Cluster properties](#sql-clustering-cluster-properties)
+ [Cluster quorum votes and 50/50 splits in a multi-site cluster](#sql-clustering-quorum)
+ [DNS registration](#sql-dns-registration)
+ [Elastic Network Adapters (ENAs)](#sql-clustering-ena)
+ [Multi-site clusters and EC2 instance placement](#sql-multi-site-clusters)
+ [Instance type selection](#sql-clustering-instance-type)
+ [Assign elastic network interfaces and IPs to the instance](#sql-clustering-assigning-ENI-IP)
+ [Heartbeat network](#sql-clustering-heartbeat)
+ [Configure the network adapter in the OS](#sql-clustering-network-adapter)
+ [IPv6](#sql-clustering-ipv6)
+ [Host record TTL for SQL Availability Group Listeners](#sql-clustering-ttl)
+ [Logging](#sql-clustering-logging)
+ [NetBIOS over TCP](#sql-clustering-2012r2-netbios)
+ [NetFT Virtual Adapter](#sql-clustering-2012r2-netft)
+ [Set possible owners](#sql-owners)
+ [Tune the failover thresholds](#sql-failover-thresholds)
+ [Witness importance and Dynamic Quorum Architecture](#sql-clustering-file-share-witness)
+ [Troubleshoot](#sql-troubleshooting)
## Assign IP addresses
Each cluster node should have one elastic network interface assigned that includes three private IP addresses on the subnet: a primary IP address, a cluster IP address, and an Availability Group IP address. The operating system (OS) should have the NIC configured for DHCP. It should not be set for a static IP address because the IP addresses for the cluster IP and Availability Group will be handled virtually in the Failover Cluster Manager. The NIC can be configured for a static IP as long as it is configured to only use the primary IP of **eth0**. If the other IPs are assigned to the NIC, it can cause network drops for the instance during failover events.
When the network drops because the IPs are incorrectly assigned, or when there is a failover event or network failure, it is not uncommon to see the following event log entries at the time of failure.
```
Isatap interface isatap.{9468661C-0AEB-41BD-BB8C-1F85981D5482} is no longer active.
```
```
Isatap interface isatap.{9468661C-0AEB-41BD-BB8C-1F85981D5482} with address fe80::5efe:169.254.1.105 has been brought up.
```
Because these messages seem to describe network issues, you could potentially mistake the cause of the outage or failure as a network error. However, these errors describe a symptom, rather than cause, of the failure. ISATAP is a tunneling technology that uses IPv6 over IPv4. When the IPv4 connection fails, the ISATAP adapter also fails. When the network issues are resolved, these entries should no longer appear in the event logs. Alternately, you can reduce network errors by safely disabling ISATAP with the following command.
```
netsh int ipv6 isatap set state disabled
```
When you run this command, the adapter is removed from Device Manager. This command should be run on all nodes. It does not impact the ability of the cluster to function. Instead, when the command has been run, ISATAP is no longer used. However, because this command might cause unknown impacts on other applications that use ISATAP, you should test it.
## Cluster properties
To see the complete cluster configuration, run the following PowerShell command.
```
Get-Cluster | Format-List -Property *
```
## Cluster quorum votes and 50/50 splits in a multi-site cluster
To learn how the cluster quorum works and what to expect if a failure occurs, see [Understanding Cluster and Pool Quorum](https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/understand-quorum).
## DNS registration
In Windows Server 2012, Failover Clustering, by default, attempts to register each DNS node under the cluster name. This is acceptable for applications that are aware the SQL target is configured for multi-site. However, when the client is not configured this way, it can result in timeouts, delays, and application errors due to attempts to connect to each individual node and failing on the inactive ones. To prevent these problems, the Cluster Resource parameter `RegisterAllProvidersIp` must be changed to **0**. For more information, see [RegisterAllProvidersIP Setting](https://msdn.microsoft.com/en-us/library/hh213080.aspx#RegisterAllProvidersIP) and [Multi-subnet Clustered SQL \$1 RegisterAllProvidersIP \$1 SharePoint 2013](https://blogs.msdn.microsoft.com/sambetts/2014/02/04/multi-subnet-clustered-sql-registerallprovidersip-sharepoint-2013/).
The `RegisterAllProvidersIp` can be modified with the following PowerShell script.
```
Import-Module FailoverClusters
$cluster = (Get-ClusterResource | where {($_.ResourceType -eq "Network Name") -and ($_.OwnerGroup -ne "Cluster Group")}).Name
Get-ClusterResource $cluster | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource $cluster |Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource $cluster
Start-ClusterResource $cluster
```
In addition to setting the Cluster Resource parameter to **0**, you must ensure that the cluster has permissions to modify the DNS entry for your cluster name.
1. Log in to the Domain Controller (DC) for the domain, or a server that hosts the forward lookup zone for the domain.
1. Launch the DNS Management Console and locate the `A` record for the cluster.
1. Choose or right-click the `A` record, and choose **Properties**.
1. Choose **Security**.
1. Choose **Add**.
1. Choose **Object Types...**, select the box for **Computers**, and choose **OK**.
1. Enter the name of the cluster resource object and choose **Check name** and **OK if resolve**.
1. Select the check box for **Full Control**.
1. Choose **OK**.
## Elastic Network Adapters (ENAs)
AWS has identified known issues with some clustering workloads running on ENA driver version 1.2.3. We recommend upgrading to the latest version, and adjusting settings on the NIC in the operating system. For the latest versions, see [Amazon ENA Driver Versions](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html#ena-adapter-driver-versions). The first setting, which applies to all systems, increases Receive Buffers, which you can do with the following example PowerShell command.
```
Set-NetAdapterAdvancedProperty -Name (Get-NetAdapter | Where-Object {$_.InterfaceDescription -like '*Elastic*'}).Name -DisplayName "Receive Buffers" -DisplayValue 8192
```
For instances with more than 16 vCPUs, we recommend preventing RSS from running on CPU 0.
Run the following command.
```
Set-NetAdapterRss -name (Get-NetAdapter | Where-Object {$_.InterfaceDescription -like '*Elastic*'}).Name -Baseprocessorgroup 0 -BaseProcessorNumber 1
```
## Multi-site clusters and EC2 instance placement
Each cluster is considered a [multi-site cluster](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197575(v=ws.10)). The EC2 service does not share IP addresses virtually. Each node must be in a unique [subnet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html). Though not required, we recommend that each node also be in a unique Availability Zone.
## Instance type selection
The type of instance recommended for Windows Server Failover Clustering depends on the workload. For production workloads, we recommend instances that support Amazon Elastic Block Store (Amazon EBS) optimization and enhanced networking. For more information, see [EBS optimization](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-optimized.html) and [Enhanced networking](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html) in the *Amazon EC2 User Guide*.
## Assign elastic network interfaces and IPs to the instance
Each node in an EC2 cluster should have only one attached elastic network interface. The network interface should have a minimum of two assigned private IP addresses. However, for workloads that use Availability Groups, such as SQL Always On, you must include an additional IP address for each Availability Group. The primary IP address is used for accessing and managing the server, the secondary IP address is used as the cluster IP address, and each additional IP address is assigned to Availability Groups, as needed.
## Heartbeat network
Some Microsoft documentation recommends using a dedicated [heartbeat network](https://learn.microsoft.com/en-us/troubleshoot/windows-server/high-availability/private-heartbeat-configuration-on-cluster-server). However, this recommendation is not applicable to EC2. With EC2, while you can assign and use a second elastic network interface for the heartbeat network, it uses the same infrastructure and shares bandwidth with the primary network interface. Therefore, traffic within the infrastructure cannot be prioritized, and cannot benefit from a dedicated network interface.
## Configure the network adapter in the OS
The NIC in the OS can keep using DHCP as long as the DNS servers that are being retrieved from the DHCP Options Set allow for the nodes to resolve each other. You can set the NIC to be configured statically. When completed, you then manually configure only the primary IP address for the elastic network interface. Failover Clustering manages and assigns additional IP addresses, as needed.
For certain instance types, you can increase the maximum transmission unit (MTU) on the network adapter to support Jumbo Frames. This configuration reduces fragmentation of packets wherever Jumbo Frames are supported. For more information, see [Network maximum transmission unit (MTU) for your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/network_mtu.html) in the *Amazon Elastic Compute Cloud User Guide*.
## IPv6
Microsoft does not recommend disabling IPv6 in a Windows Cluster. While Failover Clustering works in an IPv4-only environment, Microsoft tests clusters with IPv6 enabled. See [Failover Clustering and IPv6 in Windows Server 2012 R2](https://techcommunity.microsoft.com/t5/Failover-Clustering/Failover-Clustering-and-IPv6-in-Windows-Server-2012-R2/ba-p/371912) for details.
## Host record TTL for SQL Availability Group Listeners
Set the host record TTL to **300** seconds instead of the default 20 minutes (1200 seconds). For legacy client comparability, set `RegisterAllProvidersIP` to **0** for SQL Availability Group Listeners. This is not required in all environments. These settings are important because some legacy client applications cannot use `MultiSubnetFailover` in their connection strings. See [HostRecordTTL Setting](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/create-or-configure-an-availability-group-listener-sql-server?view=sql-server-2017#HostRecordTTL) for more information. When you change these settings, the Cluster Resource must be restarted. The Cluster Group for the listener stops when the Cluster Resource is restarted, so it must be started. If you do not start the Cluster Group, the Availability Group remains offline in a `RESOLVING` state. The following are example PowerShell scripts for changing the TTL and `RegisterAllProvidersIP` settings.
```
Get-ClusterResource yourListenerName | Set-ClusterParameter RegisterAllProvidersIP 0
```
```
Get-ClusterResource yourListenerName|Set-ClusterParameter HostRecordTTL 300
```
```
Stop-ClusterResource yourListenerName
```
```
Start-ClusterResource yourListenerName
```
```
Start-ClusterGroup yourListenerGroupName
```
## Logging
The default logging level for the cluster log is **3**. To increase the detail of log information, set the logging level to **5**. See [Set-ClusterLog](https://docs.microsoft.com/en-us/powershell/module/failoverclusters/set-clusterlog?view=win10-ps) for more information about the PowerShell cmdlet.
```
Set-ClusterLog -Level 5
```
## NetBIOS over TCP
In Windows Server 2012 R2, you can increase the speed of the failover process by disabling NetBIOS over TCP. This feature was removed from Windows Server 2016. You should test this procedure if you are using earlier operating systems in your environment. For more information, see [Speeding Up Failover Tips-n-Tricks](https://techcommunity.microsoft.com/t5/Failover-Clustering/Speeding-Up-Failover-Tips-n-Tricks/ba-p/372086). The following is an example PowerShell command to disable NetBIOS over TCP.
```
Get-ClusterResource “Cluster IP Address” | Set-ClusterParameter EnableNetBIOS 0
```
## NetFT Virtual Adapter
For Windows Server versions earlier than 2016 and non-Hyper-V workloads, Microsoft recommends you enable the NetFT Virtual Adapter Performance Filter on the adapter in the OS. When you enable the NetFT Virtual Adapter, internal cluster traffic is routed directly to the NetFT Virtual Adapter. For more information, see [NetFT Virtual Adapter Performance Filter](https://techcommunity.microsoft.com/t5/Failover-Clustering/NetFT-Virtual-Adapter-Performance-Filter/ba-p/372090). You can enable NetFT Virtual Adapter by selecting the check box in the NIC properties, or by using the following PowerShell command.
```
Get-NetAdapter | Set-NetAdapterBinding -ComponentID ms_netftflt -Enable $true
```
## Set possible owners
The Failover Cluster Manager can be configured so that each IP address specified on the Cluster Core Resources and Availability Group resources can be brought online only on the node to which the IP belongs. When the Failover Cluster Manager is not configured for this and a failure occurs, there will be some delay in failover as the cluster attempts to bring up the IPs on nodes that do not recognize the address. For more information, see [SQL Server Manages Preferred and Possible Owner Properties for AlwaysOn Availability Group/Role](https://blogs.msdn.microsoft.com/alwaysonpro/2014/02/28/sql-server-manages-preferred-and-possible-owner-properties-for-alwayson-availability-grouprole/).
Each resource in a cluster has a setting for Possible Owners. This setting tells the cluster which nodes are permitted to “online” a resource. Each node is running on a unique subnet in a VPC. Because EC2 cannot share IPs between instances, the IP resources in the cluster can be brought online only by specific nodes. By default, each IP address that is added to the cluster as a resource has every node listed as a Possible Owner. This does not result in failures. However, during expected and unexpected failures, you can see errors in the logs about conflicting IPs and failures to bring IPs online. These errors can be ignored. If you set the Possible Owner property, you can eliminate these errors entirely, and also prevent down time while the services are moved to another node.
The following image shows an example of configuring an IP address so that it can only be brought online on the node to which the IP belongs:
![\[Configuring an IP address so that it can only be brought online on the node to which the IP belongs.\]](http://docs.aws.amazon.com/sql-server-ec2/latest/userguide/images/failover_cluster_manager_1.png)
## Tune the failover thresholds
In Windows Server 2012 R2, the network thresholds for the failover heartbeat network default to high values. See [Tuning Failover Cluster Network Thresholds](https://techcommunity.microsoft.com/t5/Failover-Clustering/Tuning-Failover-Cluster-Network-Thresholds/ba-p/371834) for details. This potentially unreliable configuration, which applies to clusters with some distance between them, was addressed in Server 2016 with an increase in the number of heartbeats. It was discovered that clusters would fail over due to very brief transient network issues. The heartbeat network is maintained with UDP 3343, which is traditionally far less reliable than TCP and more prone to incomplete conversations. Although there are low-latency connections between AWS Availability Zones, there are still geographic separations with a number of "hops" separating resources. Within an Availability Zone, there may be some distance between clusters unless the customer is using Placement Groups or Dedicated Hosts. As a result, there is a higher possibility for heartbeat failure with UDP than with TCP-based heartbeats.
The only time a cluster should fail over is when there is a legitimate outage, such as a service or node that experiences a hard failover, as opposed to a few UDP packets lost in transit. To ensure legitimate outages, we recommend that you adjust the thresholds to match, or even exceed, the settings for Server 2016 listed in [Tuning Failover Cluster Network Thresholds](https://techcommunity.microsoft.com/t5/Failover-Clustering/Tuning-Failover-Cluster-Network-Thresholds/ba-p/371834). You can change the settings with the following PowerShell commands.
```
(get-cluster).SameSubnetThreshold = 10
```
```
(get-cluster).CrossSubnetThreshold = 20
```
When you set these values, unexpected failovers should be dramatically reduced. You can fine tune these settings by increasing the delays between heartbeats. However, we recommend that you send the heartbeats more frequently with greater thresholds. Setting these thresholds even higher ensures that failovers occur only for hard failover scenarios, with longer delays before failing over. You must decide how much down time is acceptable for your applications.
After increasing the `SameSubnetThreshold` or `CrossSubnetThreshold`, we recommend that you increase the `RouteHistoryLength` to double the higher of the two values. This ensures that there is sufficient logging for troubleshooting. You can set the `RouteHistoryLength` with the following PowerShell command.
```
(Get-Cluster).RouteHistoryLength = 20
```
## Witness importance and Dynamic Quorum Architecture
There is a difference between Disk Witness and File Share Witness. Disk Witness keeps a backup of the cluster database while File Share Witness does not. Both add a [vote to the cluster](#sql-clustering-quorum). You can use Disk Witness if you use iSCSI-based storage. For more about witness options, see [File Share witness vs Disk witness for local clusters](https://blogs.technet.microsoft.com/mspfe/2012/11/05/file-share-witness-vs-disk-witness-for-local-clusters/).
## Troubleshoot
If you experience unexpected failovers, first make sure that you are not experiencing networking, service, or infrastructure issues.
1. Check that your nodes are not experiencing network-related issues.
1. Check driver updates. If you are using outdated drivers on your instance, you should update them. Updating your drivers might address bugs and stability issues that might be present in your currently installed version.
1. Check for any possible resource bottlenecks that could cause an instance to become unresponsive, such as CPU and disk I/O. If the node cannot service requests, it might appear to be down by the cluster service.