はじめに

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をビルドしようとしてメモリ枯渇で死んだ話です。