AWS CloudShell のトラブルシューティング - AWS CloudShell
エラーのトラブルシューティング

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

AWS CloudShell 使用中に、CloudShell を起動したり、シェルコマンドラインインターフェースを使用して主なタスクを実行する時などに問題が発生する可能性があります。この章では、可能性のある一般的ないくつかの問題のトラブルシューティング方法を紹介します。

CloudShell に関するさまざまな質問への回答については、AWS CloudShellよくある質問をご覧ください。また、AWS CloudShell ディスカッションフォーラムで回答を検索したり、質問を投稿したりすることもできます。このフォーラムに入るには、AWS にサインインする必要がある場合があります。当社に直接お問い合わせいただくこともできます。

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

以下に挙げるインデックスに関するエラーが発生した場合、解決のために次の解決方法を使用することができますす。

拒否されるアクセス

問題: AWS マネジメントコンソールから CloudShell を起動しようとすると、次のメッセージが表示されます。「Unable to start the environment. To retry, refresh the browser or restart by selecting Actions, Restart AWS CloudShell」。IAM 管理者からのアクセス許可を要求し、ブラウザを更新したり CloudShell を再起動したりした後でも、アクセスが拒否されます。

解決策:AWSサポート部 にお問い合わせください。

(先頭に戻ります)

アクセス権限の不足

問題: AWS マネジメントコンソールから CloudShell を起動しようとすると、次のメッセージが表示されます。「Unable to start the environment. 必要なアクセス許可がありません。Ask your IAM administrator to grant access to AWS CloudShell」。アクセスを拒否され、必要なアクセス許可がないと通知されます。

原因: AWS CloudShell へのアクセスに使用している IAM アイデンティティに必要な IAM アクセス許可がありません。

解決策: IAM 管理者に必要な権限の付与を申請してください。これは、アタッチ済みの AWS マネージドポリシー (AWSCloudShellFullAccess) 、または組み込みインラインポリシーを追加することで可能になります。詳細については、「IMPポリシー内でのアクセスおよび使用の管理AWS CloudShell」を参照してください。

(先頭に戻ります)

AWS CloudShell コマンドラインにアクセスできません

問題:コンピューティング環境が使用するファイルを変更した後に、AWS CloudShell のコマンドラインにアクセスできまん。

解決策: .bashrc またはその他のファイルを誤って変更した後にアクセスできない場合、ホームディレクトリを削除することで AWS CloudShell をデフォルト設定に戻すことができます。

(先頭に戻ります)

外部 IP アドレスに ping できません

問題:コマンドライン ( ping amazon.com など) から ping コマンドを実行すると、次のメッセージが表示されます。

ping: socket: Operation not permitted

原因: ping ユーティリティは、インターネット制御メッセージプロトコル (ICMP) を使用して、エコー要求パケットをターゲットホストに送信します。ターゲットからのエコーレスポンスを待ちます。ICMP プロトコルが AWS CloudShell で有効になっていないため、ping ユーティリティはシェルのコンピューティング環境では動作しません。

解決策: ICMP は AWS CloudShell でサポートされていないため、次のコマンドを実行して Netcat をインストールできます。Netcat は、TCP または UDP を使用してネットワーク接続に対して読み書きするためのコンピュータネットワークユーティリティです。

sudo yum install nc
nc -zv www.amazon.com 443

(先頭に戻ります)

ターミナルの準備中に問題が発生しました

問題: Microsoft Edge ブラウザを使用して AWS CloudShell にアクセスしようとすると、シェルセッションを開始できず、ブラウザにエラーメッセージが表示されます。

原因: AWS CloudShell は、Microsoft Edge の以前のバージョンとの互換性がありません。AWS CloudShell にアクセスするには、サポートされているブラウザの最新の 4 つのメジャーバージョンを使用できます。

解決策: マイクロソフトのサイトから Edge ブラウザの最新版をインストールします。

(先頭に戻ります)

PowerShell で矢印キーが正しく機能しません

問題:通常の操作では、矢印キーを使用してコマンドラインインターフェースを操作したり、コマンド履歴を前後にスキャンすることができますできます。しかし、PowerShell の一部のバージョンでは、 AWS CloudShell で矢印キーを押すと、文字が正しく出力されない場合があります。

原因:矢印キーが誤って文字を出力する状況は、Linux上で実行されている PowerShell 7.2.x バージョンの問題としてすでに知られています。

