# サステナビリティ
クラウドワークロードを構築するときの持続可能性の柱には、使用しているサービスの影響の理解、ワークロードのライフサイクル全体における影響の数値化、および設計原則とベストプラクティスの適用によるそれらの影響の軽減が含まれます。実装に関する規範的なガイダンスについては、[持続可能性の柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)を参照してください。
**Topics**
+ [リージョンの選択](a-region-selection.md)
+ [需要に合わせた調整](a-alignment-to-demand.md)
+ [ソフトウェアとアーキテクチャ](a-sus-software-architecture.md)
+ [データ](a-sus-data.md)
+ [ハードウェアとサービス](a-sus-hardware-and-services.md)
+ [プロセスと文化](a-sus-process-and-culture.md)
# リージョンの選択
**Topics**
+ [SUS 1 ワークロードにリージョンを選択する方法](w2aac19c17b7b5.md)
# SUS 1 ワークロードにリージョンを選択する方法
ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を効果的に改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。
**Topics**
+ [SUS01-BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する](sus_sus_region_a2.md)
# SUS01-BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する
パフォーマンス、コスト、カーボンフットプリントなどの KPI を最適化するために、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択します。
**一般的なアンチパターン:**
+ 自分の場所に基づいてワークロードのリージョンを選択する。
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
**このベストプラクティスを活用するメリット:** ワークロードを Amazon 再生可能エネルギープロジェクトまたは公開されている炭素強度の低いリージョンの近くに配置すると、クラウドワークロードのカーボンフットプリントを減らすのに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS クラウドは、リージョンと Point of Presence (PoP) のネットワークを常に拡大し、それらをグローバルなネットワークインフラストラクチャでつないでいます。ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を効果的に改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。
### 実装手順
+ **候補地域の絞り込み:** 以下の手順に従って、コンプライアンス、利用可能な機能、コスト、レイテンシーなどのビジネス要件に基づき、ワークロードに適したリージョンを評価し、候補をリストアップします。
+ 必要なリージョンの規制 (データ主権など) に基づいて、これらのリージョンがコンプライアンスに準拠していることを確認します。
+ [AWS リージョンサービスリスト](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)を使用して、ワークロードの実行に必要なサービスと機能がリージョンに備えられているかどうかを確認します。
+ [AWS 料金見積りツール](https://calculator.aws/) を使用して、各リージョンのワークロードのコストを計算します。
+ エンドユーザーの拠点と各 AWS リージョン 間のネットワークレイテンシーをテストします。
+ **候補の選択:** Amazon の再生可能エネルギープロジェクトに近いリージョンであり、グリッドの公開されている炭素集約度が他の場所 (またはリージョン) よりも低いリージョンを選択します。
+ 関連する持続可能性ガイドラインを特定し、[温室効果ガスプロトコル](https://ghgprotocol.org/) (市場ベースおよびロケーションベースの方法) に基づいて、毎年のカーボンフットプリントを追跡して比較します。
+ 炭素排出量の追跡に使用する方法に基づいてリージョンを選択します。持続可能性のガイドラインに基づいてリージョンを選択する方法の詳細については、「[持続可能性の目標に基づいてワークロードのリージョンを選択する方法](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)」を参照してください。
## リソース
**関連ドキュメント:**
+ [炭素排出量の推定の理解](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html)
+ [世界中の Amazon](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true)
+ [再生可能エネルギーの方法論](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology)
+ [ワークロードに応じたリージョンを選択する際の注意点](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
**関連動画:**
+ [AWS re:Invent 2023 - Sustainability innovation in AWS Global Infrastructure](https://www.youtube.com/watch?v=0EkcwLKeOQA)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Architecting sustainably and reducing your AWS carbon footprint](https://www.youtube.com/watch?v=jsbamOLpCr8)
+ [AWS re:Invent 2022 - Sustainability in AWS global infrastructure](https://www.youtube.com/watch?v=NgMa8R9-Ywk)
# 需要に合わせた調整
**Topics**
+ [SUS 2 クラウドリソースを需要に合わせる方法](sus-02.md)
# SUS 2 クラウドリソースを需要に合わせる方法
ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的に需要に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します。サービスレベルをお客様のニーズと整合させます。ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用のアセットを削除します。チームメンバーには、ニーズをサポートし、持続可能性への影響を最小限にするデバイスを提供します。
**Topics**
+ [SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする](sus_sus_user_a2.md)
+ [SUS02-BP02 SLA を持続可能性の目標に合わせる](sus_sus_user_a3.md)
+ [SUS02-BP03 未使用アセットの創出と維持の停止](sus_sus_user_a4.md)
+ [SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する](sus_sus_user_a5.md)
+ [SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する](sus_sus_user_a6.md)
+ [SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する](sus_sus_user_a7.md)
# SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする
クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。
**一般的なアンチパターン:**
+ ユーザーの負荷に合わせてインフラストラクチャをスケールしない。
+ 常に手動でインフラストラクチャをスケールする。
+ スケーリングイベントの後、スケールダウンして元に戻さずに、容量を増加させたままにする。
**このベストプラクティスを活用するメリット:** ワークロードの伸縮性を設定およびテストすることで、需要とクラウドリソースの供給を効率的に一致させ、容量の過剰プロビジョニングを回避できます。クラウドの伸縮性を利用して需要の急増時や急増後に容量を自動的にスケールすることで、ビジネス要件を満たすために必要となる適切な数のリソースのみを運用できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を備えます。最適な形で需要と供給を一致させることで、ワークロードに対する環境の影響を最小限に抑えることができます。
需要は、一定の場合も変動する場合もあり、管理面の負担を軽減するには、メトリクスと自動化が必要になります。アプリケーションのスケールは、インスタンスのサイズを垂直方向に変更し (スケールアップ/スケールダウン)、インスタンス数を水平方向に変更して (スケールイン/スケールアウト)、またはこれらの組み合わせで調整します。
リソースの需要と供給は、さまざまなアプローチで一致させることができます。
+ **ターゲット追跡アプローチ:** スケーリングメトリクスをモニタリングし、必要に応じて容量を自動的に増減します。
+ **予測スケーリング:** 日次単位および週単位の傾向を見越してスケールします。
+ **スケジュールベースのアプローチ:** 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。
+ **サービススケーリング:** ネイティブにスケーリングするサービス (サーバーレスなど) を設計によって選択するか、機能として自動スケーリングを提供します。
使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除することで、効率性を改善します。
## 実装手順
+ 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。AWS では、ユーザー負荷が低い期間には迅速かつ簡単にワークロードをスケールダウンできるように、幅広い自動スケーリングメカニズムを提供しています。自動スケーリングメカニズムの例を以下に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_user_a2.html)
+ スケーリングは、一般的に、Amazon EC2 インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連して議論されます。需要に合わせて、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) の読み取り/書き込みキャパシティユニットや [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) シャードなどの非コンピューティングサービスの設定を検討してください。
+ スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードの種類に対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイする場合は、100% の CPU 使用率が予想されるため、プライマリメトリクスにするべきではありません。必要に応じて、スケーリングポリシーに[カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (メモリ使用率など) を使用できます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。
+ メトリクスは、有効な利用率メトリクスである必要があり、インスタンスがどの程度ビジーかを記述する必要があります。
+ メトリクス値は Auto Scaling グループのインスタンス数に比例して増減する必要があります。
+ Auto Scaling グループの[手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)の代わりに、[動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)を使用します。動的スケーリングで[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)を使用することをお勧めします。
+ スケールアウトとスケールインの両方のイベントに対処できるように、ワークロードをデプロイします。スケールインイベントのテストシナリオを作成して、ワークロードが期待どおりに動作し、ユーザーエクスペリエンスに影響しない (スティッキーセッションが失われない) ことを確認します。[アクティビティ履歴](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)を使用して、Auto Scaling グループのスケーリングアクティビティを確認できます。
+ 予測可能なパターンについてワークロードを評価し、予測および計画された需要の変化を想定してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、「[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 の使用を開始する](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/)
+ [Amazon OpenSearch Service、Amazon Data Firehose および 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)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Karpenter の概要 - オープンソースの高性能 Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Amazon ECS クラスターの Auto Scaling を深く探る](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**関連動画:**
+ [AWS re:Invent 2023 - Scaling on AWS for the first 10 million users ](https://www.youtube.com/watch?v=JzuNJ8OUht0)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [AWS re:Invent 2022 - Scaling containers from one user to millions ](https://www.youtube.com/watch?v=hItHqzKoBk0)
+ [AWS re:Invent 2023 - Scaling FM inference to hundreds of models with Amazon SageMaker AI ](https://www.youtube.com/watch?v=6xENDvgnMCs)
+ [AWS re:Invent 2023 - Harness the power of Karpenter to scale, optimize & upgrade Kubernetes ](https://www.youtube.com/watch?v=lkg_9ETHeks)
**関連する例:**
+ [Autoscaling](https://www.eksworkshop.com/docs/autoscaling/)
# SUS02-BP02 SLA を持続可能性の目標に合わせる
持続可能性の目標に基づいてワークロードのサービスレベルアグリーメント (SLA) をレビュー、最適化して、ビジネスニーズを満たしながらワークロードをサポートするために必要なリソースを最小化します。
**一般的なアンチパターン:**
+ ワークロード SLA がわからない、またはあいまいである。
+ SLA を可用性とパフォーマンスのためにのみ定義している。
+ すべてのワークロードに同じ設計パターン (マルチ AZ アーキテクチャなど) を使用している。
**このベストプラクティスを活用するメリット:** SLA を持続可能性の目標と整合すると、ビジネスニーズを満たすと同時にリソース使用を最適化できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
SLA は、クラウドワークロードで期待できるサービスのレベルを定義します。応答時間、可用性、データ保持などです。アーキテクチャ、リソース使用量、クラウドワークロードの環境への影響にかかわります。定期的に SLA をレビューして、リソースの使用量を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
### 実装手順
+ **持続可能性の目標を理解する:** 炭素削減やリソース使用率の向上など、組織内の持続可能性の目標を特定します。
+ **SLA の確認:** SLA を評価して、ビジネス要件をサポートしているかどうかを評価します。SLA を超えている場合は、さらに見直しを行います。
+ **トレードオフを理解する:** ワークロードの複雑さ (大量の同時接続ユーザーなど)、パフォーマンス (レイテンシーなど)、持続可能性への影響 (必要なリソースなど) のトレードオフを理解します。通常、2 つの要素に優先順位を付けると、3 つ目の要素が犠牲になります。
+ **SLA を調整する:** 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
+ **持続可能性と信頼性:** 可用性の高いワークロードは、より多くのリソースを消費する傾向があります。
+ **持続可能性とパフォーマンス:** より多くのリソースを使用してパフォーマンスを向上させると、環境への影響が大きくなる可能性があります。
+ **持続可能性とセキュリティ:** ワークロードが過度に安全であれば、環境への影響が大きくなる可能性があります。
+ **可能であれば持続可能性 SLA を定義する:** ワークロードに持続可能性 SLA を含めます。例えば、コンピューティングインスタンスの持続可能性に関する SLA として最小の使用率レベルを定義します。
+ **効率的な設計パターンを使用する:** ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる AWS 上のマイクロサービスなどの設計パターンを使用します。
+ **説明責任を伝達して確立する:** 開発チームや顧客を含む関連するすべての関係者と SLA を共有します。レポートを使用して SLA を追跡およびモニタリングします。SLA の持続可能性目標を達成するための説明責任を割り当てます。
+ **インセンティブと報酬を使用する:** インセンティブと報酬を使用して、持続可能性の目標に沿った SLA を達成または超過します。
+ **見直しと反復:** SLA を定期的に見直して調整し、進化する持続可能性とパフォーマンスの目標に合致していることを確認します。
## リソース
**関連ドキュメント:**
+ [ 回復性のパターンとトレードオフを理解して、効率的なクラウド設計を実現 ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
+ [SaaS プロバイダにとってのサービスレベルアグリーメントの重要性](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**関連動画:**
+ [AWS re:Invent 2023 - Capacity, availability, cost efficiency: Pick three](https://www.youtube.com/watch?v=E0dYLPXrX_w)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 未使用アセットの創出と維持の停止
ワークロードの未使用アセットを廃止して、需要をサポートするために必要なクラウドリソース数を削減し、無駄を最小限に抑えます。
**一般的なアンチパターン:**
+ アプリケーションを分析して冗長または不要になったアセットを見つけていない。
+ 冗長または不要になったアセットを削除していない。
**このベストプラクティスを活用するメリット:** 未使用アセットを削除すると、リソースが解放され、ワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
未使用のアセットは、ストレージ容量やコンピューティングパワーなどのクラウドリソースを消費します。このようなアセットを特定して排除することで、これらのリソースを解放できるため、クラウドアーキテクチャの効率性が向上します。事前コンパイル済みのレポート、データセット、静的イメージなどのアプリケーションアセットと、アセットのアクセスパターンを定期的に分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。このような冗長アセットを削除して、ワークロード内のリソースの無駄を削減します。
### 実装手順
+ **棚卸しを実施する:** 包括的な棚卸しを実施して、ワークロード内のすべてのアセットを特定します。
+ **使用率を分析する:** モニタリングツールを使用して、不要になった静的アセットを特定します。
+ **未使用のアセットを削除する:** 不要になったアセットを削除する計画を立てます。
+ アセットを削除する前に、削除によるアーキテクチャに対する影響を評価します。
+ 重複して生成されるアセットは統合し、冗長プロセスを排除します。
+ 不要なアセットをこれ以上生成および保存しないようにアプリケーションを更新します。
+ **サードパーティーに伝達する:** 不要になったアセットをお客様に代わって管理しているサードパーティーに、アセットの生成と保存を止めるように指示します。冗長アセットを統合するように依頼します。
+ **ライフサイクルポリシーを使用する:** ライフサイクルポリシーを使用して、未使用のアセットを自動的に削除します。
+ [Amazon S3 ライフサイクル](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を使用すると、オブジェクトのライフサイクル全体を管理できます。
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html) を使用して、EBS スナップショットと Amazon EBS-backed AMI の作成、保持、削除を自動化できます。
+ **確認と最適化をする:** ワークロードを定期的に見直して、未使用のアセットを特定し削除します。
## リソース
**関連ドキュメント:**
+ [サステナビリティのための AWS インフラストラクチャの最適化、パート II : ストレージ](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
+ [AWS アカウントで不要になったアクティブなリソースを終了するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**関連動画:**
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Preserving and maximizing the value of digital media assets using Amazon S3 ](https://www.youtube.com/watch?v=8OI0Uu-YvD8)
+ [AWS re:Invent 2023 - Optimize costs in your multi-account environments](https://www.youtube.com/watch?v=ie_Mqb-eC4A)
# SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する
ワークロード向けにネットワークトラフィックが経由しなければならない距離を削減できるクラウドのロケーションとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。
**一般的なアンチパターン:**
+ 自分の場所に基づいてワークロードのリージョンを選択する。
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
+ すべてのトラフィックが既存のデータセンターを通過する。
**このベストプラクティスを活用するメリット:** ワークロードをユーザーの近くに配置することで、ネットワーク上のデータ移動を減らし、環境負荷を低減しながら、最小限のレイテンシーを実現します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS クラウドインフラストラクチャは、リージョン、アベイラビリティーゾーン、プレイスメントグループなどのロケーションオプション、そして [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) などのエッジロケーションから構成されます。これらのロケーションオプションは、アプリケーションコンポーネント、クラウドサービス、エッジネットワーク、オンプレミスのデータセンター間の接続を維持する役割を担っています。
ワークロードのネットワークアクセスパターンを分析して、このようなクラウドロケーションオプションの使用方法や、ネットワークトラフィックが経由する距離を減らす方法を特定します。
## 実装手順
+ ワークロードのネットワークアクセスパターンを分析して、ユーザーがアプリケーションをどのように使用しているかを特定します。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) や [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) などのモニタリングツールを使用して、ネットワークアクティビティに関するデータを収集します。
+ データを分析して、ネットワークアクセスパターンを特定します。
+ 以下の主な要素に基づいて、ワークロードのデプロイに適切なリージョンを選択します。
+ **サステナビリティの目標: **「[リージョンの選択](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html)」を参照してください。
+ **データがある場所:** 大量のデータを使用するアプリケーション (ビッグデータや機械学習など) では、アプリケーションコードをできるだけデータの近くで実行してください。
+ **ユーザーがいる場所:** ユーザー向けアプリケーションの場合は、ワークロードのユーザーに近いリージョン (1 つまたは複数) を選択します。
+ **その他の制約**:「[ワークロードのリージョンを選択する際の考慮事項](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)」で説明されているように、コストやコンプライアンスなどの制約を考慮します。
+ ローカルキャッシュまたは [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/)を頻繁に使用するデータに使用すると、パフォーマンスを向上させ、データ移動を削減し、環境への影響を低減できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ 以下のように、ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ 接続プーリングを使用して、接続の再利用を可能にし、必要なリソースを削減します。
+ 永続的な接続や同期更新に依存しない分散されたデータストアを使用して、リージョンのユーザーに一貫性のあるサービスを提供します。
+ 事前にプロビジョンされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有します。
## リソース
**関連ドキュメント:**
+ [サステナビリティのための AWS インフラストラクチャの最適化、パート III : ネットワーキング](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/)
+ [AWS グローバルインフラストラクチャ ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones および AWS Outposts などエッジワークロードに適したテクノロジーの選択 ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ プレイスメントグループ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [AWS Local Zones ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
**関連動画:**
+ [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ Scaling network performance on next-gen Amazon EC2 instances ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
+ [AWS Local Zones 解説動画 ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: 概要と機能紹介 ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2023 - エッジワークロードとオンプレミスワークロードの移行戦略 ](https://www.youtube.com/watch?v=4wUXzYNLvTw)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020 - AWS Wavelength: Run apps with ultra-low latency at 5G edge ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Amazon CloudFront で低レイテンシーウェブサイトを構築 ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - AWS Global Accelerator でパフォーマンスと可用性を向上](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - AWS でグローバルなワイドエリアネットワークを構築](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020 - Amazon Route 53 でグローバルなトラフィック管理を実現 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
**関連する例:**
+ [AWS ネットワーキングワークショップ](https://catalog.workshops.aws/networking/en-US)
+ [持続可能性を考慮したアーキテクチャ - ネットワーク間のデータ移動を最小限に抑える](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する
チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら環境の持続可能性への影響を最小限に抑えます。
**一般的なアンチパターン:**
+ クラウドアプリケーションの全体的な効率性に関して、チームメンバーが使用するデバイスの影響を無視する。
+ チームメンバーが使用するリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** チームメンバーリソースを最適化すると、クラウド対応アプリケーションの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
サービスを利用するためにチームメンバーが使用するリソース、その予想ライフサイクル、および経営と持続可能性に対する影響を理解します。これらのリソースを最適化する戦略を策定します。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高性能な単一ユーザーのシステムで行うのではなく、使用率の高いスケーラブルなインフラストラクチャで行います。
### 実装手順
+ **省エネ型ワークステーションを使用する:** チームメンバーに省エネ型ワークステーションと周辺機器を支給します。これらのデバイスで効率的な電源管理機能 (低電力モードなど) を使用して、エネルギー使用量を削減します。
+ **仮想化を利用する:** 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードの必要性とデバイス要件を軽減します。
+ **リモートコラボレーションを奨励する:** [Amazon Chime](https://aws.amazon.com/chime/) および [AWS Wickr](https://aws.amazon.com/wickr/) などのリモートコラボレーションツールを使用するようチームメンバーに奨励して、出張の必要性や出張に関連する炭素排出量を削減します。
+ **エネルギー効率が優れたソフトウェアを使用する:** 不要な機能やプロセスを削除または無効にして、チームメンバーにエネルギー効率が優れたソフトウェアを支給します。
+ **ライフサイクルを管理する:** デバイスのライフサイクルにおけるプロセスやシステムの影響を評価し、ビジネス要件を満たしながらデバイスを交換する必要性を最小限にするソリューションを選択します。ワークステーションまたはソフトウェアの定期的なメンテナンスと更新を行って、効率性を維持、改善します。
+ **リモートデバイス管理を実施する:** デバイスのリモート管理を実装して出張を少なくします。
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) は、AWS やオンプレミスで実行されているノードをリモートで管理できる、統合ユーザーインターフェイス (UI) エクスペリエンスです。
## リソース
**関連ドキュメント:**
+ [Amazon WorkSpaces とは](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [ Amazon WorkSpaces のコストオプティマイザー ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**関連動画:**
+ [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE)
# SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
バッファリングやスロットリングは、需要曲線を平坦化し、ワークロードに必要なプロビジョンドキャパシティを削減します。
**一般的なアンチパターン:**
+ 即時対応が不要なクライアントのリクエストを即時処理している。
+ クライアントのリクエストの要件を分析していない。
**このベストプラクティスを活用するメリット:** 需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減できます。プロビジョンドキャパシティが削減されると、エネルギーの消費量が少なくなり、環境への影響が小さくなります。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ワークロードの需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減し、環境への影響を減らすことができます。以下の図に示す需要曲線を持つワークロードがあるとします。このワークロードには 2 つのピークがあり、これらのピークを処理するために、オレンジの線で示されるリソース容量がプロビジョニングされます。このワークロードで使用されるリソースとエネルギーは需要曲線の下の領域ではなく、プロビジョンドキャパシティのラインの下の領域で示されます。これら 2 つのピークを処理するには、プロビジョンドキャパシティが必要であるためです。
![\[高プロビジョニング容量を必要とする 2 つの異なるピークを持つプロビジョニングされた容量の波形。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/provisioned-capacity-1.png)
バッファリングやスロットリングを使用して需要曲線を変化させ、ピークをならすことができます。つまり、プロビジョンドキャパシティや消費されるエネルギーを減らすことができます。クライアントが再試行を実行できるときはスロットリングを実装します。バッファリングを実装して、リクエストを保存し、処理を延期できます。
![\[バッファリングまたはスロットリングを使用して作成された、平坦化されたピークを持つワークロードを示すウェーブフォーム図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/provisioned-capacity-2.png)
**実装手順**
+ クライアントのリクエストを分析して、それらに応答する方法を決定します。考慮すべき課題は以下のとおりです。
+ このリクエストは非同期で処理できるか?
+ クライアントは再試行できるか?
+ クライアントが再試行できる場合、スロットリングを実装できます。これにより、現在リクエストを処理できない場合は、後で再試行する必要があることが送信元に通知されます。
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/) を使用するとスロットリングを実装できます。
+ 再試行できないクライアントの場合は、バッファを実装して需要曲線を平坦化する必要があります。バッファはリクエスト処理を延期し、アプリケーションが異なる動作速度で実行されていても効果的に通信できるようにします。バッファベースのアプローチでは、キューまたはストリーミングを使用して、プロデューサーからメッセージを受信します。メッセージはコンシューマーによって読み取られ、処理されるため、コンシューマーのビジネス要件を満たせる動作速度でメッセージを実行できます。
+ [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) は、単独のコンシューマーが個別のメッセージを読むことができるキューを提供するマネージドサービスです。
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/) は、多数のコンシューマーが同じメッセージを読み取ることができるストリームを提供します。
+ 全体的な需要、変化率、および要求される応答時間を分析して、必要なスロットルまたはバッファのサイズを適正化します。
## リソース
**関連ドキュメント:**
+ [Amazon SQS の開始方法](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ キューとメッセージを使用したアプリケーション統合 ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
+ [ ワークロードでの API スロットリングの管理と監視 ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ 階層化されたマルチテナント REST API を API Gateway を使用して大規模にスロットリング ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ キューとメッセージを使用したアプリケーション統合 ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
**関連動画:**
+ [AWS re:Invent 2022 - Application integration patterns for microservices ](https://www.youtube.com/watch?v=GoBOivyE7PY)
+ [AWS re:Invent 2023 – Smart savings: Amazon EC2 cost-optimization strategies ](https://www.youtube.com/watch?v=_AHPbxzIGV0)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)
# ソフトウェアとアーキテクチャ
**Topics**
+ [SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?](sus-03.md)
# SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは廃止します。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客様のサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。
**Topics**
+ [SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する](sus_sus_software_a2.md)
+ [SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする](sus_sus_software_a3.md)
+ [SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する](sus_sus_software_a4.md)
+ [SUS03-BP04 デバイスや機器への影響を最適化する](sus_sus_software_a5.md)
+ [SUS03-BP05 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する](sus_sus_software_a6.md)
# SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する
キュー駆動型などの効率的なソフトウェアおよびアーキテクチャパターンを使用して、デプロイされたリソースの使用率を一貫して高く維持します。
**一般的なアンチパターン:**
+ 予期せぬ需要の急増に対応するために、クラウドワークロードのリソースを過剰にプロビジョニングしています。
+ お使いのアーキテクチャでは、メッセージングコンポーネントによって非同期メッセージの送信者と受信者が切り離されていません。
**このベストプラクティスを活用するメリット:**
+ 効率的なソフトウェアとアーキテクチャのパターンは、ワークロード内の未使用リソースを最小限に抑え、全体的な効率を向上させます。
+ 非同期メッセージの受信とは無関係に処理をスケールできます。
+ メッセージングコンポーネントを使用することで、可用性要件が緩和され、より少ないリソースで対応できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[イベント駆動型](https://aws.amazon.com/event-driven-architecture/)アーキテクチャなどの効率的なアーキテクチャパターンを使用すると、コンポーネントの使用率が均等になり、ワークロードのオーバープロビジョニングを抑えます。効率的なアーキテクチャパターンを使用することで、時間の経過に伴う需要の変化により、使用されずにアイドル状態になるリソースを最小限に抑えることができます。
ワークロードコンポーネントの要件を理解し、リソース全体の利用率を高めるアーキテクチャパターンを採用します。不要になったコンポーネントは廃止します。
### 実装手順
+ ワークロードの需要を分析し、それらに対応する方法を決定します。
+ 同期応答を必要としないリクエストやジョブには、キュー駆動型アーキテクチャと自動スケーリングワーカーを使用して使用率を最大化します。キュー駆動型アーキテクチャを検討する場合の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_software_a2.html)
+ いつでも処理できるリクエストやジョブについては、スケジューリングメカニズムを利用してジョブをバッチ処理することで効率化を図ります。AWS でのスケジューリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_software_a2.html)
+ アーキテクチャでポーリングやウェブフックのメカニズムを使用している場合、それらをイベントに置き換えます。[イベント駆動型アーキテクチャを使用して](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html)、高効率のワークロードを構築します。
+ [AWS でサーバーレス](https://aws.amazon.com/serverless/)を活用して、過剰にプロビジョニングされたインフラストラクチャを排除します。
+ アーキテクチャの個別のコンポーネントの適切なサイズを設定し、リソースが入力を待ってアイドル状態になるのを防ぎます。
+ または [AWS Cost Explorer または [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) で適切なサイズ設定に関する推奨事項](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-rightsizing.html)を使用して、適切なサイズ設定の機会を特定できます。
+ 詳細については、「[適切なサイジング: ワークロードに適したインスタンスのプロビジョニング](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/cost-optimization-right-sizing.html)」を参照してください。
## リソース
**関連ドキュメント:**
+ [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)
+ [Amazon SQS での AWS Lambda の使用](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)
+ [ REST API を使用した非同期ワークフローの管理 ](https://aws.amazon.com/blogs/architecture/managing-asynchronous-workflows-with-a-rest-api/)
**関連動画:**
+ [AWS re:Invent 2023 - Navigating the journey to serverless event-driven architecture ](https://www.youtube.com/watch?v=hvGuqHp051c)
+ [AWS re:Invent 2023 - Using serverless for event-driven architecture & domain-driven design ](https://www.youtube.com/watch?v=3foMZJSPMI4)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge ](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [ Asynchronous Message Patterns \$1 AWS Events ](https://www.youtube.com/watch?v=-yJqBuwouZ4)
**関連する例:**
+ [AWS Graviton プロセッサと Amazon EC2 スポットインスタンスを使用したイベント駆動型アーキテクチャ ](https://catalog.workshops.aws/well-architected-sustainability/en-US/2-software-and-architecture/event-driven-architecture-with-graviton-spot)
# SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする
未使用のコンポーネントや不要になったコンポーネントを削除し、使用率の低いコンポーネントはリファクタリングして、ワークロードの無駄を最小化します。
**一般的なアンチパターン:**
+ ワークロードの個別のコンポーネントの使用率レベルを定期的に確認していない。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) など AWS のサイズ最適化ツールからのレコメンデーションを確認しない。
**このベストプラクティスを活用するメリット:** 未使用のコンポーネントを削除すると、無駄が最小限に抑えられ、クラウドワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドワークロードで未使用または十分に活用されていないコンポーネントは、不要なコンピューティング、ストレージ、またはネットワークリソースを消費します。これらのコンポーネントを削除またはリファクタリングして、無駄を直接削減し、クラウドワークロードの全体的な効率を向上させます。これは、需要の変化や新しいクラウドサービスのリリースに伴う、反復的な改善プロセスです。例えば、[AWS Lambda](https://docs.aws.amazon.com/lambda/) 関数のランタイムが大幅に低下すると、メモリサイズを小さくする必要があることを示す指標になります。また、AWS で新しいサービスや機能がリリースされると、ワークロードに最適なサービスやアーキテクチャが変化する可能性があります。
ワークロードのアクティビティを継続的にモニタして、個別のコンポーネントの使用率レベルを改善する機会を見逃さないようにします。アイドルのコンポーネントを削除しアクティビティのサイズ最適化を行って、最小限のクラウドリソースでビジネス要件を満たすようにします。
### 実装手順
+ **AWS リソースのインベントリ作成:** AWSリソースのインベントリを作成します。AWS では、[AWS Resource Explorer](https://docs.aws.amazon.com/resource-explorer/latest/userguide/welcome.html) を有効にして AWS リソースを探索および整理できます。詳細については、「[AWS re:Invent 2022 - How to manage resources and applications at scale on AWS](https://www.youtube.com/watch?v=bbgUnKq6PAU)」を参照してください。
+ **使用率のモニタリング:** ワークロードの重要なコンポーネント ([Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) メトリクスの CPU 使用率、メモリ使用率、ネットワークスループットなど) の使用率メトリクスをモニタリング、キャプチャします。
+ **未使用コンポーネントの特定:** アーキテクチャ内の未使用のコンポーネントや使用率の低いコンポーネントを特定します。
+ 安定したワークロードの場合は、[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) などの AWS サイズ最適化ツールを定期的にチェックして、アイドル状態、未使用、使用率の低いコンポーネントを特定します。
+ 一次的なワークロードについては、使用率メトリクスを評価して、アイドル、未使用、または使用率の低いコンポーネントを特定します。
+ **不要コンポーネントの削除:** 不要になったコンポーネントや関連アセット (Amazon ECR イメージなど) を廃止します。
+ [ Amazon ECR における未使用イメージの自動クリーンアップ ](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/)
+ [AWS Config および AWS Systems Manager を使用して未使用の Amazon Elastic Block Store (Amazon EBS) ボリュームを削除](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/delete-unused-amazon-elastic-block-store-amazon-ebs-volumes-by-using-aws-config-and-aws-systems-manager.html)
+ **低使用率コンポーネントのリファクタリング:** 使用率の低いコンポーネントをリファクタリングまたは他のリソースと統合して、使用効率を改善します。例えば、使用率の低い個別のインスタンスでデータベースを実行する代わりに、1 つの [Amazon RDS](https://aws.amazon.com/rds/) データベースインスタンスで複数の小さなデータベースをプロビジョニングできます。
+ **改善の評価:** ワークロードによってプロビジョニングされる、[作業の単位を完了するために必要なリソース](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)を理解します。この情報を使用して、コンポーネントを削除またはリファクタリングすることによって達成された改善を評価します。
+ [ 持続可能性プロキシメトリクスを使用してクラウド効率を測定して追跡する、パート I: プロキシメトリクスとは](https://aws.amazon.com/blogs/aws-cloud-financial-management/measure-and-track-cloud-efficiency-with-sustainability-proxy-metrics-part-i-what-are-proxy-metrics/)
+ [ 持続可能性プロキシメトリクスを使用してクラウド効率を測定して追跡する、パート II: メトリクスパイプラインの確立](https://aws.amazon.com/blogs/aws-cloud-financial-management/measure-and-track-cloud-efficiency-with-sustainability-proxy-metrics-part-ii-establish-a-metrics-pipeline/)
## リソース
**関連ドキュメント:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ 適切なサイジング: ワークロードに適したインスタンスのプロビジョニング ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/cost-optimization-right-sizing.html)
+ [ 適切なサイズ設定の推奨事項によるコストの最適化 ](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-rightsizing.html)
**関連動画:**
+ [AWS re:Invent 2023 - Capacity, availability, cost efficiency: Pick three](https://www.youtube.com/watch?v=E0dYLPXrX_w)
# SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する
アーキテクチャの異なるコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。
**一般的なアンチパターン:**
+ リソースの使用量に対してコードを最適化しない。
+ 通常、パフォーマンスの問題にはリソースを増やすことで対処している。
+ コードの見直しおよび開発プロセスで、パフォーマンスの変化を追跡していない。
**このベストプラクティスを活用するメリット:** 効率的なコードを使用すると、リソースの使用量が最小限に抑えられ、パフォーマンスが向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドに構築されたアプリケーションのコードを含むあらゆる機能領域を精査して、そのリソース使用量とパフォーマンスを最適化することが重要です。ビルド環境および本稼働環境でワークロードのパフォーマンスを継続的にモニタし、リソースの使用量が特に高いコードスニペットを改善する機会を特定します。定期的な見直しプロセスを導入して、コードの中でリソースを効率的に使用していないバグまたはアンチパターンを特定します。自分のユースケースに合わせて、同じ結果になるシンプルで効率的なアルゴリズムを活用します。
## 実装手順
+ **効率的なプログラミング言語を使用する:** ワークロードに効率的なオペレーティングシステムとプログラミング言語を使用します。エネルギー効率に優れたプログラム言語 (Rust など) の詳細については、「[Rust での持続可能性](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/)」を参照してください。
+ **AI コーディングコンパニオンを使用する:** [Amazon Q Developer](https://aws.amazon.com/q/developer/) などの AI コーディングコンパニオンを使用して、コードの効率的な記述を検討します。
+ **コードレビューを自動化する:** ワークロードを開発する際に、自動化されたコードレビュープロセスを導入して、品質を向上させ、バグやアンチパターンを特定します。
+ [Amazon CodeGuru Reviewer でのコードレビューの自動化](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Amazon CodeGuru での同時実行バグの検出 ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
+ [ Amazon CodeGuru を使用して Python アプリケーションのコード品質を向上させる ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+ **コードプロファイラーを使用する:** コードプロファイラーを使用して、時間またはリソースを最も多く使用するコードの領域を特定し、最適化の対象とします。
+ [ Amazon CodeGuru Profiler を使用して組織のカーボンフットプリントを削減する ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
+ [ Amazon CodeGuru Profiler を使用して Java アプリケーションのメモリ使用量を理解する ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
+ [ Amazon CodeGuru Profiler を使用してカスタマーエクスペリエンスを改善しコストを削減する ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+ **モニタリングと最適化をする:** 継続的なモニタリングリソースを使用して、リソース要件が高い、または最適ではない構成のコンポーネントを特定します。
+ コンピューティング負荷が高いアルゴリズムを、結果が同じであり、よりシンプルでより効率的なバージョンに置き換えます。
+ ソートや書式設定などの不要なコードを削除します。
+ **コードのリファクタリングまたは変換を使用する:** アプリケーションのメンテナンスとアップグレードに [Amazon Q コード変換](https://aws.amazon.com/q/aws/code-transformation/)を検討します。
+ [ Amazon Q コード変換による言語バージョンのアップグレード ](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/code-transformation.html)
+ [AWS re:Invent 2023 - Amazon Q コード変換を使用してアプリケーションのアップグレードとメンテナンスを自動化する ](https://www.youtube.com/watch?v=LY76tak6Z1E)
## リソース
**関連ドキュメント:**
+ [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)
+ [AWS の構築ツールの AWS SDK](https://aws.amazon.com/tools/)
**関連動画:**
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru ](https://www.youtube.com/watch?v=OD8H63C0E0I)
# SUS03-BP04 デバイスや機器への影響を最適化する
アーキテクチャで使用されているデバイスや機器を理解し、それらの使用量を削減する戦略を使用します。これにより、環境に対するクラウドワークロードの全体的な影響を最小化できます。
**一般的なアンチパターン:**
+ 顧客によって使用されるデバイスの環境に対する影響を無視する。
+ 顧客によって使用されるリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** 顧客のデバイス用に最適化されたソフトウェアパターンと機能を実装することで、クラウドワークロードの全体的な環境への影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
顧客のデバイスに合わせて最適化されたソフトウェアパターンや機能を実装することで、複数の方法で環境に対する影響を削減できます。
+ 下位互換性がある新機能を実装することで、ハードウェアの置換を削減できます。
+ アプリケーションを最適化してデバイスで効率的に実行できるようにすることで、エネルギー消費を削減し、バッテリー寿命を延ばすことができます (バッテリー駆動の場合)。
+ また、アプリケーションをデバイスに合わせて最適化すると、ネットワーク経由のデータ転送も削減できます。
アーキテクチャで使用されているデバイスや機器、それらの予想ライフサイクル、およびそれらコンポーネントを置換した場合の影響を理解します。デバイスのエネルギー消費、顧客がデバイスを置換する必要性、およびデバイスを手動でアップグレードする必要性を最小限にできるソフトウェアパターンや機能を実装します。
### 実装手順
+ **棚卸しを実施する:** アーキテクチャで使用されているデバイスをリストアップします。デバイスには、モバイル、タブレット、IoT デバイス、スマートライト、さらに工場のスマートデバイスも含まれます。
+ **エネルギー効率が優れたデバイスを使用する:** エネルギー効率が優れたデバイスをアーキテクチャで使用することを検討してください。デバイスの電源管理設定を使用して、使用していないときは低電力モードに切り替えます。
+ **効率的なアプリケーションを実行する:** デバイスで実行されているアプリケーションを最適化します。
+ バックグラウンドでのタスク実行などの戦略を使用して、エネルギーの消費量を削減します。
+ ペイロードを構築する際にネットワーク帯域幅とレイテンシーを考慮し、低帯域幅、高レイテンシーのリンクでもアプリケーションが問題なく動作できる能力を実装します。
+ ペイロードやファイルを、デバイスが必要とする最適な形式に変換します。例えば、[Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) または [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) を使用して、サイズが大きい高品質のデジタルメディアファイルを、ユーザーがモバイルデバイス、タブレット、ウェブブラウザ、およびネット接続したテレビで再生できる形式に変換できます。
+ コンピューティングの負荷が高いアクティビティはサーバー側 (画像のレンダリングなど) で実行、またはアプリケーションストリーミングを使用して、古い型のデバイスでのユーザーエクスペリエンスを改善します。
+ 特にインタラクティブセッションの場合は、出力を分割してページ番号を付け、ペイロードを管理しローカルストレージの要件を制限します。
+ **サプライヤーを関与させる:** 持続可能な資材を使用し、サプライチェーンと環境認定に透明性を持ったデバイスサプライヤーと連携します。
+ **無線通信 (OTA) アップデートを使用する:** 自動化された無線通信 (OTA) の仕組みを使用して、1 つ以上のデバイスに更新をデプロイします。
+ [CI/CD パイプライン](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/)を使用してモバイルアプリケーションを更新できます。
+ [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) を使用して、接続されたデバイスを大規模にリモートで管理できます。
+ **マネージド型 Device Farm を使用する:** 新機能や更新をテストするには、ハードウェアの代表的なセットを備えたマネージド型 Device Farm を使用して、サポート対象のデバイスを拡大する開発を繰り返します。詳細については、以下を参照してください。[SUS06-BP05 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md)
+ **モニタリングと改善を続ける:** デバイスのエネルギー使用量を追跡して、改善が必要な分野を特定します。新しいテクノロジーやベストプラクティスを活用して、これらのデバイスの環境に配慮した取り組みを強化します。
## リソース
**関連ドキュメント:**
+ [AWS Device Farm とは](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [WorkSpaces アプリケーションドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [ FreeRTOS 実行デバイスでファームウェアを更新するための OTA チュートリアル ](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)
+ [ 環境持続可能性のための IoT デバイスの最適化 ](https://aws.amazon.com/blogs/architecture/optimizing-your-iot-devices-for-environmental-sustainability/)
**関連動画:**
+ [AWS re:Invent 2023 - Improve your mobile and web app quality using AWS Device Farm](https://www.youtube.com/watch?v=__93Tm0YCRg)
# SUS03-BP05 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する
データがどのようにワークロード内で使用されているか、ユーザーに消費されているか、転送されているか、保存されているかを理解します。データへのアクセスと保存を最適にサポートするソフトウェアパターンとアーキテクチャを使用して、ワークロードのサポートに必要なコンピューティング、ネットワーク、ストレージのリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
+ アーキテクチャはデータアクセスの高バーストの可能性をサポートしているが、その結果リソースがほとんどの時間でアイドルのままになる。
**このベストプラクティスを活用するメリット:** データアクセスとストレージパターンに基づいてアーキテクチャを選択、最適化すると、開発の複雑さが軽減され、全体的な使用率が向上します。グローバルテーブル、データのパーティショニング、キャッシュをいつ使用するべきかを理解することで、運用上の諸経費を減らし、ワークロードのニーズに応じてスケールできるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードの長期的な持続可能性を向上させるには、ワークロードのデータアクセスとストレージ特性をサポートするアーキテクチャパターンを使用します。これらのパターンは、データを効率的に取得して処理するのに役立ちます。例えば、独自の分析ユースケースに最適化された専用サービスを使用して、AWS で[最新のデータアーキテクチャ](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/)を使用します。このようなアーキテクチャパターンを使用すると、データ処理が効率的になり、リソースの使用量を削減できます。
### 実装手順
+ **データ特性の理解:** データの特性やアクセスパターンを分析して、クラウドリソースに最適な構成を特定します。考慮する主な特徴には次のものがあります。
+ **データ型:** 構造、半構造、非構造
+ **データの増加:** 制限あり、無制限
+ **データ保存期間:** 永続、一時的、一過性
+ **アクセスパターン:** 読み取りまたは書き取り、更新頻度、急増、安定
+ **最適なアーキテクチャパターンの使用:** データアクセスとストレージパターンのサポートが最も優れたアーキテクチャパターンを使用します。
+ [ データ永続化を有効にするパターン ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/enabling-patterns.html)
+ [ Let’s Architect\$1 モダンデータアーキテクチャ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
+ [AWS のデータベース: 特定のジョブに最適なデータベースを ](https://www.youtube.com/watch?v=-pb-DkD6cWg)
+ **専用サービスの使用:** 目的に合ったテクノロジーを使用します。
+ 圧縮データをネイティブに操作するテクノロジーを使用します。
+ [ Athena でサポートされる圧縮ファイル形式 ](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [ での ETL 入力および出力の形式オプションAWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [ Amazon Redshift を使用して Simple Storage Service (Amazon S3) から圧縮されたデータファイルをロードする ](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ アーキテクチャでのデータ処理に専用の[分析サービス](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a)を使用します。AWS 専用分析サービスの詳細については、「[AWS re:Invent 2022 - Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)」を参照してください。
+ 主要なクエリパターンに対して最も優れたサポートをするデータベースエンジンを使用します。データベースインデックスを管理して、効率的なクエリを実行します。詳細については、「[AWS データベース](https://aws.amazon.com/products/databases/)」および「[AWS re:Invent 2022 - Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)」を参照してください。
+ **データ移動を最小限にする:** アーキテクチャで消費されるネットワーク容量が削減できるネットワークプロトコルを選択します。
## リソース
**関連ドキュメント:**
+ [列データ形式の 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)
+ [列指向形式に変換して Amazon Athena でのクエリパフォーマンスを改善する](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.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)
+ [ Amazon S3 Intelligent-Tiering ストレージクラス](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)
+ [ Amazon DynamoDB を使用して CQRS イベントストアを構築する ](https://aws.amazon.com/blogs/database/build-a-cqrs-event-store-with-amazon-dynamodb/)
**関連動画:**
+ [AWS re:Invent 2022 - Building data mesh architectures on AWS](https://www.youtube.com/watch?v=nGRvlobeM_U)
+ [AWS re:Invent 2023 - Deep dive into Amazon Aurora and its innovations](https://www.youtube.com/watch?v=je6GCOZ22lI)
+ [AWS re:Invent 2023 - Improve Amazon EBS efficiency and be more cost-efficient ](https://www.youtube.com/watch?v=7-CB02rqiuw)
+ [AWS re:Invent 2023 - Optimizing storage price and performance with Amazon S3 ](https://www.youtube.com/watch?v=RxgYNrXPOLw)
+ [AWS re:Invent 2023 - Building and optimizing a data lake on Amazon S3](https://www.youtube.com/watch?v=mpQa_Zm1xW8)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge ](https://www.youtube.com/watch?v=6X4lSPkn4ps)
**関連する例:**
+ [AWS 目的別データベースワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/93f64257-52be-4c12-a95b-c0a1ff3b7e2b/en-US)
+ [AWS モダンデータアーキテクチャ Immersion Day](https://catalog.us-east-1.prod.workshops.aws/workshops/32f3e732-d67d-4c63-b967-c8c5eabd9ebf/en-US)
+ [ でのデータメッシュの構築AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/23e6326b-58ee-4ab0-9bc7-3c8d730eb851/en-US)
# データ
**Topics**
+ [SUS 4 データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか?](sus-04.md)
# SUS 4 データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか?
データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とデータの使用方法をより効果的にサポートするストレージテクノロジーと設定を使用します。必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし、データが不要になった場合は削除します。
**Topics**
+ [SUS04-BP01 データ分類ポリシーを実装する](sus_sus_data_a2.md)
+ [SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する](sus_sus_data_a3.md)
+ [SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する](sus_sus_data_a4.md)
+ [SUS04-BP04 伸縮性とオートメーションを使用してブロックストレージまたはファイルシステムを拡張する](sus_sus_data_a5.md)
+ [SUS04-BP05 不要なデータや重複するデータを削除する](sus_sus_data_a6.md)
+ [SUS04-BP06 共有ファイルシステムまたはストレージを使用して共通データにアクセスする](sus_sus_data_a7.md)
+ [SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える](sus_sus_data_a8.md)
+ [SUS04-BP08 データは再作成が難しい場合にのみバックアップする](sus_sus_data_a9.md)
# SUS04-BP01 データ分類ポリシーを実装する
データを分類してビジネス成果に対する重要度を理解し、データの保存にエネルギー効率の高い適切なストレージ層を選択します。
**一般的なアンチパターン:**
+ 処理または保存されているデータアセットの中で、類似の特徴 (機密度、ビジネス上の重要度、規制要件など) を持つものを特定していない。
+ データアセットのインベントリにデータカタログを実装していない。
**このベストプラクティスを活用するメリット:** データ分類ポリシーを実装すると、データの最も省エネ的なストレージ階層を決定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
データ分類には、組織が所有または運用する情報システムで処理中または保存中のデータのタイプの特定を含めます。また、データの重要度と、データの侵害、損失、誤使用によって考えられる影響についても検討します。
データ分類ポリシーは、データを使用する流れから逆算して実装し、あるデータセットの組織の運営における重要度のレベルを考慮に入れて、カテゴリ分けのスキームを作成します。
### 実装手順
+ **データインベントリを実施する:** ワークロードに存在するさまざまなデータタイプのインベントリを実施します。
+ **データをグループ分けする:** 組織に対するリスクに基づいて、データの重要度、機密度、整合性、可用性を判断します。このような要件を使用して、導入するデータ分類層のいずれかにデータをグループ分けします。例として、「[データを分類してスタートアップ企業を保護するための 4 つの簡単なステップ](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/)」を参照してください。
+ **データ分類レベルとポリシーを定義する:** データグループごとに、データ分類レベル (パブリックポリシーや機密ポリシーなど) と処理ポリシーを定義します。分類にそってデータにタグを付けます。データ分類カテゴリの詳細については、データ分類に関するホワイトペーパーを参照してください。
+ **定期的にレビューする:** タグ付けされていないデータや分類されていないデータがないか、環境を定期的にレビューして監査します。オートメーションを使用してこのデータを特定し、データを適切に分類してタグ付けします。例として、[「AWS Glue でのデータ検出とカタログ化](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)」を参照してください。
+ **データカタログを作成する:** 監査およびガバナンス機能があるデータカタログを作成します。
+ **文書化する:** 各データクラスのデータ分類ポリシーと処理手順を文書化します。
## リソース
**関連ドキュメント:**
+ [データ分類に AWS クラウドを活用](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html)
+ [AWS Organizations Tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
**関連動画:**
+ [AWS re:Invent 2022 - Enabling agility with data governance on AWS](https://www.youtube.com/watch?v=vznDgJkoH7k)
+ [AWS re:Invent 2023 - Data protection and resilience with AWS storage ](https://www.youtube.com/watch?v=rdG8JV3Fhk4)
# SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する
データへのアクセス方法や保存方法を最も良くサポートするストレージ技術を使用し、ワークロードをサポートしながらプロビジョニングされるリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
**このベストプラクティスを活用するメリット:** データのアクセスとストレージのパターンに基づいてストレージ技術を選択し最適化すると、ビジネスニーズを満たすために必要なクラウドリソースが削減し、クラウドワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アクセスパターンに最適なストレージソリューションを選択するか、パフォーマンス効率を最大にするためにストレージソリューションに合わせてアクセスパターンを変更することを検討してください。
### 実装手順
+ **データとアクセスパターンの特徴を評価する**: データの特徴とアクセスパターンを評価し、ストレージのニーズにおける主な特徴を収集します。考慮する主な特徴には次のものがあります。
+ **データ型:** 構造、半構造、非構造
+ **データの増加:** 制限あり、無制限
+ **データ保存期間:** 永続、一時的、一過性
+ **アクセスパターン:** 読み取りまたは書き取り、頻度、急増、安定
+ **適切なストレージ技術を選択する:** データの特徴とアクセスパターンをサポートする適切なストレージ技術にデータを移行します。AWS ストレージ技術とその主な特徴を例としていくつか挙げます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_data_a3.html)
+ **ストレージ割当を自動化する:** Amazon EBS や Amazon FSx など固定サイズのストレージシステムの場合、利用可能なストレージ容量をモニタリングして、しきい値に達した場合のストレージ割り当てを自動化します。Amazon CloudWatch を活用して、Amazon [EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) と [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html) のさまざまなメトリクスを収集および分析できます。
+ **適切なストレージクラスを選択する:** データに適したストレージクラスを選択します。
+ Amazon S3 ストレージクラスはオブジェクトレベルで設定できます。1 つのバケットには、すべてのストレージクラスに保存されているオブジェクトを含めることができます。
+ [Amazon S3 ライフサイクルポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を使用して、ストレージクラス間でオブジェクトを自動的に移動したり、データを削除したりすることができ、アプリケーションに変更を必要としません。一般的に、このようなストレージメカニズムを考える場合、リソース効率、アクセスのレイテンシー、信頼性の間でトレードオフを行う必要があります。
## リソース
**関連ドキュメント:**
+ [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 EBS I/O の特性](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Amazon S3 ストレージクラスを使用する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [Amazon Glacier とは](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**関連動画:**
+ [AWS re:Invent 2023 - Improve Amazon EBS efficiency and be more cost-efficient ](https://www.youtube.com/watch?v=7-CB02rqiuw)
+ [AWS re:Invent 2023 - Optimizing storage price and performance with Amazon S3 ](https://www.youtube.com/watch?v=RxgYNrXPOLw)
+ [AWS re:Invent 2023 - Building and optimizing a data lake on Amazon S3](https://www.youtube.com/watch?v=mpQa_Zm1xW8)
+ [AWS re:Invent 2022: Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
+ [AWS re:Invent 2022: Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [AWS re:Invent 2022 - Building data mesh architectures on AWS](https://www.youtube.com/watch?v=nGRvlobeM_U)
+ [AWS re:Invent 2023 - Deep dive into Amazon Aurora and its innovations](https://www.youtube.com/watch?v=je6GCOZ22lI)
+ [AWSre:Invent 2023: Advanced data modeling with Amazon DynamoDB](https://www.youtube.com/watch?v=PVUofrFiS_A)
**関連する例:**
+ [ Amazon S3 の例 ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
+ [AWS 目的別データベースワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/93f64257-52be-4c12-a95b-c0a1ff3b7e2b/en-US)
+ [開発者向けデータベース](https://catalog.workshops.aws/db4devs/en-US)
+ [AWS モダンデータアーキテクチャ Immersion Day](https://catalog.us-east-1.prod.workshops.aws/workshops/32f3e732-d67d-4c63-b967-c8c5eabd9ebf/en-US)
+ [AWS でのデータメッシュの構築](https://catalog.us-east-1.prod.workshops.aws/workshops/23e6326b-58ee-4ab0-9bc7-3c8d730eb851/en-US)
# SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する
すべてのデータのライフサイクルを管理し、自動的に削除を実行することで、ワークロードに必要なストレージの総量を最小限に抑えます。
**一般的なアンチパターン:**
+ データを手動で削除する。
+ ワークロードデータは削除しない。
+ データ保持やアクセス要件に基づいて、よりエネルギー効率の高いストレージ階層にデータを移動することがない。
**このベストプラクティスを活用するメリット:** データライフサイクルポリシーを使用すると、ワークロード内の効率的なデータアクセスと保持が保証されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
データセットには通常、そのライフサイクルにおいて異なる保持要件とアクセス要件があります。例えば、限られた期間のみ頻繁にデータセットにアクセスする必要があるアプリケーションもあります。その後、それらのデータセットにアクセスすることはほとんどありません。データストレージと計算の経時的な効率を向上させるには、データの経時的な処理方法を定義するルールであるライフサイクルポリシーを実装します。
ライフサイクル設定ルールを使用すると、特定のストレージサービスに対して、データセットをよりエネルギー効率の高いストレージ層に移行する、アーカイブする、または削除するように指示できます。このプラクティスにより、アクティブなデータの保存と取得が最小限に抑えられ、エネルギー消費量が低下します。さらに、古いデータのアーカイブや削除などのプラクティスは、規制コンプライアンスとデータガバナンスをサポートします。
### 実装手順
+ **データ分類の使用:** [ワークロード内のデータセットを分類します。](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html)
+ **処理規則の定義:** データクラスごとに処理手順を定義します。
+ **自動化の有効化:** ライフサイクルルールを適用するための自動ライフサイクルポリシーを設定します。さまざまな AWS ストレージサービスの自動ライフサイクルポリシーを設定する方法の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_data_a4.html)
+ **未使用アセットの削除:** 未使用のボリューム、スナップショット、保存期間を過ぎたデータを削除します。削除には、[Amazon DynamoDB の有効期限](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)や [Amazon CloudWatch Logs 保持](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)などのネイティブサービス機能を活用します。
+ **集約と圧縮:** ライフサイクルルールに基づいて、該当する場合はデータを集約および圧縮します。
## リソース
**関連ドキュメント:**
+ [Amazon S3 ストレージクラス分析を使用して Amazon S3 ライフサイクルルールを最適化する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)
+ [Evaluating Resources with AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
**関連動画:**
+ [AWS re:Invent 2021 - Amazon S3 Lifecycle best practices to optimize your storage spend ](https://www.youtube.com/watch?v=yGNXn7jOytA)
+ [AWS re:Invent 2023 - Optimizing storage price and performance with Amazon S3 ](https://www.youtube.com/watch?v=RxgYNrXPOLw)
+ [Simplify Your Data Lifecycle and Optimize Storage Costs With Amazon S3 Lifecycle](https://www.youtube.com/watch?v=53eHNSpaMJI)
+ [Reduce Your Storage Costs Using Amazon S3 Storage Lens](https://www.youtube.com/watch?v=A8qOBLM6ITY)
# SUS04-BP04 伸縮性とオートメーションを使用してブロックストレージまたはファイルシステムを拡張する
伸縮性とオートメーションを使用して、データの増加につれてブロックストレージまたはファイルシステムを拡張し、プロビジョニングされるストレージの合計を最小化します。
**一般的なアンチパターン:**
+ 将来必要になるかもしれない大きなブロックストレージやファイルシステムを調達している。
+ ファイルシステムの IOPS (input and output operations per second、入出力操作毎秒) を過剰プロビジョニングしている。
+ データボリュームの使用率をモニタしていない。
**このベストプラクティスを活用するメリット:** ストレージシステムのオーバープロビジョニングを最小限に抑えると、アイドル状態のリソースが減少し、ワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードに適したサイズ割り当て、スループット、レイテンシーで、ブロックストレージやファイルシステムを作成します。伸縮性とオートメーションを使用して、データの増加につれてブロックストレージまたはファイルシステムを拡張し、これらのストレージサービスを過剰プロビジョニングしないようにします。
### 実装手順
+ [Amazon EBS](https://aws.amazon.com/ebs/) などの固定サイズのストレージシステムについては、使用済みのストレージの量を全体的なストレージサイズに照らしてモニタリングするようにします。可能であれば、しきい値に到達したときにストレージサイズを増加させるオートメーションを作成します。
+ 伸縮自在なボリュームとマネージド型のブロックデータサービスを使用して、永続的データの増加に応じて追加のストレージの割り当てを自動化します。[Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) では、EBS ボリュームのボリュームサイズの増加、ボリュームタイプの変更、パフォーマンスの調整を行うことができます。
+ ファイルシステムに適したストレージクラス、パフォーマンスモード、スループットモードを選択して、ビジネスニーズを超えることなく対処できるようにします。
+ [ Amazon EFS パフォーマンス](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [Linux インスタンスでの Amazon EBS ボリュームのパフォーマンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+ データボリュームの使用率の目標レベルを設定し、予想される範囲外のボリュームはサイズ変更します。
+ データに合わせて読み取り専用ボリュームのサイズを最適化します。
+ データをオブジェクトストアに移行して、ブロックストレージの固定ボリュームサイズを超える容量をプロビジョンするのを回避します。
+ 伸縮自在なボリュームやファイルシステムを定期的に見直して、アイドルなボリュームを停止し、現在のデータサイズに合わせて過剰プロビジョンされたリソースを縮小します。
## リソース
**関連ドキュメント:**
+ [Extend the file system after resizing an EBS volume](https://docs.aws.amazon.com/ebs/latest/userguide/recognize-expanded-volume-linux.html)
+ [Modify a volume using Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)
+ [Amazon FSx Documentation](https://docs.aws.amazon.com/fsx/index.html)
+ [Amazon Elastic File System とは](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
**関連動画:**
+ [Deep Dive on Amazon EBS Elastic Volumes](https://www.youtube.com/watch?v=Vi_1Or7QuOg)
+ [Amazon EBS and Snapshot Optimization Strategies for Better Performance and Cost Savings](https://www.youtube.com/watch?v=h1hzRCsJefs)
+ [Optimizing Amazon EFS for cost and performance, using best practices](https://www.youtube.com/watch?v=9kfeh6_uZY8)
# SUS04-BP05 不要なデータや重複するデータを削除する
不要なデータや重複するデータを削除し、データセットの保存に必要なストレージリソースを最小限に抑えます。
**一般的なアンチパターン:**
+ 簡単に取得または再作成できるデータを複製している。
+ データの重要性を考慮せず、すべてのデータをバックアップしている。
+ データの削除は、不定期、運用イベント時のみ、またはまったく行わない。
+ ストレージサービスの耐久性に関係なく、データを冗長に保存している。
+ ビジネス上の正当な理由なく Amazon S3 バージョニングを有効にしている。
**このベストプラクティスを活用するメリット:** 不要なデータを削除すると、ワークロードに必要なストレージサイズとワークロードの環境への影響が軽減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
不要な冗長データセットを削除すると、ストレージコストと環境フットプリントを削減できます。この方法により、コンピューティングリソースが不要なデータではなく重要なデータのみを処理するため、コンピューティングの効率も向上する可能性があります。不要なデータの削除を自動化する。ファイルおよびブロックレベルでデータの重複を排除するテクノロジーを使用する。ネイティブデータレプリケーションと冗長性のためのサービス機能を使用します。
### 実装手順
+ **パブリックデータセットの評価:** [AWS Data Exchange](https://aws.amazon.com/data-exchange/) および [AWS の Open Data で公開されている既存のデータセットを使用し、データの保存を回避できるかどうかを評価します](https://registry.opendata.aws/)。
+ **データの重複排除:** ブロックレベルとオブジェクトレベルでデータを重複排除できる仕組みを使用します。AWS でデータの重複をなくす方法の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_data_a6.html)
+ **ライフサイクルポリシーの使用:** ライフサイクルポリシーを使用して、未使用のアセットを自動的に削除します。削除には、[Amazon DynamoDB の有効期限](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)や [Amazon S3 Lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)、[Amazon CloudWatch Logs 保持](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html)などのネイティブサービス機能を使用します。
+ **データ仮想化の使用:** AWS のデータ仮想化機能を使用してデータをソースに保持し、データの重複を回避します。
+ [AWS でのクラウドネイティブデータ仮想化](https://www.youtube.com/watch?v=BM6sMreBzoA)
+ [Amazon Redshift データ共有を使用したデータパターンの最適化](https://catalog.workshops.aws/well-architected-sustainability/en-US/3-data/optimize-data-pattern-using-redshift-data-sharing)
+ **増分バックアップの使用:** 増分バックアップが可能なバックアップテクノロジーを使用します。
+ **ネイティブ耐久性の使用:** セルフマネージドテクノロジー (独立ディスクの冗長アレイ (RAID) など) の代わりに [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) の耐久性と [Amazon EBS のレプリケーション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)を活用して、耐久性の目標を達成します。
+ **効率的なログの使用:** ログおよび追跡データを一元化し、同一のログエントリの重複を排除して、必要に応じて冗長性を調整するメカニズムを確立します。
+ **効率的なキャッシュの使用:** 正当化された場合にのみキャッシュを事前入力します。
+ キャッシュのモニタリングとオートメーションを確立し、それに従ってキャッシュをサイズ変更します。
+ **古いバージョンのアセットの削除:** ワークロードの新しいバージョンをプッシュする際に、オブジェクトストアとエッジキャッシュから古いデプロイとアセットを削除します。
## リソース
**関連ドキュメント:**
+ [Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Data deduplication on Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [Features of Amazon FSx for ONTAP including data deduplication](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)
+ [What is Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [バックアップの概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
+ [AWS Lake Formation を使用してデータセットの統合および重複の削除を実施](https://aws.amazon.com/blogs/big-data/integrate-and-deduplicate-datasets-using-aws-lake-formation-findmatches/)
**関連動画:**
+ [Amazon Redshift Data Sharing Use Cases](https://www.youtube.com/watch?v=sIoTB8B5nn4)
**関連する例:**
+ [Amazon Athena で Amazon S3 サーバーアクセスログを分析する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
# SUS04-BP06 共有ファイルシステムまたはストレージを使用して共通データにアクセスする
共有ファイルシステムまたはストレージを導入して、データの重複を避け、ワークロードのインフラストラクチャの効率を向上させます。
**一般的なアンチパターン:**
+ クライアントそれぞれにストレージをプロビジョンしている。
+ 非アクティブなクライアントからデータボリュームをデタッチしていない。
+ プラットフォームやシステムを横断してストレージに対するアクセスを提供していない。
**このベストプラクティスを活用するメリット:** 共有ファイルシステム、ストレージを使用すると、データをコピーしなくても 1 つ以上のコンシューマーにデータを共有できます。これにより、ワークロードに必要なストレージリソースを削減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
同じデータセットにアクセスするユーザーやアプリケーションが複数の場合、共有ストレージ技術を使用することが、ワークロードの効率的なインフラストラクチャを実現するために重要です。共有ストレージ技術を利用すると、データセットを 1 か所で保存および管理し、データの重複を避けることができます。また、異なるシステム間でデータの一貫性を維持できます。さらに、共有ストレージ技術を利用すると、複数のコンピューティングリソースが並列して同時にデータにアクセスして処理できるため、コンピューティング性能をより効率的に使用できます。
必要なときにのみ、このような共有ストレージサービスからデータを取得し、未使用のボリュームはデタッチしてリソースを解放します。
### 実装手順
+ **共有ストレージの使用:** データに複数のコンシューマーが存在する場合は、データを共有ストレージに移行します。AWS の共有ストレージ技術の例をいくつか示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_data_a7.html)
+ **必要なときにのみデータを取得:** 必要なときにのみ、共有ファイルシステムにデータをコピーしたり、共有ファイルシステムからデータを取得したりします。例えば、[Amazon S3 にバックアップされた Amazon FSx for Lustre ファイルシステム](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/)を作成し、処理ジョブに必要なデータのサブセットのみを Amazon FSx にロードできます。
+ **不要データの削除:**「[SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する](sus_sus_data_a4.md)」で説明されているように、使用パターンに応じてデータを削除します。
+ **非アクティブなクライアントのデタッチ:** クライアントがアクティブに使用していないボリュームをクライアントからデタッチします。
## リソース
**関連ドキュメント:**
+ [Linking your file system to an Amazon S3 bucket](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [Using Amazon EFS for AWS Lambda in your serverless applications](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)
+ [新機能 – Amazon EFS Intelligent-Tiering がアクセスパターンの変化に応じてワークロードのコストを最適化](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)
+ [オンプレミスデータリポジトリで Amazon FSx を使用する](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)
**関連動画:**
+ [Storage cost optimization with Amazon EFS](https://www.youtube.com/watch?v=0nYAwPsYvBo)
+ [AWS re:Invent 2023 - What's new with AWS file storage](https://www.youtube.com/watch?v=yXIeIKlTFV0)
+ [AWS re:Invent 2023 - File storage for builders and data scientists on Amazon Elastic File System](https://www.youtube.com/watch?v=g0f6lrmEyRM)
# SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える
共通データへのアクセスに共有ファイルシステムまたはオブジェクトストレージを使用して、ワークロードにおけるデータ移動をサポートするために必要なネットワークリソースの総量を最小化します。
**一般的なアンチパターン:**
+ データユーザーの所在地とは別の、同じ AWS リージョンにすべてのデータを保存している。
+ データをネットワーク経由で移動する前に、データサイズや形式を最適化していない。
**このベストプラクティスを活用するメリット:** ネットワーク経由のデータの移動を最適化すると、ワークロードに必要なネットワークリソースの総量を削減でき、環境への影響を抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
組織のあちこちにデータを移動するには、コンピューティング、ネットワーキング、ストレージのリソースが必要です。データ移動を最小限にするテクニックを使用して、ワークロード全体の効率を向上させます。
## 実装手順
+ **近接性の使用:** [ワークロードのリージョンを選択](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)するときは、データまたはユーザーの近接性を意思決定の要素として考慮します。
+ **パーティションサービス:** リージョン固有のデータが消費されるリージョン内に保存されるよう、リージョン内で消費されるサービスをパーティションします。
+ **効率的なファイル形式の使用:** 効率的なファイル形式 (Parquet や ORC など) を使用してデータを圧縮してから、ネットワーク経由で移動します。
+ **データ移動を最小限に抑える:** 未使用のデータは移動しません。未使用のデータ移動を防止するために参考となる事例をいくつかご紹介します。
+ API リソースを関連データのみに削減します。
+ 詳細なデータ (レコードレベルの情報は不要) を集約します。
+ 「[Well-Architected Lab - Optimize Data Pattern Using Amazon Redshift Data Sharing](https://catalog.workshops.aws/well-architected-sustainability/en-US/3-data/optimize-data-pattern-using-redshift-data-sharing)」を参照してください。
+ [AWS Lake Formation のクロスアカウントのデータ共有](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html)を考慮します。
+ **エッジサービスの使用:** ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_data_a8.html)
## リソース
**関連ドキュメント:**
+ [持続可能な AWS インフラストラクチャの最適化、第三部:ネットワーキング編](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 特徴](https://aws.amazon.com/cloudfront/features/) (グローバルエッジネットワーク他)
+ [Compressing HTTP requests in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Intermediate data compression with Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [圧縮されたデータファイルを Amazon S3 からロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [圧縮ファイルを供給する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
**関連動画:**
+ [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
# SUS04-BP08 データは再作成が難しい場合にのみバックアップする
ビジネス価値のないデータのバックアップを避け、ワークロードに必要なストレージリソースを最小化します。
**一般的なアンチパターン:**
+ データのバックアップ戦略がない。
+ 簡単に再作成できるデータをバックアップしている。
**このベストプラクティスを活用するメリット:** 重要度の低いデータのバックアップを回避することでワークロードに必要なストレージリソースを減らし、環境への影響を減らすことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
必要ではないデータのバックアップを避けると、コストを下げ、ワークロードが使用するストレージリソースを削減できます。ビジネス価値のあるデータまたはコンプライアンス要件を満たすために必要なデータのみをバックアップします。バックアップポリシーを精査し、リカバリシナリオでは価値のないエフェメラルストレージを除外します。
### 実装手順
+ **データの分類:** [SUS04-BP01 データ分類ポリシーを実装する](sus_sus_data_a2.md) で解説しているとおりにデータ分類ポリシーを実装します。
+ **バックアップ戦略の策定:** データの重要度区分を用いて、[目標復旧時間 (RTO) と目標復旧時点 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) に基づきバックアップ戦略を策定します。重要ではないデータのバックアップを避けます。
+ 簡単に再作成できるデータを除外します。
+ バックアップから一時データを除外します。
+ 共通の場所からデータを復元するために必要な時間がサービスレベルアグリーメント (SLA) を超える場合を除き、データのローカルコピーを除外します。
+ **自動化されたバックアップの使用:** 自動化されたソリューションまたはマネージドサービスを使用してビジネスクリティカルなデータをバックアップします。
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) はフルマネージド型のバックアップサービスであり、AWS のサービス、クラウド内、およびオンプレミス間で簡単に一元化およびデータ保護を自動化できます。AWS Backup を使用した自動パックアップの作成方法に関する実践的ガイダンスについては、「[Well-Architected Labs - Testing Backup and Restore of Data](https://catalog.workshops.aws/well-architected-reliability/en-US/4-failure-management/1-backup/30-testing-backup-and-restore-of-data)」を参照してください。
+ [AWS Backup を使用して Amazon EFS のバックアップを自動化しバックアップコストを最適化](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/)します。
## リソース
**関連するベストプラクティス:**
+ [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 データバックアップを自動的に実行する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
**関連ドキュメント:**
+ [AWS Backup を使用してAmazon EFS ファイルシステムをバックアップし復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS snapshots](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)
+ [APN パートナー: バックアップの支援が可能なパートナー](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EFS のバックアップ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Amazon FSx for Windows File Server のバックアップ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Amazon ElastiCache (Redis OSS) のバックアップと復元](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
**関連動画:**
+ [AWS re:Invent 2023 - Backup and disaster recovery strategies for increased resilience](https://www.youtube.com/watch?v=E073XISxrSU)
+ [AWS re:Invent 2023 - What's new with AWS Backup](https://www.youtube.com/watch?v=QIffkOyTf7I)
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
# ハードウェアとサービス
**Topics**
+ [SUS 5 アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか?](sus-05.md)
# SUS 5 アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか?
ハードウェア管理のプラクティスを変更することで、ワークロードの持続可能性に対する影響を軽減する機会を探します。プロビジョンおよびデプロイする必要があるハードウェアの数を最小化し、個別のワークロードにおいて最も効率的なハードウェアとサービスを選択します。
**Topics**
+ [SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する](sus_sus_hardware_a2.md)
+ [SUS05-BP02 影響が最も少ないインスタンスタイプを使用する](sus_sus_hardware_a3.md)
+ [SUS05-BP03 マネージドサービスを使用する](sus_sus_hardware_a4.md)
+ [SUS05-BP04 ハードウェアベースのコンピューティングアクセラレーターの使用を最適化する](sus_sus_hardware_a5.md)
# SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する
ワークロードには最小限のハードウェアを使用し、ビジネスニーズを効率的に満たします。
**一般的なアンチパターン:**
+ リソースの使用率をモニタしていない。
+ アーキテクチャに使用率が低いリソースがある。
+ 静的ハードウェアの使用率を見直してサイズを変更するかどうかを判断していない。
+ ビジネス KPI に基づいたコンピューティングインフラストラクチャのハードウェア使用率目標を設定していない。
**このベストプラクティスを活用するメリット:** クラウドリソースのサイズを最適化することで、ワークロードによる環境への影響を減らし、費用を節約して、パフォーマンス基準を維持することができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードに必要なハードウェアの総数を適切に選択して、全体の効率を改善します。AWS クラウドでは、[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) などさまざまなメカニズムによって、リソースの数を必要に応じて柔軟に拡張または縮小することができ、需要の変化に対応することができます。また、リソースの変更を最小限の労力で実行できる [API と SDK](https://aws.amazon.com/developer/tools/) も用意されています。これらの機能を使用して、ワークロードの実装を頻繁に変更できます。さらに AWS ツールが提供する適切なサイジングのガイドラインを使用して、クラウドリソースを効率的に運用し、ビジネスニーズを満たすことができます。
**実装手順**
+ **インスタンスタイプを選択する:** ニーズに最適なインスタンスタイプを選びます。Amazon Elastic Compute Cloud インスタンスの選び方や、属性ベースのインスタンスの選択といったメカニズムの使用方法については、以下を参照してください。
+ [ワークロードに適した EC2 インスタンスタイプを選択する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 Fleet の属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [属性ベースのインスタンスタイプの選択を使用して Auto Scaling グループを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+ **スケールする:** ワークロードの変動に合わせて少しずつスケールします。
+ **複数のコンピューティング購入オプションを使用する:** 複数のコンピューティング購入オプションを使用することで、インスタンスの柔軟性、スケーラビリティ、コスト削減の間のバランスを取ります。
+ [Amazon EC2 オンデマンドインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)は、インスタンスタイプやロケーション、処理時間の柔軟性が低い、ステートフルでスパイクが発生しやすい新規のワークロードに最適です。
+ [Amazon EC2 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)は、耐障害性と柔軟性を備えたアプリケーションに関して、他の方法を補完する優れた方法です。
+ 定常状態のワークロードには、[Compute Savings Plans](https://aws.amazon.com/savingsplans/compute-pricing/) を活用すれば、ニーズの変化 (AZ、リージョン、インスタンスファミリー、インスタンスタイプなど) に柔軟に対応できます。
+ **さまざまなインスタンスやアベイラビリティーゾーンを使用する:** 多様なインスタンスやアベイラビリティーゾーンを使用することで、アプリケーションの可用性を最大化し余剰のキャパシティを活用することができます。
+ **インスタンスを適切なサイズに設定する:** AWS ツールの適切なサイジングのレコメンデーションを使用して、ワークロードを調整します。詳細については、「[Optimizing your cost with Rightsizing Recommendations](https://docs.aws.amazon.com/latest/userguide/ce-rightsizing.html)」と「[適切なサイジング: ワークロードに適したインスタンスのプロビジョニング](https://docs.aws.amazon.com/latest/cost-optimization-right-sizing/cost-optimization-right-sizing.html)」を参照してください。
+ 適切なサイジングの機会を特定するには、AWS Cost Explorer の適切なサイジングのレコメンデーション、または [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用します。
+ **サービスレベルアグリーメント (SLA) を見直す:** 容量を一時的に減らせるように SLA を見直すと同時に、オートメーションを使用して代替のリソースをデプロイします。
## リソース
**関連ドキュメント:**
+ [持続可能な AWS インフラストラクチャの最適化、第一部:コンピュート編](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [新機能 — EC2 Auto Scaling と EC2 フリートの属性ベースのインスタンスタイプの選択](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [AWS Compute Optimizer のドキュメント](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [Operating Lambda: パフォーマンスの最適化 – Part 2](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/)
+ [Auto Scaling ドキュメント](https://docs.aws.amazon.com/autoscaling/index.html)
**関連動画:**
+ [AWS re:Invent 2023 – What's new with Amazon EC2](https://www.youtube.com/watch?v=mjHw_wgJJ5g)
+ [AWS re:Invent 2023 - Smart savings: Amazon Elastic Compute Cloud cost-optimization strategies](https://www.youtube.com/watch?v=_AHPbxzIGV0)
+ [AWS re:Invent 2022 - Optimizing Amazon Elastic Kubernetes Service for performance and cost on AWS](https://www.youtube.com/watch?v=5B4-s_ivn1o)
+ [AWS re:Invent 2023 - Sustainable compute: reducing costs and carbon emissions with AWS](https://www.youtube.com/watch?v=0Bl1SDU2HxI)
# SUS05-BP02 影響が最も少ないインスタンスタイプを使用する
新しいインスタンスタイプを継続的にモニタして使用し、エネルギー効率の改善を活用します。
**一般的なアンチパターン:**
+ インスタンスの 1 つのファミリーのみを使用する。
+ x86 インスタンスのみを使用する。
+ Amazon EC2 Auto Scaling の設定で 1 つのインスタンスタイプを指定する。
+ AWS インスタンスが設計されていない方法で使用されている (例えば、メモリ集中型のワークロードに計算用に最適化されたインスタンスを使用した場合)。
+ 新しいインスタンスタイプを定期的に評価しない。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) など、AWS の適切なサイジングツールのレコメンデーションを確認しない。
**このベストプラクティスを活用するメリット:** エネルギー効率に優れた適切なサイズのインスタンスを使用することで、環境への影響とワークロードのコストを大幅に下げることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドワークロードに効率的なインスタンスを使用することは、リソースの使用量を下げ、コスト効率を高めるために重要です。新しいインスタンスタイプのリリースを継続的にモニタし、エネルギー効率の改善を活用します。例えば、機械学習のトレーニングや推論、ビデオのトランスコーディングなど、特定のワークロードをサポートするように設計されたインスタンスタイプなどです。
## 実装手順
+ **インスタンスタイプを探して詳しく調べる:** ワークロードによる環境への影響を減らすことができるインスタンスタイプを特定します。
+ [AWS の最新情報](https://aws.amazon.com/new/)を購読して、AWS のテクノロジーとインスタンスに関する最新情報を入手します。
+ さまざまな AWS インスタンスタイプについて学びます。
+ Amazon EC2 でのワットあたりのエネルギー使用量が最も優れた、AWS Graviton ベースのインスタンスの詳細については、「[re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances](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 に移行する方法の詳細については、「[AWS Graviton Fast Start でイノベーションを加速する](https://aws.amazon.com/ec2/graviton/fast-start/)」と「[Considerations when transitioning workloads to AWS Graviton-based Amazon Elastic Compute Cloud instances](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)」を参照してください。
+ [AWS マネージドサービス](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)を使用するときは、AWS Graviton の利用を検討します。
+ 持続可能性に対する影響が最も少なく、かつビジネス要件を満たすインスタンスを提供するリージョンにワークロードを移行します。
+ 機械学習のワークロードには、[AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、[AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、[Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) など、特定のワークロード専用のハードウェアを活用します。AWSInferentia インスタンス (Inf2 インスタンスなど) を使用することで、同等の Amazon EC2 インスタンスに比べ、ワットあたりのパフォーマンスが最大で 50% 向上します。
+ ML 推論エンドポイントのサイズを適正化するときは、[Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) を使用します。
+ スパイクが発生しやすいワークロード (追加の容量が必要になる頻度が低いワークロード) には、[バーストパフォーマンスインスタンス](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/) など) を定期的にチェックし、インスタンスの最適化と適切なサイジングの機会を特定します。その他の例と推奨事項については、以下のラボを参照してください。
+ [Well-Architected Lab - Rightsizing Recommendations](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/3-cost-effective-resources/40-rightsizing-recommendations-100)
+ [Well-Architected Lab - Rightsizing with Compute Optimizer](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/3-cost-effective-resources/50-rightsizing-recommendations-200)
+ [Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs](https://catalog.workshops.aws/well-architected-sustainability/en-US/4-hardware-and-services/optimize-hardware-patterns-observe-sustainability-kpis)
## リソース
**関連ドキュメント:**
+ [持続可能な AWS インフラストラクチャの最適化、第一部:コンピュート編](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton プロセッサ](https://aws.amazon.com/ec2/graviton/)
+ [Amazon EC2 DL1 インスタンス](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [キャパシティ予約フリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [EC2 フリートとスポットフリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [Function Configuration](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [Amazon EC2 Fleet の属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [持続可能で、効率的かつコストが最適化されたアプリケーションを AWS で構築する](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [How the Contino Sustainability Dashboard Helps Customers Optimize Their Carbon Footprint](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)
**関連動画:**
+ [AWS re:Invent 2023 - AWS Graviton: The best price performance for your AWS workloads](https://www.youtube.com/watch?v=T_hMIjKtSr4)
+ [AWS re:Invent 2023 - New Amazon Elastic Compute Cloud generative AI capabilities in AWS マネジメントコンソール](https://www.youtube.com/watch?v=sSpJ8tWCEiA)
+ [AWS re:Invent 2023 = What's new with Amazon Elastic Compute Cloud](https://www.youtube.com/watch?v=mjHw_wgJJ5g)
+ [AWS re:Invent 2023 - Smart savings: Amazon Elastic Compute Cloud cost-optimization strategies](https://www.youtube.com/watch?v=_AHPbxzIGV0)
+ [AWS re:Invent 2021 - Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**関連する例:**
+ [Solution: Guidance for Optimizing Deep Learning Workloads for Sustainability on AWS](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
# SUS05-BP03 マネージドサービスを使用する
マネージドサービスを使用して、クラウドでより効率的に運用します。
**一般的なアンチパターン:**
+ アプリケーションの実行に、使用率が低い Amazon EC2 インスタンスを使用している。
+ 社内チームはワークロードの管理のみを行っており、イノベーションや簡易化に焦点を当てる時間がない。
+ マネージドサービスではより効率的に実行できるタスク向けの技術をデプロイして維持している。
**このベストプラクティスを活用するメリット:**
+ マネージドサービスを使用すると、AWS に責任を移行できます。当社は、数百万のお客様から得られたインサイトで、新規イノベーションと効率性を促進しています。
+ マネージドサービスは、マルチテナントコントロールプレーンのおかげで、サービスの環境に対する影響を、多くのお客様に分散します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
マネージドサービスは、使用率を高く保つ責任と、デプロイされたハードウェアの持続可能性に対する最適化の責任を AWS に移します。また、マネージドサービスによって、サービス維持に伴う運用上および管理上の負担が軽減されるため、チームに時間の余裕ができイノベーションに集中できます。
ワークロードを見直して、AWS マネージドサービスに置き換えることができるコンポーネントを特定します。例えば、[Amazon RDS](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) にはデータベースのマネージドサービスがあります。[Amazon Athena](https://aws.amazon.com/athena/)、[Amazon EMR ](https://aws.amazon.com/emr/)、[Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) には分析のマネージドサービスがあります。
**実装手順**
1. **ワークロードのリストを作成する:** サービスとコンポーネントのワークロードをリストアップします。
1. **コンポーネントの候補を特定する:** コンポーネントを評価して、マネージドサービスに置き換えることができるものを特定します。マネージドサービスの使用を検討する場合の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_hardware_a4.html)
1. **移行計画を作成する:** 依存関係を特定して移行計画を作成します。同様にランブックやプレイブックも更新します。
+ [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) は、アプリケーションの依存関係と使用状況に関する詳細な情報を自動的に収集し提供するサービスです。移行の計画を立てる際に、充分な情報に基づいて意思決定を行えるようになります。
1. **テストを行う:** マネージドサービスに移行する前にサービスをテストします。
1. **セルフホスト型のサービスを置き換える:** 作成した移行計画に基づいて、セルフホスト型のサービスをマネージドサービスに置き換えます。
1. **モニタリングし調整する:** 移行の完了後は、サービスを継続的にモニタして、必要に応じて調整し、サービスを最適化します。
## リソース
**関連ドキュメント:**
+ [AWS クラウド製品](https://aws.amazon.com/products/)
+ [AWS 総保有コスト (TCO) 計算ツール](https://calculator.aws/#/)
+ [ 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/)
**関連動画:**
+ [AWS re:Invent 2021 - Cloud operations at scale with AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)
+ [AWS re:Invent 2023 - Best practices for operating on AWS](https://www.youtube.com/watch?v=XBKq2JXWsS4)
# SUS05-BP04 ハードウェアベースのコンピューティングアクセラレーターの使用を最適化する
高速コンピューティングインスタンスの使用を最適化することで、ワークロードの物理インフラストラクチャの需要を低減します。
**一般的なアンチパターン:**
+ GPU の使用状況を監視していない。
+ 専用インスタンスがより高い性能、低コスト、ワットあたりの性能を実現できるのに対し、ワークロードに汎用インスタンスを使用している。
+ CPU ベースのコンピューティングアクセラレーターを使用した方が効率的なタスクに、ハードウェアベースのコンピューティングアクセラレーターを使用している。
**このベストプラクティスを活用するメリット:** ハードウェアベースのアクセラレーターの使用を最適化することで、ワークロードの物理インフラストラクチャの需要を低減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
高い処理能力が必要な場合、高速コンピューティングインスタンスを使用すると、グラフィック処理ユニット (GPU) やフィールドプログラマブルゲートアレイ (FPGA) などのハードウェアベースのコンピューティングアクセラレーターを利用できるというメリットが得られます。これらのハードウェアアクセラレーターは、グラフィック処理やデータパターンマッチングなどの特定の機能を、CPU ベースの代替手段よりも効率的に実行します。レンダリング、トランスコーディング、機械学習など、多くの高速ワークロードは、リソースの使用量に大きなばらつきがあります。このハードウェアは必要な時間だけ実行し、不要になったら自動で廃止することで、消費されるリソースを最小化します。
## 実装手順
+ **コンピューティングアクセラレーターの調査:** 要件に対応できる[高速コンピューティングインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html)を特定します。
+ **専用ハードウェアの使用:** 機械学習ワークロードには、[AWSTrainium](https://aws.amazon.com/machine-learning/trainium/)、[AWSInferentia](https://aws.amazon.com/machine-learning/inferentia/)、[Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) など、ワークロードに特化した専用ハードウェアを活用してください。AWSInf2 インスタンスなどの Inferentia インスタンスは、[同等の Amazon EC2 インスタンスと比較してワットあたりのパフォーマンスが最大 50% 向上します](https://aws.amazon.com/machine-learning/inferentia/)。
+ **使用状況メトリクスのモニタリング:** 高速コンピューティングインスタンスの使用状況メトリクスを収集します。例えば、「[Amazon CloudWatch で NVIDIA GPU メトリクスを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html)」のように、CloudWatch エージェントを使用して GPU の `utilization_gpu` や `utilization_memory` などのメトリクスを収集できます。
+ **適切なサイズ:** ハードウェアアクセラレーターのコード、ネットワーク操作、設定を最適化し、基盤となるハードウェアが十分に活用されるようにします。
+ [GPU 設定を最適化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html)
+ [Deep Learning AMI での GPU のモニタリングと最適化](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html)
+ [Amazon SageMaker AI での深層学習トレーニング時における、GPU パフォーマンスチューニングのための I/O 最適化](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/)
+ **最新に保つ:** 最新の高性能ライブラリと GPU ドライバーを使用します。
+ **不要なインスタンスの解放:** 使用しないときは、自動化を使用して GPU インスタンスを解放します。
## リソース
**関連ドキュメント:**
+ [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [Let's Architect\$1 Architecting with custom chips and accelerators](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ワークロードに適した EC2 インスタンスタイプを選択する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 VT1 Instances](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon SageMaker AI でコンピュータビジョン推論に最適な AI アクセラレータとモデルコンパイルを選択](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)
**関連動画:**
+ [AWS re:Invent 2021 - How to select Amazon EC2 GPU instances for deep learning](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+ [AWS Online Tech Talks - Deploying Cost-Effective Deep Learning Inference](https://www.youtube.com/watch?v=WiCougIDRsw)
+ [AWS re:Invent 2023 - Cutting-edge AI with AWS and NVIDIA](https://www.youtube.com/watch?v=ud4-z_sb_ps)
+ [AWS re:Invent 2022 - [NEW LAUNCH\$1] Introducing AWS Inferentia2-based Amazon EC2 Inf2 instances](https://www.youtube.com/watch?v=jpqiG02Y2H4)
+ [AWS re:Invent 2022 - Accelerate deep learning and innovate faster with AWS Trainium](https://www.youtube.com/watch?v=YRqvfNwqUIA)
+ [AWS re:Invent 2022 - Deep learning on AWS with NVIDIA: From training to deployment](https://www.youtube.com/watch?v=l8AFfaCkp0E)
# プロセスと文化
**Topics**
+ [SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?](sus-06.md)
# SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?
開発、テスト、デプロイのプラクティスを変更することで、持続可能性への影響を軽減する機会を探します。
**Topics**
+ [SUS06-BP01 持続可能性の目標を伝え、段階的に広める](sus_sus_dev_a1.md)
+ [SUS06-BP02 持続可能性の改善を迅速に導入できる方法を採用する](sus_sus_dev_a2.md)
+ [SUS06-BP03 ワークロードを最新に保つ](sus_sus_dev_a3.md)
+ [SUS06-BP04 ビルド環境の利用率を高める](sus_sus_dev_a4.md)
+ [SUS06-BP05 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md)
# SUS06-BP01 持続可能性の目標を伝え、段階的に広める
テクノロジーは持続可能性の重要なイネーブラーです。IT チームは、組織の持続可能性目標に向けて有意義な変化を推進する上で重要な役割を果たします。これらのチームは、会社の持続可能性目標を明確に理解し、それらの優先事項をオペレーション全体に伝え、広めるよう努める必要があります。
**一般的なアンチパターン:**
+ 組織の持続可能性の目標や、それらがチームにどのように適用されるかがわからない。
+ クラウドワークロードの環境への影響に関する認識とトレーニングが不十分である。
+ 優先すべき具体的なエリアが不明である。
+ 持続可能性の取り組みに従業員や顧客を関与させていない。
**このベストプラクティスを活用するメリット:** インフラストラクチャとシステムの最適化から革新的なテクノロジーの使用まで、IT チームは組織の二酸化炭素排出量を削減し、リソースの消費を最小限に抑えることができます。持続可能性の目標を伝えることによって、IT チームは進化する持続可能性の課題を継続的に改善し、適応できるようになります。さらに、これらの持続可能な最適化はコスト削減につながることも多く、ビジネスケースを強化できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
IT チームの主な持続可能性の目標は、システムとソリューションを最適化してリソース効率を高め、組織の二酸化炭素排出量と全体的な環境への影響を最小限に抑えることです。トレーニングプログラムや運用ダッシュボードなどの共有サービスやイニシアチブは、組織が IT オペレーションを最適化し、二酸化炭素排出量を大幅に削減できるソリューションを構築する際に役立ちます。クラウドは、物理インフラストラクチャとエネルギー調達の責任をクラウドプロバイダーの共同責任に移行するだけでなく、クラウドベースのサービスのリソース効率を継続的に最適化する機会も提供します。
チームがクラウド固有の効率性と責任共有モデルを使用すると、組織の環境への影響を大幅に削減できます。これにより、組織全体の持続可能性の目標に貢献し、より持続可能な未来に向けた取り組みにおける戦略的パートナーとしてのこれらのチームの価値を実証できます。
### 実装手順
+ **目標と目的の定義:** IT プログラムの明確に定義された目標を設定します。これには、IT、持続可能性、財務など、さまざまな部門から責任ある利害関係者からの情報収集も含まれます。これらのチームは、炭素削減やリソースの最適化などの分野を含め、組織の持続可能性目標に沿った測定可能な目標を定義する必要があります。
+ **ビジネスの炭素会計の境界を理解する:** Greenhouse Gas (GHG) Protocol などの炭素会計方法がクラウド内のワークロードにどのように関連しているかを理解します (詳細については、「[クラウドの持続可能性](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/cloud-sustainability.html)」を参照してください)。
+ **炭素会計にクラウドソリューションを使用する:** [AWS の炭素会計ソリューション](https://aws.amazon.com/solutions/sustainability/carbon-accounting/)などのクラウドソリューションを使用して、オペレーション、ポートフォリオ、バリューチェーン全体で GHG 排出量の範囲 1、2、3 を追跡します。これらのソリューションにより、組織は GHG 排出データの取得を合理化し、レポートを簡素化し、気候戦略に役立つインサイトを得ることができます。
+ **IT ポートフォリオのカーボンフットプリントをモニタリングする:** IT システムの二酸化炭素排出量を追跡して報告します。[AWS Customer Carbon Footprint Tool](https://aws.amazon.com/aws-cost-management/aws-customer-carbon-footprint-tool/) を使用して、AWS使用状況から発生する炭素排出量を追跡、測定、レビュー、予測します。
+ **プロキシメトリクスを使用してリソースの使用状況をチームに伝達する:** [プロキシメトリクスを使用してリソースの使用状況](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)を追跡してレポートします。クラウドのオンデマンド価格設定モデルでは、リソース使用量はコストに関連しており、これは一般的に理解できるメトリクスです。少なくとも、コストをプロキシメトリクスとして使用して、各チームによるリソースの使用状況と改善点を伝えます。
+ **Cost Explorer で時間単位の詳細度を有効にし、[コストと使用状況レポート (CUR) を作成する](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/):** CUR は、すべての AWS サービスの日単位または時間単位の使用状況の詳細度、レート、コスト、使用状況属性を示します。[クラウドインテリジェンスダッシュボード](https://catalog.workshops.aws/awscid/) とその持続可能性プロキシメトリクスダッシュボードを、コストと使用状況に基づくデータの処理と視覚化の開始点として使用します。詳細については、以下をご参照ください。
+ [持続可能性プロキシメトリクスを使用してクラウド効率を測定して追跡する、パート I: プロキシメトリクスとは](https://aws.amazon.com/blogs/aws-cloud-financial-management/measure-and-track-cloud-efficiency-with-sustainability-proxy-metrics-part-i-what-are-proxy-metrics/)
+ [持続可能性プロキシメトリクスを使用してクラウド効率を測定して追跡する、パート II: メトリクスパイプラインの確立](https://aws.amazon.com/blogs/aws-cloud-financial-management/measure-and-track-cloud-efficiency-with-sustainability-proxy-metrics-part-ii-establish-a-metrics-pipeline/)
+ **継続的な最適化と評価:** [改善プロセス](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)を使用して、効率と持続可能性のためのクラウドワークロードを含む IT システムを継続的に最適化します。最適化戦略の実装前後にカーボンフットプリントをモニタリングします。カーボンフットプリントの削減を使用して、有効性を評価します。
+ **持続可能性カルチャーの醸成:** トレーニングプログラム ([AWS スキルビルダーなど](https://explore.skillbuilder.aws/learn/external-ecommerce;view=none;redirectURL=?ctldoc-catalog-0=se-sustainability)) を使用して、持続可能性について従業員を教育します。持続可能性イニシアチブにエンゲージさせます。成功事例を共有し、称賛します。持続可能性の目標を達成した場合は、インセンティブを使用して報奨します。
## リソース
**関連ドキュメント:**
+ [炭素排出量の推定の理解](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html)
**関連動画:**
+ [AWS re:Invent 2023 - Accelerate data-driven circular economy initiatives with AWS](https://www.youtube.com/watch?v=ivTJorpUTo0)
+ [AWS re:Invent 2023 - Sustainability innovation in AWS Global Infrastructure ](https://www.youtube.com/watch?v=0EkcwLKeOQA)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Architecting sustainably and reducing your AWS carbon footprint](https://www.youtube.com/watch?v=jsbamOLpCr8)
+ [AWS re:Invent 2022 - Sustainability in AWS global infrastructure](https://www.youtube.com/watch?v=NgMa8R9-Ywk)
**関連する例:**
+ [Well-Architected Lab - Turning cost & usage reports into efficiency reports](https://catalog.workshops.aws/well-architected-sustainability/en-US/5-process-and-culture/cur-reports-as-efficiency-reports)
**関連するトレーニング:**
+ [AWS での持続可能性の変革](https://explore.skillbuilder.aws/learn/course/internal/view/elearning/15981/sustainability-transformation-with-aws?trk=f5740d24-133a-44e7-bdca-e6669e296419&sc_channel=el)
+ [SimuLearn - 持続可能性レポート](https://explore.skillbuilder.aws/learn/course/internal/view/elearning/20240/aws-simulearn-sustainability-reporting)
+ [AWS による脱炭素化](https://explore.skillbuilder.aws/learn/course/internal/view/elearning/19030/decarbonization-with-aws-introduction)
# SUS06-BP02 持続可能性の改善を迅速に導入できる方法を採用する
改善の可能性の検証、テストコストの最小化、小規模な改善の提供を行う手段やプロセスを導入します。
**一般的なアンチパターン:**
+ 持続可能性についてアプリケーションをレビューするのは、プロジェクトの開始時に 1 回だけである。
+ リリースプロセスが複雑すぎてリソース効率化のための小規模な変更を導入しづらいため、ワークロードが古くなった。
+ 持続可能性のためにワークロードを改善する仕組みがない。
**このベストプラクティスを活用するメリット:** 持続可能性に関する改善を導入および追跡するプロセスを確立することで、継続的に新しい機能や能力を導入し、問題を排除して、ワークロードの効率を向上させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
本稼働環境にデプロイする前に、持続可能性を改善できるかをテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。
### 実装手順
+ **組織の持続可能性目標の理解と周知:** 二酸化炭素削減やウォータースチュワードシップなど、組織の持続可能性目標を理解します。これらの目標をクラウドワークロードの持続可能性要件に変換します。これらの要件を主なステークホルダーに伝えます。
+ **持続可能性要件のバックログへの追加:** 持続可能性の改善に関する要件を開発バックログに追加します。
+ **反復と改善:** [反復的な改善プロセス](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)を使用して、これらの改善を特定、評価、優先順位付け、テスト、デプロイします。
+ **実用最小限の製品 (MVP) を使用したテスト:** 最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善を開発およびテストし、テストのコストと環境への影響を削減します。
+ **プロセスの合理化:** 開発プロセスを継続的に改善および合理化します。例えば、継続的な統合および配信 (CI/CD) パイプラインを使用してソフトウェア配信プロセスを自動化して、工数レベルを削減し手動プロセスで発生するエラーを減らす可能性のある改善をテストしデプロイします。
+ **トレーニングと啓発:** チームメンバーを対象にトレーニングプログラムを実施して、持続可能性、および活動が組織の持続可能性目標にどのように影響するかについて教育します。
+ **評価と調整:** 改善の影響を継続的に評価し、必要に応じて調整します。
## リソース
**関連ドキュメント:**
+ [AWS がサステナビリティソリューションを実現](https://aws.amazon.com/sustainability/)
**関連動画:**
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Architecting sustainably and reducing your AWS carbon footprint](https://www.youtube.com/watch?v=jsbamOLpCr8)
+ [AWS re:Invent 2022 - Sustainability in AWS global infrastructure](https://www.youtube.com/watch?v=NgMa8R9-Ywk)
+ [AWS re:Invent 2023 - What's new with AWS observability and operations](https://www.youtube.com/watch?v=E8qQBMDJjso)
# SUS06-BP03 ワークロードを最新に保つ
ワークロードを最新の状態に保ち、効率的な機能を導入し、問題を排除し、ワークロード全体の効率性を向上させます。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。
**このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
最新のオペレーティングシステム、ランタイム、ミドルウェア、ライブラリ、アプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。定期的に最新の機能やリリースを導入し、ワークロードを最新に保ちます。
### 実装手順
+ **プロセスの定義:** ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを使用します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。
+ 持続可能性への影響を削減する。
+ パフォーマンスの効率を高める。
+ 計画した改善にとっての障壁を取り除く。
+ 持続可能性に対する影響の測定能力と管理能力を高める。
+ **インベントリの作成:** ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
+ [AWSSystems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) を使用すれば、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスがアップデートする必要があるかを迅速に把握することが可能です。
+ **更新手順の学習:** ワークロードのコンポーネントを更新する方法を理解します。
| ワークロードコンポーネント | 更新方法 |
| --- | --- |
| マシンイメージ | [EC2 Image Builder](https://aws.amazon.com/image-builder/) を使用して、Linux または Windows サーバーイメージの [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) の更新を管理します。 |
| コンテナイメージ | 既存のパイプラインに [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)。 |
| AWS Lambda | AWS Lambda には[バージョン管理機能](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)があります。 |
+ **自動化の使用:** 更新を自動化して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。
+ [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) を使用すると、AMI、コンテナイメージなど、クラウドアプリケーションに関連するアーティファクトを自動的に更新できます。
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用するとシステム更新のプロセスを自動化でき、[AWS Systems Manager Maintenance Windows](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 re:Invent 2022 - Optimize your AWS workloads with best-practice guidance](https://www.youtube.com/watch?v=t8yl1TrnuIk)
+ [All Things Patch: AWS Systems Manager](https://www.youtube.com/watch?v=PhIiVsCEBu8)
# SUS06-BP04 ビルド環境の利用率を高める
リソースの使用率を上げて、ワークロードを開発、テスト、構築します。
**一般的なアンチパターン:**
+ ビルド環境を手動でプロビジョニングおよび停止している。
+ テスト、ビルド、リリースアクティビティとは無関係にビルド環境を実行し続けている (例えば、開発チームメンバーの就業時間外に環境を実行している)。
+ ビルド環境にリソースを過剰プロビジョニングしている。
**このベストプラクティスを活用するメリット:** ビルド環境の使用率を上げることで、構築者が効率的に開発、テスト、構築できるようにリソースを配分しながら、クラウドワークロード全体の効率を上げることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
オートメーションと Infrastructure as Code (IaC) を使用して、必要に応じてビルド環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。テスト環境は、本稼働構成とよく似たものにする必要があります。ただし、バーストキャパシティ、Amazon EC2 スポットインスタンス、自動スケールするデータベースサービス、コンテナ、サーバーレステクノロジーを備えたインスタンスタイプを使用して、開発およびテストのキャパシティを使用に合わせて調整できる機会を探ります。データ量を、テスト要件を満たす量だけに制限します。本番データをテストに使用する場合は、データを移動するのではなく、本稼働環境とデータを共有できる可能性を探ります。
**実装手順**
+ **Infrastructure as Code (IaC) を使用する:** 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)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS での Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
**関連動画:**
+ [AWS re:Invent 2023 - Continuous integration and delivery for AWS](https://www.youtube.com/watch?v=25w9uJPt0SA)
# SUS06-BP05 マネージド型 Device Farm を使用してテストする
マネージド型 Device Farm を使用して、ハードウェアの代表的なセットで新機能を効率的にテストします。
**一般的なアンチパターン:**
+ 個別の物理デバイス上で、アプリケーションを手動でテストおよびデプロイしている。
+ アプリケーションテストサービスを使用せずに、実際の物理デバイス上でアプリケーションをテストおよび操作している (Android、iOS、ウェブアプリケーションなど)。
**このベストプラクティスを活用するメリット:** マネージド型 Device Farm を使用してクラウド対応アプリケーションをテストすると、多くのメリットがあります。
+ 幅広い種類のデバイスでアプリケーションをテストする、より効率的な機能などです。
+ これにより、テスト用の社内インフラストラクチャが必要なくなります。
+ あまり使われない古いハードウェアを含む、さまざまデバイスタイプが提供されているため、不要なデバイスをアップグレードする必要がなくなります。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
マネージド型 Device Farm を使用すると、代表的な一連のハードウェアで新機能をテストするプロセスを合理化できます。マネージド型 Device Farm は、あまり使われない古いハードウェアを含むさまざまなデバイスタイプを提供するため、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。
### 実装手順
+ **テストの要件を定義する**: テストの要件と計画 (テストの種類、オペレーティングシステム、テストのスケジュールなど) を定義します。
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) を使用して、クライアント側のデータを収集および分析し、テスト計画を策定できます。
+ **マネージド型 Device Farm を選択する:** テスト要件に対応できるマネージド型 Device Farm を選択します。例えば、[AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) を使用すると、代表的なハードウェア一式における変更をテストし、その影響を理解できます。
+ **オートメーションを使用する:** 継続的統合/継続的デプロイ (CI/CD) を使用して、テストをスケジュールし実行します。
+ [AWS Device Farm を CI/CD パイプラインと統合してクロスブラウザの Selenium テストを実行する](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)
+ [Building and testing iOS and iPadOS apps with AWS DevOps and mobile services](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)
+ **見直して調整する:** テスト結果を継続的に見直し、必要な改善を行います。
## リソース
**関連ドキュメント:**
+ [AWS Device Farm デバイスリスト](https://awsdevicefarm.info/)
+ [CloudWatch RUM ダッシュボードの表示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)
**関連動画:**
+ [AWS re:Invent 2023 - Improve your mobile and web app quality using AWS Device Farm](https://www.youtube.com/watch?v=__93Tm0YCRg)
+ [AWS re:Invent 2021 - Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
**関連する例:**
+ [AWS Device Farm Android 向けサンプルアプリ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [AWS Device Farm iOS 向けサンプルアプリ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [AWS Device Farm 向け Appium ウェブテスト](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)