AWSから「再起動します」と言われたFTPサーバーで、まず確認すること

はじめに

AWS から「お使いのインスタンスで再起動が予定されています」というメールが届いた。EC2 を運用していれば一度は見る、あの通知である。

FTP サーバーを載せているインスタンスだと、この通知の重みが他のサーバーとは違う。FTP は PASV 応答の本文に接続先 IP を書いて返すプロトコルなので、他のサーバーなら軽微な「IP が変わった」が、そのまま直接の故障要因になる。だから「再起動される」と聞いた瞬間に、身構える理由がある。

ただし、身構える方向を間違えると意味がない。

❌ ホストが変わる再起動は IP も変わるから危ない

👉 ホストが変わることと IP が変わることは別の軸である。ホストを移るのに IP を維持するイベントがあり、逆に「止めて起こすだけ」に見えて自動割当パブリック IPv4 と instance store のデータを持っていくイベントもある。

この記事は、通知が来てから何をすべきかを、以下の順で辿る。

• まず event code を確定する
• スケジュールイベント5種類の対応表を作る
• その表を FTP の壊れ方に翻訳する
• 待つべきか、自分で先に手を打つべきかをイベント別に判断する
• 再スケジュールできる条件を確認する
• 実施前に FTP 側で見ておくチェックリスト
• 実施後の確認

OS レベルの罠——bind できない、PASV が返す IP、パッシブポート範囲、セッション切断——は、この記事では再現手順と詳細な検証までは扱わない。それは既存記事 FTPサーバーの再起動で踏む4つの罠 に譲る。この記事の役割は、AWS 側が何をするか、どの操作をこちらで選べるか、それが FTP の何に効くかを整理することである。

検証環境は以下のとおり。

aws-cli/2.33.14 Python/3.13.11 Linux/6.17.0-35-generic exe/x86_64.ubuntu.24

👉 この記事の執筆環境には有効な AWS 認証情報がない（aws sts get-caller-identity は InvalidClientTokenId を返す）。したがってAWS API を実際に実行した結果は載せていない。CLI のコマンド形とオプション名は aws <コマンド> help で実在を確認したうえで載せている。出力例を載せる箇所では、AWS ドキュメントに記載されている例であることをそのつど明示する。

---

まず event code を確定する

判断の根拠は、通知メールの文面ではなく event code に置く。メールの日本語文面は、あとで触れるとおり種別まで書き分けていないことがあるからである。

確認は describe-instance-status で行う。

aws ec2 describe-instance-status \
    --instance-ids i-1234567890abcdef0 \
    --query "InstanceStatuses[].Events"

以下は AWS ドキュメントに載っている出力例である（手元で実行した結果ではなく、ドキュメントからの引用のため JSON として閉じていない）。

[
    "Events": [
        {
            "InstanceEventId": "instance-event-0d59937288b749b32",
            "Code": "system-reboot",
            "Description": "The instance is scheduled for a reboot",
            "NotAfter": "2020-03-14T22:00:00.000Z",
            "NotBefore": "2020-03-14T20:00:00.000Z",
            "NotBeforeDeadline": "2020-04-05T11:00:00.000Z"
        }
    ]
]

各フィールドの読み方は以下のとおり。

• Code — イベントの種別。以降の判断はすべてこれで決まる
• InstanceEventId — 再スケジュールするときに指定する ID
• NotBefore / NotAfter — 実施される時間帯
• NotBeforeDeadline — イベントの期限日。このフィールドがあるイベントだけ再スケジュールできる

コンソールの Events 画面でも確認できる。Event type 列に event code が出る。

👉 メールの文面は種別まで書き分けていないことがある。instance-reboot と system-reboot は日本語にするとどちらも「再起動」だが、やることも、取れる手も違う。文面を読んで判断するのではなく、event code を見て判断する。

👉 AWS Health イベントも合わせて送られる。Amazon EventBridge で監視・管理できるので、通知の受け取りを自動化したい場合はそちらを調べるとよい。

出典: Scheduled events for Amazon EC2 instances

---

5種類のイベントで、何が作り直され何が残るか

event code が確定したら、次はそのコードが何を意味するかである。まず一覧で押さえる。

