# サステナビリティ
**Topics**
+ [リージョンの選択](a-region-selection.md)
+ [ユーザーの行動パターン](a-user-behavior-patterns.md)
+ [ソフトウェアとアーキテクチャのパターン](a-sus-software-architecture-patterns.md)
+ [データパターン](a-sus-data-patterns.md)
+ [ハードウェアパターン](a-sus-hardware-patterns.md)
+ [開発とデプロイのプロセス](a-sus-development-deployment.md)
# リージョンの選択
**Topics**
+ [SUS 1 リージョンをどのように選択して、持続可能性目標を目指しますか?](w2aac19c15b5b5.md)
# SUS 1 リージョンをどのように選択して、持続可能性目標を目指しますか?
ビジネス要件と持続可能性目標の両方に基づいて、ワークロードを実装するリージョンを選択します。
ベストプラクティス:
# SUS01-BP01 Amazon の再生可能エネルギープロジェクトに近いリージョンと、グリッドの炭素強度が他の場所 (またはリージョン) よりも低く公表されているリージョンを選択する
Amazon の再生可能エネルギープロジェクトに近いリージョンであり、グリッドの公開されている炭素集約度が他の場所 (またはリージョン) よりも低いリージョンを選択します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
Amazon の再生可能エネルギープロジェクトに近いリージョンであり、グリッドの公開されている炭素集約度が他の場所 (またはリージョン) よりも低いリージョンを選択します。
## リソース
**関連するドキュメント:**
+ [Amazon Around the Globe (世界中の Amazon)](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true)
+ [再生可能エネルギーの方法論](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology)
+ [What to Consider when Selecting a Region for your Workloads (ワークロードに応じたリージョンを選択する際の注意点)](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
# ユーザーの行動パターン
**Topics**
+ [SUS 2 ユーザーの行動パターンをどのように利用して、持続可能性目標を目指しますか?](w2aac19c15b7b5.md)
# SUS 2 ユーザーの行動パターンをどのように利用して、持続可能性目標を目指しますか?
ユーザーがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的にユーザーの負荷に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみがデプロイされているようにします。サービスレベルをお客様のニーズと整合させます。ユーザーがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用の既存アセットを削除します。作成されたが未使用のアセットを特定し、作成を止めます。チームメンバーには、必要な機能をサポートし持続可能性への影響を最小限にするデバイスを提供します。
ベストプラクティス:
# SUS02-BP01 ユーザーの負荷に合わせてインフラストラクチャをスケールする
使用率が低い、または使用されていない期間を特定し、リソースをスケールダウンして余分な容量を排除し効率性を改善します。
**一般的なアンチパターン:**
+ ユーザーの負荷に合わせてインフラストラクチャをスケールしない。
+ 常に手動でインフラストラクチャをスケールする。
+ スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。
**このベストプラクティスを活用するメリット:** ワークロードの伸縮性を設定してテストすることで、ワークロードの環境への影響を削減し、費用を節減し、パフォーマンスベンチマークを維持できます。クラウドの伸縮性を活用して、ユーザーの負荷の急増時や急増後にキャパシティを自動的にスケールして、お客様のニーズを満たすために必要なリソースのみを正確に使用できるようにすることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。アーキテクチャの伸縮性を使用して、ユーザーの負荷が低い時間帯にワークロードを迅速かつ容易にスケールダウンできるようにします。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) を使用して、アプリケーションのユーザー負荷を処理するための適切な数の Amazon EC2 インスタンスがあることを確認できます。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) を使用して、個別の AWS サービス (Lambda 関数や Amazon Elastic Container Service (Amazon ECS) サービスなど) のリソースを、Amazon EC2 を超えて自動的にスケーリングします。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) を使用して、AWS の Kubernetes クラスターを自動的にスケーリングします。
+ スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。必要な場合は、スケーリングポリシーとして [カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (メモリ使用率など) を使用できます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。
+ メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。
+ メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) ではなく [動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) を Auto Scaling グループに使用します。また、動的スケーリングでは、 [ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) を使用することをお勧めします。
+ ワークロードのデプロイがスケールアップとスケールダウンの両方のイベントに対処できることを確認します。スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。専用のインフラストラクチャで **アクティビティ履歴** を使用して、Auto Scaling グループのスケーリングアクティビティをテストし、確認することができます。
+ ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon EC2 Auto Scaling で予測スケーリング](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) を使用して、キャパシティを誇張する必要性をなくします。
## リソース
**関連するドキュメント:**
+ [Getting Started With Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and Kibana](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [Amazon CloudWatch とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon EC2 Auto Scaling での予測スケーリングのネイティブサポートの概要](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [メモリ利用率メトリクスに基づいて Amazon EC2 Auto Scaling ポリシーを作成する方法 (Linux)](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/)
+ [Karpenter の概要 - オープンソースの高性能 Kubermetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
**関連動画:**
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw)
**関連する例:**
+ ラボ: Amazon EC2 Auto Scaling グループの例
+ [ラボ: Karpenter による自動スケーリングの実装](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 SLA を持続可能性の目標に合わせる
可用性やデータ保持期間などに関するサービスレベルアグリーメント (SLA) を定義、更新し、ビジネス要件を満たしながら、ワークロードをサポートするために必要なリソース数を最小化します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ ビジネス要件を満たしながら持続可能性の目標をサポートする SLA を定義します。
+ ビジネス要件を超えるのではなく、要件に合わせて SLA を再定義します。
+ 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
+ ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる設計パターンを使用します。
## リソース
**関連するドキュメント:**
+ [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/)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS02-BP03 未使用アセットの創出と維持の停止
アプリケーションアセット (事前コンパイル済みのレポート、データセット、静的イメージなど) とアセットのアクセスパターンを分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。生成されたアセットを冗長性コンテンツ (重複または共通のデータセットと出力が含まれる月次レポートなど) と統合し、出力が重複する際に消費されるリソースをなくします。使用されていないアセット (既に販売していない製品の画像など) を廃止し、消費されていたリソースを解放して、ワークロードをサポートするために使用されるリソース数を削減します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ 静的アセットを管理し、不要になったアセットは削除します。
+ 生成されたアセットを管理し、不要になったアセットは生成を止めて削除します。
+ 重複して生成されるアセットは統合し、冗長プロセスを排除します。
+ 不要になったアセットをお客様に代わって管理しているサードパーティーに、アセットの生成と保存を止めるように指示します。
+ サードパーティーに、お客様の代わりに生成されている冗長アセットを統合するように指示します。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage (サステナビリティのための AWS インフラストラクチャの最適化、パートII : ストレージ)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS02-BP04 ワークロードの地理的な配置を、ユーザーのロケーションに合わせて最適化する
ネットワークのアクセスパターンを分析し、顧客が地理的にどこから接続しているかを特定します。ネットワークトラフィックが経由しなければならない距離を削減できるリージョンとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。
** 一般的なアンチパターン: **
+ 自分の場所に基づいてワークロードのリージョンを選択する。
**このベストプラクティスを活用するメリット:** ワークロードを顧客の近くに配置することで、ネットワーク上のデータ移動を減らし、環境負荷を低減しながら、最小限のレイテンシーを実現します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 以下の主な要素に基づいて、ワークロードのデプロイに適切なリージョンを選択します。
+ **持続可能性目標:** 以下で説明されています [リージョンの選択](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html).
+ **データの場所:** 大量のデータを使用するアプリケーション (ビッグデータや機械学習など) では、アプリケーションコードをできるだけデータの近くで実行してください。
+ **ユーザーの場所:** ユーザー向けアプリケーションの場合は、ワークロードの顧客ベースに近いリージョンを選びます。
+ **その他の制約:** 以下で説明されているように、セキュリティやコンプライアンスなどの制約を考慮します。 [What to Consider when Selecting a Region for your Workloads (ワークロードに応じたリージョンを選択する際の注意点)](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/).
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS ローカルゾーン](https://aws.amazon.com/global-infrastructure/localzones/) を使用して、動画レンダリングやグラフィックス集約的な仮想デスクトップアプリケーションなどのワークロードを実行します。ローカルゾーンでは、エンドユーザーの近くにコンピューティングリソースやストレージリソースがあるというメリットが得られます。
+ ローカルキャッシュまたは [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/) を、頻繁に使用するリソースに使用すると、パフォーマンスを向上させ、データ移動を削減し、環境への影響を低減できます。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) を使用すると、画像、スクリプト、動画などの静的コンテンツだけでなく、API 応答やウェブアプリケーションなどの動的コンテンツをキャッシュできます。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) を使用して、ウェブアプリケーションのコンテンツをキャッシュします。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) を使用して、DynamoDB テーブルにインメモリアクセラレーションを追加します。
+ ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Lambda@Edge](https://aws.amazon.com/lambda/edge/) は、オブジェクトがキャッシュにないときに実行される、コンピューティング負荷の高いオペレーションに使用します。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon CloudFront 関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) は、HTTP リクエストまたはレスポンス操作など、短時間実行の関数で実行できるシンプルなユースケースに使用します。
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS IoT Greengrass](https://aws.amazon.com/greengrass/) を使用して、接続されたデバイスのローカルコンピューティング、メッセージング、データキャッシュを実行します。
+ コネクションプーリングを使用して、接続の再利用を可能にし、必要なリソースを削減します。
+ 永続的な接続や同期更新に依存しない分散されたデータストアを使用して、リージョンのユーザーに一貫性のあるサービスを提供します。
+ 事前にプロビジョンされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有します。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache のドキュメント](https://docs.aws.amazon.com/elasticache/index.html)
+ [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront の主な特徴](https://aws.amazon.com/cloudfront/features/)
+ [Lambda@Edge](https://aws.amazon.com/lambda/edge/)
+ [CloudFront 関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html)
+ [AWS IoT Greengrass](https://aws.amazon.com/greengrass/)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
**関連する例:**
+ [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US)
# SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する
チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら持続可能性への影響を最小限に抑えます。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高性能な単一ユーザーのシステムで行うのではなく、使用率の高い共有クラウドデスクトップで行います。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ 使用方法に合わせてワークステーションや他のデバイスをプロビジョンします。
+ 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードとデバイス要件を制限します。
+ プロセッサーやメモリの負荷が大きいタスクをクラウドに移動します。
+ デバイスのライフサイクルにおけるプロセスやシステムの影響を評価し、ビジネス要件を満たしながらデバイスを交換する必要性を最小限にするソリューションを選択します。
+ デバイスのリモート管理を実装して出張を少なくします。
## リソース
**関連するドキュメント:**
+ [Amazon WorkSpaces とは?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# ソフトウェアとアーキテクチャのパターン
**Topics**
+ [SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?](w2aac19c15b9b5.md)
# SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは使用停止にします。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客さまのサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。
ベストプラクティス:
# SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する
ソフトウェアの効率的な設計とアーキテクチャを使用し、作業単位で必要な平均リソースを最小化します。コンポーネントの使用率が平均化されるメカニズムを実装し、タスクの合間でアイドルになるリソースを削減して、負荷のスパイクの影響を最小化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 即時処理を必要としないリクエストをキューに入れます。
+ 直列化を増やしてパイプライン全体の使用率を平均化します。
+ 個別のコンポーネントの容量を変更し、リソースが入力を待ってアイドル状態になるのを防ぎます。
+ バッファを作成し、レート制限を設定して外部サービスの消費を円滑化します。
+ 使用できる中で最も効率的なハードウェアを使用し、ソフトウェアを最適化します。
+ キュー駆動型アーキテクチャ、パイプライン管理、オンデマンドインスタンスワーカーを使用して、バッチ処理の使用率を最大化します。
+ タスクをスケジュールして、同時実行による負荷のスパイクとリソースの競合を避けます。
+ 電力の炭素強度が最も低い時間帯にジョブを処理します。
## リソース
**関連するドキュメント:**
+ [Amazon Simple Queue Service とは?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Amazon MQ とは?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [Amazon SQS に基づいたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [AWS Step Functions とは?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda とは?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Lambda を Amazon SQS に使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [Amazon EventBridge とは?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**関連動画:**
+ [Building Sustainably on AWS](https://www.youtube.com/watch?v=ARAitMSIxc8)
+ [Moving to event-driven architectures](https://www.youtube.com/watch?v=h46IquqjF3E)
# SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする
ワークロードアクティビティをモニターして、個別のコンポーネントの時間経過による使用率の変化を特定します。未使用のコンポーネントや不要になったコンポーネントを削除し、使用率の低いコンポーネントはリファクタリングして、無駄なリソースを制限します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ 機能コンポーネントの負荷を (トランザクションフローや API コールなどのインジケーターを使用して) 分析し、未使用および使用率の低いコンポーネントを特定します。
+ 不要になったコンポーネントは使用停止にします。
+ 使用率の低いコンポーネントはリファクタリングします。
+ 使用率の低いコンポーネントを他のリソースと統合して、使用効率を改善します。
## リソース
**関連するドキュメント:**
+ [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ServiceLens を使用してアプリケーションのヘルスをモニターする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [Automated Cleanup of Unused Images in Amazon ECR (Amazon ECR における未使用画像の自動クリーンアップ)](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する
ワークロードアクティビティをモニターして、リソースの消費が最も大きいアプリケーションコンポーネントを特定します。それらのコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ リソース使用率が作用するパフォーマンスをモニターして、作業単位でリソースを多く必要とするコンポーネント特定し、最適化の対象とします。
+ コードプロファイラーを使用して、時間またはリソースを最も多く使用するコードの領域を特定し、最適化の対象とします。
+ アルゴリズムを同じ結果が生成される、より効率的なバージョンに置き換えます。
+ ハードウェアアクセラレーションを使用して、実行時間が長いコードブロックの効率を改善します。
+ 最も効率的なオペレーティングシステムとプログラム言語をワークロードに使用します。
+ 不要なソートと書式設定を削除します。
+ データの変更頻度と消費方法に基づいて使用されるリソースを最小化するデータ転送パターンを使用します。例えば、状態変更情報は、クライアントがリソースを消費してポーリングし価値のない「変更なし」のメッセージを受信するのではなく、クライアントにプッシュします。
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CodeGuru Profiler とは?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [The AWS SDKs on Tools to Build on AWS (AWS の構築ツールの AWS SDK)](https://aws.amazon.com/tools/)
**関連動画:**
+ [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP04 お客様のデバイスや機器への影響を最適化する
お客さまのサービスを利用するために顧客が使用しているデバイスや機器、その予想ライフサイクル、およびそれらのコンポーネントを交換することによる金融および持続可能性に対する影響を理解します。顧客のデバイスの交換や機器のアップグレードの必要性を最小化するソフトウェアパターンとアーキテクチャを実装します。例えば、新機能の実装には、より古いハードウェアやオペレーティングシステムのバージョンと後方互換性のあるコードを使用します。また、ペイロードのサイズを管理して、対象デバイスのストレージ容量を超えないようにします。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 顧客が使用するデバイスのインベントリを作成します。
+ マネージド型 Device Farm を代表的なハードウェアセットと共に使用してテストを行い、変更の影響を理解して、サポート対象のデバイスを最大化する開発を繰り返します。
+ ペイロードを構築する際にネットワーク帯域幅とレイテンシーを考慮し、低帯域幅、高レイテンシーのリンクでもアプリケーションが問題なく動作できる能力を実装します。
+ データペイロードを事前に処理して、ローカルでの処理要件を削減し、データ転送要件を制限します。
+ コンピューティングの負荷が高いアクティビティはサーバー側 (画像のレンダリングなど) で実行するか、アプリケーションストリーミングを使用して、古い型のデバイスでのユーザーエクスペリエンスを改善します。
+ 特にインタラクティブセッションの場合は、出力を分割してページ番号を付け、ペイロードを管理しローカルストレージの要件を制限します。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm とは?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [Amazon Elastic Transcoder のドキュメント](https://docs.aws.amazon.com/elastic-transcoder/)
**関連動画:**
+ [Building Sustainably on AWS](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP04 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する
データがどのようにワークロード内で使用されているか、ユーザーに消費されているか、転送されているか、保存されているかを理解します。データの処理と保存の要件を最小化するテクノロジーを選択します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ データアクセスとストレージパターンを分析します。
+ 不要な処理を (分析の実行時などに) 回避するため、Parquet などの効率的なファイル形式でデータファイルを保存し、プロビジョンする合計ストレージを削減します。
+ 圧縮データをネイティブに操作するテクノロジーを使用します。
+ 主要なクエリパターンに対して最も優れたサポートをするデータベースエンジンを使用します。
+ データベースインデックスを管理してインデックスの設計が効率的なクエリ実行を確実にサポートするようにします。
+ 消費されるネットワーク容量が削減できるネットワークプロトコルを選択します。
## リソース
**関連するドキュメント:**
+ [Athena でサポートされる圧縮ファイル形式](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [Amazon Redshift を使用した列指向のデータ形式からの COPY](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [Firehose で入力レコード形式を変換する](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)
+ [AWS Glue の ETL 入出力の形式オプション](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [列指向形式に変換して Amazon Athena でのクエリパフォーマンスを改善する](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [Amazon Redshift を使用して圧縮されたデータファイルを Amazon S3 からロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon Aurora での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [AWS IoT FleetWise](https://aws.amazon.com/about-aws/whats-new/2021/11/aws-iot-fleetwise-transferring-vehicle-data-cloud/)
**関連動画:**
+ [Building Sustainably on AWS](https://www.youtube.com/watch?v=ARAitMSIxc8)
# データパターン
**Topics**
+ [SUS 4 データのアクセスパターンおよび使用パターンをどのように利用して、持続可能性目標を目指しますか?](w2aac19c15c11b5.md)
# SUS 4 データのアクセスパターンおよび使用パターンをどのように利用して、持続可能性目標を目指しますか?
データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とデータの使用方法を最もよくサポートするストレージテクノロジーと設定を使用します。必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし、データが不要になった場合は削除します。
ベストプラクティス:
# SUS04-BP01 データ分類ポリシーを実装する
データを分類して、ビジネス成果にとっての重要性を理解します。この情報を使用して、データをよりエネルギー効率が高いストレージに移動するタイミングや、安全に削除するタイミングを検討します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ データのディストリビューション、保持、削除の要件を検討します。
+ ボリュームやオブジェクトへのタグ付けを使用してメタデータを記録し、それを使用してデータ分類を含む管理方法を検討します。
+ 環境を定期的に監査してタグ付けおよび分類されていないデータを探し、そのデータを適切に分類してタグ付けします。
## リソース
**関連するドキュメント:**
+ [Data Classification Process](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-process.html)
+ [Leveraging AWS クラウド to Support Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html)
+ [AWS Organizations のタグポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
# SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する
データへのアクセス方法や保存方法をもっともよくサポートするストレージを使用し、ワークロードをサポートしながらプロビジョニングされるリソースを最小化します。例えば、ソリッドステートドライブ (SSD) は磁気式ドライブよりもエネルギー消費が大きいため、アクティブなデータのユースケースのみに使用するべきです。アクセスの少ないデータに対して、エネルギー効率の高いアーカイブクラスのストレージを使用します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ データのアクセスパターンをモニタリングします。
+ アクセスパターンに基づいて適切なテクノロジーにデータを移行します。
+ アーカイブデータを目的に合わせて設計されたストレージに移行します。
## リソース
**関連するドキュメント:**
+ [Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+ [Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [Amazon S3 のストレージクラスを使用する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [Amazon CloudWatch とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon Glacier とは?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**関連動画:**
+ [Architectural Patterns for Data Lakes on AWS](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
# SUS04-BP03 ライフサイクルポリシーを使用して不要なデータを削除する
データすべてのライフサイクルを管理し、削除のタイムラインを自動的に適用して、ワークロードに必要な合計ストレージを最小化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ すべてのデータ分類タイプのライフサイクルポリシーを定義します。
+ ライフサイクルルールを適用するための自動ライフサイクルポリシーを設定します。
+ 未使用のボリュームとスナップショットを削除します。
+ ライフサイクルルールに基づいて、該当する場合はデータを集約します。
## リソース
**関連するドキュメント:**
+ [Amazon ECR ライフサイクルポリシー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html)
+ [Amazon EFS ライフサイクル管理](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [AWS Config ルールを使用してリソースを評価する](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ [Amazon S3 でストレージのライフサイクルを管理する](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [AWS Elemental MediaStore のオブジェクトライフサイクルポリシー](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle.html)
**関連動画:**
+ [Amazon S3 Lifecycle](https://www.youtube.com/watch?v=53eHNSpaMJI&ab_channel=AmazonWebServices)
# SUS04-BP04 ブロックストレージの過剰プロビジョニングを最小化する
プロビジョニングされる合計ストレージを最小化するには、ワークロードに適したサイズ割り当てのブロックストレージを作成します。伸縮自在なボリュームを使用し、データの増加に合わせて、コンピューティングリソースに添付されたストレージをサイズ変更することなく拡張します。伸縮自在なボリュームを定期的に確認し、現在のデータサイズに合わせてプロビジョンされたボリュームを縮小します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ データボリュームの使用率をモニターします。
+ 伸縮自在なボリュームとマネージド型のブロックデータサービスを使用して、永続的データの増加に応じて追加のストレージの割り当てを自動化します。
+ データボリュームの使用率の目標レベルを設定し、予想される範囲外のボリュームはサイズ変更します。
+ データに合わせて読み取り専用ボリュームのサイズを設定します。
+ データをオブジェクトストアに移行して、ブロックストレージの固定ボリュームサイズを超える容量をプロビジョンするのを回避します。
## リソース
**関連するドキュメント:**
+ [Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)
+ [Amazon FSx のドキュメント](https://docs.aws.amazon.com/fsx/index.html)
+ [Amazon CloudWatch とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon Elastic File System とは?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
# SUS04-BP04 不要なデータや重複するデータを削除する
データの複製は必要なときにのみ行い、消費される合計ストレージを最小化します。ファイルおよびブロックレベルでデータの重複を排除するバックアップテクノロジーを使用します。サービスレベルアグリーメント (SLA) の要件を満たすために必要な場合を除き、RAID (Redundant Array of Independent Drives) 設定の使用を制限します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ブロックレベルとオブジェクトレベルでデータを重複排除できる仕組みを使用します。
+ ブロック、ファイル、オブジェクトレベルでデータの増分のバックアップおよび重複排除を実行できるバックアップテクノロジーを使用します。
+ RAID は SLA を満たすために必要な場合にのみ使用します。
+ ログおよび追跡データを一元化し、同一のログエントリの重複を排除して、必要に応じて冗長性を調整するメカニズムを確立します。
+ キャッシュを事前入力は、正当な場合にのみ行います。
+ キャッシュのモニタリングとオートメーションを確立し、それに従ってキャッシュをサイズ変更します。
+ ワークロードの新しいバージョンをプッシュする際に、オブジェクトストアとエッジキャッシュから古いデプロイとアセットを削除します。
## リソース
**関連するドキュメント:**
+ [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [CloudWatch Logs のログデータ保持期間を変更する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server でのデータの重複排除](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [データの重複排除を含む Amazon FSx for ONTAP の機能](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [Amazon CloudFront でのファイルの無効化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html)
+ [AWS Backup を使用してバックアップを行い、Amazon EFS ファイルシステムを復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon CloudWatch Logs とは?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon RDS でのバックアップの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**関連する例:**
+ [ラボ: Amazon Redshift データ共有を使用したデータパターンの最適化](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
# SUS04-BP06 共有ファイルシステムまたはオブジェクトストレージを使用して共通データにアクセスする
共有ストレージと単一の信頼できるソースを採用し、データの複製を避けてワークロードに必要な合計ストレージを削減します。必要に応じて共有ストレージからデータを取得します。未使用のボリュームをデタッチして利用可能なリソースを増やします。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ データに複数のコンシューマーが存在する場合は、データを共有ストレージに移行します。
+ 必要に応じて共有ストレージからデータを取得します。
+ 使用パターンに合わせてデータを削除し、有効期限 (TTL) 機能を導入してキャッシュされたデータを管理します。
+ クライアントがアクティブに使用していないボリュームをクライアントからデタッチします。
## リソース
**関連するドキュメント:**
+ [Amazon FSx](https://aws.amazon.com/fsx/)
+ [キャッシング戦略](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html)
+ [Amazon Elastic File System とは?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon S3 とは?](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
# SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える
共有ストレージを使用し、その地域のデータストアからデータにアクセスして、ワークロードにおけるデータ移動をサポートするために必要なネットワークリソースの総量を最小化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 可能な限りコンシューマーの近くにデータを保存します。
+ リージョン固有のデータは、消費するリージョン内に保存されるので、パーティションは、リージョンでサービスを消費します。
+ ネットワーク全体で変更をコピーする場合、ファイルまたはオブジェクトレベルの重複ではなくブロックレベルの重複を使用します。
+ データを圧縮してからネットワーク経由で移動します。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [Amazon CloudFront の主な特徴 (CloudFront グローバルエッジネットワークなど)](https://aws.amazon.com/cloudfront/features/)
+ [Amazon OpenSearch Service での HTTP リクエストの圧縮](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Amazon EMR を使用して中間データを圧縮する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [圧縮されたデータファイルを Amazon S3 から Amazon Redshift にロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon CloudFront を使用して圧縮ファイルを提供する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
# SUS04-BP08 データは再作成が難しい場合にのみバックアップする
ストレージの消費を最小化するには、ビジネス価値のあるデータまたはコンプライアンス要件を満たすために必要なデータのみをバックアップします。バックアップポリシーを精査し、リカバリーシナリオでは価値のないエフェメラルストレージを除外します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ データ分類を使用して、バックアップが必要なデータを設定します。
+ 簡単に再作成できるデータを除外します。
+ バックアップから一時データを除外します。
+ 共通の場所からデータを復元するために必要な時間がサービスレベルアグリーメント (SLA) を超える場合を除き、データのローカルコピーを除外します。
## リソース
**関連するドキュメント:**
+ [AWS Backup を使用してバックアップを行い、Amazon EFS ファイルシステムを復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon Relational Database Service でのバックアップの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
# ハードウェアパターン
**Topics**
+ [SUS 5 ハードウェアの管理および使用のプラクティスは、持続可能性目標を目指すうえでどのように役立ちますか?](w2aac19c15c13b5.md)
# SUS 5 ハードウェアの管理および使用のプラクティスは、持続可能性目標を目指すうえでどのように役立ちますか?
ハードウェア管理のプラクティスを変更することで、ワークロードの持続可能性に対する影響を軽減する機会を探します。プロビジョンおよびデプロイする必要があるハードウェア数を最小化し、個別のワークロードにおいて最も効率のいいハードウェアを選択します。
ベストプラクティス:
# SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する
クラウドの能力を使用して、ワークロードの実装を頻繁に変更できます。ニーズの変化に応じて、デプロイされたコンポーネントを更新します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 水平スケーリングを有効にし、オートメーションを使用して、負荷の増加に応じてスケールアウトし、負荷の減少に応じてスケールインします。
+ ワークロードの変動に合わせて少しずつスケールします。
+ スケーリングを周期的な使用パターンに合わせます (例えば、ペイロードシステムを隔週の負荷の高いプロセッシングアクティビティに合わせます)。負荷は日、週、月、年によって異なるためです。
+ 容量の一時的な削減ができるようにサービスレベルアグリーメント (SLA) を交渉すると同時に、オートメーションを使用して代替リソースをデプロイします。
## リソース
**関連するドキュメント:**
+ [AWS Compute Optimizer のドキュメント](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [Lambda のオペレーション: パフォーマンスの最適化](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/)
+ [Auto Scaling のドキュメント](https://docs.aws.amazon.com/autoscaling/index.html)
# SUS05-BP02 影響が最も少ないインスタンスタイプを使用する
新しいインスタンスタイプのリリースを継続的にモニタリングし、機械学習のトレーニング、推論、ビデオのトランスコーディングなどの特定のワークロードをサポートするように設計されたインスタンスタイプを含む、エネルギー効率の改善を活用します。
**一般的なアンチパターン:**
+ インスタンスの 1 つのファミリーのみを使用する。
+ x86 インスタンスのみを使用する。
+ Amazon EC2 Auto Scaling 設定で 1 つのインスタンスタイプを指定する。
+ AWS インスタンスが設計されていない方法で使用されている (たとえば、メモリ集中型のワークロードに計算用に最適化されたインスタンスを使用した場合)。
+ 新しいインスタンスタイプを定期的に評価しない。
+ 次のような AWS サイズ最適化ツールからのレコメンデーションを確認しない : [AWS Compute Optimizer。](https://aws.amazon.com/compute-optimizer/)
**このベストプラクティスを活用するメリット:** エネルギー効率が高く、適切なサイズのインスタンスを使用することで、環境への影響とワークロードのコストを大幅に削減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロード環境への影響を削減できるインスタンスタイプを学習し、試します。
+ 例えば、 [AWS の最新情報](https://aws.amazon.com/new/) を購読して、最新の AWS テクノロジーとインスタンスの情報を入手します。
+ さまざまな AWS インスタンスタイプについて学びます。
+ Amazon EC2 のエネルギー使用量 1 ワットあたりで最高のパフォーマンスを発揮する AWS Graviton ベースのインスタンスについて、以下のビデオをご覧ください。 [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (AWS Graviton2 プロセッサ搭載 Amazon EC2 インスタンスの詳細)](https://www.youtube.com/watch?v=NLysl0QvqXU) と [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents).
+ ワークロードを計画し、最も影響の少ないインスタンスタイプに移行することができます。
+ ワークロードの新機能やインスタンスを評価するプロセスを定義します。クラウドの俊敏性を利用して、新しいインスタンスタイプがワークロード環境の持続可能性をどのように改善するかをすばやくテストします。プロキシメトリクスを使用して、1 つの作業単位を完了するのに必要なリソース数を測定します。
+ 可能な場合は、異なる数の vCPU と異なる量のメモリで動作するようにワークロードを変更して、インスタンスタイプの選択肢を最大化します。
+ ワークロードのパフォーマンス効率を向上させるために、Graviton ベースのインスタンスへの移行を検討します ( [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/) と [AWS Graviton2 for ISVs を参照](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)) を指定する必要があります。ワークロードを [AWS Graviton ベースの Amazon Elastic Compute Cloud インスタンスに移行する際の考慮事項を覚えておいてください。](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)
+ 以下の利用において、AWS Graviton オプションの選択を検討します : [AWS マネージドサービス。](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)
+ 持続可能性に対する影響が最も少なく、かつビジネス要件を満たすインスタンスを提供するリージョンにワークロードを移行します。
+ 機械学習ワークロードの場合は、次のようなカスタム Amazon Machine Learning チップに基づく Amazon EC2 インスタンスを使用します : [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)io1 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、および [Amazon EC2 DL1。](https://aws.amazon.com/ec2/instance-types/dl1/)
+ 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) を使用して、機械学習推論エンドポイントのサイズを適切に設定します。
+ リアルタイムの動画トランスコーディングを伴うワークロードについては、 [Amazon EC2 VT1 インスタンスを使用します。](https://aws.amazon.com/ec2/instance-types/vt1/)
+ スパイキーなワークロード (追加のキャパシティが必要になることがあまりないワークロード) の場合は、 [バーストパフォーマンスインスタンスを使用します。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ ステートレスで耐障害性の高いワークロードについては、 [Amazon EC2 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) を使用して、クラウドの全体使用率を高め、未使用のリソースの持続可能性に対する影響を軽減します。
+ ワークロードインスタンスを操作して、最適化します。
+ 一次的なワークロードについては、 [インスタンス Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) ( `CPUUtilization` など) を評価して、インスタンスがアイドルか使用率が低いかを識別します。
+ 安定したワークロードの場合は、AWS サイズ適正化ツール ( [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) など) を定期的にチェックし、インスタンスの最適化とサイズ適正化の機会を識別します。
## リソース
**関連するドキュメント:**
+ [持続可能性のために AWS インフラストラクチャを最適化する、パート I: コンピューティング](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton プロセッサ](https://aws.amazon.com/ec2/graviton/)
+ [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)
+ [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)
+ [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [Amazon EC2 キャパシティ予約フリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [Amazon EC2 スポットフリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [Amazon EC2 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)
+ [Amazon EC2 VT1 インスタンス](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
**関連動画:**
+ [Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (AWS Graviton2 プロセッサ搭載 Amazon EC2 インスタンスの詳細)](https://www.youtube.com/watch?v=NLysl0QvqXU)
+ [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
**関連する例:**
+ [ラボ: 適切なサイズのレコメンデーション](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [ラボ: Compute Optimizer によるサイズ適正化](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ラボ: ハードウェアパターンの最適化と持続可能性 KPI の観察](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
# SUS05-BP03 マネージドサービスを使用する
マネージドサービスは、平均使用率を高く保つ責任と、デプロイされたハードウェアの持続可能性に対する最適化の責任を AWS に移します。マネージドサービスを使用して、サービスの持続可能性に対する影響を、そのサービスのすべてのテナント間に分散し、お客様単体の関与を軽減します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 自己ホスト型サービスからマネージドサービスに移行します。例えば、マネージド型の [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) インスタンスを使用するか (独自の Amazon RDS インスタンスを [Amazon Elastic Compute Cloud (Amazon EC2) ](https://aws.amazon.com/ec2/)で維持する代わりに)、あるいは [AWS Fargate](https://aws.amazon.com/fargate/)のようなマネージドコンテナサービスを (独自のコンテナインフラストラクチャを実装する代わりに) 使用します。
## リソース
**関連するドキュメント:**
+ [AWS Fargate](https://aws.amazon.com/fargate/)
+ [Amazon DocumentDB](https://aws.amazon.com/documentdb/)
+ [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/)
+ [Amazon Redshift](https://aws.amazon.com/redshift/)
+ [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/)
# SUS05-BP04 GPU の使用を最適化する
グラフィック処理ユニット (GPU) は高電力消費のソースになることがあります。GPU ワークロードの種類は多く、レンダリング、トランスコーディング、機械学習トレーニング、モデリングなどさまざまです。GPU インスタンスは必要な時間だけ実行し、必要がないときはオートメーションで廃棄して、消費されるリソースを最小化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ GPU は、CPU ベースの代替手段より効率的な場合にのみ、タスクに使用します。
+ 使用しないときは、オートメーションを使用して GPU インスタンスを解放します。
+ 専用の GPU インスタンスではなく、柔軟なグラフィックスアクセラレーションを使用します。
+ ワークロードに特化したカスタムの専用ハードウェアを活用します。
## リソース
**関連するドキュメント:**
+ [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)
+ [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)
+ [EC2 インスタンスの高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [Amazon EC2 VT1 インスタンス](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon Elastic Graphics](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-graphics.html)
# 開発とデプロイのプロセス
**Topics**
+ [SUS 6 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?](w2aac19c15c15b5.md)
# SUS 6 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?
開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。
ベストプラクティス:
# SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する
本稼働環境にデプロイする前に、潜在的な改善をテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 持続可能性の要件を開発プロセスに追加します。
+ 持続可能性の改善策を開発、テスト、デプロイするために、リソースを並行して働かせることができるようにします。
+ 本稼働環境にデプロイする前に、持続可能性に対する影響をもたらしうる改善をテストして検証します。
+ 最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善をテストします。
+ テスト済みの持続可能性の改善が利用可能になったら本番環境にデプロイします。
## リソース
**関連するドキュメント:**
+ [AWS enables sustainability solutions (AWS が実現するサステナビリティソリューション)](https://aws.amazon.com/sustainability/)
**関連する例:**
+ [ラボ: ](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) コストと使用状況レポートを効率性レポートに変える
# SUS06-BP02 ワークロードを最新に保つ
最新のオペレーティングシステム、ライブラリ、およびアプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。
**一般的なアンチパターン:**
+ 現在のアーキテクチャは、時間が経つと更新されずに静的なものになると想定している。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的なミーティングがない。
+ あなたは、理由なしで、時間の経過とともにアーキテクチャの変更を導入します。
**このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを定義します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。
+ 持続可能性への影響を削減する。
+ パフォーマンスの効率を高める。
+ 計画した改善にとっての障壁を取り除く。
+ 持続可能性に対する影響の測定能力と管理能力を高める。
+ ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。専用のインフラストラクチャで [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) を使用して、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスがアップデートする必要があるかを迅速に把握することが可能です。
+ ワークロードのコンポーネントを更新する方法を理解します。
+ Linux または Windows サーバーイメージ向けの [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) の更新を管理するには、以下を使用します [EC2 Image Builder](https://aws.amazon.com/image-builder/).
+ 既存のパイプラインで [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) を使用して、 [Amazon Elastic Container Service (Amazon ECS) イメージの管理と](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) と [Amazon Elastic Kubernetes Service イメージの管理ができます。](https://docs.aws.amazon.com/=AmazonECR/latest/userguide/ECR_on_EKS.html)
+ AWS Lambda には、 [バージョン管理機能が含まれています。](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)
+ 更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。例えば [AWS Systems Manager パッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用して、システム更新のプロセスを自動化し、 [AWS Systems Manager メンテナンスウィンドウを使用してアクティビティをスケジューリングします](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html).
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS Systems Manager パッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**関連する例:**
+ [Well-Architected ラボ: インベントリおよびパッチ管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
+ [ラボ: AWS Systems Manager](https://mng.workshop.aws/ssm.html)
# SUS06-BP03 ビルド環境の利用率を高める
オートメーションと Infrastructure as Code を使用して、必要に応じて本番稼働前の環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。休止は、状態を維持し、必要なときにのみインスタンスを迅速にオンラインにする便利な手段です。バーストキャパシティ、スポットインスタンス、伸縮自在なデータベースサービス、コンテナ、その他のテクノロジーを備えたインスタンスタイプ使用して、開発およびテストのキャパシティを使用に合わせて調整します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ オートメーションを使用して、開発環境とテスト環境を最大限に活用します。
+ オートメーションを使用して開発環境とテスト環境のライフサイクルを管理します。
+ 最小限に実行可能である代表的な環境を使用して、潜在的な改善を開発およびテストします。
+ オンデマンドインスタンスを使用してデベロッパーのデバイスを支給します。
+ オートメーションを使用して、ビルドリソースの効率を最大化します。
+ バーストキャパシティ、スポットインスタンス、その他のテクノロジーを備えたインスタンスタイプを使用して、ビルドキャパシティを使用状況に合わせて調整します。
+ 要塞ホストのフリートをデプロイするのではなく、ネイティブなクラウドサービスを採用して、インスタンスシェルのアクセスを保護します。
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [AWS CloudFormation とは?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# SUS06-BP04 マネージド型 Device Farm を使用してテストする
マネージド型の Device Farm は、ハードウェアの製造やリソースの使用の持続可能性に対する影響を複数のテナントに分散させます。マネージド型 Device Farm は、さまざまなデバイスタイプを提供するため、あまり使われない古いハードウェアをサポートすることで、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
マネージド型 Device Farm を代表的なハードウェアセットと共に使用してテストを行い、変更の影響を理解して、サポート対象のデバイスを最大化する開発を繰り返します。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm とは?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)