amplify pushを1回実行しただけで、別の人がマージ済みだった「Lambdaの固定IP設定」を消しました。SalesforceのAPIが弾かれ、Slackにエラー通知が大量に流れ、復旧に数時間かかりました。
なぜ固定IPが必要だったのか、なぜ消えたのか、どう直したのか。事故の一部始終を正直に書きます。
対象読者AWS Amplifyをチームで使っている人、Lambdaから外部API（Salesforceなど）を叩いていて出口IPを固定している人に向けて書きます。
- なぜLambdaに固定IPが必要だったか（Salesforce凍結問題）
- 事故発生：amplify pushで固定IPが消えた
- なぜ消えたのか ― amplify pushの本質
- 復旧手順と、数時間かかった理由
- 再発防止のために変えたこと
- まとめ
なぜLambdaに固定IPが必要だったか（Salesforce凍結問題）
そもそもなぜ固定IPが必要だったのか。ここを理解しないと、この事故の重さが伝わりません。
このアプリはモバイルからSalesforceにログインして連携する仕組みでした。ところがモバイルからアクセスするたびに送信元IPが変わる。Wi-Fi、モバイル回線、場所が変われば当然IPは変動します。
Salesforce側にはセキュリティ機能があり、見慣れないIPからのアクセスが続くと不正と判断してアカウントを凍結します。IPが毎回変わる＝毎回「知らないIP」とみなされ、凍結されるという状態でした。
これを解決するため、Lambdaを経由させて出口IPを固定しました。モバイルからのアクセスを一度Lambdaで受け、そこからSalesforceへ。LambdaをVPCに配置しNAT Gateway経由で通信させることで、出口IPが常に同じになります。
? POINT
外部サービスがIP制限（許可リスト）でアクセスを絞っている場合、クラウドからの通信は出口IPを固定する必要があります。Lambdaの場合はVPCに入れてNAT Gateway経由にするのが定番です。この固定IPをSalesforce側の許可リストに登録していました。事故発生：amplify pushで固定IPが消えた
事故は、別のPRのレビュー中に起きました。
TROUBLE
PRレビューでブランチを切り替えてamplify pushしたら、固定IP設定が消えた
何が起きたか
あるPRの動作確認のため、そのブランチに切り替えてamplify pushを実行した。すると、別のPRですでにマージ済みだった「Lambda VPC + 固定IP設定」が上書きされて消えた。出口IPが変わり、Salesforceから見ると「知らないIP」になった。結果、API連携が弾かれ、Slackにエラー通知が大量に流れ始めた。
なぜ起きたか
レビュー対象のブランチは、固定IP設定がマージされる前に切られていた。つまりそのブランチのローカル設定には固定IPの定義が存在しなかった。amplify pushはローカルの設定でAWSを上書きするため、「固定IPがない状態」がそのままAWSに反映され、本番の固定IPが消えた。
⚠️ 一番怖いポイント
自分が編集したのは全く別のコードでした。固定IP設定には一切触れていない。それでも、ブランチが古いというだけで、触っていない設定まで巻き込んで消えました。amplify pushは「差分だけ」ではなく「ローカル全体の状態」をAWSに反映するためです。
なぜ消えたのか ― amplify pushの本質
この事故の根本原因は、amplify pushの挙動を正しく理解していなかったことです。
amplify pushは「自分が変更した差分だけを送る」ものだと思っていました。実際は違います。ローカルのamplify設定（backendの定義）全体を、現在の環境のAWSに反映するコマンドです。
だから「固定IP設定を含まない古いブランチ」でamplify pushすると、AWSは「固定IPは不要になったんだな」と解釈して削除します。悪意も操作ミスもなく、コマンドの仕様通りに動いた結果でした。
復旧手順と、数時間かかった理由
復旧自体の手順はシンプルでした。固定IP設定を含む最新ブランチに戻して、再度pushするだけです。
ただ、原因の特定に数時間かかりました。理由はこうです。
? 教訓
手順自体は数分でも、「何が起きているか分からない時間」が一番長い。原因が自分のpushにあると早く疑えていれば、復旧はずっと早かったはずです。再発防止のために変えたこと
① PRレビューの動作確認は個人環境でやる
チーム共有の環境でamplify pushしないのが大前提。動作確認は個人の検証環境に切り替えてから行うようにしました。
② pushする前にブランチの新しさを確認する
古いブランチでpushすると、その後マージされた設定が巻き戻る。レビュー対象ブランチがmainの最新を取り込んでいるか確認してからpushするようにしました。
③ 重要なインフラ設定は何が含まれているか共有する
固定IPのような「消えると全停止する設定」がどのブランチ・どの構成に含まれているかを、チームで把握しておく。今回は自分がそれを知らなかったことも原因の一つでした。
⚠️ amplify pushの鉄則
amplify pushは「ローカルの状態でAWSを上書きする」コマンド。実行前に必ず「今どの環境にいるか」「このブランチは最新か」の2つを確認する。この2つだけで、今回のような事故はほぼ防げます。
- モバイルはアクセスのたびにIPが変わり、Salesforceに凍結される。だからLambda経由で出口IPを固定していた
- 固定IP設定を含まない古いブランチでamplify pushしたら、本番の固定IPが消えた
- amplify pushは差分ではなく「ローカルの状態全体」でAWSを上書きする
- 復旧手順は数分。でも原因特定に数時間かかった。早く自分のpushを疑うべきだった
- 再発防止：個人環境でpush・ブランチを最新化・重要インフラ設定をチームで共有
触ってもいない設定を消すことがある。それがamplify pushの怖さです。でも「どの環境か」「このブランチは最新か」の2つを確認するだけで、この事故は防げます。同じ思いをする人が減れば嬉しいです。
コメント