AWS prescriptive-guidance documentation change
Summary
Updated internal links (welcome.html to introduction.html, Microsoft documentation URL, blog post URL fragment removal), and changed section header from 'Notice' to 'Note'
Security assessment
All changes are URL corrections, formatting adjustments, or documentation style updates. No security-related content was added/modified. The Microsoft URL fix maintains technical accuracy but doesn't address vulnerabilities. Blog post URL fragment removal improves readability but doesn't impact security.
Diff
diff --git a/prescriptive-guidance/latest/migration-microsoft-workloads-aws/migrating-failover-workloads.md b/prescriptive-guidance/latest/migration-microsoft-workloads-aws/migrating-failover-workloads.md index 238be2c71..9cae8ad95 100644 --- a//prescriptive-guidance/latest/migration-microsoft-workloads-aws/migrating-failover-workloads.md +++ b//prescriptive-guidance/latest/migration-microsoft-workloads-aws/migrating-failover-workloads.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Options, tools, and best practices for migrating Microsoft workloads to AWS](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Options, tools, and best practices for migrating Microsoft workloads to AWS](introduction.html) @@ -11 +11 @@ A [Microsoft failover cluster](https://learn.microsoft.com/en-us/windows-server/ -Windows failover clusters work differently in the cloud than in on-premises environments. It's important to note that only multi-subnet clusters can be deployed in the cloud. Unlike in on-premises environments, the IP address in a Windows failover cluster is assigned to an Elastic Network Adapter (ENA) rather than at the operating system level. In an on-premises environment, the operating system handles IP address assignment, but a cloud provider (AWS) handles the IP address assignment in the cloud. Because failover clustering is an operating system level feature it can't take control of the IP failover. Therefore, the same IP can't fail over between nodes. To work around that, you can use multi-subnet clusters where clusters fail over to a secondary IP. The secondary IP is assigned to ENA in another subnet and can come online. For more information, see [Failover Clustering Networking Basics and Fundamentals](https://techcommunity.microsoft.com/t5/failover-clustering/failover-clustering-networking-basics-and-fundamentals/ba-p/1706005) in the Microsoft documentation. +Windows failover clusters work differently in the cloud than in on-premises environments. It's important to note that only multi-subnet clusters can be deployed in the cloud. Unlike in on-premises environments, the IP address in a Windows failover cluster is assigned to an Elastic Network Adapter (ENA) rather than at the operating system level. In an on-premises environment, the operating system handles IP address assignment, but a cloud provider (AWS) handles the IP address assignment in the cloud. Because failover clustering is an operating system level feature it can't take control of the IP failover. Therefore, the same IP can't fail over between nodes. To work around that, you can use multi-subnet clusters where clusters fail over to a secondary IP. The secondary IP is assigned to ENA in another subnet and can come online. For more information, see [Failover Clustering Networking Basics and Fundamentals](https://techcommunity.microsoft.com/blog/failoverclustering/failover-clustering-networking-basics-and-fundamentals/1706005) in the Microsoft documentation. @@ -51 +51 @@ Consider your options for migrating to AWS, including a lift-and-shift approach - * **Traditional failover cluster migration** – If you're manually configuring a Microsoft failover cluster from scratch, you can follow the instructions in [Deploy SQL Server on Amazon EC2](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/create-sql-server-on-ec2-instance.html). Shared storage is one of the most important considerations for a failover cluster migration. Amazon EBS multi-attach doesn't support SCSI-3 Persistent Reservation, but [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) and [Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html) both work well as shared storage options. One of the most common use cases is using an Always On Failover Cluster Instance for a SQL Server cluster with Amazon FSx for Windows File Server. For more information, see the [Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) post in the AWS Storage Blog. The next step is bringing the nodes to the cloud. This can be achieved by using AWS Application Migration Service. For more information, see the [Migrating your Microsoft Windows clusters to AWS using CloudEndure Migration](https://aws.amazon.com/blogs/storage/migrating-your-microsoft-windows-clusters-to-aws-using-cloudendure-migration/#:~:text=Register%20for%20a%20CloudEndure%20account,for%20the%20replication%20to%20complete) post in the AWS Storage Blog. Then, you can configure a clustered role for your application to provide high availability. + * **Traditional failover cluster migration** – If you're manually configuring a Microsoft failover cluster from scratch, you can follow the instructions in [Deploy SQL Server on Amazon EC2](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/create-sql-server-on-ec2-instance.html). Shared storage is one of the most important considerations for a failover cluster migration. Amazon EBS multi-attach doesn't support SCSI-3 Persistent Reservation, but [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) and [Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html) both work well as shared storage options. One of the most common use cases is using an Always On Failover Cluster Instance for a SQL Server cluster with Amazon FSx for Windows File Server. For more information, see the [Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) post in the AWS Storage Blog. The next step is bringing the nodes to the cloud. This can be achieved by using AWS Application Migration Service. For more information, see the [Migrating your Microsoft Windows clusters to AWS using CloudEndure Migration](https://aws.amazon.com/blogs/storage/migrating-your-microsoft-windows-clusters-to-aws-using-cloudendure-migration/) post in the AWS Storage Blog. Then, you can configure a clustered role for your application to provide high availability. @@ -57 +57 @@ Consider your options for migrating to AWS, including a lift-and-shift approach -###### Notice +###### Note