AWS Cloud9 のトラブルシューティング

以下の情報を使用して、AWS Cloud9 の問題を特定および対処します。

該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、AWS Cloud9 フォーラムを参照してください。(このフォーラムにアクセスするには AWS へのサインインが必要になることがあります。) 当社に直接お問い合わせいただくこともできます。

環境の作成エラー: 「EC2 インスタンスを作成することができません...」

問題: AWS Cloud9 開発環境を作成しようとすると、「アカウントの検証とアクティベーション中に、アカウントで EC2 インスタンスを作成できません」というメッセージが表示される。

原因: 現在、AWS はお客様の AWS アカウントを確認およびアクティブ化中です。アクティベーションが完了するまで (最大 24 時間かかる場合があります)、この環境やその他の環境を作成することはできません。

解決策: 環境をもう一度作成してみてください。24 時間以上経過してもこのメッセージがまだ表示される場合は、[e-mail] に E メールでお問い合わせください。AWS CloudFormation は、環境の作成に失敗しても、関連するスタックをアカウントで作成することに注意してください。これらのスタックは、アカウントでのスタック作成制限に対してカウントされます。スタック作成制限に達するのを回避するため、失敗したスタックを削除しても問題ありません。詳細については、「」を参照してください。AWS CloudFormation コンソールでのスタックの削除()AWS CloudFormation ユーザーガイド。

(先頭に戻る)

環境の作成エラー: 「sts: AssumeRole を実行する権限がありません」

問題: 新しい環境を作成しようとすると、次のエラーが表示されます。「sts: AssumeRole を実行する権限がありません」と環境が作成されません。

考えられる原因: AWS Cloud9 サービスにリンクされたロールが AWS アカウントに存在しません。

推奨される解決策: AWS コマンドラインインターフェイス (AWS CLI) または aws-shell を使用して次のコマンドを実行し、AWS Cloud9 サービスにリンクされたロールを AWS アカウント内で作成します。

aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the AWS CLI.
iam create-service-linked-role --aws-service-name cloud9.amazonaws.com     # For the aws-shell.

これを実行できない場合は、AWS アカウントの管理者に確認してください。

このコマンドを実行した後、もう一度環境の作成を試みます。

(先頭に戻る)

コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」

問題: AWS Cloud9 コンソールを使用して AWS Cloud9 開発環境を作成したり管理したりしようとすると、「ユーザー arN: aws: iam: iam። 123456789012: ユーザー/myuser がクラウド9: アクションを実行することは許可されていない。リソースの arn: aws: cloud9: us-east-2:123456789012: 環境:123456789012: 環境:12a34564564566 b8cd9012345ef67abcd890e1」。ここで、

• arn:aws:iam::123456789012:user/MyUser は、リクエストするユーザーの Amazon リソースネーム (ARN) です。

• action は、ユーザーがリクエストしたオペレーションの名前です。

• arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1は、ユーザーがオペレーションを実行するためにリクエストした環境の ARN です。

原因: AWS Cloud9 コンソールにサインインするときに使用したユーザーに、このアクションを実行するための正しい AWS アクセス権限がありません。

解決策: ユーザーが正しい AWS アクセス権限を持っていることを確認して、もう一度アクションの実行を試みます。詳細については、次のトピックの 1 つ以上を参照してください。

• ステップ 3: AWS Cloud9 アクセス権限をグループに追加するチームセットアップ

• ステップ 6. 組織内のグループとユーザーが AWS Cloud9 を使用できるようにするエンタープライズセットアップ

• 環境メンバーのアクセスロールについて共有環境を使用する

(先頭に戻る)

フェデレーション ID で環境を作成できない

問題: AWS フェデレーテッドアイデンティティを使用して AWS Cloud9 開発環境を作成しようとすると、アクセスエラーメッセージが表示され、環境は作成されません。

原因: : AWS Cloud9 は、サービスにリンクされたロールを使用します。サービスにリンクされたロールは、アカウントに初めて環境が作成されたときに作成されます。iam:CreateServiceLinkedRoleを呼び出します。ただし、フェデレーティッドユーザーは IAM API を呼び出すことができません。詳細については、「」を参照してください。GetFederationToken()AWS Security Token Service API リファレンス。

解決策: AWS アカウント管理者に、AWS Cloud9 のサービスにリンクされたロールを作成するように依頼してください。IAM コンソールを使用するか、AWS コマンドラインインターフェイス (AWS CLI) でこのコマンドを実行して作成できます。

aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

あるいは、次の aws-shell でこのコマンドを実行します。

iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

詳細については、「」を参照してください。サービスにリンクされたロールの使用()IAM ユーザーガイド。

(先頭に戻る)

環境を開けません

問題: 環境を開こうとすると、IDE が長時間 (5 分以上) 表示されません。

考えられる原因:

• AWS Cloud9 コンソールにサインインした IAM ユーザーに、環境を開くために必要な AWS アクセス権限がありません。

• 環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合:

  • インスタンスに関連付けられた VPC が、AWS Cloud9 用に正しく設定されていません。

  • インスタンスが AWS Cloud9 がインスタンスに接続しようとしたときにインスタンスが状態から状態への遷移中、または自動化されたステータスチェックに失敗した。

• 環境が SSH 環境の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていない。

推奨される解決策:

• AWS Cloud9 コンソールにサインインした IAM ユーザーに、環境を開くために必要な AWS アクセス権限があることを確認してから、もう一度環境を開いてください。詳細については以下を参照するか、AWS アカウントの管理者に確認してください。

  • ステップ 3: AWS Cloud9 アクセス権限をグループに追加するチームセットアップ

  • AWS Cloud9 の AWS 管理 (事前定義) ポリシー認証とアクセスコントロール

  • AWS Cloud9 を使用するチームのカスタマー管理ポリシーの例高度なチームセットアップ

  • お客様が管理するポリシーの例認証とアクセスコントロール

  • IAM ユーザーのアクセス権限の変更()IAM ユーザーガイド

  • IAM ポリシーのトラブルシューティング()IAM ユーザーガイド

  サインインしている IAM ユーザーがまだ環境を開くことができない場合は、いったんサインアウトしてから、アカウントの AWS アカウントルートユーザーまたは IAM 管理者ユーザーとしてサインインし直してみます。その後、環境をもう一度開いてみてください。この方法で環境を開くことができる場合、IAM ユーザーのアクセス権限に問題がある可能性が最も高いと言えます。

