AWSサポートに問い合わせる前に確認するべきこと

AWSを利用していると、AWSに関する障害や予期せぬ動作などで、どうしてもサポートに問い合わせて解決したいことがしばしばあります。
今回はそんな中で、どのようにAWSサポートに問い合わせるべきかを記述します。

この記事の対象者

• AWSサポートへどのような質問をすればよいかお悩み中の方。
• AWSサポートへ問い合わせる内容/受け付けない内容は何か知りたい方。

AWS サポート への問い合わせ方

実は問い合わせ方についてはAWS側で明記しています。
以下のリンク「技術的なお問い合わせに関するガイドライン」 にAWSへの問い合わせに関する注意事項などが記載されております。
サポートへ問い合わせる前に一度読んでから実施した方が、やり取り少なく円滑に解決できる確率が高くなるため、一度読んでいただければと思います。

質問文の書き方

「技術的なお問い合わせに関するガイドライン」から、必要な文章としては以下の内容が含まれていれば概ね問い合わせ内容としては宜しいかと思われます。
以下の内容が網羅されていれば、完璧に近い問い合わせができる。。かも？

1. 発生時刻、アカウント情報 ... 「状況を正確に共有する」を参考に。

   • アカウント情報(アカウントID,リージョン)は記述する
   • 発生時刻の記述(タイムゾーンの記述やアカウント情報など忘れずに。)

2. 対象サービス(EC2やRDSなどのインスタンスIDなどの情報。)

   • 障害発生したインスタンスIDなどのリソースID情報を連携する。

3. 発生事象について 「経緯を共有する」を参考に。

   • エラー発生までのを時系列を記述。
   • エラー文言は正確に記述する。キャプチャなどがあれば添付する。

4. 原因調査について ... AWSに問い合わせる前に最低限自分たちで調査してみること。

   • エラーログがあればその内容を記述する。
   • 原因調査に使用したURLがあったら記述する。
   • キャプチャやログを圧縮して、AWSサポートに添付して送信することができる。
   • 最低限、エラー発生時に必要なログは調査して添付する。
     • 例えばOSの場合、/var/log/messagesの内容や該当するサービスのログは最低限添付するように。
     • 「追加で取得するログがありましたらご教授のほどお願いいたします」と記載した方が後々の調査が進む。

5. 復旧内容について

   • 復旧の際に検索した記事や、手順などがあれば連携する。
   • 復旧で実施した手順やログを連携する。
   • 復旧の結果についても同様に記述する。
     • 成功/失敗したのか。
   • ファイル数が多い場合、圧縮して添付する。

6. 問い合わせの目的 ... 問い合わせの目的(AWSサポートに求めるもの)を明確にする。

   • AWSサポートへ何を求めているのかゴールを記述する。
     • 例えば、「原因を突き止めたい」と「原因を突き止め、復旧の手順を連携して欲しい」は明確に異なるため、問い合わせで求めることは正確に.

困った質問内容

こちらはアンチパターンの質問になります。

「ご案内が難しいご質問」を参考にすればどのような質問がNGかがわかるため、できる/できない内容については、事前に把握しておいた方がAWSと円滑に応答ができるでしょう。

AWS アカウント ID を超えたお問い合わせ

問い合わせ対象外のアカウントIDについては基本的には問い合わせは実施しないように。
どうしても他アカウントの値を含めるのなら、クロスアカウントでの利用や、Organizationsを利用している等の背景は含めないと伝わらないかと。

障害の原因についてのお問い合わせ

「EC2インスタンス上が停止した。何故だ!!」的な質問にはお答えできない。。
インスタンスは壊れるものと想定して、早急に復旧するシナリオを事前に作成しておく。
また、復旧を試みたが正常起動しなかった場合は、復旧で実行した手順や、調査内容(ログ、キャプチャ、参考にしたURL)を添えて問い合わせた方が良い。
また、OSレイヤー以上のアプリの問い合わせになるとAWS側も対応できない可能性もあるため、問い合わせはAWSに関係する内容で問い合わせた方がよい。

性能指標についてのお問い合わせ

「思ったよりパフォーマンスが出ないんだけど」についてもお答えできません。。あくまで事前に検証や本番を想定した負荷試験などでパフォーマンスを測定して、アーキテクチャを顧客自身が検討いただく必要があるかと。

メンテナンスの過去の実績や頻度についてのお問い合わせ

→ 「今度DBバージョンをあげるんだけど過去の実績ない？」などの質問に関しては受け付けていません。
あくまでも、検証用DBを作成してAWS提供の移行ツールなどで検証してみて、その上で移行ツールを検討すればよいかと。。

AWS 内部の仕組みについてのお問い合わせ

これも言わずもがなかと。。責任境界外のアーキテクチャについて知ってどうなるのかと。。。

コンプライアンス関連のお問い合わせ

そもそも担当部署が異なる。。
https://pages.awscloud.com/compliance-contact-us.html?Languages=Japanese

AWS 基盤の不具合改修のご案内

個別対応はしてないため、不具合の解消有無については別途ケースを発行する。

まとめ

「技術的なお問い合わせに関するガイドライン」を事前に把握していれば、やり取りを少なく、円滑に解決までのやり取りを実施することができるため、ぜひ一度目を通していただければと思います。