はじめに
目的
本書は、AWS環境で「ポート8080にアクセスできない」問題の原因と解決手順を体系的に示します。EC2やECS/FargateでWebアプリが8080で待ち受けているのに外部から見えないときに、順序立てて確認できるように設計しました。
対象読者
開発者、運用担当者、クラウド利用の初中級者を想定します。AWSの基本操作（コンソールやSSH）が分かれば読み進められます。
想定環境とよくある症状
想定は、アプリがポート8080でリッスンしているサーバやコンテナです。症状例：ブラウザで http://:8080 にアクセスできない、curlで接続がタイムアウトする、など。
本書の構成（全5章）
- はじめに（本章）
- 全体像：確認すべきレイヤーのまとめ
- アプリ／OS側の確認方法
- インスタンス内ファイアウォール確認
- AWSセキュリティグループ等の設定確認
使い方
問題発生時はまず第2章で全体像を把握し、その後順に各章の手順で検証してください。作業前にログ取得と設定のバックアップをおすすめします。
AWSで「8080にアクセスできない」ときにまず押さえる全体像
はじめに
EC2上のSpring BootやTomcatが8080で動いているのに外部からアクセスできない、ECS/FargateのコンテナがALB経由でも応答しない、ローカルでは動くがAWS上ではタイムアウトする――こうした事例がよくあります。原因は一箇所ではなく、順を追って確認すると短時間で直ることが多いです。
典型的な状況（具体例）
- EC2でアプリは起動しているがブラウザでタイムアウト
- ECSのタスクはRUNNINGだがALBのターゲットがunhealthy
- ローカルのDockerではアクセスできるがAWSでは接続拒否やタイムアウト
原因は大きく四つのレイヤー
- アプリ／OSレベル：アプリが本当にポート8080で待ち受けしているか、localhostだけでバインドしていないかを確認します（例：Spring Bootが127.0.0.1でバインドしている）。
- インスタンス内ファイアウォール：iptablesやufwで8080がブロックされている場合があります。
- AWS側（セキュリティグループ／ALB）：セキュリティグループのインバウンドやALBのリスナー/ターゲット設定を確認します。
- ネットワーク設計ミス：サブネットのルーティング、NACL、プライベートサブネット配置など経路が正しいかを確認します。
優先して確認する順序（実行しやすいチェック）
- インスタンス内部からcurl http://localhost:8080 で応答を確認
- ポートの待ち受け確認：ss -lntp | grep 8080 または netstat -tlnp
- ファイアウォール確認：sudo iptables -L / sudo ufw status
- 別のホストから接続確認（EC2なら別のインスタンスや踏み台からcurl）
- セキュリティグループで8080が許可されているか、ALB経由ならターゲットのヘルスチェック設定を確認
- コンテナの場合はポートマッピング（ホスト側とコンテナ側のポート）やタスク定義を確認
最初に上から順に確認すると、原因の切り分けが速く行えます。次章ではアプリ／OS側での確認方法を詳しく説明します。
アプリ／OS側で「8080」が本当に開いているか確認する
確認の狙い
ポート8080でアプリが待ち受けているかを確かめます。外部から届かない原因は、アプリが起動していない、別プロセスが占有している、あるいはローカルのみでしか聞いていない場合が多いです。
ポート競合の症状とログ例
起動時に「EADDRINUSE」などのエラーが出ます。例：
Error: listen EADDRINUSE: address already in use :::8080
この場合は同じポートを別プロセスが使っています。
実際に使うコマンド
- EC2上（またはコンテナ内で）
sudo lsof -i :8080
sudo netstat -tulpn | grep 8080
または
ss -tulpn | grep 8080
これでプロセス名とPIDが分かります。
ECSタスク（Fargate含む）では、タスク内に入って同様のコマンドを実行するか、aws ecs execute-commandでシェルを取得して確認します。
バインド先（アドレス）の違い
- 127.0.0.1（localhost）：そのホスト内からのみ接続可能です。
- 0.0.0.0：全てのネットワークインターフェースで接続を受け付けます。
外部からアクセスさせるにはアプリを0.0.0.0でリッスンさせます。設定例：
– Node.js: app.listen(8080, ‘0.0.0.0’)
– Flask: app.run(host=’0.0.0.0′)
– Spring Boot: –server.address=0.0.0.0
またコンテナを使う場合は、コンテナ側が0.0.0.0で待ち受け、ホスト側のポートマッピング（-p 8080:8080）を確認してください。
簡単な確認手順
- インスタンス内で lsof/ss でポート確認
- ログにEADDRINUSEなどが無いか確認
- アプリのバインド先が0.0.0.0か確認
- コンテナならポートマッピングを確認
以上を順に確認すれば、アプリ/OS側の問題は絞り込めます。
インスタンス内ファイアウォールの確認
背景
EC2やオンプレのインスタンスにはOSレベルのファイアウォール（iptables、firewalld、ufwなど）が動作します。AWSのセキュリティグループが開いていても、OS側でブロックされていれば外部からアクセスできません。両方のレイヤーを必ず確認してください。
確認手順（基本）
- ポートがアプリでリスンしているか確認:
ss -tlnp | grep 8080（またはnetstat -tlnp） - firewalldの状態:
sudo systemctl status firewalld - iptablesのルール確認:
sudo iptables -L -n -v - ufwの状態確認（Ubuntu等）:
sudo ufw status
firewalldでの具体例（ポート8080を開放）
- 永続的に追加:
sudo firewall-cmd --permanent --add-port=8080/tcp - 設定反映:
sudo firewall-cmd --reload - 確認:
sudo firewall-cmd --list-portsまたはsudo firewall-cmd --list-all
iptables／ufwでの簡単な例
- iptablesで一時的に許可:
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT（永続化はディストロにより手順が異なります） - ufwで許可:
sudo ufw allow 8080/tcp
チェックの順序と注意点
- アプリのリスン確認→2. OSファイアウォール確認→3. AWSセキュリティグループ確認の順で確認すると効率的です。OS側の変更は即時反映されますが、誤って不要なポートを開かないよう最小限に留めてください。
AWSセキュリティグループで8080が開いているか
概要
セキュリティグループはインスタンスやサービスへの出入り口を制御します。インバウンドでTCPポート8080を許可するかどうかがポイントです。ここでは直接アクセスとALB経由の2通りを分かりやすく説明します。
直接アクセス（Public IP:8080）の例
- 必要設定: 対象インスタンスのセキュリティグループでインバウンドにTCP 8080を追加します。ソースはアクセス元IPに限定してください。
- 実例: 自宅からだけアクセスするなら自宅の固定IP/32を指定。全世界からのアクセス（0.0.0.0/0）は避けます。
ALB経由の構成例
- ALB側: クライアントからのHTTP/HTTPSを許可（通常はポート80/443、ソースは0.0.0.0/0が一般的）。
- インスタンス側: ALBのセキュリティグループをソースにしてTCP 8080を許可します（セキュリティグループIDを指定）。これで外部から直接8080へ繋がらず、ALB経由だけ許可されます。
設定の確認とテスト方法
- コンソール: EC2 > セキュリティグループ > 当該SGの「インバウンドルール」を確認。
- CLI例: aws ec2 describe-security-groups –group-ids sg-xxxxxxxx
- 動作確認: 直接アクセスなら curl http://:8080 、ALB経由ならALBのFQDNへアクセスします。
守るべきポイント
- 必要最小限のアクセスに限定する。
- ALBとインスタンスでSGを分け、SG参照（ID指定）で許可する。
- 問題の際はセキュリティグループの設定に加え、OS側ファイアウォールとアプリのポートを合わせて確認してください。