• 環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合:

  • インスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されていることを確認してから、もう一度環境を開いてください。詳細については、「AWS Cloud9 の Amazon VPC 要件」を参照してください。

    AWS クラウドコンピューティングインスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されていますが、それでも環境を開くことができない場合は、インスタンスのセキュリティグループによって AWS Cloud9 へのアクセスが妨げられている可能性があります。トラブルシューティングの手法としてのみ、セキュリティグループをチェックして、少なくともポート 22 経由のインバウンド SSH トラフィックがすべての IP アドレス (Anywhere または 0.0.0.0/0) について許可されていることを確認してください。手順については、以下を参照してください。セキュリティグループについて説明するおよびセキュリティグループルールを更新する()Linux インスタンス用 Amazon EC2 ユーザーガイド。

    VPC のトラブルシューティングのその他の手順については、関連する 5 分間のビデオをご覧くださいAWS ナレッジセンタービデオ: VPC 内のインスタンスに接続できない場合の確認点とは?」を YouTube ウェブサイトでご覧ください。

    警告

    トラブルシューティングが完了したら、「AWS Cloud9 のインバウンド SSH IP アドレスの範囲」の説明に従って、インバウンドルールを適切なアドレス範囲に設定してください。

  • インスタンスを再起動して、インスタンスが実行されており、すべてのシステムチェックにパスしていることを確認してから、再度環境を開いてください。詳細については、 を参照してください。インスタンスの再起動およびステータスチェックの表示()Linux インスタンス用 Amazon EC2 ユーザーガイド。

• 環境が SSH 環境の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていることを確認してから、もう一度環境を開いてください。詳細については、「SSH 環境ホストの要件」を参照してください。

(先頭に戻る)

AWS Cloud9 インストーラがハングまたは失敗する

問題: どのときに使うかAWS Cloud9 Installer をダウンロードして実行する場合、1 つ以上のエラーメッセージが表示され、インストーラのスクリプトにDone。

原因: AWS Cloud9 インストーラで 1 つ以上のエラーが発生し、このエラーから復旧できないために失敗しています。

解決策: 一般的なエラー、考えられる原因、および推奨される解決策については、AWS Cloud9 インストーラのトラブルシューティング。

(先頭に戻る)

SSH 環境エラー: 「pty.js をインストールするには Python バージョン 2.7 が必要です」

問題: AWS Cloud9 SSH 開発環境を開くと、AWS Cloud9 IDE のターミナルに「pty.js をインストールするには Python バージョン 2.7 が必要です」で始まるメッセージが表示されます。

原因: SSH環境が意図したとおりに動作するには、Python バージョン 2.7 がインストールされている必要があります。

解決策: 環境に Python バージョン 2.7 をインストールします。バージョンを確認するには、サーバーのターミナルからコマンド python --version を実行します。サーバーに Python 2.7 をインストールするには、次のいずれかを参照してください。

• ステップ 1: Python のインストール()Python サンプル。

• Python ウェブサイトの Download Python および Python Packaging User Guide の「Installing Packages」。

(先頭に戻る)

アプリケーションプレビューまたはファイルプレビューの通知: 「サードパーティーの Cookie を無効にしました」

問題: プレビューしようとしたときアプリケーションまたはファイルをクリックすると、次のメッセージとともに通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能が無効になっています。」

原因: サードパーティーの Cookie は AWS Cloud9 IDE を開くために不要ですが、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの Cookie を有効にする必要があります。

解決策: ウェブブラウザでサードパーティーの Cookie を有効にして、IDE を再読み込みしてから、もう一度プレビューを開いてみてください。

• Apple Safari: Safari の Cookie と Web サイトのデータを管理する」Support。

• Google Chrome: Cookie の設定を変更するがChrome で Cookie をクリア、有効化、管理するGoogle Chrome ヘルプウェブサイトをご覧ください。

• Internet Explorer: クッキーをブロックまたは許可するがクッキーの削除と管理マイクロソフトSupport ウェブサイトにある。

• Microsoft Edge: サードパーティーの Cookie を禁止するマイクロソフトSupport ウェブサイトにある。

• Mozilla Firefox: サードパーティの Cookie を受け入れるでの設定ウェブサイトがお客様の設定を追跡するために使用する Cookie を有効または無効にするMozilla Support ウェブサイトにある。

• 他のウェブブラウザの場合は、そのウェブブラウザのドキュメントを参照してください。

サードパーティーAWS Cloud9 Cookie を有効化するには (ウェブブラウザでこの詳細度が可能な場合)、AWS Cloud9 を使用するサポートされている AWS リージョンに応じて、以下のドメインを指定します。

