８／２３の１３：００過ぎ頃から、駅メモに接続できなくなる障害が発生していました。（同日１９：００頃解消）
原因はＡｍａｚｏｎのクラウド（Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ）の障害でしたが、詳細がだいたいわかりましたので書いておきます。
駅メモに接続できなくなる障害発生
【不具合報告】
— 駅メモ！公式 (@ekimemo) August 23, 2019
現在、アプリ版駅メモ！を正常にプレイしづらい不具合が発生しております。
ただいま対応を行っておりますので、復旧まで今しばらくお待ち下さい。
ご不便をおかけして申し訳ございません #駅メモ
こちらにつきまして、クラウドサーバの障害による不具合であることを確認いたしました。
— 駅メモ！公式 (@ekimemo) August 23, 2019
なお、本件について現在は状態が安定し、正常にプレイできることを確認しております。
ご迷惑をおかけしてしまい、誠に申し訳ございません #駅メモ https://t.co/uALRqQk1Ik
【不具合報告】
— 駅メモ！公式 (@ekimemo) August 23, 2019
クラウドサーバの障害の影響により、再度駅メモ！に接続できない状態が発生したことを確認しております。
本件への対応のため緊急メンテナンスを実施させていただきます。
突然の実施となってしまい大変申し訳ございませんが、復旧までお待ちください #駅メモ
【現在の障害について】
— 駅メモ！公式 (@ekimemo) August 23, 2019
現在の接続障害につきまして、他社サービスの障害に起因しているため、現時点で復旧見込みのご報告が難しい状況です。現在は可能な範囲で復旧に向けた準備を行っておりますので、ご迷惑をおかけいたしますが、復旧までお待ちくださいますようお願いいたします #駅メモ
クラウドサーバ側からの正式な復旧報告はないものの、段階的ではありますがプレイ可能な状態を確認したため、サービスの再開を優先し緊急メンテナンスを終了いたしました。
— 駅メモ！公式 (@ekimemo) August 23, 2019
今後の対応は正式な復旧報告を確認後、改めてご報告いたします。この度はご迷惑をおかけし、申し訳ございません #駅メモ
また、メンテナンス時間中、すべての駅におけるリンク解除を実施いたしました。大変申し訳ございませんが、メンテナンス実施前のリンク状態に関する個別の補填はできかねますので、ご理解の程よろしくお願いいたします #駅メモ
— 駅メモ！公式 (@ekimemo) August 23, 2019
８／２３の１５：００に、駅メモで新ラッピングが公開されました。
なかなかカジュアルで好評なデザインセンスだったこともあり、ガチャに課金する人多数。しかし、この直後からゲームに接続しづらくなる現象が発生しはじめました。
一時的にレイカさんやセリアさんの接続失敗ロゴが出たり出なかったり、という状況があった後、すぐに「長時間のメンテナンス」に入ってしまいました。
メンテナンスの原因は「他社サービス」の「クラウドの障害」ということでした。ご存知の方も多いと思いますが、これは具体的にはＡｍａｚｏｎのＷｅｂ Ｓｅｒｖｉｃｅ（ＡＷＳ）のことです。
Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（ＡＷＳ）で大規模障害
AWS Service Health Dashboard - Aug 23, 2019 PDT
（「Asia Pacific」というタブを参照）
和訳：
午後8時36分（PDT）から、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2サーバーの一部が過熱のためシャットダウンしました。これにより、EC2インスタンスが損なわれ、アベイラビリティーゾーンの影響を受ける領域のリソースのEBSボリュームパフォーマンスが低下しました。過熱の原因は、制御システムの障害であり、影響を受けたアベイラビリティーゾーンの一部で複数の冗長冷却システムが故障しました。
AP-NORTHEAST-1 リージョンというのは、東京にあるリージョン（データセンタ）の意味です。要するに、ＡＷＳを使用している日本企業の多くはここを拠点にしています。
実は駅メモが落ちる少し前、１３：３６（ＪＳＴ）頃からＡＷＳ東京リージョン（データセンタ）で障害が発生し、機器が高温になり停止する障害が発生していました。
機器が高温になってから停止するため、すべてのサービスが同時多発的に落ちるのではなく、数時間かけて徐々に影響が広がっていくタイプの障害です。
従って、他のサービスはすぐにサービス停止に追い込まれるなどしていた一方で、駅メモは１５：００（ＪＳＴ）過ぎまでサービスを提供できていました。
なお最初に影響を受けたのは、引用箇所にあるＥＢＳ（Ｅｌａｓｔｉｃ Ｂｌｏｃｋ Ｓｔｏｒｅ）、つまり「仮想サーバのディスクのようなもの」だったようです。
ディスクが止まったようなものですので、関連するＥＣ２（Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ：サーバのようなもの）、RDS（リレーショナルデータベースシステム）が軒並み停止に追い込まれています。
結局駅メモも影響を受けたのですが、１９：１９頃にサービス復旧しています。
なお「冷却装置障害」だったため、冷却装置の復旧ですぐにサービスが再開できるわけではなく、関連する機器のクールダウンを待ってから、徐々にサービスインしていくような曖昧な形での再開になっています。
最終報告
日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。
８／２５までに、Ａｍａｚｏｎから正式な調査結果が発表されていました。
これによると、直接原因は「冗長化された」「空調設備・・・の管理システムの障害」という事で、これだけ読んでもよくわかりません。
実はこの後ろにも詳細が書かれていて、それによるとどうも「温度センサーなどから情報をかき集めてデータセンタの空調設備を制御するサーバ」があり、それのことを「管理システム」と呼んでいるようです。（このサーバが冗長化されている）
この温度センサーや空調機と接続するドライバー周りにバグがあり、その影響で空調管理システムが無応答となり、空調設備に冷却命令が飛ばず、温度上昇に繋がったことが今回の現象の顛末のようです。
トラブルを回避するために、駅メモはどうすればよかったのか？
ＡＷＳはクラウド（仮想環境）とはいえ、実際にはユーザの目につかないところに物理環境があり、物理環境がある以上、障害は発生し得ます。
障害によるサービス停止を回避する方策として、Ａｍａｚｏｎでは「マルチＡＺ」や「マルチリージョン」を推奨しているのですが・・・
今回は「マルチＡＺを行っていてもダウンした」という話も出ており（真偽不明）、これで回避できたかはわかりません。
日本には東京リージョンしかありませんが、他のリージョンを使用した冗長化などを行っておく必要があるかもしれません。契約面倒なんだよな・・・
さて。
駅メモに限らず「ＡＷＳを使用している企業やゲームはみんなコケた」状態でしたが、「駅奪取」は正常に動作していました。
恐らくＡＷＳを使っておらず、そのためトラブルに巻き込まれずに済んだのだと思います。
ただ「駅メモ」と「一緒に位置登録」している場合、駅奪取側で「奪取！」ボタンを押すと、しばらく駅メモの応答を待ちダンマリになっていました。
挙動を見ると、どうも「駅メモ」側のチェックイン処理を先に行っているようです。
Ａｍａｚｏｎが見解修正
2019年8月28日(日本時間)更新:
最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。AWS では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。
Ａｍａｚｏｎが、当初見解を修正してきましたので引用しておきます。
結局、ＥＣ２が影響を受けた場合には、ＥＣ２やＲＤＳ以外にも影響が及んだとのこと。また、サービスダウンは、障害が発生したＡＺ以外にも及んでいたとのことです。
このため、当初の「マルチＡＺで環境をこさえていれば、障害を回避できた」という主張は崩壊。対策については「個別に対応」となっています。
