# SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?
<a name="sus-06"></a>

開発、テスト、デプロイのプラクティスを変更することで、持続可能性への影響を軽減する機会を探します。

**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 持続可能性の目標を伝え、段階的に広める
<a name="sus_sus_dev_a1"></a>

 テクノロジーは持続可能性の重要なイネーブラーです。IT チームは、組織の持続可能性目標に向けて有意義な変化を推進する上で重要な役割を果たします。これらのチームは、会社の持続可能性目標を明確に理解し、それらの優先事項をオペレーション全体に伝え、広めるよう努める必要があります。

 **一般的なアンチパターン:** 
+  組織の持続可能性の目標や、それらがチームにどのように適用されるかがわからない。
+  クラウドワークロードの環境への影響に関する認識とトレーニングが不十分である。
+  優先すべき具体的なエリアが不明である。
+  持続可能性の取り組みに従業員や顧客を関与させていない。

 **このベストプラクティスを活用するメリット:** インフラストラクチャとシステムの最適化から革新的なテクノロジーの使用まで、IT チームは組織の二酸化炭素排出量を削減し、リソースの消費を最小限に抑えることができます。持続可能性の目標を伝えることによって、IT チームは進化する持続可能性の課題を継続的に改善し、適応できるようになります。さらに、これらの持続可能な最適化はコスト削減につながることも多く、ビジネスケースを強化できます。

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

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

 IT チームの主な持続可能性の目標は、システムとソリューションを最適化してリソース効率を高め、組織の二酸化炭素排出量と全体的な環境への影響を最小限に抑えることです。トレーニングプログラムや運用ダッシュボードなどの共有サービスやイニシアチブは、組織が IT オペレーションを最適化し、二酸化炭素排出量を大幅に削減できるソリューションを構築する際に役立ちます。クラウドは、物理インフラストラクチャとエネルギー調達の責任をクラウドプロバイダーの共同責任に移行するだけでなく、クラウドベースのサービスのリソース効率を継続的に最適化する機会も提供します。

 チームがクラウド固有の効率性と責任共有モデルを使用すると、組織の環境への影響を大幅に削減できます。これにより、組織全体の持続可能性の目標に貢献し、より持続可能な未来に向けた取り組みにおける戦略的パートナーとしてのこれらのチームの価値を実証できます。

### 実装手順
<a name="implementation-steps"></a>
+  **目標と目的の定義:** 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)) を使用して、持続可能性について従業員を教育します。持続可能性イニシアチブにエンゲージさせます。成功事例を共有し、称賛します。持続可能性の目標を達成した場合は、インセンティブを使用して報奨します。

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

 **関連ドキュメント:** 
