# SUS02-BP02 SLA を持続可能性の目標に合わせる
<a name="sus_sus_user_a3"></a>

 持続可能性の目標に基づいてワークロードのサービスレベルアグリーメント (SLA) をレビューし最適化して、ビジネスニーズを満たしながらワークロードをサポートするために必要なリソースを最小化します。 

 **一般的なアンチパターン:** 
+  ワークロード SLA がわからない、またはあいまいである。 
+  SLA を可用性とパフォーマンスのためにのみ定義している。 
+  すべてのワークロードに同じ設計パターン (マルチ AZ アーキテクチャなど) を使用している。 

 **このベストプラクティスを活用するメリット:** SLA を持続可能性の目標に合わせることで、ビジネスニーズを満たしながら最適なリソース使用量を実現できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 SLA は、クラウドワークロードで期待できるサービスのレベルを定義します。応答時間、可用性、データ保持などです。アーキテクチャ、リソース使用量、クラウドワークロードの環境への影響に関わります。定期的に SLA をレビューして、リソースの使用量を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。 

 **実装手順** 
+  ビジネス要件を超えるのではなく満たしながら、持続可能性の目標をサポートする SLA を定義または再設計します。 
+  持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。 
  +  **持続可能性と信頼性:** 可用性が高いワークロードはより多くのリソースを消費する傾向があります。 
  +  **持続可能性とパフォーマンス:** より多くのリソースを使用してパフォーマンスを強化すると、環境への影響が大きくなる場合があります。 
  +  **持続可能性とセキュリティ:** 過剰に保護されたワークロードは環境への影響が大きくなる場合があります。 
+  ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる設計パターン ([AWS のマイクロサービス](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)など) を使用します。 

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

 **関連するドキュメント:** 
+  [AWS サービスレベルアグリーメント (SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all) 
+  [Importance of Service Level Agreement for SaaS Providers](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) (SaaS プロバイダーにとってのサービスレベルアグリーメントの重要性) 

 **関連動画:** 
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)(持続可能でパフォーマンスが高いアーキテクチャを実現する)
+ [Build a cost-, energy-, and resource-efficient compute environment (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)](https://www.youtube.com/watch?v=8zsC5e1eLCg)