AWS リージョン	ドメイン
米国東部（バージニア北部）	*.vfs.cloud9.us-east-1.amazonaws.com vfs.cloud9.us-east-1.amazonaws.com
米国東部 (オハイオ)	*.vfs.cloud9.us-east-2.amazonaws.com vfs.cloud9.us-east-2.amazonaws.com
米国西部 (北カリフォルニア)	*.vfs.cloud9.us-west-1.amazonaws.com vfs.cloud9.us-west-1.amazonaws.com
米国西部 (オレゴン)	*.vfs.cloud9.us-west-2.amazonaws.com vfs.cloud9.us-west-2.amazonaws.com
アジアパシフィック (香港)	*.vfs.cloud9.ap-east-1.amazonaws.com vfs.cloud9.ap-east-1.amazonaws.com
アジアパシフィック (ムンバイ)	*.vfs.cloud9.ap-south-1.amazonaws.com vfs.cloud9.ap-south-1.amazonaws.com
アジアパシフィック (ソウル)	*.vfs.cloud9.ap-northeast-2.amazonaws.com vfs.cloud9.ap-northeast-2.amazonaws.com
アジアパシフィック (シンガポール)	*.vfs.cloud9.ap-southeast-1.amazonaws.com vfs.cloud9.ap-southeast-1.amazonaws.com
アジアパシフィック (シドニー)	*.vfs.cloud9.ap-southeast-2.amazonaws.com vfs.cloud9.ap-southeast-2.amazonaws.com
アジアパシフィック (東京)	*.vfs.cloud9.ap-northeast-1.amazonaws.com vfs.cloud9.ap-northeast-1.amazonaws.com
カナダ (中部)	*.vfs.cloud9.ca-central-1.amazonaws.com vfs.cloud9.ca-central-1.amazonaws.com
欧州 (フランクフルト)	*.vfs.cloud9.eu-central-1.amazonaws.com vfs.cloud9.eu-central-1.amazonaws.com
欧州 (アイルランド)	*.vfs.cloud9.eu-west-1.amazonaws.com vfs.cloud9.eu-west-1.amazonaws.com
欧州 (ロンドン)	*.vfs.cloud9.eu-west-2.amazonaws.com vfs.cloud9.eu-west-2.amazonaws.com
ヨーロッパ (ミラノ)	*.vfs.cloud9.eu-south-1.amazonaws.com vfs.cloud9.eu-south-1.amazonaws.com
欧州 (パリ)	*.vfs.cloud9.eu-west-3.amazonaws.com vfs.cloud9.eu-west-3.amazonaws.com
欧州 (ストックホルム)	*.vfs.cloud9.eu-north-1.amazonaws.com vfs.cloud9.eu-north-1.amazonaws.com
中東 (バーレーン)	*.vfs.cloud9.me-south-1.amazonaws.com vfs.cloud9.me-south-1.amazonaws.com
南米 (サンパウロ)	*.vfs.cloud9.sa-east-1.amazonaws.com vfs.cloud9.sa-east-1.amazonaws.com

(先頭に戻る)

アプリケーションプレビュータブにエラーが表示されない

問題: IDE のメニューバーで、[[Preview (プレビュー)]、Preview Running Application (実行中のアプリケーションのプレビュー)]または[Tools (ツール)], [Preview (プレビュー)], [Preview Running Application (実行中のアプリケーションのプレビュー)]IDE のプレビュータブにアプリケーションを表示しようとすると、タブにエラーが表示されるか、タブが空白になります。

考えられる原因:

• アプリケーションが IDE で実行されていない。

• アプリケーションが HTTP を使用して実行されていない。

• アプリケーションが複数のポート経由で実行されている。

• アプリケーションが 8080、8081、または 8082 以外のポート経由で実行されている。

• アプリケーションが 127.0.0.1、localhost、または 0.0.0.0 以外の IP で実行されている。

• ポート (8080、8081、または 8082) がプレビュータブの URL で指定されていない。

• ネットワークがポート 8080、8081、または 8082 へのインバウンドトラフィックをブロックしている。

• IP 127.0.0.1、localhost、または 0.0.0.0 を含むアドレスに移動しようとしている。AWS Cloud9 IDE のデフォルトの組み込み動作では、環境に接続されているインスタンスまたは独自のサーバーに移動しようとせずに、ローカルコンピュータに移動しようとします。

推奨される解決策:

• IDE でアプリケーションが実行されていることを確認します。

• HTTP を使用してアプリケーションが実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

• アプリケーションが 1 つのポート経由のみで実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

• アプリケーションがポート 8080、8081、または 8082 経由で実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

• アプリケーションが IP 127.0.0.1、localhost、または 0.0.0.0 を使用して実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

• プレビュータブの URL に :8080、:8081、または :8082 を追加します。

• ネットワークがポート 8080、8081、または 8082 経由のインバウンドトラフィックを許可していることを確認します。ネットワークを変更できない場合は、ネットワーク管理者にお問い合わせください。

• IP を含むアドレスに移動しようとしている127.0.0.1、localhost, または0.0.0.0場合は、代わりに次のアドレスに移動してみます。https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/ここで、とします。12a34567b8cd9012345ef67abcd890e1は AWS Cloud9 が環境に割り当てる ID で、us-east-2は、環境の AWS リージョンの ID です。IDE 外でこのアドレスへの移動を試みることもできますが、環境用の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている場合のみ機能します。

• 上記の条件がすべて満たされていることを確認して、アプリケーションを停止してから再度起動してみてください。

• アプリケーションを停止してから再度起動した場合は、メニューバーで再度 [Preview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)] または [Tools (ツール)]、[Preview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)] を選択します。対応するアプリケーションプレビュータブが既に表示されている場合は、そのタブで [Refresh (最新の情報に更新)] ボタン (円状の矢印) を選択します。

(先頭に戻る)

実行中のアプリケーションを IDE の外部で表示できない

問題: IDE 外の Web ブラウザタブで実行中のアプリケーションを表示しようとすると、その Web ブラウザタブにエラーが表示されるか、タブが空白になります。

考えられる原因:

• アプリケーションが IDE で実行されていない。

• アプリケーションが 127.0.0.1 または localhost の IP で実行されている。

• アプリケーションが AWS Cloud9 EC2 開発環境で実行されており、対応する Amazon EC2 インスタンスに関連付けられている 1 つ以上のセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。

• アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) 用の AWS Cloud9 SSH 開発環境で実行されており、対応するインスタンスに関連付けられている仮想プライベートクラウド (VPC) のサブネットのネットワーク ACL が、プロトコル経由のインバウンドトラフィックを許可していない。、ポート、またはアプリケーションが必要とするIPアドレスです。

• URL に誤りがある。

• インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。

• IP 127.0.0.1 または localhost を含むアドレスに移動しようとしている。これらの IP は、環境内のリソースではなくローカルコンピュータ上のリソースにアクセスしようとします。

• インスタンスのパブリック IP アドレスが変更された。

• ウェブリクエストが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックしている仮想プライベートネットワーク (VPN) から送信されている。