解決策:矢印キーの動作を変更するエスケープシーケンスを削除するには、PowerShell プロファイルファイルを編集し、$PSStyle 変数を PlainText に設定します。

  1. AWS CloudShell コマンドラインで、以下のコマンドを入力してプロファイルファイルを生成します。

    vim ~/.config/powershell/Microsoft.PowerShell_profile.ps1
    注記

    すでに PowerShell を使用している場合は、次のコマンドを使用してエディターでプロファイルファイルを開くこともできます。

    vim $PROFILE

  2. エディターで、ファイルの既存のテキストの末尾に移動し、i を押して挿入モードに入り、次のステートメントを追加します。

    $PSStyle.OutputRendering = 'PlainText'

  3. 編集したら、Esc を押してコマンドモードに入力します。次に、次のコマンドを入力してファイルを保存し、エディタを終了します。

    :wq
注記

変更は、PowerShell の次回起動時に有効になります。

(先頭に戻ります)

サポートされていないウェブソケットが原因で CloudShell セッションを開始できない

問題:AWS CloudShell を起動しようとすると、「Failed to open sessions : Timed out while opening the session」というメッセージが繰り返し表示されます。

原因: CloudShell は WebSocket プロトコルに依存しています。これにより、ウェブブラウザと AWS CloudShell の間で双方向のインタラクティブ通信が可能になります。プライベートネットワークでブラウザを使用している場合、プロキシサーバーとファイアウォールによってインターネットへの安全なアクセスが促進されていると考えられます。通常、WebSocket 通信は、問題なくプロキシサーバーを通過できます。しかし、場合によっては、プロキシサーバーが WebSockets の正常な動作を妨げることがあります。この問題が発生すると、CloudShell はシェルセッションを開始できず、接続を試みても最終的にタイムアウトになります。

解決策:接続タイムアウトは、サポートされていない WebSockets 以外の問題が原因である可能性があります。その場合は、まず CloudShell コマンドラインインターフェースがあるブラウザウィンドウを更新してください。

更新後もタイムアウトエラーが続く場合は、プロキシサーバーのドキュメントを参照してください。また、プロキシサーバーが Web ソケットを許可するように設定されていることを確認してください。または、ネットワークのシステム管理者に問い合わせてください。

注記

特定の URL を許可リストに登録して、詳細な権限を定義したいとしましょう。AWS Systems Manager セッションが入力の送信と出力の受信のための WebSocket 接続を開くために使用する URL の一部を追加できます。AWS CloudShell コマンドはその Systems Manager セッションに送信されます。

Systems Manager が使用するこの StreamUrl の形式は wss://ssmmessages.region.amazonaws.com/v1/data-channel/session-id?stream=(input|output) です。

リージョンは、AWS Systems Manager でサポートされている AWS リージョンのリージョン識別子を表します。例えば、us-east-2 は米国東部 (オハイオ) のリージョン識別子です。

セッション ID は特定の Systems Manager セッションが正常に開始された後に作成されるため、URL 許可リストを更新するときしか wss://ssmmessages.region.amazonaws.com を指定できません。詳細については、「AWS Systems Manager API リファレンス」の「StartSession」オペレーションを参照してください。

(先頭に戻ります)

AWSPowerShell.NetCore モジュールをインポートできない。

問題: PowerShell で、Import-Module -Name AWSPowerShell.NetCore を使ってAWSPowerShell.netCore モジュールをインポートすると、次のエラーメッセージが表示されます。

Import-Module:どのモジュールディレクトリでも有効なモジュールファイルが見つからなかったため、指定されたモジュール「AWSPowerShell.NetCore」はロードされませんでした。

原因: AWSPowerShell.NetCore モジュールが AWS CloudShell 内のサービスごとの AWS .Tools モジュールに置き換えられます。

解決策:明示的なインポートステートメントは不要になるか、関連するサービスごとの AWS.Tools モジュールに変更する必要がなくなる可能性があります。

  • ほとんどの場合、.NET タイプが使用されていない限り、明示的なインポートステートメントは必要ありません。以下は、インポートステートメントの例です。

    • Get-S3Bucket

    • (Get-EC2Instance).Instances

  • .NET タイプを使用する場合は、サービスレベルモジュール (AWS.Tools.<Service>) をインポートします。構文の例を次に示します。

    Import-Module -Name AWS.Tools.EC2
$InstanceTag = [Amazon.EC2.Model.Tag]::new("Environment","Dev")
    Import-Module -Name AWS.Tools.S3 
