# REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

 リソースに障害が発生したときには、リソースが正常に終了されるまで、クォータにカウントされることがあります。エラーが生じたリソースが停止されるまで、エラーが生じたすべてのリソースと代替リソースの合計リソース数がクォータ内に収まるようにします。この開きを計算するときは、アベイラビリティーゾーンの不具合を考慮する必要があります。 

 **一般的なアンチパターン:** 
+  フェイルオーバーシナリオを考慮せずに、現在のニーズに基づいてサービスクォータを設定する。 

 **このベストプラクティスを活用するメリット:** イベントが可用性に影響する恐れがあるとき、クラウドでは、これらのイベントを緩和またはイベントから復旧するための戦略を実装できます。そのような戦略には、多くの場合、障害が発生したリソースに置き換わる追加リソースの作成が含まれます。クォータ戦略は、これらの追加リソースに対応する必要があります。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  フェイルオーバーに対応するため、サービスクォータと最大使用量の間に十分なギャップがあることを確認します。 
  +  デプロイのパターン、可用性の要件、消費の増加を考慮して、サービスクォータを決定します。
  +  必要に応じてクォータの引き上げをリクエストします。クォータの引き上げリクエストの実行に必要な時間を計画します。
    +  信頼性の要件 (「9 の数」としても知られる) を決定します。 
    +  障害シナリオ (コンポーネント、アベイラビリティーゾーン、リージョンの損失など) を確立します。
    +  デプロイ手法 (例えば、Canary、ブルー/グリーン、レッド/ブラック、ローリングなど) を確立します。
    +  現在の制限に適切なバッファ (例えば、15%) を含めます。 
    +  消費の増加を計画します (例えば、消費の傾向をモニタリングする)。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)