• アプリケーションが SSH 環境で実行されており、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。

推奨される解決策:

• IDE でアプリケーションが実行されていることを確認します。

• アプリケーションが IP 127.0.0.1 または localhost を使用して実行されていないことを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

• アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) で実行されている場合は、対応するインスタンスに関連付けられているすべてのセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可していることを確認します。手順については、以下を参照してください。ステップ 2: インスタンスのセキュリティグループを設定するが実行中のアプリケーションをインターネット上で共有する。以下の資料も参照してください。VPC のセキュリティグループ()Amazon VPC ユーザーガイド。

• アプリケーションが AWS クラウドコンピューティングインスタンスで実行されており、対応するインスタンスに関連付けられている VPC のサブネットにネットワーク ACL が存在する場合、そのネットワーク ACL でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可されていることを確認します。手順については、以下を参照してください。ステップ 3: インスタンスのサブネットの設定が実行中のアプリケーションをインターネット上で共有する。以下の資料も参照してください。ネットワーク ACL()Amazon VPC ユーザーガイド。

• プロトコル (およびポートを指定する必要がある場合はポート) を含むリクエストしている URL が正しいことを確認します。詳細については、「」を参照してください。ステップ 5: 実行中のアプリケーションの URL を共有するが実行中のアプリケーションをインターネット上で共有する。

• 形式を使用して URL をリクエストすることはお勧めしません。https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/ここで、とします。12a34567b8cd9012345ef67abcd890e1は AWS Cloud9 が環境に割り当てる ID で、us-east-2は環境の AWS リージョンの ID です)。この URL を使用するには、環境の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている必要があります。

• IP 127.0.0.1 または localhost を含むアドレスに移動しようとしている場合、代わりに実行中のアプリケーションのローカルではない正しいアドレスに移動してみます。詳細については、「実行中のアプリケーションをインターネット経由で共有する」を参照してください。

• アプリケーションが AWS クラウドコンピューティングインスタンスで実行されている場合、インスタンスのパブリック IP アドレスが変更されたかどうかを判断します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。詳細については、「」を参照してください。ステップ 5: 実行中のアプリケーションの URL を共有するが実行中のアプリケーションをインターネット上で共有する。

• ウェブリクエストが VPN から送信されている場合は、その VPN でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のトラフィックが許可されていることを確認します。VPN を変更できない場合は、ネットワーク管理者にお問い合わせください。または、可能であれば別のネットワークからウェブリクエストを行います。

• アプリケーションが独自のサーバーの SSH 環境で実行されている場合は、サーバーおよび関連付けられたネットワークで、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックが許可されていることを確認します。サーバーまたは関連付けられているネットワークに変更を加えることができない場合は、サーバーまたはネットワークの管理者にお問い合わせください。

• 環境内のターミナルからアプリケーションを実行しようとすると、curlコマンドの後に URL を入力します。このコマンドでエラーメッセージが表示される場合、AWS Cloud9 に関連しない他の問題がある可能性があります。

(先頭に戻る)

環境を再ロードした後、アプリケーションのプレビューを更新する必要があります

問題: アプリケーションプレビュータブを表示する環境を再ロードした後、タブにアプリケーションプレビューが表示されません。

原因: ユーザーが作成したコードが無限ループを実行する場合や、使用するメモリ量が多すぎるためにアプリケーションプレビューを実行する際に AWS Cloud9 IDE が一時停止または停止する場合があります。これを防止するには、環境が再ロードされても、AWS Cloud9 はアプリケーションプレビュータブを再ロードしません。

解決策: アプリケーションプレビュータブを表示する環境を再ロードした後、アプリケーションプレビューを表示するには、クリックしてページを読み込みますボタンをクリックします。

(先頭に戻る)

HTTP を使用する AWS Cloud9 IDE でアプリケーションをプレビューできない

問題: AWS Cloud9 IDE のアプリケーションプレビュータブのアドレスボックスでは、URL が常にで始まります。https。ボックスの https をhttp に変更して Enter を押すと、タブにアプリケーションプレビューが表示されません。

原因: コードの安全性を向上させるため、IDE のアプリケーションプレビュータブのアドレスボックスでは、AWS Cloud9 が常にhttps。この動作は変更できません。

解決策: で始まるアドレスでアプリケーションのプレビューを表示するにはhttpの代わりにhttps、変更https] タブの [アドレス] ボックスにhttpを押したままEnter。その後、Open your page in a new tab ボタンを選択します。こうすることで、アプリケーションプレビューが HTTP を使用して別のウェブブラウザタブに表示されます。

(先頭に戻る)

EC2 環境で一部のコマンドまたはスクリプトを実行できない

問題: AWS Cloud9 EC2 開発環境を開いた後、一部のタイプのパッケージのインストール、yumまたはapt他の Linux オペレーティングシステムで使用されるコマンドを含むスクリプトを実行することもできます。

