EC2トラブルシューティング集！接続できない・エラーの原因と対処法まとめ
生徒
「EC2インスタンスに接続しようとしてもタイムアウトになるんです。何が原因か全然分からなくて……」
先生
「EC2で接続できない場合は、ネットワーク設定やセキュリティグループ、鍵ファイルの権限など、いくつかの原因が考えられるよ。一緒に確認してみよう！」
生徒
「お願いします！何からチェックすればいいですか？」
先生
「まずは接続できない状況を整理して、原因別にトラブルシューティングしていこうか！」
1. セキュリティグループのポート設定を確認
EC2インスタンスにSSH（Tera TermやMacのターミナルなど）で接続しようとして「Connection timed out」と表示される場合、最も多い原因はセキュリティグループのインバウンドルール（入ってくる通信の許可設定）に不備があることです。
セキュリティグループは、いわば「インスタンスの周りにある仮想的な防火壁（ファイアウォール）」です。明示的に「このポートを通しても良い」という許可を与えない限り、すべての通信を遮断してしまいます。
以下の設定がインバウンドルールに含まれているか確認しましょう。
- タイプ： SSH
- プロトコル： TCP
- ポート範囲： 22
- 送信元： 0.0.0.0/0（どこからでも許可） または 自分のIP（推奨）
設定の手順は、AWSマネジメントコンソールから「EC2」を開き、「セキュリティグループ」を選択します。対象のグループを選んで「インバウンドルールを編集」をクリックし、ポート22が空いているか確認してください。
例えば、Linuxサーバー側でWebサーバー（Apacheなど）を動かしてブラウザから確認したい場合は、SSHの「22番」だけでなく、HTTPの「80番」も許可する必要があります。
未経験の方のために、もし「自分のPCからサーバーのポート22が開いているか」を確認したい場合のコマンド例（ncコマンド）を紹介します。
nc -zv xx.xx.xx.xx 22
Connection to xx.xx.xx.xx port 22 [tcp/ssh] succeeded!このように「succeeded!」と表示されれば、セキュリティグループの設定は正しく外部に公開されています。もし反応がない場合は、まずAWSコンソールの設定画面を見直すのがトラブル解決の近道です。
2. キーペア（.pem）の権限エラーを確認
SSH接続時に以下のようなエラーが表示されたら、キーペアファイルのパーミッション設定が原因です。
WARNING: UNPROTECTED PRIVATE KEY FILE!
対処法は、.pemファイルの権限をchmod 400で変更することです。
chmod 400 my-key.pem
ssh -i my-key.pem ec2-user@xx.xx.xx.xx
正しいパーミッションでないと、SSHがセキュリティのために接続を拒否します。
3. Elastic IPの割り当てと接続先アドレスの確認
EC2インスタンスに接続する際、一時的なパブリックIPを使用していると、再起動後にアドレスが変わってしまいます。
安定した接続を行いたい場合は、Elastic IPをインスタンスに割り当てましょう。Elastic IPは固定のパブリックIPとして扱え、DNS設定にも利用できます。
コンソールの「Elastic IP」→「Elastic IPアドレスの割り当て」から取得し、対象のインスタンスに「アタッチ」してください。
4. OSやユーザー名の違いによる接続エラー
Amazon Linux 2やUbuntuなど、EC2のAMI（OS）によって初期ユーザー名が異なります。ユーザー名が間違っていると接続できません。
- Amazon Linux：
ec2-user - Ubuntu：
ubuntu - RHEL：
ec2-userまたはroot - CentOS：
centos
SSH接続時は以下のように指定しましょう。
ssh -i my-key.pem ubuntu@xx.xx.xx.xx
5. ネットワークACLとVPC設定を見直す
セキュリティグループが正しくても、VPCのネットワークACL（NACL）でSSHトラフィックがブロックされていることがあります。NACLはVPC内のサブネット単位で適用されるファイアウォールです。
以下のようなルールが設定されているか確認しましょう。
- インバウンド：ポート22を0.0.0.0/0から許可
- アウトバウンド：ポート1024-65535を許可
また、インスタンスが所属するサブネットに、インターネットゲートウェイがアタッチされているか、ルートテーブルで正しくルーティングされているかもチェックしましょう。
6. インスタンスの状態チェックとCloudWatchログの確認
EC2インスタンスが「running」でも、システムステータスチェックやインスタンスステータスチェックが失敗していると、接続できません。
EC2ダッシュボードでステータスチェックに「2/2 checks passed」と表示されているか確認してください。
それでも原因が分からない場合は、CloudWatch Logsを利用して、EC2の初期化ログ（/var/log/cloud-init.logなど）を確認するとヒントが得られることがあります。
7. WindowsインスタンスのRDP接続ができない
Windowsインスタンスにリモートデスクトップ（RDP）で接続できない場合は、以下の点をチェックしましょう。
- セキュリティグループでポート3389（RDP）が開放されているか
- Elastic IPが割り当てられているか
- Windowsパスワードの取得が正しくできているか
また、Windows Firewall側でRDPが許可されていないと接続できません。インスタンス内でローカル接続できる場合は、コントロールパネルのファイアウォール設定も見直しましょう。
まとめ
今回の記事では、AWS EC2インスタンスに接続できないときの代表的なトラブルシューティング方法を、具体的な原因別に解説しました。特に初心者がつまずきやすいのは、セキュリティグループのポート開放ミス、キーペア（.pem）ファイルのパーミッション設定、Elastic IP未設定、インスタンスのユーザー名の間違いなどです。これらの設定ミスは、SSHやRDPで接続できない一因となりがちです。
EC2の接続トラブルは、単なる「サーバーが落ちている」だけではなく、AWSのネットワーク設定、VPC構成、インスタンスの状態、ルーティングやファイアウォール設定など、広範囲にわたる原因が潜んでいます。だからこそ、段階的に確認すべきポイントを押さえておくことが重要です。
たとえば、以下のような順序で確認すると、無駄なく原因を特定できます。
- インスタンスのステータスチェック（EC2ダッシュボードで「2/2 Passed」）
- Elastic IPアドレスの設定確認（動的IPでは再起動で変更される）
- セキュリティグループでポート22（または3389）が許可されているか
- キーペアのパーミッション設定（SSHの場合）
- OSごとの正しいユーザー名で接続しているか
- ネットワークACL（NACL）やVPCルートテーブルの見直し
- CloudWatchでインスタンスログやシステムログを確認
こうした設定チェックを自動化するには、AWS CLIを用いたスクリプトの活用も有効です。たとえば、セキュリティグループのポートを一覧で確認するスクリプトは次のようになります。
aws ec2 describe-security-groups \
--query "SecurityGroups[*].{Name:GroupName, Ingress:IpPermissions[*].FromPort}" \
--output table
また、ステータスチェックやElastic IPの有無を確認するには、次のコマンドも役立ちます。
aws ec2 describe-instance-status \
--instance-ids i-0123456789abcdef0 \
--query "InstanceStatuses[*].{Status:InstanceStatus.Status, System:SystemStatus.Status}" \
--output table
さらに、Windows Server系のトラブルではRDP接続に必要なポート3389の開放だけでなく、Windows Firewallの設定確認も忘れずに。管理ツールから「リモートデスクトップ」を許可していないと、外部からのアクセスが失敗します。
AWSのEC2インスタンスは非常に柔軟でパワフルですが、その分トラブルの範囲も広いため、トラブルシューティングの知識はクラウド運用における重要なスキルとなります。今回学んだ接続トラブルの原因とその対処法は、今後の実践でも大きな武器になるはずです。
生徒
「接続できない原因がこんなにたくさんあるなんて驚きでした。でも一つずつチェックすれば解決できそうです！」
先生
「そうだね。EC2ではネットワークやセキュリティ設定がきちんとしていないと、トラブルになりやすいんだ。でも今回のように原因を分類して順に確認すれば、冷静に対応できるようになるよ。」
生徒
「Elastic IPやセキュリティグループ、ステータスチェックなど、普段あまり見ていなかったところにも注目できるようになりました！」
先生
「それは大きな進歩だね。今後は新しいインスタンスを作成するときにも、これらの確認ポイントをチェックリストとして使ってみよう！」
この記事を読んだ人からの質問