+  [炭素排出量の推定の理解](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 持続可能性の改善を迅速に導入できる方法を採用する
<a name="sus_sus_dev_a2"></a>

 改善の可能性の検証、テストコストの最小化、小規模な改善の提供を行う手段やプロセスを導入します。

 **一般的なアンチパターン:** 
+  持続可能性についてアプリケーションをレビューするのは、プロジェクトの開始時に 1 回だけである。
+  リリースプロセスが複雑すぎてリソース効率化のための小規模な変更を導入しづらいため、ワークロードが古くなった。
+  持続可能性のためにワークロードを改善する仕組みがない。

 **このベストプラクティスを活用するメリット:** 持続可能性に関する改善を導入および追跡するプロセスを確立することで、継続的に新しい機能や能力を導入し、問題を排除して、ワークロードの効率を向上させることができます。

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

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

 本稼働環境にデプロイする前に、持続可能性を改善できるかをテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。

### 実装手順
<a name="implementation-steps"></a>
+  **組織の持続可能性目標の理解と周知:** 二酸化炭素削減やウォータースチュワードシップなど、組織の持続可能性目標を理解します。これらの目標をクラウドワークロードの持続可能性要件に変換します。これらの要件を主なステークホルダーに伝えます。
+  **持続可能性要件のバックログへの追加:** 持続可能性の改善に関する要件を開発バックログに追加します。
+  **反復と改善:** [反復的な改善プロセス](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)を使用して、これらの改善を特定、評価、優先順位付け、テスト、デプロイします。
+  **実用最小限の製品 (MVP) を使用したテスト:** 最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善を開発およびテストし、テストのコストと環境への影響を削減します。
+  **プロセスの合理化:** 開発プロセスを継続的に改善および合理化します。例えば、継続的な統合および配信 (CI/CD) パイプラインを使用してソフトウェア配信プロセスを自動化して、工数レベルを削減し手動プロセスで発生するエラーを減らす可能性のある改善をテストしデプロイします。
+  **トレーニングと啓発:** チームメンバーを対象にトレーニングプログラムを実施して、持続可能性、および活動が組織の持続可能性目標にどのように影響するかについて教育します。
+  **評価と調整:** 改善の影響を継続的に評価し、必要に応じて調整します。

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

 **関連ドキュメント:** 
+  [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 ワークロードを最新に保つ
<a name="sus_sus_dev_a3"></a>

 ワークロードを最新の状態に保ち、効率的な機能を導入し、問題を排除し、ワークロード全体の効率性を向上させます。

 **一般的なアンチパターン:** 
+  現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+  更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。

 **このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。

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

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

 最新のオペレーティングシステム、ランタイム、ミドルウェア、ライブラリ、アプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。定期的に最新の機能やリリースを導入し、ワークロードを最新に保ちます。

### 実装手順
<a name="implementation-steps"></a>
+  **プロセスの定義:** ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを使用します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。
  +  持続可能性への影響を削減する。
  +  パフォーマンスの効率を高める。
  +  計画した改善にとっての障壁を取り除く。
  +  持続可能性に対する影響の測定能力と管理能力を高める。
+  **インベントリの作成:** ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
  +  [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) を使用するとアクティビティをスケジュールできます。

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

 **関連ドキュメント:** 
+  [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 ビルド環境の利用率を高める
<a name="sus_sus_dev_a4"></a>

 リソースの使用率を上げて、ワークロードを開発、テスト、構築します。

 **一般的なアンチパターン:** 
+  ビルド環境を手動でプロビジョニングおよび停止している。
+  テスト、ビルド、リリースアクティビティとは無関係にビルド環境を実行し続けている (例えば、開発チームメンバーの就業時間外に環境を実行している)。
+  ビルド環境にリソースを過剰プロビジョニングしている。

 **このベストプラクティスを活用するメリット:** ビルド環境の使用率を上げることで、構築者が効率的に開発、テスト、構築できるようにリソースを配分しながら、クラウドワークロード全体の効率を上げることができます。

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

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

 オートメーションと Infrastructure as Code (IaC) を使用して、必要に応じてビルド環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。テスト環境は、本稼働構成とよく似たものにする必要があります。ただし、バーストキャパシティ、Amazon EC2 スポットインスタンス、自動スケールするデータベースサービス、コンテナ、サーバーレステクノロジーを備えたインスタンスタイプを使用して、開発およびテストのキャパシティを使用に合わせて調整できる機会を探ります。データ量を、テスト要件を満たす量だけに制限します。本番データをテストに使用する場合は、データを移動するのではなく、本稼働環境とデータを共有できる可能性を探ります。

 **実装手順** 
+  **Infrastructure as Code (IaC) を使用する:** Infrastructure-as-Code を使用してビルド環境をプロビジョニングします。
+  **オートメーションを使用する:** オートメーションを使用して開発環境とテスト環境のライフサイクルを管理し、ビルド用リソースの効率を最大化します。
+  **使用率を最大化する:** 開発環境とテスト環境を最大限に活用する戦略を使用します。
  +  最小限に実行可能である代表的な環境を使用して、潜在的な改善を開発およびテストします。
  +  可能な限り、サーバーレス技術を利用します。
  +  オンデマンドインスタンスを使用して開発者のデバイスを補完します。
  +  バーストキャパシティ、スポットインスタンス、その他のテクノロジーを備えたインスタンスタイプを使用して、ビルドキャパシティを使用状況に合わせて調整します。
  +  踏み台ホストのフリートをデプロイするのではなく、ネイティブなクラウドサービスを採用して、インスタンスシェルのアクセスを保護します。
  +  ビルドジョブに合わせてビルドリソースを自動的にスケールします。

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

 **関連ドキュメント:** 
+  [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 を使用してテストする
<a name="sus_sus_dev_a5"></a>

 マネージド型 Device Farm を使用して、ハードウェアの代表的なセットで新機能を効率的にテストします。

 **一般的なアンチパターン:** 
+  個別の物理デバイス上で、アプリケーションを手動でテストおよびデプロイしている。
+  アプリケーションテストサービスを使用せずに、実際の物理デバイス上でアプリケーションをテストおよび操作している (Android、iOS、ウェブアプリケーションなど)。

 **このベストプラクティスを活用するメリット:** マネージド型 Device Farm を使用してクラウド対応アプリケーションをテストすると、多くのメリットがあります。
+  幅広い種類のデバイスでアプリケーションをテストする、より効率的な機能などです。
+  これにより、テスト用の社内インフラストラクチャが必要なくなります。
+  あまり使われない古いハードウェアを含む、さまざまデバイスタイプが提供されているため、不要なデバイスをアップグレードする必要がなくなります。

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

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

 マネージド型 Device Farm を使用すると、代表的な一連のハードウェアで新機能をテストするプロセスを合理化できます。マネージド型 Device Farm は、あまり使われない古いハードウェアを含むさまざまなデバイスタイプを提供するため、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。

### 実装手順
<a name="implementation-steps"></a>
+  **テストの要件を定義する**: テストの要件と計画 (テストの種類、オペレーティングシステム、テストのスケジュールなど) を定義します。
  +  [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/) 
+  **見直して調整する:** テスト結果を継続的に見直し、必要な改善を行います。

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

 **関連ドキュメント:** 
+  [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)