はじめに
staging環境の構築で最初にやるのは、当然EC2インスタンスの作成です。本番のAMIから複製すれば一瞬...と思っていたのですが、SSH接続するまでに4台のインスタンスを作っては壊しを繰り返すことになりました。
この記事では、EC2インスタンス作成時にハマったポイントと解決策を共有します。
前提
- 本番環境: EC2（t3.small）、Amazon Linux 2023ベースのカスタムAMI
- 本番のElastic IP: 52.196.133.112
- リージョン: ap-northeast-1（東京）
作戦: 本番AMIから複製
本番環境のAMI（AI-navi-ami）が既に作成されていたので、これを使ってインスタンスを起動すれば、Ruby・MySQL・Nginx等が全てインストール済みの状態からスタートできます。
本番AMI → 新インスタンス起動 → SSH接続 → 環境調整 → 完了！
...のはずでした。
ハマりポイント1: サブネットが違う
最初のインスタンスを起動してSSH接続を試みると:
$ ssh -i ~/.ssh/AI-navi-KEY.pem ec2-user@57.180.52.138
ssh: connect to host 57.180.52.138 port 22: Operation timed out
タイムアウト。セキュリティグループのインバウンドルールにはSSH(22)が許可されているのに...
原因
本番インスタンスは subnet-0dbd688d89dfaa992（ap-northeast-1c）にあるのに、新しいインスタンスは subnet-00b57c7bdb7eea154（ap-northeast-1a）に作成されていました。
セキュリティグループのルールがサブネットに依存する設定になっていたため、異なるサブネットではSSH接続ができなかったのです。
解決策
本番EC2のメタデータAPIからサブネットIDを確認:
# 本番EC2で実行
curl -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/$(curl -s http://169.254.169.254/latest/meta-data/mac)/subnet-id
# → subnet-0dbd688d89dfaa992
インスタンスを作り直す際に、本番と同じサブネットを明示的に指定しました。
教訓
AMIからインスタンスを複製する際は、サブネットを本番と合わせること。デフォルトのサブネット選択に任せると、異なるAZに配置される可能性がある。
ハマりポイント2: セキュリティグループのIPが違う
サブネットを合わせて再作成。今度こそ...
$ ssh -i ~/.ssh/AI-navi-KEY.pem ec2-user@57.180.52.138
ssh: connect to host 57.180.52.138 port 22: Operation timed out
またタイムアウト。
原因
セキュリティグループのSSHインバウンドルールを確認すると:
ポート: 22
ソース: 133.106.32.1/32
しかし、自分のIPアドレスは 133.106.32.252 でした。下位オクテットが違う。
さらに調べると、ISPによってIPアドレスが 133.106.32.1 と 133.106.32.252 の間で変動していることが判明。
解決策
単一IPではなく、CIDR範囲で許可するように変更:
ポート: 22
ソース: 133.106.32.0/24
これにより、133.106.32.0 〜 133.106.32.255 の範囲を全てカバーできます。
教訓
SSHのIP制限は、ISPによるIP変動を考慮して /24 など余裕を持った範囲で設定すること。特にモバイル回線や一部のISPではIPが頻繁に変わる。
ハマりポイント3: PEMキーの混乱
インスタンス作成時にキーペアを Meta-navi-KEY で設定したのですが、手元にあるのは AI-navi-KEY.pem。
原因
AMIに元々 AI-navi-KEY の公開鍵が ~/.ssh/authorized_keys に登録されていたため、キーペアの設定に関わらず AI-navi-KEY.pem でSSH接続が可能でした。
AMIから起動する場合、AMI作成時の authorized_keys がそのまま引き継がれるため、EC2コンソールで設定するキーペアと実際に使えるキーが異なることがあります。
教訓
AMIから複製したインスタンスでは、AMI内の
authorized_keysが優先される。キーペアの設定はあくまでメタデータで、実際のSSH認証には影響しない場合がある。
最終的な正しい設定
| 設定項目 | 値 |
|---|---|
| AMI | AI-navi-ami (ami-06becd0f05bd0c9d8) |
| インスタンスタイプ | t3.small |
| サブネット | subnet-0dbd688d89dfaa992 (ap-northeast-1c) |
| セキュリティグループ | launch-wizard-2 (SSH元IPを /24 で許可) |
| SSHキー | AI-navi-KEY.pem |
# ついにSSH成功！
$ ssh -i ~/.ssh/AI-navi-KEY.pem ec2-user@57.181.44.170
Last login: ...
[ec2-user@ip-172-31-14-185 ~]$
4台目にしてようやくSSH接続成功。ここまでで約2時間かかりました。
まとめ
EC2インスタンスの作成自体は数クリックですが、ネットワーク周りの設定を一つでも間違えるとSSH接続すらできません。
| ハマりポイント | 解決策 |
|---|---|
| サブネットが本番と異なる | 本番のサブネットIDを確認して明示的に指定 |
| セキュリティグループのIPが不一致 | /24 の CIDR 範囲で許可 |
| PEMキーの混乱 | AMI内の authorized_keys を確認 |
次回は、このインスタンスにRuby 4.0.0をビルドしようとしてメモリ枯渇で死んだ話です。