原因: AWS Cloud9 が EC2 環境で使用する Amazon EC2 インスタンスは Amazon Linux (Red Hat Enterprise Linux (RHEL) ベースです。

解決策: EC2 環境の IDE でパッケージをインストールしたり管理したり、コマンドやスクリプトを実行したりする場合は、その環境のインスタンスに応じて、RHEL（Amazon Linux用）または Ubuntu サーバーと互換性があることを確認してください。

(先頭に戻る)

AWS CLI/aws-シェルエラー: EC2 環境で「リクエストに含まれているセキュリティトークンが無効です」

問題: AWS Command Line Interface (AWS CLI) または aws-shell を使用して EC2 環境の AWS Cloud9 IDE でコマンドを実行しようとすると、エラーが表示されます。「リクエストに含まれているセキュリティトークンが無効です。」

原因: AWS 管理の一時認証情報が有効になっており、以下のいずれかが発生した場合は、無効なセキュリティトークンが発生する可能性があります。

• AWS 管理の一時的な認証情報で許可されていないコマンドを実行しようとしました。許可されたコマンドの一覧については、「AWS 管理の一時認証情報によってサポートされているアクション」を参照してください。

• AWS 管理の一時認証情報は 15 分後に自動的に期限切れになります。

• 新しいメンバーが環境所有者以外のユーザーによって追加されたため、共有環境の AWS 管理の一時認証情報が無効になりました。

推奨される解決策:

• AWS 管理の一時的な認証情報で許可されているコマンドのみを実行します。AWS 管理の一時的認証情報によって許可されていないコマンドを実行する必要がある場合は、永続的認証情報を持つ AWS CLI または aws-shell を環境に設定することで、この制限を取り除くことができます。手順については、「永続的なアクセス資格情報の作成と環境への保存」を参照してください。

• 非アクティブ化または期限切れの認証情報の場合は、AWS Cloud9 が環境の一時認証情報を更新できるように、環境所有者が環境を開くことを確認します。詳細については、「AWS 管理の一時認証情報へのアクセスをコントロールする」を参照してください。

(先頭に戻る)

Amazon EC2 インスタンスは自動的には更新されません

問題: 最近のシステム更新が、AWS Cloud9 開発環境に接続する Amazon EC2 インスタンスに自動的に適用されません。

原因: 最近のシステム更新を自動的に適用すると、事前の知識や承認なくコードや Amazon EC2 インスタンスで予期しない動作が発生する可能性があります。

推奨される解決策:

Amazon EC2 インスタンスにシステム更新を適用するには、「」の手順に従ってください。インスタンスソフトウェアの更新()Linux インスタンス用 Amazon EC2 ユーザーガイド。

インスタンスでコマンドを実行するには、インスタンスに接続されている環境から AWS Cloud9 IDE でターミナルセッションを使用できます。

また、ssh や PuTTY などの SSH リモートアクセスユーティリティを使用してインスタンスに接続できます。これを行うには、ローカルコンピュータから、ssh-keygen または PuTTYgen などの SSH キーペア作成ユーティリティを使用します。インスタンスに接続されている環境から AWS Cloud9 IDE を使用して、生成したパブリックキーをインスタンスに保存します。次に、生成されたプライベートキーとともに SSH リモートアクセスユーティリティを使用して、インスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。

(先頭に戻る)

Lambda ローカル関数の実行エラー: SAM Local をインストールできません

問題: AWS Cloud9 IDE で AWS Lambda 関数のローカルバージョンを実行すると、AWS Cloud9 が SAM Local のインストールで問題が発生したというダイアログボックスが表示されます。AWS Cloud9 では、IDE でローカルバージョンの AWS Lambda 関数を実行するには、SAM Local が必要です。SAM Local がインストールされるまで、IDE でローカルバージョンの Lambda 関数を実行することはできません。

原因: AWS Cloud9 が、環境内で予定されたパス () で SAM Local を見つけられません。~/.c9/bin/sam。これは SAM Local がまだインストールされていないか、インストールされている場合、AWS Cloud9 がその場所に見つけられないためです。

推奨される解決策: AWS Cloud9 によって SAM Local のインストールが完了するまで待つか、自分でインストールします。

SAM Local をインストールするために AWS Cloud9 が行っていることを確認するには、ウィンドウ、インストーラメニューバーの [] を選択します。

SAM Local を自分でインストールするには、Linux への AWS SAM CLI のインストール()AWS サーバーレスアプリケーションモデル開発者ガイド

IDE 警告: 「この環境のメモリが不足しています」または「この環境の CPU 負荷が高い」

問題: IDE の実行中、「この環境はメモリが不足しています」または「この環境の CPU 負荷が高くなっています」という内容のメッセージが表示される。

原因: IDE に、遅延やハングアップしないで実行を続けるのに必要なコンピューティングリソースがない可能性があります。

推奨される解決策:

• 実行中のプロセスを 1 つ以上停止し、使用可能なメモリを解放してください。これを行うには、環境の IDE のメニューバーで、ツール、プロセスリスト。停止するプロセスごとに、プロセスを選択して [Force Kill (強制終了)] を選択します。

• 環境に swap ファイルを作成します。Aスワップファイルは、オペレーティングシステムが仮想メモリとして使用できる環境内のファイルです。

  環境が現在スワップメモリを使用しているかどうかを確認するには、 top コマンドを、環境内のターミナルセッションで実行します。スワップメモリが使用されている場合、出力にゼロ以外の Swap メモリ統計が表示されます (たとえば、Swap: 499996k total, 1280k used, 498716 free, 110672k cached)。リアルタイムのメモリ情報の表示をやめるには、Ctrl + C を押します。​

  スワップファイルを作成するには、環境で次のようなコマンドを実行します。

  sudo fallocate --length 512MB /var/swapfile && sudo chmod 600 /var/swapfile && sudo mkswap /var/swapfile && echo '/var/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab > /dev/null

  前述のコマンドは以下の処理を実行します。

  1. /var ディレクトリに swapfile という 512 MB のファイルを作成します。

  2. swapfile ファイルのアクセス権限を所有者のみの読み取り/書き込みに変更します。

  3. swapfile ファイルをスワップファイルとして設定します。

  4. 情報を /etc/fstab file に書き込みます。これにより、システムが再起動するたびにこのスワップファイルが使用可能になります。

  前述のコマンドを実行したら、再起動しなくてもこのスワップファイルをすぐに使用可能にするため、次のコマンドを実行します。

  sudo swapon /var/swapfile

• コンピューティングリソースの多いインスタンスまたはサーバーに移動するか、サイズを変更します。Amazon EC2 インスタンスを移動またはサイズ変更するには、以下を参照してください。環境の移動と Amazon EBS ボリュームのサイズ変更または暗号化。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。

(先頭に戻る)

ファイルをプレビューすると 499 エラーが返される

問題: AWS Cloud9 IDE を使用して、<script>要素を含むsrc属性とtype属性をmodule、499 エラーが発生し、スクリプトが期待どおりに実行されません。

原因: AWS Cloud9 IDE でのファイルプレビューフェッチリクエストでは、認証のためにウェブブラウザから Cookie を送信する必要があります。crossorigin 属性を追加した場合を除き、デフォルトでは、ウェブブラウザは通常のスクリプトリクエストに対しては Cookie を送信しますが、モジュールスクリプトリクエストに対しては Cookie を送信しません。

解決策: の追加crossorigin属性を<script>要素。例:<script type="module" src="index.js" crossorigin></script>。次に変更したファイルを保存し、再度プレビューを試みます。

(先頭に戻る)

環境の削除エラー: 「1 つ以上の環境を削除できませんでした」

問題: AWS Cloud9 コンソールで 1 つ以上の環境を削除しようとすると、「1 つ以上の環境を削除できませんでした」というメッセージが表示されます。このとき、少なくとも 1 つの環境は削除されません。

考えられる原因: AWS CloudFormation で、1 つ以上の環境の削除に問題が発生しました。（AWS Cloud9 は AWS CloudFormation を使用して環境を作成および削除します）。

推奨される解決策: AWS CloudFormation を使用して、削除されなかった環境のそれぞれの削除を試みてください。手順は以下のとおりです。

1. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソールを開きます。

2. AWS ナビゲーションバーで、環境の AWS リージョンを選択します。

3. AWS CloudFormation スタックのリストで、スタックの名前には削除されていない環境名が含まれ、ステータス、DELETE_FAILED。たとえば、環境名がmy-demo-environmentで、名前で始まるスタックを選択しますaws-クラウド9-マイデモ環境。(環境名自体ではなく、環境名の横にあるボックスまたはオプションを選択します)。

4. [アクション]、[スタックの削除] の順に選択します。

5. プロンプトが表示されたら、[はい、削除します] を選択します。

スタックの削除処理には数分かかる場合があります。

スタックがリストから消えた場合、環境は削除されています。

スタックがまだ表示されている場合は、DELETE_FAILED数分後、環境はまだ削除されていません。その場合は、障害が発生した各スタックのリソースを手動で削除してみてください。

注記

障害が発生したスタックのリソースを手動で削除すると、スタック自体は AWS アカウントから削除されません。

これらのリソースを手動で削除するには、AWS CloudFormation コンソールで、障害が発生したスタックを選択してからリソースセクションに追加します。このリストの各リソースの AWS のコンソールに移動し、そのコンソールを使用して手動でリソースを削除します。

(先頭に戻る)

コンソールの警告: 「最小限のコード補完エンジンに切り替えます...」

問題: AWS Cloud9 コンソールで作業している場合 (IDE を開いたり、IDE のウェブページを更新したりする場合など)、次のメッセージが表示されます。「この環境では、1 つ以上のセッションまたは共同作業者がアクティブになっています。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。

原因: コード補完エンジンを実行すると、環境からメモリと CPU サイクルが消費されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に t2.nano や t2.micro などの小さなインスタンスサイズで、リソースの使用量が多すぎないようにするため、AWS Cloud9 は最小限のコード補完エンジンに切り替えます。

推奨される解決策: 頻繁および長期間共同作業を行う場合は、EC2 環境を作成するときに大きな Amazon EC2 インスタンスを選択します。または、SSH 環境をより容量の大きいインスタンスに接続します。

注記

より大きな Amazon EC2 インスタンスを選択すると、AWS アカウントに追加料金が発生する可能性があります。詳細については、「Amazon EC2 料金表」を参照してください。

(先頭に戻る)

AWS Cloud9 インストーラが、以下を表示した後に終了しない 「パッケージCloud9 IDE 1」

問題: AWS Cloud9 は、SSH 開発環境を作成するプロセスの一環として、既存の Amazon EC2 インスタンスまたは独自のサーバーにインストールされます。このメッセージが表示されて、インストールが停止します。AWS Cloud9 インストーラダイアログボックス: 「Package Cloud9 IDE 1」。[] を選択するとキャンセルの場合は、次のメッセージが表示されます。「インストールに失敗しました。」 このエラーは、AWS Cloud9 パッケージをお客様の SSH ホストにインストールできない場合に発生します。

原因: SSH ホストでは、Node.js がインストールされている必要があります。私たちは現在、Node.js 0.6.16～Node.js 12.xAWS Cloud9 でサポートされていない Node.js のバージョンがホストにある場合、インストールエラーが発生する可能性があります。

推奨される解決策: のバージョンをインストールするNode.jsAWS Cloud9 が SSH ホストでサポートしていることを確認します。

(先頭に戻る)

EC2-Classic アカウントの VPC エラー: 「環境にアクセスできません」

問題: EC2-Classic は、Amazon EC2 のオリジナルリリースで導入されました。2013 年 12 月 4 日以前にセットアップされた AWS アカウントを使用している場合、このエラーはvirtual private cloudAWS Cloud9 EC2 開発環境の作成時に (Amazon VPC) とサブネットを使用します。

デフォルトの VPC 設定を受け入れると、Amazon EC2 インスタンスはデフォルト VPC のサブネットではなく EC2-Classic ネットワーク内で起動されます。環境の作成に失敗すると、次のメッセージが表示されます。

Environment Error

Unable to access your environment

The environment creation failed with the error: The following resource(s) failed to create: [Instance]. . Rollback requested by user..

EC2 インスタンスがデフォルト VPC に存在しないためにエラーが発生したことを確認できます。AWS CloudFormation を使用して、開発環境のスタックイベント履歴を表示します。

1. AWS CloudFormation コンソールを開きます。詳細については、「Logging in to the AWS CloudFormation console」を参照してください。

2. AWS CloudFormation コンソールで、[スタック。

3. [スタック] ページで、作成に失敗した開発環境の名前を選択します。

4. [スタックの詳細] ページで、[イベント ] タブを選択し、次のエントリを確認します。

   Status: CREATE_FAILED

   Status reason: The AssociatePublicIpAddress parameter is only supported by VPC launches. [...]

原因: AWS Cloud9 開発環境は、特定の VPC 要件を満たす Amazon VPC に関連付けられている必要があります。EC2-Classic が有効なアカウントの場合、EC2 環境の作成は、必要な EC2 インスタンスが VPC 内で起動されていないことを意味します。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。

推奨される解決策: EC2-Classic アカウントでは、EC2 環境の作成。[設定の構成] ページの [ネットワーク設定 (高度)] セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。

(先頭に戻る)

AWS Cloud9 環境を開くことができない: 「現在、共同作業者がこの環境にアクセスすることはできません。管理された一時的な認証情報の削除が完了するまでお待ちください。または、この環境の所有者に問い合わせてください。」

問題: 環境所有者ではないユーザーによって新しい共同作業者が環境に追加された場合、AWS 管理の一時認証情報は無効になります。クレデンシャルは、~/.aws/credentialsファイルを開きます。の削除中~/.aws/credentialsファイルが進行中の場合、新しい共同作業者は AWS Cloud9 環境にアクセスできません。

原因: AWS 管理の一時認証情報の削除中に環境へのアクセスを防止することは、セキュリティ対策です。これにより、環境の所有者は、信頼された共同作業者だけが管理された資格情報にアクセスできることを確認できます。共同作業者のリストが有効であることが確認できたら、環境所有者は管理された資格情報を再度有効にして共有することができます。詳細については、「AWS 管理の一時認証情報へのアクセスをコントロールする」を参照してください。

推奨される解決策: 削除を待つことができます~/.aws/credentialsファイルを完了してから、AWS Cloud9 環境を再度開こうとします。クレデンシャルの有効期限の最大待機時間は 15 分です。または、管理された一時認証情報を再度有効または無効にするよう、環境所有者に依頼します。認証情報が再び有効または無効になったら、共同作業者はすぐに環境にアクセスできます。（管理された資格情報の状態を ENABLED または DISABLED に切り替えることで、環境所有者は資格情報が中間状態にとどまらず、共同作業者が環境にアクセスできないようにします）。

注記

環境所有者と共同作業者が同じ AWS アカウントに属している場合、共同作業者は連絡する環境所有者を識別できます。そのためには、環境の設定コンソールの [] ページに移動します。環境所有者も、環境の詳細ページで.

(先頭に戻る)

AWS CloudFormation を使用して EC2 環境を作成するときに「インスタンスプロファイル AWSCloud9SSMinStanceProfile がアカウントに存在しません」と報告するエラーメッセージ

問題: を使用する場合AWS::Cloud9::EnvironmentEC2AWS CloudFormation リソースを使用して EC2 環境を作成した場合、ユーザーには Instance profile AWSCloud9SSMInstanceProfile does not exist in account.

原因: 進入しない EC2 環境を作成するときは、サービスロールを作成する必要がありますAWSCloud9SSMAccessRoleインスタンスプロファイルのAWSCloud9SSMInstanceProfile。これらの IAM リソースにより、Systems Manager は開発環境をバックアップする EC2 インスタンスを管理できます。

コンソールで入力なし環境を作成する場合、AWSCloud9SSMAccessRoleおよびAWSCloud9SSMInstanceProfileは自動的に作成されます。ただし、AWS CloudFormation または AWS CLI を使用して最初の入力なし環境を作成する場合は、これらの IAM リソースを手動で作成する必要があります。

推奨される解決策: AWS CloudFormation テンプレートの編集と IAM アクセス許可の更新については、AWS CloudFormation を使用して進入しない EC2 環境を作成する

AWS CloudFormation を使用して EC2 環境を作成するときに、「実行する権限がありません:SSM: リソース上のStartSession」というエラーメッセージを報告する

問題: を使用する場合AWS::Cloud9::EnvironmentEC2AWS CloudFormation リソースを使用して EC2 環境を作成する場合、ユーザーはAccessDeniedException「SSM：StartSessionをリソースで実行する権限がありません」と通知されます。

原因: ユーザーを呼び出すためのアクセス許可を欠いているStartSession入力なしのインスタンスに Systems Manager を使用する EC2 環境の設定の一部として必要な API です。

推奨される解決策: AWS CloudFormation テンプレートの編集と IAM アクセス許可の更新については、AWS CloudFormation を使用して進入しない EC2 環境を作成する。

(先頭に戻る)

VPC の IP アドレスが Docker によって使用されているため、EC2 環境に接続できません

問題: EC2 環境で、IPv4 クラスレスドメイン間ルーティング（CIDR）ブロックを使用する Amazon VPC（仮想プライベートクラウド）に EC2 インスタンスを起動した場合172.17.0.0/16、その環境を開こうとすると、接続が停止することがあります。

原因: Dockerは、ブリッジネットワークと呼ばれるリンク層デバイスを使用して、同じブリッジネットワークに接続されたコンテナが通信できるようにします。AWS Cloud9 は、コンテナ通信にデフォルトのブリッジを使用するコンテナを作成します。デフォルトのブリッジは、通常、172.17.0.0/16サブネット。

環境のインスタンスの VPC サブネットが、Docker で既に使用されているアドレス範囲と同じアドレス範囲を使用している場合、IP アドレスの競合が発生する可能性があります。したがって、AWS Cloud9 がインスタンスに接続しようとすると、その接続はゲートウェイルートテーブルによって EC2 インスタンスではなく Docker ブリッジにルーティングされます。これにより、AWS Cloud9 が開発環境をバックアップする EC2 インスタンスに接続できなくなります。

推奨される解決策: 同じ IPv4 CIDR アドレスブロックを使用する Amazon VPC と Docker によって引き起こされる IP アドレスの競合を解決するには、EC2 環境をバッキングするインスタンス用に新しい VPC を設定します。この新しいVPC では、CIDRブロックを設定します。172.17.0.0/16。（既存の VPC またはサブネットの IP アドレスの範囲を変更することはできません）。

設定の詳細については、以下を参照してください。VPC とサブネットのサイズ設定」(Amazon VPC ユーザーガイド) を参照してください。

(先頭に戻る)

AWS ツールキットの実行時のエラー: 「環境の inode が不足しています。'fs.inotify.max_user_watches' の制限値を大きくしてください。

問題: AWS Toolkit で使用されるファイル監視ユーティリティが、監視できるファイルの現在の制限に近づいています。

原因: AWS Toolkit は、ファイルとディレクトリの変更を監視するファイルウォッチャーユーティリティを使用します。ユーティリティが監視できるファイルの現在の制限に近づいていると、警告メッセージが表示されます。

推奨される解決策: ファイルウォッチャーで処理できるファイルの最大数を増やすには、次の操作を行います。

1. ターミナルセッションを開始するには、Window、New Terminal (新しいターミナル)メニューバーの [] を選択します。

2. コマンドラインで次のとおりに入力します。

   sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p

(先頭に戻る)

注意点: コラボレーションサポートの依存関係をインストールできませんでした

問題: AWS Cloud9 では、依存関係をダウンロードするためにインターネットアクセスが必要です。AWS Cloud9 がこれらの依存関係をダウンロードできない場合、Noticeダイアログボックスに次のエラーが表示されます。

Failed to install dependencies for collaboration support
      
Please try to resolve this problem and refresh the page to enable collaboration support. A common cause is a lack of available disk space. Error was:
      
Error downloading from location
<LINK> to <LOCATION>
Problem was: Error: connect ETIMEDOUT <IPADDRESS>

考えられる原因: AWS Cloud9 環境がプロキシを使用してインターネットにアクセスしている場合、AWS Cloud9 は依存関係をインストールするためにプロキシの詳細を必要とします。このエラーは、AWS Cloud9 にプロキシの詳細を指定していない場合に表示されます。

推奨される解決策: AWS Cloud9 にプロキシの詳細を提供するには、以下を環境の~/.bashrcファイルを開きます。

export http_proxy=<proxy url for http>
export https_proxy=<proxy url for https>

たとえば、httpプロキシURLがhttp://172.31.26.80:3128あなたのhttpsプロキシURLはhttps://172.31.26.80:3129の場合は、次の行を~/.bashrcファイルを開きます。

export http_proxy=http://172.31.26.80:3128
export https_proxy=https://172.31.26.80:3129

注記

これらの環境変数が/etc/profileしかし、~/.bashrcの場合、AWS Cloud9 はそれらを/etc/profileはログインシェル専用です。なぜなら/etc/profileもロードする~/.bashrcに設定し、設定を~/.bashrcは、環境変数がログインシェルと AWS Cloud9 の両方で利用できるようにします。

(先頭に戻る)

エラーありgdbC++ プロジェクトのデバッグ時

問題: に関するエラーが報告されましたgdbデバッガは、IDE で C++ プロジェクトをデバッグしようとするとします。

考えられる原因: AWS Cloud9 環境で特定の EC2 インスタンスタイプ（t3.smallまたはm5.largeなど)、IDE の組み込みランナーを使用して C++ プロジェクトを実行およびデバッグしようとすると、デバッグエラーが発生することがあります。このエラーは、gdb(GNU プロジェクトデバッガ) は、特定のプロセッサプラットフォームでは動作しません。次の状況コードが表示されることがあります。

GDB server terminated with code 1

推奨される解決策: の問題は次のとおりです。gdb特定のプロセッサプラットフォームをサポートしていないが、バージョン3.0以降。したがって、古いバージョンのデバッガをアンインストールし、新しいバージョンのgdb:

1. AWS Cloud9 ターミナルで次のコマンドを実行して、既存のバージョンのデバッガを削除します。

   sudo yum -y remove gdb

2. のアーカイブの取得gdb解凍してから、次のコマンドを実行して、解凍したファイルが含まれているディレクトリに移動します。

   wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
   tar xzf gdb-8.3.tar.gz
   cd gdb-8.3                          

3. 次のコマンドを実行してデバッガをビルドします（下のテキストを単一のブロックとして貼り付け、returnを実行make):

   ./configure --prefix=/usr \
               --with-system-readline \
               --with-python=/usr/bin/python3 &&
   make

