# ベストプラクティス 11.3 – サービスの可用性を復元するためのアプローチを定義する 可用性の復元は、特定の障害シナリオで、サービスの損失が発生することを前提としています。リストアのアプローチでは、サービスの復元に必要な時間、および可用性目標を達成するために必要なアクションを検討する必要があります。 **提案 11.3.1 – EC2 インスタンスのインスタンスの復旧を有効にする** Amazon EC2 インスタンスをモニタリングし、基盤となるハードウェアの障害が原因でインスタンスに障害が発生した場合に自動的にインスタンスを復旧する Amazon CloudWatch アラームを作成できます。このアクションにより、マニュアルによる介入の必要性を取り除くことができますが、スタートアップ、アプリケーションの再起動、ロード時間を、目標復旧時間 (RTO) の計算に含める必要があります。クラスタリングソリューションを使用してハードウェア障害から保護する場合は、インスタンスリカバリがクラスターソリューションと互換性があるかどうかを評価する必要があります。 + AWS ドキュメント: [Amazon EC2 インスタンスの復旧](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) **提案 11.3.2 – AMI と Infrastructure as Code を使用して EC2 インスタンスを再構築する戦略を立てる** Infrastructure as Code (IaC) の利点は、プログラムで環境全体を構築および破棄できることです。回復力を考慮した設計であれば、 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) のテンプレートや [AWS Systems Manager のオートメーションにより、数分で環境を実装することができます。](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) .オートメーションは、高可用性と迅速な復旧を維持するために不可欠です。 戦略の一環として、次の AWS のサービスを評価する必要があります。 + AWS サービス: [EC2 Image Builder](https://aws.amazon.com/image-builder/) + AWS サービス: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) + AWS サービス: [AWS Cloud Development Kit](https://aws.amazon.com/cdk/) + SAP on AWS ブログ: [DevOps for SAP (SAP 向け DevOps)](https://aws.amazon.com/blogs/awsforsap/category/devops/) **提案 11.3.3 – Amazon EBS の障害を理解する** 1 つまたは複数の EBS ボリュームに障害が発生した場合、SAP ワークロードの可用性と耐久性に影響を与える可能性があります。そのため、Amazon EBS の障害発生率、通知メカニズム、復旧オプションについて理解しておく必要があります。 + AWS ドキュメント: [Amazon EBS の耐久性](https://aws.amazon.com/ebs/features/#Amazon_EBS_availability_and_durability) + AWS ドキュメント: [ボリュームのステータスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html) + AWS サービス: [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) + AWS ドキュメント: [Amazon EBS スナップショットを使用したボリュームリカバリ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) **提案 11.3.4 – AWS Personal Health Dashboard の通知に対応するための戦略を立てる** AWS Personal Health Dashboard からの通知を受け取り、対処するための戦略を立てる必要があります。これには、CloudWatch を使用して Amazon SNS を開始したり、 [AWS Health API を介して ITSM ツールと統合したりすることが含まれます](https://docs.aws.amazon.com/health/latest/ug/health-api.html) 。 **提案 11.3.5 – 可用性に影響を与える偶発的または悪意のあるイベントから保護されていることを確認する** SAP ワークロードの可用性に影響を与える可能性のある偶発的または悪意のあるイベントから確実に保護するために、次のアプローチを検討する必要があります。 + 最小特権の原則を [実装し、](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) AWS Identity and Access Management 内で職務の分離を実施します。 + AWS ナレッジセンターの記事のガイダンスに従ってください。 [EC2 インスタンスの偶発的な終了からデータを保護するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/accidental-termination/) + Amazon EC2 の [ベストプラクティスに従ってください。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html) + [セキュリティ] のセキュリティガイダンスにも従う必要があります。 [ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する。](best-practice-8-3.md) **提案 11.3.6 – AWS の SAP ワークロード以外の依存関係を特定します。** 共有サービスやサポートコンポーネントまたはシステムなど、SAP ビジネスプロセスの基本的な依存関係を理解します。例えば、アクティブディレクトリ、DNS、ID プロバイダー、SaaS サービス、オンプレミスシステムなどです。障害発生時の影響と必要な緩和策を評価します。