イベントコード	AWS が行うこと
instance-stop	予定時刻にインスタンスを停止する。再度起動すると新しいホストへ移行する。EBS ルートボリュームのインスタンスにのみ適用
instance-retirement	予定時刻に、EBS ルートなら停止、instance store ルートなら終了する
instance-reboot	予定時刻に再起動する。インスタンスはホストに留まり、その間にホストがメンテナンスされる（in-place reboot）
system-reboot	予定時刻に再起動し、新しいホストへ移行する（reboot migration）
system-maintenance	予定時刻に、ネットワークメンテナンスまたは電源メンテナンスの影響を一時的に受ける可能性がある

これだけだと「結局何が変わるのか」が見えない。同じ軸で並べたのが次の表である。

	instance-reboot	system-reboot	system-maintenance	instance-stop / instance-retirement
ホストが変わる	変わらない	変わる	変わらない（設定はすべて保持される）	start 時に多くの場合変わる
IP アドレス・DNS 名	維持	維持	維持	自動割当パブリック IPv4 は変わる（EIP なら維持）
プライベート IPv4	維持	維持	維持	維持（ENI ごと残る）
instance store のデータ	保持	保持	保持	消える
OS が再起動する	する	する	電源メンテなら再起動／ネットワークメンテなら再起動しない	停止→起動
所要時間の目安	約30秒	数分	短時間	停止と起動のぶん

👉 太字の交差点が本記事の要点である。system-reboot は新しいホストへ移るのに、IP アドレスと DNS 名を維持し、instance store のデータも保持する。ホスト移行の有無と IP 維持の有無は独立した軸である。

👉 逆に instance-stop / instance-retirement は「止めて起こすだけ」に見えて、自動割当パブリック IPv4 と instance store のデータを持っていく。見た目の軽さと影響の軽さは一致しない。

❌ 「ホストが変わる再起動は IP も変わる、ホストが変わらない再起動は IP も変わらない」

この思い込みは system-reboot の列を見た時点で崩れる。ホストは変わるが IP は変わらない。逆に instance-stop はホストが変わっても変わらなくても、自動割当パブリック IPv4 は変わる。「ホストが変わるかどうか」と「IP が変わるかどうか」を同じ質問だと思わないことが、この表の使い方である。

system-maintenance の2種類

system-maintenance は一行にまとめると誤解を生む。中身は2種類ある。

• ネットワークメンテナンス — 対象インスタンスは短時間ネットワーク接続を失う。完了後に通常の接続が回復する
• 電源メンテナンス — 対象インスタンスは短時間オフラインになり、その後再起動される。再起動時にインスタンスの設定はすべて保持される

👉 system-maintenance を「再起動しないイベント」と決めつけてはいけない。電源メンテナンスなら再起動される。

EIP と自動割当パブリック IPv4 は別物

上の表の「変わる」「維持」は、パブリック IP をひとくくりにすると読み間違える。

• 停止時に失われるのは「EC2 が自動的に割り当てたパブリック IPv4 アドレス」であって、Elastic IP ではない
• Elastic IP は ENI に紐づくので停止・起動をまたいでも残る。ただし停止中も EIP には課金される
• プライベート IPv4 と IPv6 も ENI ごと残る
• start 時、パブリック IPv4 を受け取る設定のインスタンスには新しいアドレスが割り当てられる。ただし Elastic IP が関連付けられたセカンダリ ENI またはセカンダリプライベート IPv4 を持つ場合を除く

出典:

• Scheduled events for Amazon EC2 instances
• Manage Amazon EC2 instances scheduled for reboot
• Manage Amazon EC2 instances scheduled to stop or retire
• Manage Amazon EC2 instances scheduled for maintenance
• How EC2 instance stop and start works

---

FTP に翻訳する

前章の表は AWS 側の事実の一覧にすぎない。ここからは、その表を FTP の壊れ方に対応づける。

PASV が返す IP

FTP のパッシブモードでは、クライアントが PASV コマンドを送ると、サーバーが「このアドレスのこのポートに繋ぎ直せ」と応答本文に IP を書いて返す。この応答を見てクライアントがデータコネクションを張り直す。

vsftpd の pasv_address に生の IP を書いていると、この応答に使われる IP は固定される。たとえば pasv_address=203.0.113.10 と書いた状態で instance-stop 後に start すると、自動割当パブリック IPv4 は 203.0.113.25 のような別の値に変わる。設定ファイルの中身は古い IP のままなので、クライアントは古い 203.0.113.10 に繋ぎに行く。

