By the time Slack had recovered, engineers at AWS had found the trigger for our problems: Part of our AWS networking infrastructure had indeed become saturated and was dropping packets.

Slackが復旧するころには、AWSのエンジニアたちが障害を引き起こした事象を発見していた。AWSのネットワーク基盤の一部が飽和しており、パケットをドロップしていたのだ。

　SlackはAWSの上で構築されています。しかもAWS上で複数のVPC（Virtual Private Clouds）を用いており、それぞれのVPCはAWSのマネージドサービスであるAWS Transit Gatewayを通じて相互に接続されていました。

　Slackを構成するVPCを相互に接続するAWS Transit Gatewayが飽和していたというのです。

AWSのエンジニアがマニュアル操作で対応

　AWSのエンジニアはこれに関するアラートを受け取り、手動操作でキャパシティーを増やして対応しました。

Our own serving systems scale quickly to meet these kinds of peaks in demand (and have always done so successfully after the holidays in previous years). However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually. By 10:40am PST that change had rolled out across all Availability Zones and our network returned to normal, as did our error rates and latency.

私たち自身のサービスはピークに合わせて迅速にスケールしていた（これまでも連休後の対応はいつもうまくいっていた）。しかし、私たちが利用していたAWS Transit Gatewayが十分にスケールしてくれなかったのだ。

この事象が起きたときに、AWSのエンジニアはこのパケットドロップに関するアラートを内部モニタリングシステムから受け取とり、手動でキャパシティーを増やした。太平洋標準時10時40分までにこの変更が全てのアベイラビリティゾーンに適用され、ネットワークは通常の状態に戻り、エラーレートとレイテンシも戻った。

AWS Transit Gatewayのアルゴリズムを見直す

　AWSは今回のインシデントを受けて、AWS Transit Gatewayのアルゴリズムを見直すとのこと。

AWS assures us that they are reviewing the TGW scaling algorithms for large packet-per-second increases as part of their post-incident process. We’ve also set ourselves a reminder (a Slack reminder, of course) to request a preemptive upscaling of our TGWs at the end of the next holiday season.

AWSは、秒あたりのパケットが急激に増加する際のAWS Transit Gatewayのスケーリングアルゴリズムの見直しを、インシデント発生後のプロセスの一環として行っていると確約した。また、私たちが次のホリデーシーズンの終わりにはAWS Transit Gatewayのアップスケーリングをあらかじめリクエストするようにリマインダー（もちろんSlackのリマインダー）を設定した。

　Slackの今回の障害は、Slack自身ではコントロールできないAWSのマネージドサービスにおける問題がきっかけでした。これは（規模は違えども）一般のAWSユーザーにおいても何らかの形で起こりうることでしょう。

　そうなればユーザー側にできることはそれほど多くありません。できるだけ迅速に問題を発見し解決を図るため、きめこまかなシステムのモニタリングと問題の切り分けなどが重要になるのではないでしょうか。

クラウド市場でAlibabaがIBMを抜き去り、AWS、Azure、Googleに次いで4位に
米Synergy Research Groupのクラウドインフラ調査によると、クラウドベンダーの2020年第4四半期のシェアは、AWSが首位、Microsoftが2位、Googleが3位となった。Alibabaは徐々にシェアを下げるIBMを抜き、4位の座についた。
Amazonのジェフ・ベゾスCEOが退任して会長に　後任はAWSのジャシーCEO
Amazon.comの創業者、ジェフ・ベゾスCEOが7～9月期に会長職に退く。後任はAWSのアンディ・ジャシーCEO。ベゾス氏は引き続きAmazonのプロジェクトに従事するが、Blue OriginやWashington Post、慈善基金に割く時間を増やす。
AWS、商用サービス化を制限するライセンス変更に対抗し「Elasticsearch」をフォーク　独自のオープンソース版へ
AWSが、オープンソースで開発されている検索エンジン「Elaticsearch」とデータの可視化ツール「Kibana」をフォークし、独自ディストリビューションを作成すると発表した。その背景に何があったのか。
AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
AWSの障害に、各社はどのように対応したのか。ITmedia NEWS編集部では問題に直面した企業やエンジニアに聞き取り調査を行った。生の声から、実情が見えてきた。
AWS障害、どうすれば回避できた？　冗長性はどこまで？　AWSのパートナー企業に聞く
思わぬ大障害に発展し、復旧に時間を要したAWS東京リージョン。その回避方法はあったのか。これからの対応の指針とすべく、AWSの最上位パートナー認定を取得している企業に話を聞いた。