メンテナンスやらなんやらでてんやわんや

こいつを見てから*1対応に追われてました。

AWSで緊急メンテナンス

AWS to Reboot a Number of EC2 Instances

「Amazon EC2」が大規模なメンテナンス、一部ユーザーは懸念を表明 – ZDNet Japan

影響をうけるのはEC2、RDS、Elasticache、RedShift
情報が出たのが週の真ん中で、その週末に強制リブート。
事前のリブートや立て直しでの回避不可。

なんてことだ…。

これ、相当影響範囲広いんじゃないですかね？
週末の深夜にダウンしたりちょっと重くなったりしたサービスがあったら、それはAWSを利用してるかもしれません。
いや、まあある程度突然負荷が増える可能性のある最近のWEBサービスとかソーシャルゲームとかは
高確率で使ってるサービスではありますけれど。

それに加えてbashの脆弱性が露見したりとか、
世の中のインフラエンジニアを殺す気ですかね？

回避策

Tokyo Resionに限った話で言えば、
Availability Zone 1aと1cは日程が1日分けられているようなので、
ELBにぶら下げてるWEBサーバなら、
別のAvailability Zoneにサーバを立てて、
新たにELBにぶら下げることで影響を最小限にできるかなと思います。*2

ただし、1台だけ立てているサーバは影響が不可避ですね。
最悪の場合ダウンタイムを許容するしかないでしょう。

RDSの場合は、Multi-AZにしてればフェイルオーバーするだけで済むみたいです。
ただ、2日でフェイルオーバー→フェイルバックとなることもままあるので、そのことを念頭に置いて。
Maintenance Windowである程度タイミングは操作できるようです。

Elasticacheはリブート不可避っぽいので、一つしか繋いでないのならそもそも乗せてるサービスをメンテナンスにしてしまうほうが無難かも。
複数繋いでて、メンテナンス対象じゃないものがあるなら、一時的にメンテナンス対象のインスタンスを外すぐらいですかね。
あんまりいい方法はわからんです…。

RedShiftは使ってないんでわかりません(・ω<)

bashの脆弱性

影響範囲はどこまで？：bashにコードインジェクションの脆弱性「Shellshock」、管理者に大きなショック – ＠IT

簡単に言うと、
環境変数に、「関数につづいて任意のコマンドを入力する」と、コマンドが勝手に実行されてしまう
ということ。
任意のコマンドが実行できるのでもうやりたい放題ですね。

bash使ってないから…という方でも、CGIやスクリプトでbash使ってコマンド叩いてる可能性もあるので、
危険性は非常に高いですね

回避策

JPCERTからも正式に注意喚起が出てますね。対処法も。
GNU bash の脆弱性に関する注意喚起

まあ、bashを使わないか、対処されたバージョンにアップデートするかでしょうけど、
非常に使用率が高いので、ちゃんとアップデートするのが無難でしょう。

ここ数日書いてなかったのは忙しかったからであって、
決して書くのが面倒だったからではありません。
ほんとだよ！