ドキュメントに引用は見つかりませんが、私の経験では、EC2のネットワーキングインフラストラクチャ全般（RDSと、すべてではないにしても、顧客ごとにプロビジョニングされた仮想マシンで実行される他のAWSサービスが含まれる可能性があります）が示唆されていますAWSは、確かに「EC2インスタンス」に厳密に限定されているようには見えません）ステートフルパケットインスペクションを実装し、TCP接続が数分間の絶対アイドル状態の後に有効であることを「忘れ」ます...あなたが説明する動作を引き起こします。
接続の両端にあるマシンは、接続がまだ存在していると確信している場合がありますが、SPI環境のTCPセッションは検出されず、作成され、しか実行できないため、ネットワークはトラフィックがそれらの間を通過することを許可しません。ネットワークが最初に接続を確認したときに作成されます（ SYN、 SYN / ACK、ACK ）。私は当初、EC2（RDSではない）のMySQLサーバーでこの問題に遭遇しましたが、根本的な原因が同じでない場合は非常に驚きます。
これを回避するには、2つのアプローチが考えられます。
PHPマシンがLinuxの場合、レイヤー4で接続を維持するようにカーネルを構成します。これらのキープアライブがTimeの値を変更しないという意味で、この変更は表示されません。 SHOW PROCESSLISTの列 Sleepでの接続の場合 レイヤー7で接続がアイドル状態になっている時間をリセットしないためです...ただし、MySQL接続を管理するライブラリがソケットオプションを正しく設定してそれを利用している場合は、AWSインフラストラクチャからのタイムアウトを回避する必要があります。
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive .html これをライブで設定する方法と、再起動後も永続的にする方法について説明します。
それができない場合、他のオプションは、MySQLにネットワークタイムアウトよりも早く接続を閉じるように強制することです。 これにより、PHPマシンは、閉じたソケットで通信しようとしていることをすぐに認識します。タイムアウトを長くするのではなく短くするのは直感に反するように聞こえるかもしれませんが、タイムアウトを短くすると、セッションが長時間アイドル状態になっている場合にpingテストがすぐに失敗し、正常性を前提として問題が（本質的に）「解決」されます。 PHPクライアントライブラリにあります。アプリケーションがビジーになると、接続がタイムアウトに達するほど長くアイドル状態になることはおそらくほとんどありません。
MySQLサーバーには2つの異なるアイドルタイムアウト設定があります： wait_timeout
（非対話型セッション、つまりPHPなどのコードからの接続の場合）および interactive_timeout
（クエリブラウザとコマンドラインクライアントから）ただし、クライアントライブラリは、確立している接続の種類をサーバーに通知する必要があるため、サーバーは違いしか認識しません。クライアントライブラリが正しい設定を使用していると仮定して、wait_timeout あなたが探しているものです。 LinuxカーネルでTCPキープアライブ設定を変更しても問題が解決しない場合は、これを900未満の値に設定すると問題が解決するはずです。ただし、変更を行った後は、将来の接続のみが影響を受けることに注意してください。変更が行われたときにすでに確立されている接続は、現在の値（デフォルトは8時間（28800秒））で引き続き実行されます。これらは、インスタンスのRDSパラメーターグループで構成できます。
こちらのAWSドキュメントに同様の動作のヒントがあります 、上記で想定したように、LinuxではなくWindowsでPHPサーバーを実行している場合は、TCPキープアライブを変更するために調整する必要のあるWindowsレジストリ設定とともに...この記事は特にRedshiftと外部接続に関するものですがEC2は、上記のように根本的な問題を検証しているようです。