食い違いが起きても、制御コネクションは生きているのでログインまではできる。壊れるのはデータコネクションだけである。ログインはできるのに ls が固まる、という形で症状が出る。

生の IP を避け、ホスト名を書いて起動時に解決させるのが対策になる。

pasv_enable=YES
pasv_address=ftp.example.com
pasv_addr_resolve=YES
pasv_min_port=50000
pasv_max_port=50100

ただし、pasv_address にホスト名を書き、pasv_addr_resolve=YES で解決させる構成であっても油断はできない。vsftpd の pasv_addr_resolve は、ホスト名を起動時に一度だけ解決する。これは既存記事 FTPサーバーの再起動で踏む4つの罠 で Docker 検証済みの挙動であり、本記事では再検証せずリンクする。つまり、ftp.example.com が指す先の DNS レコードを新しい IP（203.0.113.25）に更新しても、vsftpd プロセスを再起動しない限り古い IP を返し続ける。

❌ ホスト名で pasv_address を書いておけば IP が変わっても安心

👉 起動時に一度だけ解決される以上、「DNS を更新した」だけでは直らない。OS が再起動した後に vsftpd も新しい情報で起動し直っていることが前提になる。

この罠が発火するのは、前章の表でいえば instance-stop / instance-retirement で自動割当パブリック IPv4 を使っている場合だけである。system-reboot は IP アドレスと DNS 名を維持するので、この罠を踏まない。instance-reboot も IP を維持する。Elastic IP を使っている場合は、instance-stop / instance-retirement であっても IP 自体が変わらないので、この罠は発火しない。

👉 罠②を構造的に消したいなら Elastic IP を関連付ける。EIP は ENI に紐づくので stop/start をまたいでも変わらず、pasv_address に書いた値も DNS も動かさずに済む。停止中も課金される点だけ承知しておく。

データの置き場所

前章の表にあるとおり、消えるのは instance store 上のデータだけである。EBS 上のデータは、停止・起動をまたいでも残る。

ここで見落としやすいのが構成である。ルートボリュームが EBS でも、追加で instance store ボリュームをアタッチしている構成はある。 この場合、ルートは残ってもアタッチした instance store ボリュームの中身は、停止すれば消える。「EBS ルートだから大丈夫」という判断は、FTP のデータ領域がどのボリュームに乗っているかを確認していなければ成り立たない。

FTP のデータ領域がどちらに乗っているかは、事前に以下で確認できる。

lsblk
df -h /srv/ftp
grep -v '^#' /etc/fstab

lsblk でブロックデバイスの一覧を見て、df -h /srv/ftp で FTP のデータディレクトリがどのデバイスにマウントされているかを特定し、/etc/fstab でそのデバイスが永続化されたマウントかどうかを確認する、という順序である。

OS 再起動そのものが引き起こす罠

ここまでは「IP」と「データ」という、AWS 側の事情が直接効く罠だった。一方で、既存記事の罠のうち①・③・④は、AWS のイベント種別を問わず、OS が再起動しさえすれば発火しうる。前章の表で「OS が再起動する」に印がついている種別はすべて対象になる。

既存記事の罠	発火する条件
① 存在しない IP には bind できない	OS 再起動を伴うすべて（system-maintenance は電源メンテ時）
② PASV が返す IP	instance-stop / instance-retirement で自動割当パブリック IPv4 を使っている場合
③ パッシブポート範囲・firewall	OS 再起動を伴うすべて（ただし SG は AWS 側リソースなので消えない）
④ 転送中セッションの切断	すべて（ネットワークメンテナンスでも切れる）

罠②だけが IP の変化を前提にしているので、種別を選ぶ。罠①・③・④は OS 再起動という現象そのものに紐づくので、instance-reboot や system-reboot のように IP を維持する種別でも発火する。罠④に至っては、OS を再起動しないネットワークメンテナンスでも、通信断そのものによって転送中セッションが切れる。

👉 セキュリティグループのパッシブポート範囲の許可は AWS 側のリソースである。インスタンスを再起動しても、停止・開始してもセキュリティグループの設定は消えない。これは OS 側の firewall（iptables / nftables / firewalld）を永続化していない場合とは事情が違う。OS 側の firewall ルールは、永続化の設定をしていなければ再起動のたびに失われる。再起動で消えるものと消えないものの線は、OS の内側と外側に引かれている。

