翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 高可用性とディザスタリカバリのソリューションを選択する ## 概要 目標復旧時間 (RTO) や目標復旧時点 (RPO) などの[ディザスタリカバリ (DR) 目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)も達成しながらビジネスニーズを満たす、 AWS 上の SQL Server デプロイ用のアーキテクチャを設計することをお勧めします。以下のソリューションは、SQL Server ワークロードのコストも最適化しながら、Amazon Elastic Compute Cloud (Amazon EC2) 上の SQL Server に適したアーキテクチャを設計するのに役立ちます。 + **SQL Server Always On 可用性グループ **–** **SQL Server Always On 可用性グループは、SQL Server データベースの高可用性とディザスタリカバリ (HA/DR) ソリューションを提供します。可用性グループは、フェイルオーバーされるユーザーデータベースのセットで構成されます。Always On 可用性グループもデータベースレベルで冗長性を提供しますが、共有ストレージは必要ありません。各レプリカには独自のローカルストレージがあります。この機能は HA/DR ソリューションとしてデプロイできます。詳細については、Microsoft ドキュメントの「[What is an Always On availability group?](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16)」を参照してください。 + **SQL Server Always On フェイルオーバークラスターインスタンス (FCI)** –** **SQL Server Always On FCI は Windows Server フェイルオーバークラスタリング (WSFC) を使用して、SQL Server インスタンスレベルで HA を提供します。FCI では、データベースをホストするために共有ストレージが必要です。共有ブロックストレージまたは共有ファイルストレージを使用できます。例えば、Amazon FSx for Windows File Server または Amazon FSx for NetApp ONTAP を、複数のアベイラビリティーゾーンを持つ共有ストレージソリューションとして使用できます。詳細については、Microsoft ドキュメントの「[Always On Failover Cluster Instances (SQL Server)](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver16)」を参照してください。 + **SIOS DataKeeper** –** **SIOS DataKeeper は、アベイラビリティーゾーンと AWS リージョンの両方にまたがる SQL Server FCI を有効にすることで、HA と DR の両方の要件を満たすのに役立ちます。SIOS DataKeeper は、ローカル Amazon Elastic Block Store (Amazon EBS) ボリュームを使用してクラスター化された仮想 SAN を作成し、HA のアベイラビリティーゾーン間の同期レプリケーションを使用し、ディザスタリカバリのためにリージョン間の非同期レプリケーションを使用します。詳細については、SIOS ドキュメントの「[High Availability Protection for Windows Applications](https://us.sios.com/products/windows/)」を参照してください。 + **分散可用性グループ** –** **分散可用性グループは、2 つの別々の Always On 可用性グループにまたがる特殊な種類の可用性グループです。可用性グループは、2 つの別々のリージョン (`us-east-1` や `us-west-1` など) にまたがって存在できます。基盤となる Always On 可用性グループは 2 つの異なる WSFC クラスターに設定されているため、分散可用性グループを、可用性グループの可用性グループと考えることができます。分散可用性グループをデプロイするには、SQL Server Enterprise Edition が必要です。詳細については、Microsoft ドキュメントの「[Distributed availability groups](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups?view=sql-server-ver16)」を参照してください。 + **ログ配布** –** **万が一リージョンが影響を受けて使用できなくなった場合に備えて、ログ配布を実装して、複数のリージョンにまたがるデータベースを保護できます。トランザクションとログ配布の頻度に応じて、数分以内に RPO と RTO を達成できます。詳細については、Microsoft ドキュメントの「[About Log Shipping (SQL Server)](https://learn.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-ver16)」を参照してください。 + **AWS Elastic Disaster Recovery** – Elastic Disaster Recovery は、DR AWS 目的で、あらゆるインフラストラクチャから へのサーバーのレプリケーションを管理する Software as a Service (SaaS) アプリケーションです。Elastic Disaster Recovery を使用して、リージョン間で SQL Server をレプリケートすることもできます。Elastic Disaster Recovery は、オペレーティングシステム、インストールされているすべてのアプリケーション、すべてのデータベースを含む仮想マシン全体をステージングエリアにレプリケートするエージェントベースのソリューションです。詳細については、Elastic Disaster Recovery ドキュメントの「[What is Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)」を参照してください。 + **AWS Database Migration Service (AWS DMS)** – は AWS、別のリージョンを含む、 との間のデータのライブ移行** **AWS DMS をサポートします。この機能を使用して、ディザスタリカバリデータベースとして機能する別のリージョンに別個の SQL Server インスタンスをセットアップできます。詳細については、[「 とは」を参照してください AWS Database Migration Service。](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) AWS DMS 「」を参照してください。 ## SQL Server Always On 可用性グループ 高可用性 [Always On 可用性グループ](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16)のみに SQL Server Enterprise Edition を使用している場合は、基本的な可用性グループを利用して SQL Server Standard Edition にダウングレードできます。Always On 可用性グループの代わりに基本的な可用性グループを使用することで、コストを 65～75% 削減できます。 **注記** 異なる SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。 **特徴** + SQL Server Standard Edition で使用可能 + レプリカは 2 つまで (プライマリとセカンダリ) + セカンダリレプリカへの読み取りアクセスなし + セカンダリレプリカの整合性チェックなし **制限事項** + 可用性グループごとに 1 つの可用性データベースのみをサポート + 基本的な可用性グループを分散可用性グループの一部にすることはできない 次の図は、Windows Server フェイルオーバークラスターソリューションのアーキテクチャの例を示しています。 ![Windows Server フェイルオーバークラスターアーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/wfc_arch.png) ## SQL Server Always On フェイルオーバークラスターインスタンス フェイルオーバークラスターインスタンス (FCI) を使用して、ダウンタイムを最小限に抑え、データ損失のリスクを減らしながら、データベースの継続的なオペレーションを確保できます。FCI は、リードレプリカの設定なしで SQL Server データベースの高可用性を求める場合に、信頼性の高いソリューションを提供します。 可用性グループとは異なり、FCI は SQL Server Enterprise Edition を必要とせずに、信頼性の高いフェイルオーバーソリューションを提供できます。代わりに、FCI では SQL Server Standard Edition ライセンスのみが必要です。FCI を使用して、SQL Server のライセンスコストを 65～75% 削減できます。 **注記** SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。 以下の点を考慮してください。 + Amazon FSx for Windows File Server は、SQL Server FCI 共有ストレージ要件を満たすための強力なソリューションを提供します。FSx for Windows File Server を使用すると、ストレージレプリケーションソリューションのライセンスを購入し、共有ストレージを自分で管理する必要がなくなります。これにより、30～40% の大幅なコスト削減につながります。詳細については、 AWS ストレージブログの[「Amazon FSx for Windows File Server を使用した Microsoft SQL Server の高可用性デプロイの簡素化](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」の投稿を参照してください。 + 「[Software Assurance benefits summary](https://download.microsoft.com/download/0/0/3/0039F316-45CF-4083-AA6E-C35DA9D25C1B/SA_InteractiveBenefitsChart.pdf)」(ダウンロード可能な PDF) と Bring Your Own License (BYOL) モデルを使用すると、セカンダリサーバーがパッシブである限り、パッシブフェイルオーバーのメリットを活用できます。これにより、クラスターのパッシブノードにライセンスを提供する必要がないため、SQL ライセンスのコスト削減につながります。 次の図は、FSx for Windows File Server を使用した SQL Server FCI のアーキテクチャの例を示しています。 ![FSx for Windows File Server アーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/fsx_arch.png) ## SIOS DataKeeper SQL Server FCIsデプロイする場合は、共有ストレージ要件を検討することをお勧めします AWS。従来のオンプレミスインストールでは通常、共有ストレージ要件を満たすためにストレージエリアネットワーク (SAN) が使用されますが、これは AWSでは実行可能なオプションではありません。Amazon FSx for Windows File Server は、 上の SQL Server FCI に推奨されるストレージソリューションですが AWS、異なる にクラスターサーバーを追加することを妨げる制限があります AWS リージョン。 [SIOS DataKeeper](https://aws.amazon.com/blogs/architecture/field-notes-implementing-ha-and-dr-for-microsoft-sql-server-using-always-on-failover-cluster-instance-and-sios-datakeeper/) を使用して、コストを 58～71% 削減しながら、アベイラビリティーゾーンとリージョンの両方をカバーする SQL Server FCI を作成できます。SIOS DataKeeper は、FCI の高可用性のメリットを実現するのに役立ちます。これにより、SIOS DataKeeper は組織にとってコスト効率と信頼性に優れたソリューションになります。 SIOS DataKeeper を使用することで得られる次のような利点も考慮してください。 + SIOS DataKeeper は、ローカル EBS ボリュームを使用して、クラスター化された仮想 SAN を作成し、アベイラビリティーゾーン間の同期レプリケーションを使用して高可用性を実現します。ディザスタリカバリの場合、SIOS DataKeeper はリージョン間の非同期レプリケーションを使用します。 + SIOS DataKeeper は、SQL Server Standard Edition を使用してエンタープライズクラスのクラスタリング機能を提供します。これにより、SQL Server Enterprise Edition を使用する SQL Server Always On 可用性グループによる高可用性の実装と比較して、SQL Server のライセンスコストが 65～75% 削減されます。SIOS DataKeeper を使用すると、組織のニーズを満たす、可用性が高くて柔軟で費用対効果の高い SQL Server 環境を作成できます。 **注記** SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。 次の図は、クラスター化された仮想 SAN ソリューションを使用した SQL Server FCI のアーキテクチャの例を示しています。 ![クラスター化された仮想 SAN ソリューションを使用した SQL Server FCI](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/clustered_vsan_arch.png) ## Always On 可用性グループ Always On 可用性グループは、高可用性とディザスタリカバリの両方の目的で使用できます。SQL Server を 1 つのリージョンの 2 つのアベイラビリティーゾーンにデプロイすることで、高可用性を実現できます。リージョン間で可用性グループを拡張することで、ディザスタリカバリを実現できます。 次の図は、Always On 可用性グループに基づくソリューションのアーキテクチャの例を示しています。図のリージョン 1 のレプリカは、可用性グループの自動フェイルオーバーを提供する同期コミットを使用しています。リージョン 2 のレプリカは非同期コミットを使用しているため、可用性グループの手動フェイルオーバーが必要になります。 ![Always On 可用性グループアーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/alwayson_ag_arch.png) ## 分散可用性グループ 信頼性やディザスタリカバリで妥協できないミッションクリティカルな SQL Server デプロイの場合は、マルチリージョンアプローチをお勧めします。複数のリージョンに可用性グループを分散させることは、ビジネス継続性を維持し、ダウンタイムを最小限に抑えるための最も回復力の高いソリューションです。 このアーキテクチャは、共有ストレージ、同期ブロックレベルレプリケーション、SQL Server FCI など、Amazon FSx for Windows File Server の機能を最大限に活用します。これらの機能により、複数のアベイラビリティーゾーンにまたがる高可用性 SQL Server 環境を作成できるようになります。この設定を別のリージョンにレプリケートすることで、最も深刻な中断にも対応できる完全に冗長なシステムが得られます。このソリューションを際立たせているのは、それが提供する柔軟性とセキュリティのレベルです。分散可用性グループのドメインに依存しないアーキテクチャにより、基盤となる Windows クラスターサーバーを異なる Active Directory ドメインに参加させることができると同時に、証明書ベースの認証により、SQL Server 環境に対する最大限の保護が保証され、マルチリージョン DR 戦略に高い RTO および RPO 要件が提供されます。マルチリージョンアーキテクチャの構築の詳細については、「 アーキテクチャブログ」の[「Field Notes: Building a Multi-Region Architecture for SQL Server using FCI and Distributed Availability Groups](https://aws.amazon.com/blogs/architecture/field-notes-building-a-multi-region-architecture-for-sql-server-using-fci-and-distributed-availability-groups/)」を参照してください。 AWS 次の図は、分散可用性グループを使用したマルチリージョンソリューションのアーキテクチャの例を示しています。 ![マルチリージョンアーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/multi_region_arch.png) ## ログ配布 ログ配布は、予期しない停止が発生した場合にリージョン間でデータベースを保護するための、実績があり、信頼性が高く、費用対効果の高い方法です。組織は数十年にわたってログ配布を使用してデータを保護してきました。 ログ配送を実装する場合 AWS、トランザクションの頻度とログ配送ジョブに応じて、RPO と RTO を数分で実現できます。万一、リージョンにアクセスできなくなった場合、ログ配布によりデータの安全性と回復性が維持されます。 ログ配布を使用することで得られる次のような利点も考慮してください。 + リージョン間のディザスタリカバリ耐障害性のためにログ配布を使用することで、コストを削減し、ビジネス要件を満たします。SQL Server Standard Edition または SQL Server Web Edition のライセンスのみが必要なため、ログ配布は TCO を削減します。 + アクティブな[ソフトウェアアシュアランス](https://download.microsoft.com/download/0/0/3/0039F316-45CF-4083-AA6E-C35DA9D25C1B/SA_InteractiveBenefitsChart.pdf)でのログ配布を使用して、ディザスタリカバリ/パッシブサーバーからライセンスコストを削減します。ソフトウェアアシュアランスでのログ配布を使用する場合は、プライマリ/アクティブ SQL Server のみをライセンスする必要があります。 + SQL Server Enterprise Edition でリージョン間で分散可用性グループをセットアップする必要がなくなるため、SQL Server のライセンスコストが 65～75% 削減されます。これを行うには、SQL Server Standard Edition と SQL Server FCI をログ配布と組み合わせて使用して、ディザスタリカバリ要件を満たします。 **注記** SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。 詳細については、 AWS アーキテクチャブログの[「Amazon FSx for Windows 設定で SQL Server FCI のログ配信を使用して SQL Server DR を拡張](https://aws.amazon.com/blogs/architecture/extend-sql-server-dr-using-log-shipping-for-sql-server-fci-with-amazon-fsx-for-windows-configuration/)する」を参照してください。 次の図は、ログ配布ソリューションのアーキテクチャの例を示しています。 ![ログ配布アーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/log_shipping_arch.png) ## AWS Database Migration Service AWS Database Migration Service (AWS DMS) を使用して、アプリケーションのニーズに基づいて HA/DR ソリューションを設計できます。 AWS DMS を使用すると、同じリージョン (HA) またはリージョン (DR) 間でセカンダリ SQL Server データベースにデータを簡単にコピーできます。このアプローチは技術的に健全であり、リソース使用量を最適化しながら AWS インフラストラクチャへの投資を最大化できます。 AWS DMS はコスト効率の高いサービスです。転送プロセス中に使用される CPU リソースと追加のログストレージに対してのみ課金されます。つまり、大幅な追加コストを発生させることなく、このソリューションのメリットを享受できます。を使用して AWS DMS 、ライセンスとリソースの使用に関連するコストを最小限に抑えながら、データの可用性とアクセス性を確保できます。 次の図は、 AWS DMSに基づくソリューションのアーキテクチャの例を示しています。 ![AWS DMS アーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_dms_arch.png) ## AWS Elastic Disaster Recovery 組織によっては、すべての重要なビジネスアプリケーションにディザスタリカバリ計画が導入されていることを確認する必要があります。以前は、このような組織の多くは、従来のディザスタリカバリソリューションに多額の投資を行っていました。この場合、重複するインフラストラクチャ全体を事前に構築して維持する必要があります。このアプローチはコストも時間もかかり、スケーリングも困難です。 これで、 AWS Elastic Disaster Recovery を使用してディザスタリカバリインフラストラクチャを事前に構築する必要がなくなります。ディザスタリカバリマシンは、必要になるまで Elastic Disaster Recovery で起動されないため、必要なときに使用した分だけお支払いいただきます。つまり、ソフトウェアライセンスと高性能コンピューティングのコストを大幅に削減できます。 さらに、ディザスタリカバリソリューションのステージングエリアには、低コストの Amazon Elastic Block Store (Amazon EBS) ボリュームが含まれています。EBS ボリュームは、重複リソースのプロビジョニングコストをさらに削減します。これにより、ビジネス要件を満たす堅牢で信頼性の高いディザスタリカバリソリューションを維持しながら、全体的なディザスタリカバリコストを削減できます。Elastic Disaster Recovery を使用してコアビジネス活動に集中できますが、 AWS はディザスタリカバリソリューションの基盤となるインフラストラクチャを処理します。 SQL Server では、費用対効果の高いディザスタリカバリオプションとして Elastic Disaster Recovery を使用できます。耐障害性があり可用性の高い SQL Server アーキテクチャのパッシブノードのライセンスは、アクティブなソフトウェアアシュアランスを使用する場合にカバーされます。ただし、パッシブサーバーがオンラインになるためのコンピューティングコストは引き続き発生します。Elastic Disaster Recovery を使用すると、プライマリサーバーは、アクティブなソフトウェアアシュアランスを維持しなくても DR 環境にレプリケートでき、ディザスタリカバリのコンピューティングコストを支払う必要もありません。このコスト削減の組み合わせにより、SQL Server のディザスタリカバリコストを 50% 以上削減できます。 次の図は、Elastic Disaster Recovery に基づくソリューションのアーキテクチャの例を示しています。 ![Elastic Disaster Recovery アーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_drs_arch.png) 詳細については、 AWS ブログの Microsoft Workloads の「 [を使用して復元された DR サイトで SQL Server の高可用性を設定する方法 AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/set-up-high-availability-for-sql-server-at-dr-site-using-aws-elastic-disaster-recovery/)」を参照してください。 ## コスト比較 次の表は、このセクションで説明する HA/DR ソリューションのコストを比較したものです。この比較では、次の前提が適用されます。 + **インスタンスタイプ** – r5d.xlarge + **ライセンスタイプ** – Windows と SQL Server の両方に含まれるライセンス + **[Region]** (リージョン) - `us-east-1` **** | ソリューション | 高可用性 | ディザスタリカバリ | Enterprise Edition | Standard Edition | Cost | | --- | --- | --- | --- | --- | --- | | ログ配布 | いいえ | はい | はい | はい | SQL Server Enterprise Edition: 32,674.8 USD (2 ノード)
SQL Server Standard Edition: 14,804.4 USD (2 ノード) | | Always On 可用性グループ | はい | はい | はい | あり。ただし、基本的な可用性グループ (2 ノード) | SQL Server Enterprise Edition: 32,674.8 USD (2 ノード)
SQL Server Standard Edition: 14,804.4 USD (2 ノード) | | Always On FCI | はい | なし | はい | あり (2 ノード) | SQL Server Standard Edition: 14,804.4 USD | | 分散可用性グループ | はい | はい | あり | いいえ | SQL Server Enterprise Edition: 65,349.6 USD (4 ノード) | | Elastic Disaster Recovery | いいえ | はい | はい | はい | 1 インスタンスと 1 TB のストレージのレプリケーションの場合、月額約 107.48 USD
**注**: Elastic Disaster Recovery は、レプリケートするサーバーごとに時間単位で請求されます。ディスク数、ストレージサイズ、ドリルまたはリカバリの起動数、レプリケートするリージョンに関係なく、コストは同じです。 | | SIOS DataKeeper | はい | はい | はい | はい | ソフトウェアアシュアランスを使用する Always On 可用性グループ (2 ノード、24 コア): 213,480 USD
SIOS DataKeeper とソフトウェアアシュアランスを使用する SQL Server Standard Edition で実行される 2 ノード SQL Server クラスター: 61,530 USD (2 ノード) | | AWS DMS | いいえ | はい | はい | はい | r5.xlarge インスタンスと 1 TB のストレージの場合、月額 745.38 USD | ## コスト最適化の推奨事項 組織の要件を満たす HA/DR ソリューションを選択するには、次のステップを実行することをお勧めします。 + このガイドの「[SQL Server ワークロードに適した EC2 インスタンスを選択する](right-ec2-instance.md)」セクションを確認します。 + ピークワークロード中にパフォーマンスカウンターを実行して、ワークロードの IOPS とスループットの要件を決定します。 + IOPS = ディスク読み取り/秒 \+ ディスク書き込み/秒 + スループット = ディスク読み取りバイト/秒 \+ ディスク書き込みバイト/秒 + パフォーマンスとコスト削減を向上させるには、次のストレージボリュームタイプを使用します。 + `tempdb` およびバッファプール拡張用の NVMe インスタンスストレージ + データベースファイル用の io2 ボリューム + Amazon EC2 上の SQL Server のコスト最適化に関する推奨事項については、[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) を使用します。SQL Server 最適化チェックを実行する Trusted Advisor ために、 のエージェントをインストールする必要はありません。 は、仮想 CPUs (vCPUs)、バージョン、エディションなど、Amazon EC2 SQL Server のライセンス込みインスタンス設定 Trusted Advisor を検査します。次に、 はベストプラクティスに基づいてレコメンデーション Trusted Advisor を行います。 + Amazon EC2 インスタンスと Amazon EBS の両方の適切なサイジングレコメンデーション AWS Compute Optimizer に使用します。 + [AWS 料金見積りツール](https://calculator.aws/#/) を使用して、コスト見積もりのための HA/DR 戦略を設計します。 + SQL Server Enterprise Edition から SQL Server Standard Edition へのダウングレードが可能なオプションかどうかを判断するには、[sys dm\_db\_persisted\_sku\_features](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-persisted-sku-features-transact-sql?view=sql-server-ver16) 動的管理ビューを使用して、現在のデータベースでアクティブなエディション固有の機能を特定します。 **注記** ライセンス込み EC2 インスタンスを使用する場合、SQL Server エディションの変更にはサイドバイサイド移行が必要です。 + 定義された RTO と RPO でデータベースを復旧できる設計をより適切に構築するために、半年または年に 1 回のディザスタリカバリドリルを実行します。これは、アーキテクチャの弱点を特定するのにも役立ちます。 ## その他のリソース + [Amazon FSx for Windows File Server を使用して Microsoft SQL Server の高可用性デプロイを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server) (AWS ストレージブログ) + [フィールドノート: FCI と分散可用性グループを使用した SQL Server のマルチリージョンアーキテクチャの構築](https://aws.amazon.com/blogs/architecture/field-notes-building-a-multi-region-architecture-for-sql-server-using-fci-and-distributed-availability-groups/) (AWS アーキテクチャブログ) + [SQL Server のディザスタリカバリの設計 AWS: パート 1](https://aws.amazon.com/blogs/database/part-1-architect-a-disaster-recovery-for-sql-server-on-aws/) (AWS データベースブログ) + 「[Microsoft SQL high availability with Amazon FSx for Windows](https://www.youtube.com/watch?v=8dsRkVLy0Nc)」(YouTube) + 「[Maximizing Microsoft SQL Server Performance with Amazon EBS](https://aws.amazon.com/blogs/storage/maximizing-microsoft-sql-server-performance-with-amazon-ebs/)」(AWS ストレージブログ) + [オンプレミスストレージパターンと AWS ストレージサービスの比較](https://aws.amazon.com/blogs/storage/comparing-your-on-premises-storage-patterns-with-aws-storage-services/) (AWS ストレージブログ) + [データセンター NAS を Amazon FSx File Gateway に置き換える計画](https://aws.amazon.com/blogs/storage/planning-to-replace-a-data-center-nas-with-amazon-fsx-file-gateway/) (AWS ストレージブログ) + [での高可用性 SQL Server デプロイのコストの最適化 AWS](https://aws.amazon.com/blogs/storage/optimizing-cost-for-your-high-availability-sql-server-deployments-on-aws/) (AWS ストレージブログ) + 「[How to set up disaster recovery for SQL Server Always On Availability Groups using AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-set-up-disaster-recovery-for-sql-server-always-on-availability-groups-using-aws-elastic-disaster-recovery/)」(Microsoft Workloads on AWS) + [を使用して復元された DR サイトで SQL Server の高可用性を設定する方法 AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/set-up-high-availability-for-sql-server-at-dr-site-using-aws-elastic-disaster-recovery/) (Microsoft ワークロードオン AWS)