$LifecycleRule = [Amazon.S3.Model.LifecycleRule]::new()

詳細については、AWS Tools for PowerShell の バージョン 4 の告知を参照してください。

(先頭に戻ります)

AWS CloudShell の使用時に Docker が動作しない

問題: AWS CloudShell の使用時に Docker が適切に動作しません。メッセージ「docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?」が表示されます。

解決策: 環境を再起動してみてください。このエラー メッセージは、GovCloud リージョンの AWS CloudShell で Docker を実行したときに発生する可能性があります。サポートされている AWS リージョンで Docker を実行していることを確認してください。Docker を利用できるリージョンのリストについては、「AWS CloudShell でサポートされている AWS リージョン」を参照してください。

Docker のディスク容量が不足している

問題: エラーメッセージ「ERROR: failed to solve: failed to register layer: write [...]: no space left on device」が表示されます。

原因: AWS CloudShell で使用可能なディスク容量を Dockerfile が超えています。これは、個々のイメージが大きいか、既存の Docker イメージが多すぎることが原因である可能性があります。

解決策: df -h を実行してディスクの使用状況を確認します。sudo du -sh /folder/folder1 を実行して、大きいと思われる特定のフォルダのサイズを評価するとともに、他のファイルを削除してスペースを解放することを検討します。1 つのオプションとしては、docker rmi を実行して未使用の Docker イメージの削除を検討します。環境内における Docker のスペースは限られていることに注意してください。Docker の詳細については、Docker ドキュメントのガイドを参照してください。

docker push がタイムアウトし、再試行し続ける

問題: docker push を実行すると、タイムアウトになり、成功しないまま再試行を続けます。

原因: これは、アクセス許可の不足、間違ったリポジトリへのプッシュ、または認証の欠如が原因である可能性があります。

解決策: この問題を解決するには、正しいリポジトリにプッシュしていることを確認します。docker login を実行して適切に認証します。Amazon ECR リポジトリにプッシュするために必要なすべてのアクセス許可があることを確認します。

AWS CloudShell の VPC 環境から VPC 内のリソースにアクセスできない

問題: AWS CloudShell の VPC 環境の使用時に VPC 内のリソースにアクセスできません。

原因: AWS CloudShell の VPC 環境は VPC のネットワーク設定を継承します。

解決策: この問題を解決するには、リソースにアクセスできるように VPC が正しく設定されていることを確認します。詳細については、VPC ドキュメントの「VPC を他のネットワークに接続する」および Network Access Analyzer ドキュメントの「Network Access Analyzer」を参照してください。AWS CloudShell の VPC 環境で使用している IPv4 アドレスを確認するには、コマンドラインプロンプトまたは VPC コンソールページを使用して環境内で `ip -a` コマンドを実行します。

VPC 環境で AWS CloudShell が使用している ENI がクリーンアップされない

問題: VPC 環境で AWS CloudShell が使用している ENI をクリーンアップできません。

原因: ロールの ec2:DeleteNetworkInterface アクセス許可が有効になっていません。

解決策: この問題を解決するには、次のサンプルスクリプトに示すように、ロールの ec2:DeleteNetworkInterface アクセス許可を必ず有効にします。

{
  "Effect": "Allow",
  "Action": [
    "ec2:DeleteNetworkInterface"
  ],
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/ManagedByCloudShell": ""
    }
  },
  "Resource": "arn:aws:ec2:*:*:network-interface/*"
}

VPC 環境への CreateEnvironment アクセス許可のみを持つユーザーが AWS CloudShell のパブリック環境にもアクセスできる

問題: CreateEnvironment アクセス許可が VPC のみに制限されているユーザーが、AWS CloudShell のパブリック環境にもアクセスできます。

原因: CreateEnvironment アクセス許可を VPC 環境の作成のみに制限したときに、CloudShell のパブリック環境が既に作成済みである場合は、このパブリック環境をウェブユーザーインターフェイスを使用して削除するまで、引き続きパブリック環境にアクセスできます。ただし、以前に CloudShell を使用したことがない場合は、パブリック環境にアクセスできません。

解決策: AWS CloudShell のパブリック環境へのアクセスを制限するには、まず IAM 管理者が IAM ポリシーを更新して、この制限を含める必要があります。次に、ユーザーが AWS CloudShell ウェブユーザーインターフェイスを使用して既存のパブリック環境を手動で削除する必要があります ([アクション] → [CloudShell 環境を削除])。