---

待つか、自分で先にやるか

ここまでで「何が起きるか」は整理できた。ここからは「通知を受け取った側が何をすべきか」である。イベント種別によって、先回りが効くものと空振りするものがはっきり分かれる。

instance-reboot

instance-reboot イベントに対して自分で reboot しても、インスタンスは現在のハードウェアに留まる（in-place reboot）。ホストのメンテナンスは行われず、イベントは開いたまま残る。

❌ 良かれと思って予定時刻より前に自分で再起動しておく

👉 先回りしても AWS 側が予定している作業は消化されない。サービス断を1回増やしただけで、後日また同じイベントが来る。 instance-reboot に対して取れる手は「待つ」か、次章で扱う「再スケジュール」の2つだけである。

system-reboot

system-reboot イベントを受け取ったインスタンスは、既定でユーザー起因の reboot migration が有効になっている。この既定を踏まえると、自分で再起動したときの結果は次のようになる。

• reboot migration が有効なら、自分で再起動すると新しいハードウェアへの移行を試みる。成功すればイベントはクリアされる
• 移行に失敗すると in-place reboot になり、イベントは残る

つまり system-reboot の先回りは、instance-reboot と違って意味を持ちうる。ただし確実ではなく、失敗すれば空振りに終わる。

reboot migration の有効・無効は modify-instance-maintenance-options で切り替えられる。

aws ec2 modify-instance-maintenance-options \
    --instance-id i-1234567890abcdef0 \
    --reboot-migration disabled

--reboot-migration に default を指定すれば元の有効な状態に戻る。

👉 無効にしてもイベント自体は消えない。 消えるのは「自分の再起動で移行が成功したとき」だけである。無効にした場合、自分の再起動は in-place reboot になってイベントは残ったままだが、その後スケジュールされた時刻が来れば、結局 AWS が新しいハードウェアへ移す。無効化は「先回りを封じる設定」であって、「イベントを消す設定」ではない。

reboot migration が使えない条件

reboot migration には対応していないインスタンスがある。以下のいずれかに該当すると、そもそもこの手は使えない。

• Xen ハイパーバイザ上でネイティブに動作するインスタンス
• metal インスタンス
• Dedicated Host（Dedicated Host では Dedicated Host Auto Recovery を使う）
• instance store ボリュームを持つインスタンス
• Elastic Fabric Adapter を使うインスタンス
• Auto Scaling グループに属するインスタンス

👉 FTP のデータ領域を instance store に置いていると、この条件に引っかかる。先回りの手が最初から使えないということである。「FTP に翻訳する」で確認した「FTP のデータ領域がどちらのボリュームに乗っているか」が、ここでも効いてくる。

対応しているインスタンスタイプは、以下で確認できる。

aws ec2 describe-instance-types \
    --filters Name=reboot-migration-support,Values=supported \
    --query "InstanceTypes[*].[InstanceType]" \
    --output text | sort

instance-stop / instance-retirement

EBS ルートボリュームのインスタンスなら停止が、instance store ルートボリュームのインスタンスなら終了がスケジュールされる。取れる手は、ルートボリュームの種類で分かれる。

EBS ルートの場合：

• 予定時刻の停止を待つ
• 自分で都合のよい時刻に stop/start する
• AWS Health のイベントに反応して stop/start を自動化する（実装の詳細は本記事の射程外。スケジュールイベントのドキュメント で監視・管理できる）

❌ reboot すれば代わりになる

👉 reboot では代わりにならない。 instance-stop / instance-retirement のイベントでは、reboot はホストを移らない（reboot migration は system-reboot イベントを持つインスタンスの仕組みである）。ホストを移すのは stop/start である。instance-stop / instance-retirement が問題にしているのは、ホストの修復不能な障害であって、OS の再起動ではない。

stop/start を自分で実施する前に、退避すべきものが2つある。

• instance store のデータ（停止すれば消える。「FTP に翻訳する」の確認手順を先に済ませておく）
• パブリック IP が変わる前提での pasv_address と DNS の手当て（「FTP に翻訳する」で扱った罠②がここで発火する）

