# データ
**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-BP04 不要なデータや重複するデータを削除する](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 データ分類ポリシーを実装する
データを分類してビジネス成果に対する重要度を理解し、データの保存にエネルギー効率の高い適切なストレージ層を選択します。
**一般的なアンチパターン:**
+ 処理または保存されているデータアセットの中で、類似の特徴 (機密度、ビジネス上の重要度、規制要件など) を持つものを特定していない。
+ データアセットのインベントリにデータカタログを実装していない。
**このベストプラクティスを活用するメリット:** データ分類ポリシーを実装すると、データに対して最もエネルギー効率の高いストレージ層を検討できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
データ分類には、組織が所有または運用する情報システムで処理中または保存中のデータのタイプの特定を含めます。また、データの重要度と、データの侵害、損失、誤使用によって考えられる影響についても検討します。
データ分類ポリシーは、データを使用する流れから逆算して実装し、あるデータセットの組織の運営における重要度のレベルを考慮に入れて、カテゴリ分けのスキームを作成します。
**実装手順**
+ ワークロードに存在するさまざまなデータタイプのインベントリを実施します。
+ データ分類カテゴリの詳細については、[Data Classification whitepaper](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) (データ分類ホワイトペーパー) をご覧ください。
+ 組織に対するリスクにもとづいて、データの重要度、機密度、整合性、可用性を判断します。このような要件を使用して、導入するデータ分類層のいずれかにデータをグループ分けします。
+ 例として、[Four simple steps to classify your data and secure your startup](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/) (データを分類しスタートアップを保護する 4 つのシンプルなステップ) を参照してください。
+ 環境を定期的に監査してタグ付けおよび分類されていないデータを探し、そのデータを適切に分類してタグ付けします。
+ 例として、[AWS Glue のデータカタログとクローラー](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)を参照してください。
+ 監査およびガバナンス機能があるデータカタログを作成します。
+ データクラスごとに処理手順を決定して文書化します。
+ 自動化を使用し、環境を継続的に監査してタグ付けおよび分類されていないデータを探し、そのデータを適切に分類してタグ付けします。
## リソース
**関連するドキュメント:**
+ [Leveraging AWS クラウド to Support Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html) (AWS クラウドを活用したデータ分類のサポート)
+ [AWS Organizations のタグポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
**関連動画:**
+ [ Enabling agility with data governance on AWS](https://www.youtube.com/watch?v=vznDgJkoH7k)(AWS 上でのデータガバナンスで俊敏性を実現する)
# SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する
データへのアクセス方法や保存方法を最もよくサポートするストレージ技術を使用し、ワークロードをサポートしながらプロビジョニングされるリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
**このベストプラクティスを活用するメリット:** データのアクセスとストレージのパターンに基づいてストレージ技術を選択し最適化すると、ビジネスニーズを満たすために必要なクラウドリソースが削減し、クラウドワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アクセスパターンに最適なストレージソリューションを選択するか、パフォーマンス効率を最大にするためにストレージソリューションに合わせてアクセスパターンを変更することを検討してください。
+ データの特徴とアクセスパターンを評価し、ストレージのニーズにおける主な特徴を収集します。考慮する主な特徴には次のものがあります。
+ **データタイプ:** 構造、半構造、非構造
+ **データの増加:** 制限あり、制限なし
+ **データの耐久性:** 永続、一過性、一時的
+ **アクセスパターン:** 読み取りまたは書き込み、頻度、急増、または安定
+ データの特徴とアクセスパターンをサポートする適切なストレージ技術にデータを移行します。AWS ストレージ技術とその主な特徴を例としていくつか挙げます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/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 ストレージクラスは、オブジェクトレベルで設定でき、単一のバケットのすべてのストレージクラスのオブジェクトを含めることができます。
+ また、Amazon S3 ライフサイクルポリシーを使用して、アプリケーションを変更せずにストレージクラス間でオブジェクトを自動的に移動したり、データを削除したりすることができます。一般的に、このようなストレージメカニズムを考える場合、リソース効率、アクセスのレイテンシー、信頼性の間でトレードオフを行う必要があります。
## リソース
**関連するドキュメント:**
+ [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)
**関連動画:**
+ [Architectural Patterns for Data Lakes on AWS](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
+ [ Deep dive on Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Optimize your storage performance with Amazon S3 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
**関連サンプル:**
+ [ Amazon EFS CSI Driver ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Amazon EBS CSI Driver ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Amazon EFS Utilities ](https://github.com/aws/efs-utils)
+ [ Amazon EBS Autoscale ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Amazon S3 のサンプル ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
# 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/2023-04-10/framework/sus_sus_data_a4.html)
+ 未使用のボリューム、スナップショット、保存期間を過ぎたデータを削除します。削除には、Amazon DynamoDB の有効期限や Amazon CloudWatch ログ保持などのネイティブサービス機能を活用します。
+ ライフサイクルルールに基づいて、該当する場合はデータを集約および圧縮します。
## リソース
**関連するドキュメント:**
+ [Optimize your Amazon S3 Lifecycle rules with Amazon S3 Storage Class Analysis ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)(Amazon S3 ストレージクラス分析によって Amazon S3 ライフサイクルルールを最適化する)
+ [AWS Config ルール を使用してリソースを評価する](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
**関連動画:**
+ [Simplify Your Data Lifecycle and Optimize Storage Costs With Amazon S3 Lifecycle ](https://www.youtube.com/watch?v=53eHNSpaMJI)(Amazon S3 ライフサイクルによってデータライフサイクルを簡素化し、ストレージコストを最適化する)
+ [Reduce Your Storage Costs Using Amazon S3 Storage Lens ](https://www.youtube.com/watch?v=A8qOBLM6ITY)(Amazon S3 ストレージレンズを使用してストレージコストを削減する)
# 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) を使用して、Amazon 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)
+ データボリュームの使用率の目標レベルを設定し、予想される範囲外のボリュームはサイズ変更します。
+ データに合わせて読み取り専用ボリュームのサイズを最適化します。
+ データをオブジェクトストアに移行して、ブロックストレージの固定ボリュームサイズを超える容量をプロビジョンするのを回避します。
+ 伸縮自在なボリュームやファイルシステムを定期的に見直して、アイドルなボリュームを停止し、現在のデータサイズに合わせて過剰プロビジョンされたリソースを縮小します。
## リソース
**関連するドキュメント:**
+ [Amazon FSx ドキュメント](https://docs.aws.amazon.com/fsx/index.html)
+ [What is Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) (Amazon Elastic File System とは)
**関連動画:**
+ [ Deep Dive on Amazon EBS Elastic Volumes ](https://www.youtube.com/watch?v=Vi_1Or7QuOg)(Amazon EBS Elastic Volumes の詳細)
+ [ Amazon EBS and Snapshot Optimization Strategies for Better Performance and Cost Savings ](https://www.youtube.com/watch?v=h1hzRCsJefs)(パフォーマンスとコスト節約の向上を目指した Amazon EBS とスナップショットの最適化戦略)
+ [ Optimizing Amazon EFS for cost and performance, using best practices ](https://www.youtube.com/watch?v=9kfeh6_uZY8)(ベストプラクティスを使用した Amazon EFS のコストとパフォーマンスの最適化)
# SUS04-BP04 不要なデータや重複するデータを削除する
不要なデータや重複するデータを削除し、データセットの保存に必要なストレージリソースを最小限に抑えます。
**一般的なアンチパターン:**
+ 簡単に取得または再作成できるデータを複製している。
+ データの重要性を考慮せず、すべてのデータをバックアップしている。
+ データの削除は、不定期、運用イベント時のみ、または全く行わない。
+ ストレージサービスの耐久性に関係なく、データを冗長に保存している。
+ ビジネス上の正当な理由なく Amazon S3 バージョニングを実行している。
**このベストプラクティスを確立するメリット:** 不要なデータを削除することで、ワークロードに必要なストレージサイズを縮小し、ワークロードの環境に対する影響も軽減します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
不要なデータを保存しない。不要なデータの削除を自動化する。ファイルおよびブロックレベルでデータの重複を排除するテクノロジーを使用する。サービスのネイティブデータレプリケーションと冗長性機能を活用する。
**実装手順**
+ [AWS Data Exchange](https://aws.amazon.com/data-exchange/) および[Open Data on AWS](https://registry.opendata.aws/)で公開されている既存のデータセットを利用することで、データの保存を回避できないかを評価します。
+ ブロックレベルとオブジェクトレベルでデータを重複排除できる仕組みを使用します。AWS でデータの重複をなくす方法の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a6.html)
+ データアクセスを分析し、不要なデータを特定します。ライフサイクルポリシーを自動化します。削除のための [Amazon DynamoDB 有効期限](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)、[Amazon S3 ライフサイクル](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)、[Amazon CloudWatch ログ保持](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html)などのネイティブサービス機能を活用します。
+ AWS のデータ仮想化機能を使用してデータをソースに保持し、データの重複を回避します。
+ [AWS でのクラウドネイティブデータ仮想化](https://www.youtube.com/watch?v=BM6sMreBzoA)
+ [ラボ: Amazon Redshift データ共有を使用したデータパターンの最適化](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ 増分バックアップが可能なバックアップテクノロジーを使用します。
+ セルフマネージドテクノロジー (RAID (Redundant Array of Independent Disks) など) の代わりに、[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)を活用して、耐久性の目標を達成します。
+ ログおよび追跡データを一元化し、同一のログエントリの重複を排除して、必要に応じて冗長性を調整するメカニズムを確立します。
+ キャッシュの事前入力は、正当な場合にのみ行います。
+ キャッシュのモニタリングとオートメーションを確立し、それに従ってキャッシュをサイズ変更します。
+ ワークロードの新しいバージョンをプッシュする際に、オブジェクトストアとエッジキャッシュから古いデプロイとアセットを削除します。
## リソース
**関連するドキュメント:**
+ [CloudWatch Logs のログデータ保持期間を変更する](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server でのデータの重複排除](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [データの重複排除を含む Amazon FSx for ONTAP の機能](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [Amazon CloudFront でのファイルの無効化](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html)
+ [AWS Backup を使用してバックアップを行い、Amazon EFS ファイルシステムを復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html)
+ [Amazon RDS でのバックアップの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**関連動画:**
+ [Fuzzy Matching and Deduplicating Data with ML Transforms for AWS Lake Formation](https://www.youtube.com/watch?v=g34xUaJ4WI4) (AWS Lake Formation の機械学習トランスフォームによるファジーマッチングとデータの重複排除)
**関連する例:**
+ [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/2023-04-10/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)に概説されているように、使用パターンに応じてデータを削除します。
+ クライアントがアクティブに使用していないボリュームをクライアントからデタッチします。
## リソース
**関連するドキュメント:**
+ [ Amazon S3 バケットにファイルシステムをリンクする ](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/)(サーバーレスアプリケーションの AWS Lambda に Amazon EFS を使用する)
+ [ Amazon EFS Intelligent-Tiering Optimizes Costs for Workloads with Changing Access Patterns ](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)(Amazon EFS Intelligent-Tiering はアクセスパターンを変更しワークロードのコストを最適化する)
+ [ オンプレミスデータリポジトリで 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)(Amazon EFS を使用したストレージコストの最適化)
# 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://wellarchitectedlabs.com/sustainability/300_labs/300_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/2023-04-10/framework/sus_sus_data_a8.html)
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [Amazon CloudFront の主な特徴 (CloudFront グローバルエッジネットワークなど)](https://aws.amazon.com/cloudfront/features/)
+ [Amazon OpenSearch Service での HTTP リクエストの圧縮](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Amazon EMR を使用して中間データを圧縮する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [圧縮されたデータファイルを Amazon S3 から Amazon Redshift にロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon CloudFront を使用して圧縮ファイルを提供する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
**関連動画:**
+ [ Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
**関連サンプル:**
+ [ 持続可能性を考慮したアーキテクチャ - ネットワーク間のデータ移動を最小限に抑える ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# 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://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) (Well-Architected ラボ - データのバックアップと復元のテスト) を参照してください。
+ [Automate backups and optimize backup costs for Amazon EFS using AWS Backup](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/) (AWS Backup を使用して Amazon EFS のバックアップを自動化しコストを最適化する)。
## リソース
**関連するベストプラクティス:**
+ [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 スナップショット](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)
+ [ Backing Up Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)(Amazon EFS ファイルシステムのバックアップ)
+ [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 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)(AWS re:Invent 2021 - AWS によるバックアップ、ディザスタリカバリ、ランサムウェア保護)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE) (AWS Backup デモ: クロスアカウントおよびクロスリージョンバックアップ)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft.Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)(AWS re:Invent 2019: AWS Backup の詳細、Rackspace 特集 (STG341))
**関連する例:**
+ [ Well-Architected Lab - Testing Backup and Restore of Data ](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected ラボ - デーのバックアップと復元のテスト)
+ [ Well-Architected Lab - Backup and Restore with Failback for Analytics Workload ](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)(Well-Architected ラボ - 分析ワークロードのフェイルバックによるバックアップと復元)
+ [ Well-Architected Lab - Disaster Recovery - Backup and Restore ](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)(Well-Architected ラボ - ディザスタリカバリ - バックアップと復元)