タイトル通り、です。
※パッチを当てたのか別のことをしたのかは、自分ではまだ情報を捕捉できていません。そのため、今後情報を追記する可能性があります。
結果、「元の性能に戻ったみたい」です。
※以下の記事の続報です。
2018/01/15追記（01/16一部修正）：
AWSとしては「対応を完了した」という認識のようですが、詳細な情報は出していません。
- Processor Speculative Execution Research Disclosure ※2018/01/13 13:00 PST 更新版 および 2018/01/15 20:30 PST 更新版で確認
RDS/AuroraではなくEC2向けのAmazon Linuxについては、週末（1/13～14あたり）に更新版のカーネルアップデートが配布されたようです。
なお、私の初報の記事（前述）が、Publickey さんの以下の記事で（ちょっとだけ）取り上げられています（ありがとうございます）。
Googleの対応についても先に記事にされていますが、対比して読むと面白いです。
脆弱性の発見者にGoogleのチームが含まれているので当然といえば当然ですが、時間をかけて慎重に進めることができたGoogleがパフォーマンスの問題を（ほぼ）出さずに対応を終えた一方で、AWSはおそらく時間も情報も足りていなかったのでしょう、結果として初回の対応では性能低下を避けられませんでした（本当のところはどうなのか、また初回の性能低下は意図的なのかミスなど想定外の事態だったのかは、発表がない以前に「性能低下していない」ことにしてしまっているのでわかりませんが）。
※Googleの対応についての記事を最初に読んだときに見落としていましたが、Googleは（2017/06の対応で）「Web全体の顧客保護を行うために業界での協力を行」ったと書いてありました。加えて、AWS自身もPVインスタンスのユーザ向けにはかなり前にメンテナンス予告をしていたことを考えると、単純に「時間も情報も足りていなかった」と見るのは正しくなさそうです。「HVMインスタンス向け（もしかするとPVインスタンス向けも）の対応について判断を誤った」（もしくは作業ミスをした）と考えるほうが自然だと思います。
mysqlslapの内容（同じです）
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u 【ユーザ名】 -h 【クラスタエンドポイント】 -p
結果
いずれも暗号化あり、です。
| 実施時期 | db.r4.large・バイナリログなし | db.r4.large・バイナリログあり | db.r4.xlarge・バイナリログなし | db.r4.xlarge・バイナリログあり | db.r4.2xlarge・バイナリログなし | db.r4.2xlarge・バイナリログあり |
|---|---|---|---|---|---|---|
| 2017/10/末 | 48.860 | 57.737 | 33.133 | 37.857 | - | - |
| 2018/01/上 | 74.779 | 91.679 | 45.433 | 54.413 | 34.180 | 39.621 |
| 2018/01/13 （今回） | 50.990 | 61.550 | 32.440 | 38.089 | 24.209 | 26.682 |
※単位は秒。結果は3回実行した平均です。
ほぼ元に戻った模様なので、性能比は省略します（2017/10比で誤差の範囲だと思います）。
この1週間、振り回された人が多そう…（もしかして、振り回したのはAWSではなくて私？）。
因みに、この記事とは関係ありませんが、db.r3.xlargeで運用していて本日（2018/01/13）朝にdb.r4.xlargeに移行したインスタンス（参照負荷が0で冗長化のためだけに用意されているリードレプリカ）のCPU負荷の推移は、以下のようになっています（右端のほうの山はVer.1.14からVer.1.16へのバージョンアップとR4への移行）。
AWSの再パッチらしきタイミングで元の負荷に近いラインに戻るとともに、バージョンアップ＆R4化でも（さらに）CPU負荷が下がっていますね。