instance store ルートの場合、停止ではなく終了がスケジュールされるので、取れる手はより手前に用意する必要がある。

• 最新の AMI から代替インスタンスを起動する
• 必要なデータを新しいインスタンスへ移す
• 元のインスタンスを終了する

system-maintenance

system-maintenance は、通知の説明文で内容が変わる。

• ネットワークメンテナンスなら短時間ネットワークが切れるだけで、再起動はしない
• 電源メンテナンスなら短時間オフラインになった後に再起動される（インスタンスの設定はすべて保持される）

どちらに該当するかは通知の説明文で判断するしかない。👉 再起動される可能性がある以上、OS 再起動を伴う前提で備えるのが安全である。「ネットワークメンテナンスだろう」と決めつけて備えを省略すると、電源メンテナンスだった場合に「FTP に翻訳する」の罠①・③・④を素通しすることになる。

待つ以外の手としては、自分で stop/start して新しいホストへ移ることもできる。ただしこの場合も instance-stop と同じく、自動割当パブリック IPv4 が変わる点は変わらない。

判断のまとめ

先回りする意味があるかどうかは、イベントごとに以下のように整理できる。

イベント	先回りする意味
instance-reboot	ない（イベントが残る）
system-reboot	条件付きである（reboot migration が有効かつ対応構成なら消える）
system-maintenance	stop/start なら移れるが IP が変わる
instance-stop / instance-retirement	ある（時刻を選べる。ただし stop/start）

出典:

• Manage Amazon EC2 instances scheduled for reboot
• Manage Amazon EC2 instances scheduled to stop or retire
• Manage Amazon EC2 instances scheduled for maintenance

---

再スケジュールできる条件

前章で「再スケジュール」という言葉が出た。ここではその中身を条件として整理する。誰でも好きなだけ動かせるわけではない。

• イベント期限日を持つイベントだけが再スケジュールできる。期限日はコンソールの Deadline 列、CLI の NotBeforeDeadline フィールドに出る
• 再スケジュールできるのはまだ開始していないイベントだけ。開始時刻はコンソールの Start time 列、CLI の NotBefore フィールドに出る
• 今後 5 分以内に開始予定のイベントは再スケジュールできない
• 新しい開始時刻は現在時刻から最低 60 分先でなければならない
• コンソールで複数イベントをまとめて再スケジュールすると、期限日は最も早い期限日のイベントに合わせられる

NotBeforeDeadline と NotBefore はどちらも「まず event code を確定する」の章で見たフィールドである。再スケジュールが効くかどうかは、この2つの値を確認するところから始まる。

コマンドは以下のとおり。--instance-event-id には describe-instance-status で取得した InstanceEventId の値をそのまま渡す。

aws ec2 modify-instance-event-start-time \
    --instance-id i-1234567890abcdef0 \
    --instance-event-id instance-event-0d59937288b749b32 \
    --not-before 2026-09-15T02:00:00.000

👉 期限日そのものは動かせない。動かせるのは期限日までの範囲で開始時刻を選ぶことだけ。 FTP の転送が少ない時間帯に寄せる、という使い方になる。

出典: Reschedule a scheduled event for an EC2 instance

---

実施前チェックリスト

再起動であれ stop/start であれ、実施前に見ておくべき項目をまとめる。既存記事側のチェック（bind / パッシブポート / セッション切断そのものの検証手順）とは重ならないよう、AWS の構成に紐づく項目を中心にする。

• FTP のデータ領域は EBS か instance store か（lsblk / df -h / /etc/fstab で確認済みか）
• 追加した EBS を /etc/fstab に書いているか。デバイス名ではなく UUID を使っているか。nofail を付けているか
• パブリック IPv4 は Elastic IP か、EC2 が自動割り当てたものか
• pasv_address に生の IP を書いていないか。書いているなら、それが Elastic IP であることを確認する
• systemctl is-enabled vsftpd — 手で起動したまま enable し忘れていないか
• セキュリティグループにパッシブポート範囲が空いているか（再起動では消えないが、この機会に確認しておく）
• 転送中セッションが切れることを、クライアント側の運用者に伝えたか
• EBS スナップショットを取ったか

まとめて確認するなら以下のコマンドになる。