4. デバッガをインストールします。

   sudo make -C gdb install

5. 最後に、更新されたバージョンのデバッガがインストールされていることを確認します。

    gdb --version

(先頭に戻る)

AWS Cloud9 環境に十分なディスク容量がないため、AWS Toolkit で SAM アプリケーションをローカルで実行中にエラーが発生しました

問題: AWS Toolkit を使用して、SAM テンプレートによって定義されたアプリケーションに対して AWS SAM CLI コマンドを実行すると、エラーが発生します。

考えられる原因: AWS Toolkit を使用してサーバーレスアプリケーションをローカルで実行およびデバッグする場合、AWS SAM はランタイム環境を提供する Docker イメージを使用し、デプロイ先の Lambda 環境をエミュレートするツールを構築します。

しかし、環境に十分なディスク容量がない場合、これらの機能を提供するDockerイメージはビルドできず、ローカルSAMアプリケーションを実行できません。この問題が発生した場合は、でエラーが発生する場合があります。出力タブでは、次のようになります。

Error: Could not find amazon/aws-sam-cli-emulation-image-python3.7:rapid-1.18.1 image locally and failed to pull it from docker.

このエラーは、Python ランタイムを使用して構築された SAM アプリケーションに関連します。アプリケーション用に選択したランタイムによっては、若干異なるメッセージが表示される場合があります。

推奨される解決策: Docker イメージを構築できるように、環境内のディスク領域を解放します。IDE の端末で次のコマンドを実行して、未使用のDockerイメージを削除します。

docker image prune -a

ディスク容量の制限により SAM CLI コマンドに問題が繰り返し発生する場合は、開発環境に切り替えて、別のインスタンスタイプ。

(先頭に戻る)

古いバージョンの Microsoft Edge ブラウザを使用して IDE を読み込めません

問題: HTTP403: FORBIDDENMicrosoft Edge ウェブブラウザを使用して AWS Cloud9 IDE をロードしようとすると、エラーが返されます。

考えられる原因: AWS Cloud9 IDE では、一部の古いバージョンの Microsoft Edge がサポートされていません。

推奨される解決策: ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンを選択します。メニューで、[設定[] を選択して、Microsoft Edge について。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。

(先頭に戻る)