

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Elastic Beanstalk 環境のトラブルシューティング
<a name="troubleshooting"></a>

この章では、Elastic Beanstalk 環境の問題をトラブルシューティングするためのガイダンスを提供します。この情報には以下が含まれます。
+  AWS Systems Manager の概要。トラブルシューティングのステップと推奨事項を出力する事前定義された Elastic Beanstalk ランブックを実行する手順が含まれます。
+ 環境ステータスが低下した場合に使用するアクションとリソースに関する一般的なガイダンス。
+ カテゴリごとに整理されたより具体的なトラブルシューティングのヒント。

**環境の状態が赤に変わった**場合は、まず事前定義されたランブックを含む AWS Systems Manager ツールを使用して Elastic Beanstalk のトラブルシューティングを行うことをお勧めします。詳細については、「[ Systems Manager ツールの使用](#troubleshooting-systems-manager)」を参照してください。

**AI アシストによるトラブルシューティングのために Amazon Q Developer CLI を試す**  
 Amazon Q Developer CLI は、環境の問題を迅速にトラブルシューティングするのに役立ちます。Q CLI は、環境ステータスのチェック、イベントの確認、ログの分析、および明確化のための質問を行うことでソリューションを提供します。詳細と詳細なチュートリアルについては、 AWS ブログの[「Amazon Q Developer CLI を使用した Elastic Beanstalk 環境のトラブルシューティング](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/)」を参照してください。

**Topics**
+ [AI を活用した環境分析の使用](#troubleshooting-ai-analysis)
+ [AWS Systems Manager Elastic Beanstalk ランブックの使用](#troubleshooting-systems-manager)
+ [Elastic Beanstalk 環境のトラブルシューティングに関する一般的なガイダンス](#troubleshooting-general)
+ [環境変数を使用してシークレットとパラメータにアクセスする環境](#troubleshooting-secrets-env-variables)
+ [環境の作成とインスタンスの起動](#troubleshooting-envcreate)
+ [デプロイ](#troubleshooting-deployments)
+ [健康](#troubleshooting-health)
+ [デュアルスタック設定されたロードバランサーを備えた環境](#troubleshooting-dual-stack-load-balancer)
+ [設定](#troubleshooting-configuration)
+ [Docker コンテナのトラブルシューティング](#troubleshooting-docker)
+ [よくある質問](#troubleshooting-faq)
+ [共通エラー](#common-errors)
+ [デプロイエラー](#python-common-troubleshooting)

## AI を活用した環境分析の使用
<a name="troubleshooting-ai-analysis"></a>

Elastic Beanstalk は AI を活用した分析を提供し、根本原因を特定し、環境のヘルス問題に対する解決策を提案します。この機能は、コンソールの **AI 分析**ボタン、 を介して Elastic Beanstalk API を使用する AWS CLI、または EB CLI **eb logs --analyze**で実行することでアクセスできます。この分析では、環境のログ、イベント、インスタンスの状態を調べて重要な問題を特定し、step-by-step推奨事項を提供します。

詳細については、「[AI を活用した環境分析](health-ai-analysis.md)」を参照してください。

## AWS Systems Manager Elastic Beanstalk ランブックの使用
<a name="troubleshooting-systems-manager"></a>

Systems Manager を使用して Elastic Beanstalk 環境のトラブルシューティングを行うことができます。Systems Manager は、お客様にすぐに使用を開始していただけるように、Elastic Beanstalk 用に事前定義されたオートメーションランブックを用意しています。オートメーションランブックは、環境のインスタンスやその他の  AWS  リソースで実行するアクションを定義する Systems Manager ドキュメントの一種です。

このドキュメント `AWSSupport-TroubleshootElasticBeanstalk` は、Elastic Beanstalk 環境のパフォーマンスが低下する可能性のある一般的な問題をいくつか特定するのに役立つように設計されたオートメーションランブックです。そうするためには、EC2 インスタンス、VPC、 CloudFormation  スタック、ロードバランサー、Auto Scaling グループ、セキュリティグループルール、ルートテーブル、ACL に関連するネットワーク設定など、環境のコンポーネントをチェックします。

また、バンドルされたログファイルを環境から  AWS  サポートにアップロードするオプションもあります。

詳細については「*AWS Systems Manager 自動 ランブックリファレンス*」の [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html) を参照してください。

**Systems Manager を使用して `AWSSupport-TroubleshootElasticBeanstalk` ランブックを実行する**
**注記**  
この手順は、Elastic Beanstalk 環境 AWS リージョン があるのと同じ で実行します。

1. [AWS Systems Manager](https://console.aws.amazon.com/systems-manager/home) コンソールを開きます。

1. ナビゲーションペインの **[変更管理]** で、**[オートメーション]** を選択します。

1. [**Execute automation (自動化の実行)**] を選択してください。

1. **[Amazon が所有]** タブの**[オートメーションドキュメント]** 検索ボックスに、「`AWSSupport-TroubleshootElasticBeanstalk`」を入力します。

1. **[AWSSupport-TroubleshootElasticBeanstalk]** カードを選択してから、**[次へ]** を選択します。

1. **[実行]** を選択します。

1. **[入力パラメータ]** セクションで、以下の操作を行います。

   1. **[AutomationAssumeRole]** ドロップダウンから、System Manager がユーザーに代わってアクションを実行できるようにするロールの ARN を選択します。

   1. **[ApplicationName]** に、Elastic Beanstalk アプリケーションの名前を入力します。

   1. **[環境名]** には、Elastic Beanstalk 環境を入力します。

   1. (オプション) **S3UploaderLink** の場合、 AWS サポートエンジニアからログ収集用の S3 リンクが提供されている場合は、リンクを入力します。

1. **[実行]** を選択してください。

   いずれかのステップが失敗した場合は、失敗したステップの **[ステップ ID]** 列の下にあるリンクを選択します。これにより、ステップの **[実行詳細]** ページが表示されます。**[VerificationErrorMessage]** セクションには、注意が必要な手順の概要が表示されます。たとえば、`IAMPermissionCheck` には警告メッセージが表示される場合があります。この場合、**[AutomationAssumeRole]** ドロップダウンで選択したロールに必要な権限があるかどうかを確認できます。

すべての手順が正常に完了すると、出力にはトラブルシューティングの手順および環境を正常な状態に復元するための推奨事項が表示されます。

## Elastic Beanstalk 環境のトラブルシューティングに関する一般的なガイダンス
<a name="troubleshooting-general"></a>

エラー メッセージは、コンソールの [イベント] ページ、ログ、または [ヘルス] ページに表示されることがあります。また、最近の変更によってパフォーマンスが低下した環境から回復するための対策を講じることもできます。対象環境のヘルスステータスが「赤色」に変わった場合は、以下の操作を試してください。
+ 環境の AI を活用した分析をリクエストします。詳細については、「[AI を活用した環境分析](health-ai-analysis.md)」を参照してください。
+ 環境に対するオペレーションが `The stack {{stack_id}} associated with environment {{environment-ID}} is in {{stack-status}} state` というテキストを含むエラーを返した場合、トラブルシューティングのヘルプについては「[Elastic Beanstalk 環境を無効な状態から復旧する](environment-management-invalid-stack.md)」を参照してください。
+ 環境に対するオペレーションが `Environment {{environment-name}} associated CloudFormation stack {{stack_arn}} does not exist` というテキストを含むエラーを返した場合、その環境を終了して別の環境を作成します。
+ 最新の環境[イベント](using-features.events.md)を確認します。デプロイ、負荷、設定の問題に関する Elastic Beanstalk からのメッセージは、多くの場合、ここに表示されています。
+ 最近の、環境に関する[変更履歴](using-features.changehistory.md)を確認します。変更履歴には、環境に加えられたすべての設定変更の内容がリストされています。さらに、変更を行った IAM ユーザーや、設定が行われたパラメータなど、その他の情報も含まれています。
+ [ログをプル](using-features.logging.md)して、最新のログファイルエントリを表示します。ウェブサーバーのログには、受信リクエストおよびエラーに関する情報が含まれています。
+ [インスタンスに接続](using-features.ec2connect.md)し、システムリソースをチェックします。
+ アプリケーションの以前の稼働バージョンに[ロールバック](using-features.deploy-existing-version.md)します。
+ 最新の設定変更を元に戻すか、[保存した設定](environment-configuration-methods-before.md#configuration-options-before-savedconfig)を復元します。
+ 新しい環境をデプロイします。この新しい環境に特に問題がないと確認できたら、[CNAME スワップ](using-features.CNAMESwap.md)を実行してその環境にトラフィックをルーティングし、以前の環境のデバッグを続けます。

## 環境変数を使用してシークレットとパラメータにアクセスする環境
<a name="troubleshooting-secrets-env-variables"></a>

**イベント:** *インスタンスのデプロイで 1 つ以上のシークレットを取得できませんでした*

このメッセージは、Elastic Beanstalk がアプリケーションのデプロイ中に指定された 1 つ以上のシークレットをフェッチできなかったことを示します。
+ 環境変数設定の ARN 値で指定されたリソースが存在することを確認します。
+ Elastic Beanstalk EC2 インスタンスプロファイルロールに、リソースにアクセスするために必要な [IAM アクセス許可](AWSHowTo.secrets.IAM-permissions.md#AWSHowTo.secrets.IAM-permissions.secrets-manager)があることを確認します。
+ このイベントが `RestartAppServer` オペレーションを介してトリガーされた場合、問題が修正されたら、`RestartAppServer` コールを再試行して問題を解決します。
+ イベントが `UpdateEnvironment` コールを介してトリガーされた場合は、`UpdateEnvironment` オペレーションを再試行します。

これらのコマンドの例については、「[https://docs.aws.amazon.com//cli/latest/userguide/cli_elastic-beanstalk_code_examples.html](https://docs.aws.amazon.com//cli/latest/userguide/cli_elastic-beanstalk_code_examples.html)」を参照してください。これらのオペレーションの API アクションの詳細については、「*[AWS Elastic Beanstalk API リファレンス](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)*」を参照してください。

**イベント:** *インスタンスのデプロイで、このプラットフォームではサポートされていない 1 つ以上の複数行の環境値が検出されました*

複数行変数は、Docker および ECS マネージド Docker プラットフォームを除き、Amazon Linux 2 プラットフォームではサポートされていません。続行できるオプションについては、「[複数行の値](AWSHowTo.secrets.env-vars.md#AWSHowTo.secrets.multiline)」を参照してください。

**イベント:** *シークレットが指定されると CreateEnvironment が失敗する*

`CreateEnvironment` が失敗し、環境変数としてシークレットがある場合は、根本的な問題に対処してから、`UpdateEnvironment` を使用して環境設定を完了する必要があります。この状況では環境を起動するには十分ではないため、`RestartAppServer` を使用しないでください。これらのコマンドの例については、「[https://docs.aws.amazon.com//cli/latest/userguide/cli_elastic-beanstalk_code_examples.html](https://docs.aws.amazon.com//cli/latest/userguide/cli_elastic-beanstalk_code_examples.html)」を参照してください。これらのオペレーションの API アクションの詳細については、「*[AWS Elastic Beanstalk API リファレンス](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)*」を参照してください。

## 環境の作成とインスタンスの起動
<a name="troubleshooting-envcreate"></a>

**イベント:** *環境を起動できませんでした*

このイベントは、Elastic Beanstalk が環境を起動しようとし、その途中でエラーが起こったときに発生します。[**イベント**] ページの以前のイベントが、この問題の根本的な原因について警告します。

**イベント:** *環境の作成オペレーションは完了しましたが、コマンドがタイムアウトしました。タイムアウト期間を長くしてみてください。*

インスタンス上でコマンドを実行する、大きなファイルをダウンロードする、あるいはパッケージをインストールするために設定ファイルを使用すると、アプリケーションのデプロイに時間がかかる場合があります。[コマンドタイムアウト](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console)を増やして、デプロイ中にアプリケーションが実行開始できる時間を多くしてください。

**イベント:** *以下のリソースで [AWSEBInstanceLaunchWaitCondition] を作成できませんでした*

このメッセージは、環境の Amazon EC2 インスタンスが、正常に起動した Elastic Beanstalk と通信しなかったことを示します。これは、インスタンスにインターネットの接続がない場合に発生します。プライベート VPC サブネットでインスタンスを起動するように環境を設定した場合は、インスタンスに対して Elastic Beanstalk への接続を許可する [NAT がサブネットにある](vpc.md)ことを確認します。

**イベント:** *このリージョンではサービスロールが必要です。環境にサービスロールオプションを追加してください。*

Elastic Beanstalk はサービスロールを使用して環境のリソースをモニタリングし、[マネージド型プラットフォーム更新](environment-platform-update-managed.md)をサポートします。詳細については「[Elastic Beanstalk サービスロールの管理](iam-servicerole.md)」を参照してください。

## デプロイ
<a name="troubleshooting-deployments"></a>

**問題:** *デプロイ中にアプリケーションが使用不可になります*

Elastic Beanstalk はドロップインアップグレードプロセスを使用するため、数秒間のダウンタイムが生じることがあります。[ローリングデプロイ](using-features.rolling-version-deploy.md)を使用して、運用環境におけるデプロイの影響を最小化します。

**イベント:** *Elastic Beanstalk AWS アプリケーションバージョンの作成に失敗しました*

アプリケーションソースバンドルが大きすぎるか、[アプリケーションバージョンクォータ](applications-versions.md)に達した可能性があります。

**イベント:** *環境更新オペレーションは完了しましたが、コマンドがタイムアウトしました。タイムアウト期間を長くしてみてください。*

インスタンス上でコマンドを実行する、大きなファイルをダウンロードする、あるいはパッケージをインストールするために設定ファイルを使用すると、アプリケーションのデプロイに時間がかかる場合があります。[コマンドタイムアウト](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console)を増やして、デプロイ中にアプリケーションが実行開始できる時間を多くしてください。

## 健康
<a name="troubleshooting-health"></a>

**イベント:** *CPU 使用率が 95.00％ を超える*

[実行するインスタンスを増やす](using-features.managing.as.md)か、[別のインスタンスタイプを選択](using-features.managing.ec2.md)してください。

**イベント:** *Elastic Load Balancer awseb-{{myapp}} ゼロヘルスインスタンスがあり*、*ELB プロセスは {{Y}} インスタンスのうち {{X}} インスタンスでは正常ではありません。*、*ELB プロセスはすべてのインスタンスで正常ではありません。*

これらのメッセージは、ロードバランサーのヘルスチェックが 1 つ以上のインスタンスで失敗していることを示します。アプリケーションが動作しているように見える場合は、アプリケーションのヘルスチェック URL が正しく設定されていることを確認してください。そうでない場合は、以下を試してください。
+ アプリケーションログ ( など`/var/log/web.stdout.log`) と をチェックして、エラー、起動失敗、デプロイの問題`/var/log/eb-engine.log`がないか確認します。
+ (nginx) または `/var/log/nginx/` (`/var/log/httpd/`Apache) の接続エラーがないかプロキシログを確認します。
+ アプリケーションが設定されたヘルスチェックパスに HTTP 200 で応答し、予想されるポートをリッスンしていることを確認します。
+ セキュリティグループがロードバランサーからヘルスチェックポートのインスタンスへのインバウンドトラフィックを許可していることを確認します。EC2 コンソールで、インスタンスのセキュリティグループのインバウンドルールをチェックして、ヘルスチェックポートがロードバランサーのセキュリティグループに対して開いていることを確認します。
+ CloudWatch メトリクス (`CPUUtilization`、) で CPU とメモリの使用率を確認します`EnvironmentHealth`。リソースを使い果たすと、ヘルスチェックのタイムアウトが発生する可能性があります。

詳細については、[完全なバンドルログを取得する](using-features.logging.md)か、[CloudWatch ログストリーミングを有効にします](AWSHowTo.cloudwatchlogs.md)。[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html) オートメーションランブックを実行して、問題を診断することもできます。

**イベント:** *Elastic Load Balancer awseb-{{myapp}} が見つかりません*

環境のロードバランサーが帯域外に削除された可能性があります。環境のリソースに対する変更は、Elastic Beanstalk によって提供される設定オプションおよび[拡張可能性](ebextensions.md)のみにしてください。環境を再構築するか、新しいインスタンスを起動してください。

**イベント:** *EC2 インスタンス起動エラー。新しい EC2 インスタンスの起動の待機中...*

環境のインスタンスタイプの可用性が低いか、アカウントのインスタンスクォータに達した可能性があります。[サービスヘルスダッシュボード](https://status.aws.amazon.com/)を調べ、Elastic Compute Cloud (Amazon EC2) サービスが緑色になっていることを確認してください。なっていない場合は[クォータの引き上げをリクエスト](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-ec2-instances)してください。

**イベント:** *どのインスタンスもデータを送信していません。*

Elastic Beanstalk はインスタンスからヘルスデータを受信していません。これは、ネットワーク接続の問題、ヘルスエージェントの問題、またはシステムレベルの障害が原因である可能性があります。
+ ネットワーク接続を確認します。セキュリティグループがアウトバウンド HTTPS (ポート 443) を許可していることを確認します。プライベートサブネットのインスタンスの場合は、NAT ゲートウェイまたは VPC エンドポイントが設定されていることを確認します。ルートテーブルで正しいアウトバウンドルートを確認し、VPC で DNS 解決が正しく機能することを確認します。
+ ヘルスモニタリングエージェントを確認します。`/var/log/healthd/daemon.log` ヘルスエージェントのエラーとシステムレベルのエラー`/var/log/messages`を確認します。SSH 経由でインスタンスに接続し、 を実行して、ヘルスサービスが実行されていることを確認します`systemctl status healthd`。
+ リソースの枯渇 (メモリ、CPU、ディスク容量）、NTP/システムクロックの同期、インスタンスメタデータサービスの接続などのシステムレベルの問題を確認します。

詳細については、[完全なバンドルログを取得する](using-features.logging.md)か、[CloudWatch ログストリーミングを有効にします](AWSHowTo.cloudwatchlogs.md)。[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshoot-elastic-beanstalk.html) オートメーションランブックを実行して、問題を診断することもできます。

## デュアルスタック設定されたロードバランサーを備えた環境
<a name="troubleshooting-dual-stack-load-balancer"></a>

**イベント:** *VPC {{vpc\_id}} には IPv6 CIDR ブロックが設定されていません。デュアルスタックロードバランサーには IPv6 CIDR ブロックが必要です。デュアルスタックモードを使用する前に、IPv6 CIDR ブロックを VPC に関連付けてください。*

VPC とすべてのサブネットには IPv6 CIDR ブロックが関連付けられている必要があります。これは、デュアルスタックのサポート用にロードバランサーを設定する前に完了する必要がある VPC 前提条件の 1 つです。このタスクを完了するための詳細については、このトピックで前述した「[Amazon VPC の前提条件](environments-cfg-elbv2-ipv6-dualstack.md#environments-cfg-elbv2-ipv6-dualstack.prereqs)」を参照してください。

 **イベント:** *VPC {{vpc\_id}} の 1 つ以上のサブネットに IPv6 CIDR ブロックが設定されていません。デュアルスタックロードバランサーとともに使用されるサブネットには、IPv6 CIDR ブロックが必要です。デュアルスタックモードを使用する前に、IPv6 CIDR ブロックをすべての必要なサブネットに関連付けてください。*

VPC のすべてのサブネットには、IPv6 CIDR ブロックが関連付けられている必要があります。これは、デュアルスタックのサポート用にロードバランサーを設定する前に完了する必要がある VPC 前提条件の 1 つです。このタスクを完了するための詳細については、このトピックで前述した「[Amazon VPC の前提条件](environments-cfg-elbv2-ipv6-dualstack.md#environments-cfg-elbv2-ipv6-dualstack.prereqs)」を参照してください。

 **エラー:** *`IpAddressType` オプションは、Application Load Balancer または Network Load Balancer を使用して設定された Elastic Beanstalk 環境にのみ適用されます。*

このメッセージは、Elastic Beanstalk 環境が単一のインスタンス環境であるか、Classic Load Balancer を使用している可能性があることを示しています。Application Load Balancer または Network Load Balancer を使用して設定された環境のみが `IpAddressType` を設定できます。

## 設定
<a name="troubleshooting-configuration"></a>

**イベント:** *環境 `{{environment-ID}}` に関連付けられたスタック `{{stack_id}}` が `{{stack-status}}` 状態です*

環境の基盤となる CloudFormation スタックは \**\_FAILED *ステータスの場合があります。環境で Elastic Beanstalk オペレーションを続行するには、このステータスを修正する必要があります。詳細については、「[Elastic Beanstalk 環境を無効な状態から復旧する](environment-management-invalid-stack.md)」を参照してください。

**イベント:** *Elastic Load Balancing Target オプションおよび Application Healthcheck URL オプションの値を使用して、Elastic Beanstalk 環境を設定することはできません。*

`Target` 名前空間の `aws:elb:healthcheck` オプションは廃止されました。`Target` オプション名前空間を環境から削除してもう一度更新してください。

**イベント:** *ELB を同じ AZ 内の複数のサブネットに接続することはできません*

このメッセージは、同じアベイラビリティーゾーン内のサブネット間でロードバランサーを移動しようとすると表示される場合があります。ロードバランサーのサブネットを変更するには、元のアベイラビリティーゾーンの外に移動してから、必要なサブネットを用意した元のアベイラビリティーゾーンに戻す必要があります。この処理中は、すべてのインスタンスは AZ 間で移行されるため、長時間のダウンタイムが発生します。代わりに、新しい環境を作成して [CNAME のスワップを実行](using-features.CNAMESwap.md)することを検討してください。

## Docker コンテナのトラブルシューティング
<a name="troubleshooting-docker"></a>

**イベント:** *Docker イメージを取得できませんでした :latest: 無効なリポジトリ名です ()。[a-z0-9-\_.] のみが許可されています。詳細については、ログを追跡します。*

JSON 検証ツールを使用して `dockerrun.aws.json` ファイルの構文をチェックします。また、「[Elastic Beanstalk へのデプロイ用に Docker イメージを準備する](single-container-docker-configuration.md)」で説明されている要件を参照して dockerfile の内容を確認します。

**イベント:** *Dockerfile に EXPOSE ディレクティブが見つかりません。デプロイを中止します*

`Dockerfile` または `dockerrun.aws.json` ファイルでコンテナポートが宣言されていません。`EXPOSE` インストラクション (`Dockerfile`) または `Ports` ブロック (`dockerrun.aws.json` ファイル) を使用して、受信トラフィックに対してポートを開きます。

**イベント:** {{バケット名}}から認証資格情報{{リポジトリ}}をダウンロードできませんでした

`dockerrun.aws.json` ファイルは `.dockercfg` ファイルに無効な EC2 キーペアや S3 バケットを指定します。または、インスタンスプロファイルに S3 バケットの GetObject の権限がありません。`.dockercfg` ファイルに有効な S3 バケットと EC2 キーペアが含まれていることを確認します。インスタンスプロファイル内の IAM ロールに `s3:GetObject` 操作を許可します。詳細については、[Elastic Beanstalk インスタンスプロファイルの管理](iam-instanceprofile.md) を参照してください

**イベント:** *以下の理由により、アクティビティの実行に失敗しました。警告: 認証設定ファイルが無効です*

認証ファイル（`config.json`）が正しくフォーマットされていません。「[イメージリポジトリを使用した認証の使用 AWS Secrets Manager](docker-configuration.remote-repo.md)」を参照してください。

## よくある質問
<a name="troubleshooting-faq"></a>

**質問:***アプリケーション URL を、myapp.us-west-2.elasticbeanstalk.com から www.myapp.com に変更したい。*

DNS サーバーで、**www.mydomain.com CNAME mydomain.elasticbeanstalk.com** などの CNAME レコードを登録します。

**質問:** *Elastic Beanstalk アプリケーションに特定のアベイラビリティーゾーンを指定できない。*

API、CLI、Eclipse プラグイン、または Visual Studio プラグインを使用すると、特定のアベイラビリティーゾーンを指定できます。Elastic Beanstalk コンソールを使用してアベイラビリティーゾーンを指定する方法については、「[Elastic Beanstalk 環境インスタンスの Auto Scaling](using-features.managing.as.md)」を参照してください。

**質問:** *環境のインスタンスタイプを変更したい*

環境のインスタンスタイプを変更するには、[環境設定] ページに移動し、**[インスタンス]** 設定カテゴリにある **[編集]** をクリックします。新しいインスタンスタイプを選択し、[**適用**] をクリックして環境を更新します。その後、実行中のすべてのインスタンスが Elastic Beanstalk により終了され、新しいインスタンスに置き換えられます。

**質問:** *いずれかのユーザーが環境設定を変更したかどうかを知るにはどうすればよいですか?*

この情報を表示するには、Elastic Beanstalk コンソールのナビゲーションペインで [**変更履歴**] をクリックして、すべての環境の設定変更のリストを表示します。このリストから、変更の日時、設定されたパラメータと変更後の値、その変更を行った IAM ユーザーが確認できます。詳細については、「[変更履歴](using-features.changehistory.md)」を参照してください。

**質問:** *インスタンスの終了時に Amazon EBS ボリュームが削除されないようにしたい。*

環境内のインスタンスは Amazon EBS を使用して保管されますが、Auto Scaling によってインスタンスが終了されると、ルートボリュームが削除されます。ご自身のインスタンス上に、状態やその他のデータを保存することは推奨されません。必要に応じて、「 [AWS CLI リファレンス](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html)」で説明されている`$ aws ec2 modify-instance-attribute -b '/dev/sdc=<vol-id>:false`ように、 AWS CLIを使用してボリュームが削除されないようにできます。

**質問:** *Elastic Beanstalk アプリケーションから個人情報を削除したい。*

AWS Elastic Beanstalk アプリケーションが使用する リソースは、個人情報を保存する場合があります。環境を終了すると、Elastic Beanstalk で作成されたリソースが終了されます。[設定ファイル](ebextensions.md)を使用して、追加したリソースも終了します。ただし、Elastic Beanstalk 環境の外部で AWS リソースを作成し、アプリケーションに関連付ける場合は、アプリケーションが保存した可能性のある個人情報が保持されないように手動で確認する必要がある場合があります。このデベロッパーガイドを通して追加リソースの作成について取り扱う際は、それらの削除を検討する必要がある場合についても必ず言及しています。

## 共通エラー
<a name="common-errors"></a>

このトピックでは、EB CLI の使用時に表示される一般的なエラーメッセージと考えられる解決策を示しています。ここに示していないエラーメッセージが表示される場合は、[*フィードバック*] リンクを使用してお知らせください。

**エラー: Git コマンドの処理中にエラーが発生しました。エラーコード: 128 エラー: 致命的: 有効なオブジェクト名 HEAD ではありません**

**原因**: Git リポジトリを初期化したが、まだコミットしていない場合にこのエラーメッセージが表示されます。プロジェクトフォルダーに Git リポジトリが含まれていると、EB CLI は HEAD リビジョンを検索します。

**解決策:** ステージングエリアにプロジェクトフォルダ内のファイルを追加してコミットします。

```
~/my-app$ git add .
~/my-app$ git commit -m "First commit"
```

**エラー: このブランチにはデフォルト環境がありません。「eb status my-env-name」と入力して環境を指定するか、「eb use my-env-name」と入力してデフォルト環境を設定する必要があります。**

**原因:** Git で新しいブランチを作成すると、デフォルトでは Elastic Beanstalk 環境にアタッチされません。

**解決策:** **eb list** を実行して、利用可能な環境のリストを表示します。その後、**eb use {{env-name}}** を実行して、利用可能な環境のいずれかを使用します。

**エラー: 2.0 以上のプラットフォームにはサービスロールが必要です。サービスロールは、--service-role オプションで指定できます**

**原因:** **eb create** で環境名 (**eb create my-env** など) を指定した場合、EB CLI はサービスロールの自動作成を試みません。デフォルトのサービスロールがない場合、上記のエラーが表示されます。

**解決策:** 環境名を指定しないで **eb create** を実行し、プロンプトに従ってデフォルトのサービスロールを作成します。

## デプロイエラー
<a name="python-common-troubleshooting"></a>

Elastic Beanstalk のデプロイは、404 (アプリケーションの起動に失敗した場合) または 500 (ランタイム中にアプリケーションが失敗した場合) のレスポンスで応答する場合があります。多くの一般的な問題のトラブルシューティングを行うには、EB CLI を使用してデプロイのステータスの確認、ログの表示、SSH を使用した EC2 インスタンスへのアクセスの取得、またはアプリケーション環境の AWS マネジメントコンソールページを開くことができます。

**EB CLI を使用してデプロイのトラブルシューティングを行うには**

1. **eb status** を実行して、現在のデプロイのステータスおよび EC2 ホストの状態を確認します。例えば、次のようになります。

   ```
   $ eb status --verbose
   
   Environment details for: python_eb_app
     Application name: python_eb_app
     Region: us-west-2
     Deployed Version: app-150206_035343
     Environment ID: e-wa8u6rrmqy
     Platform: 64bit Amazon Linux 2014.09 v1.1.0 running Python 2.7
     Tier: WebServer-Standard-
     CNAME: python_eb_app.elasticbeanstalk.com
     Updated: 2015-02-06 12:00:08.557000+00:00
     Status: Ready
     Health: Green
     Running instances: 1
         i-8000528c: InService
   ```
**注記**  
`--verbose` スイッチを使用すると、実行中のインスタンスのステータスに関する情報が表示されます。このスイッチを指定しない場合、**eb status** では、環境に関する全般的な情報のみが表示されます。

1. 環境のヘルス情報を表示するには、**eb health** を実行します。

   ```
   $ eb health --refresh
    elasticBeanstalkExa-env                                  Degraded                  2016-03-28 23:13:20
   WebServer                                                                              Ruby 2.1 (Puma)
     total      ok    warning  degraded  severe    info   pending  unknown
       5        2        0        2        1        0        0        0
   
     instance-id   status     cause
       Overall     Degraded  Incorrect application version found on 3 out of 5 instances. Expected version "Sample Application" (deployment 1).
     i-d581497d    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
     i-d481497c    Degraded  Incorrect application version "v2" (deployment 2). Expected version "Sample Application" (deployment 1).
     i-136e00c0    Severe    Instance ELB health has not been available for 5 minutes.
     i-126e00c1    Ok
     i-8b2cf575    Ok
   
     instance-id   r/sec    %2xx   %3xx   %4xx   %5xx      p99      p90      p75     p50     p10
       Overall     646.7   100.0    0.0    0.0    0.0    0.003    0.002    0.001   0.001   0.000
     i-dac3f859    167.5    1675      0      0      0    0.003    0.002    0.001   0.001   0.000
     i-05013a81    161.2    1612      0      0      0    0.003    0.002    0.001   0.001   0.000
     i-04013a80    0.0         -      -      -      -         -        -       -       -       -
     i-3ab524a1    155.9    1559      0      0      0    0.003    0.002    0.001   0.001   0.000
     i-bf300d3c    162.1    1621      0      0      0    0.003    0.002    0.001   0.001   0.000
   
     instance-id   type       az   running     load 1  load 5      user%  nice%  system%  idle%   iowait%
     i-d581497d    t2.micro   1a   25 mins       0.16     0.1        7.0    0.0      1.7   91.0       0.1
     i-d481497c    t2.micro   1a   25 mins       0.14     0.1        7.2    0.0      1.6   91.1       0.0
     i-136e00c0    t2.micro   1b   25 mins        0.0    0.01        0.0    0.0      0.0   99.9       0.1
     i-126e00c1    t2.micro   1b   25 mins       0.03    0.08        6.9    0.0      2.1   90.7       0.1
     i-8b2cf575    t2.micro   1c   1 hour        0.05    0.41        6.9    0.0      2.0   90.9       0.0
     
     instance-id   status     id   version              ago                                  deployments
     i-d581497d    Deployed   2    v2                   9 mins
     i-d481497c    Deployed   2    v2                   7 mins
     i-136e00c0    Failed     2    v2                   5 mins
     i-126e00c1    Deployed   1    Sample Application   25 mins
     i-8b2cf575    Deployed   1    Sample Application   1 hour
   ```

   上記の例は、5 つあるインスタンスのうち、3 番目のインスタンスでバージョン「v2」のデプロイに失敗した環境を示しています。デプロイの失敗後、想定されたバージョンは正常にデプロイされた最後のバージョン（この例では、最初のデプロイの「サンプルアプリケーション」）にリセットされます。詳細については「[EB CLI を使用した環境ヘルスのモニタリング](health-enhanced-ebcli.md)」を参照してください。

1. **eb logs** を実行して、アプリケーションのデプロイに関連付けられたログをダウンロードして表示します。

   ```
   $ eb logs
   ```

1. **eb ssh** を実行して、アプリケーションを実行している EC2 インスタンスに接続し、直接調査します。インスタンスでは、デプロイされたアプリケーションは `/opt/python/current/app` ディレクトリに、Python 環境は `/opt/python/run/venv/` にあります。

1. **eb console** を実行して、[AWS マネジメントコンソール](https://aws.amazon.com/console/)でアプリケーション環境を表示します。ウェブインターフェイスを使用して、アプリケーションの設定、ステータス、イベント、ログなど、デプロイのさまざまな側面を簡単に調査できます。また、サーバーにデプロイした現在または過去のアプリケーションバージョンをダウンロードすることもできます。