systemctl is-enabled vsftpd
grep -E 'pasv_address|pasv_addr_resolve|pasv_min_port|pasv_max_port|listen_address' /etc/vsftpd.conf
lsblk
grep -v '^#' /etc/fstab

👉 マウントに失敗して起動が止まると、FTP の設定がどれだけ正しくても関係ない。nofail を付けておけば、マウントできなくても起動は進む。ただしその場合は FTP のルートディレクトリが空のままサービスが上がるので、「起動したから大丈夫」ではなく、事後確認でマウントの中身を見ることとセットにしておく。

---

実施後の確認

再起動、あるいは stop/start が終わったあとに見るべき項目をまとめる。

イベントがクリアされたか

describe-instance-status を再実行する。

aws ec2 describe-instance-status \
    --instance-ids i-1234567890abcdef0 \
    --query "InstanceStatuses[].Events"

完了していれば、イベントは配列から消えているか、残っていても Description が [Completed] から始まる。

👉 インスタンスのステータス説明の更新には最大1時間かかることがある。 すぐに再実行して配列が空でなくても、それだけで「まだ終わっていない」とは判断できない。完了したメンテナンスイベントは、EC2 コンソールのダッシュボードには最大1週間表示され続ける。イベントがコンソールに見えていること自体は「未完了」の証拠にならない。

パブリック IPv4 が変わっていないか

aws ec2 describe-instances \
    --instance-ids i-1234567890abcdef0 \
    --query "Reservations[].Instances[].PublicIpAddress"

「5種類のイベントで、何が作り直され何が残るか」の表で見たとおり、instance-stop / instance-retirement では自動割当パブリック IPv4 が変わる。ここで取得した値が、pasv_address や DNS に設定している値と一致しているかを突き合わせる。

マウントが戻っているか

lsblk
df -h /srv/ftp
mount | grep /srv/ftp

「実施前チェックリスト」で nofail を付けた場合、起動自体は成功していても FTP のデータ領域が空のままになっている可能性がある。起動の成否とマウントの成否は別の確認である。

FTP はログインと ls まで確認する

ftp ftp.example.com

接続してログインが通ったら、そのまま ls を実行してディレクトリ一覧が返ってくるかを見る。

👉 「サービスが起動している」と「FTP が使える」は別である。 制御コネクションはログインまでで確立するが、データコネクションは ls を叩いて初めて張られる。既存記事の罠②・③は、サービスが上がっていて制御コネクションも生きているのに、ls の時点で固まるという形で出る。したがって systemctl status vsftpd がアクティブでも、それは確認にならない。ログインの成功は PASV の成功を何も保証しない。

出典: Manage Amazon EC2 instances scheduled for maintenance

---

症状から疑う場所を引く

出た症状から、確認すべき章に戻れるようにしておく。

症状	疑う場所
ログインできるが ls が固まる	パブリック IPv4 が変わった（instance-stop / instance-retirement）→「FTP に翻訳する」
自分で再起動したのにイベントが消えない	instance-reboot だった、または reboot migration が無効・非対応 →「待つか、自分で先にやるか」
再スケジュールのメニューが選べない	NotBeforeDeadline がない、または開始5分前を切っている →「再スケジュールできる条件」
停止・起動のあとにデータが消えている	instance store 上に置いていた →「5種類のイベントで、何が作り直され何が残るか」
サービスが上がってこない	既存記事の罠①（bind）、またはマウント失敗 →「実施前チェックリスト」
イベントが消えたか判断できない	ステータス説明の更新に最大1時間かかる →「実施後の確認」

---

まとめ

• AWS からの再起動は5種類あり、ホストが変わることと IP が変わることは別の軸である
• system-reboot はホストを移るのに IP アドレス・DNS 名・instance store のデータを維持する。FTP で本当に危ないのはこちらではない
• 危ないのは instance-stop / instance-retirement である。自動割当パブリック IPv4 と instance store のデータを持っていく
• instance-reboot に先回りしても無駄である。system-reboot の先回りは条件付きで効く
• 判断の根拠は通知メールの文面ではなく、event code に置く

OS レベルの罠——bind できない、PASV が返す IP、パッシブポート範囲、セッション切断——の具体的な確認手順は、既存記事 FTPサーバーの再起動で踏む4つの罠 に譲る。AWS 側が何をしてくるかが分かれば、次はその記事で OS 側の備えを固める番である。