📝

AWS の技術的なお問い合わせに関するガイドラインをあらためてながめてみた

2023/07/22に公開

AWS におけるトラブルシューティングや仕様確認時に AWS サポートへ問い合わせることがあると思います。
問い合わせの際には技術的なお問い合わせに関するガイドラインを確認する方も多いと思います。
当該ガイドラインについて検索すると「新人研修に使用できる」など問い合わせ以外の活用方法もあるようです。
しかしながら、意外と紹介されていない部分もあったので本記事ではあらためてガイドラインの中から注意すべきポイントを紹介したいと思います。

1 ケース＝ 1 質問をおすすめします

例
△
Lambda のトラブルシューティングと、課金体系を１ケースで質問する
◯
Lambda のトラブルシューティングで技術系のお問い合わせ１ケース、Lambda の課金体系について、非技術系のお問い合わせ１ケース、計２サポートケースを起票する

１つのサポートケースには、一時点で、１人のサポートエンジニアが対応しますので、独立性の高い質問は、複数のケースに分けて起票いただくと対応を迅速化できる場合があります。

もちろん相互に関連の強い質問は１ケースにご記載ください。迷った際は、書きやすい形でご記載ください。サポートエンジニアがサポートケースの分割をご提案する場合もあります。

意外とやってしまう問い合わせが 1 つのケースで関連性のない複数の質問をすることです。
例では技術的な質問と料金の質問を 1 つのケースで質問しています。

AWS サポートでは「技術」に関する窓口と「料金」に関する窓口が分かれているため、それぞれの窓口宛てにケースを起票するのが適切です。

AWS 技術サポートを受ける | AWS re:Post
アカウント・請求関連のご質問

その他にも以下のようなケースが考えられます。

EC2 に関する仕様と RDS に関する仕様を 1 つのケースで質問する
→ EC2 のサービスカテゴリーと RDS のサービスカテゴリーでケースを分割する方が適切
EC2 の OS に関する質問とネットワーク疎通に関する質問を 1 つのケースで質問する
→ OS に関する質問とネットワークに関する質問でケースを分割する方が適切
EC2 に関するトラブルが解決した後に同じケースで RDS のトラブルについて質問する
→ EC2 に関するケースをクローズし、RDS に関するトラブルシューティングで別途ケース起票する方が適切

上記のように適切なカテゴリーで起票することで AWS サポート側も焦点を絞ることができるため、ケースを分割することで最終的な問題解決の時間が短縮される可能性があります。

そのため、「1 ケース＝ 1 質問」を基本にケース起票しましょう。

文脈依存性のない記述にご協力ください

例
×
新会計システムが、また動かなくなりました。ステ環では動きます。
◯ ELB (ELB 名***）について質問です。以前の問合せ（ケース ID＝****）の関連です。具体的には日本時間昨日正午から……

お客様がどのような状況に直面されているのか、サポートケースごとに、具体的にサポートエンジニアに伝わるようご記載ください。

お客様組織内の独自の用語等は使わずにご質問ください。

過去のケースを参照する場合は、ケース番号をご記載ください。

AWS サポートは皆さんの組織の中の人間ではありません。
そのため、組織内では当たり前の用語でも AWS サポートには伝わりませんので、一般的な用語を使用しましょう。

ありがちなのは説明の冒頭からリソース名のみで記載するパターンです。

dev_app へデプロイが成功したので prod_app にもデプロイしましたが prod ではデプロイに失敗しました。

組織のプロジェクトメンバーであれば上記で状況が伝わるかもしれませんが、AWS サポートからすれば dev_app と prod_app がリソース名なのかどうかすらわかりません。

上記のように記載するのであれば、冒頭に各用語に関する説明などを記載しましょう。

まず、本件では開発環境の EC2 インスタンスと本番環境の EC2 インスタンスが 1 台ずつ起動しております。

開発環境の EC2 インスタンス: i-xxxxxxx (dev_app)
本番環境の EC2 インスタンス: i-yyyyyyy (prod_app)

各インスタンスについては以降、dev_app、prod_app と呼称いたします。

上記の記載であれば誰が読んでも EC2 インスタンスであることがわかります。
文脈依存性の高い記述をすると認識合わせのためのヒアリングが発生する可能性があり、ヒアリングが発生する分解決までの時間が増大する可能性があります。

状況が 1 回で伝わるようなケース起票を意識しましょう。

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

障害発生は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発生率の低減に努めておりますが、障害の発生を完全に防ぐことは困難です。

このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を行っています。

たとえば EC2 において、お客様が AWS 基盤の異常を検知した場合、不安定なリソースは廃棄していただき、新たに別の EC2 を調達していただく等、クラウドの特性を活かしたアクションが可能です。

AWS では、障害内容の詳細なご説明は行っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活用や、一次復旧を優先する方法をご案内することで、お客様の課題を迅速に解決することを目指します。

詳細な障害原因について問い合わせたことがある方も多いのではないでしょうか。

AWS では一時的な障害や大規模障害を完全に防ぐことはできないと明記されており、「Design For Failure」(故障を前提とした設計)を推奨しています。
また、障害内容の詳細な説明は行っていない旨も明記されています。

AWS では基盤側に問題があったとしてもユーザー側では基盤側の調査や不具合修正はできません。そのため、「EC2 基盤のここに問題があったのでここを直せばよい」という案内をユーザーに行ったとしてもユーザーにとっての回避策にはなり得ません。

ユーザー側で可能なことは障害に備えて高可用性のアーキテクチャを採用することや DR 戦略を考えることであるため、ガイドラインにもベストプラクティスの案内をする旨が記載されています。

どうしても障害原因についての問い合わせが必要な場合には、同ガイドラインに記載されている障害と判断した状況をご共有くださいを確認し、障害と判断した根拠を示しましょう。

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

AWS では各サービスの性能指標についてご案内しておりません（ドキュメントで公開されているものはこの限りではありません）。

「性能」の多くは、お客様の環境やワークロードに依存します。一般的にご案内できる情報を AWS が持ち得ない点をご理解ください。

お客様ご自身の環境で実際に測定していただくことが、適切な指標になりうると考えております。実測したい環境を容易に複製し、破棄できるのがクラウドのメリットです。ご活用ください。

性能についても問い合わせたことがある方が多いのではないでしょうか。

EC2 の場合にはインスタンスタイプが多いため、使用するアプリケーションにどのインスタンスタイプが適しているのかは気になるところではあります。
しかしながら、インスタンスタイプとの相性はアプリケーション実装などによるため AWS サポートから一概に「このインスタンスタイプが適している」などの性能指標は案内が難しい内容です。

EC2 に関してはインスタンスタイプごとに適したワークロードの例が記載されている資料もありますので、まずは公式資料を確認しましょう。

インスタンスタイプ - Amazon EC2 | AWS
PowerPoint プレゼンテーション

ドキュメントや公式資料に記載のない性能指標については検証環境で十分な検証を実施しましょう。
ガイドラインにも記載されている通り、環境構築と破棄が容易にできるのがクラウドのメリットです。
クラウドのメリットを生かして検証環境での性能テストなどを実施し、本番環境への適用などを検討しましょう。

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

AWS ではメンテナンスの実績や頻度についてご案内しておりません。

AWS が実施するメンテナンスは、お客様に AWS を安心してご利用いただくためのものです。お客様のご利用への影響を小さくするため、AWS は改善に努めておりますが、残念ながら、お客様のご利用に影響が出るメンテナンスの発生をゼロに抑えることはできません。

またメンテナンスにつきましては、セキュリティへの対応等、やむをえず緊急で行われる場合もあり、過去の頻度から将来的なメンテナンスの頻度を予測することは適切ではありません。予めご了承ください。

AWS ではサービスによってはメンテナンスが発生する場合があります。
メンテナンスに関する通知については Health Dashboard に掲載される場合もあるので、Health Dashboard の確認は必須です。

ただし、メンテナンスの実績や頻度、将来的な頻度予測などは案内していません。
メンテナンスが発生した場合にはユーザーへの影響が発生する可能性もありますが、回避策は上述の「Design For Failure」になるかと思います。

いつ障害が発生するかわからないという考えと同様に、いつメンテナンスが発生してもよいという考え方でシステムやアプリケーションを構築することが必要だと思います。

Well-Architected Framework をベースに、AWS の特性を踏まえたアーキテクチャを設計しましょう。

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

ご質問の背景を共有いただくことで、適切な情報をご案内できる場合があります。
例
×
Multi AZ 構成の RDS が切り替わる仕組みや利用している技術を教えてください。
◯
Multi AZ 構成のRDSがフェイルオーバーする条件を教えてください。現在、監視システムの設計をおこなっています。

例文の前段のようなご質問への回答は通常いたしかねますが、後段のようにご質問の具体的な背景を共有いただけると、お役に立てる情報を回答できる場合があります。

AWS では詳細な内部仕様については原則非公開となっています。
「原則」なので、ドキュメントや公式資料で公開されている場合は例外となります。

内部の仕組みを安易に公開することは脆弱性につながります。
システムやアプリケーションでも内部の仕組みをすべて公開するケースは少ないと思います。(OSS などでは GitHub などでソースコードの公開はあるかと思います)

システムやアプリケーションの内部実装をすべて公開すれば悪意のある攻撃者が実装の穴を突いて攻撃してくる可能性があります。
AWS でも同様に、セキュリティを確保するためには公開できない情報もあることを理解したうえで質問しましょう。

ガイドラインには直接的な回答ができない場合でも背景を添えることで関連情報を回答できる可能性がある旨も記載されているので、「なぜ」その質問をするのかを明確にしましょう。

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

お客様が AWS 基盤の不具合により影響を受けた場合、サポートエンジニアは、お客様に回避策等のご案内を差し上げるとともに、サービス開発チームに不具合改修のエスカレーションを行う場合があります。

この場合、不具合が解消する期日についてはお約束することができません。また、不具合が解消された際であっても、AWS サポートからお客様には個別にご連絡を差し上げることができません。

このようなご要望がある場合には、お客様から新規にケースを起票いただき、不具合が解消したか否かについてお問い合わせをいただくようご案内しております。お客様にはお手数をおかけしておりますが、ご協力をお願いいたします。

エンタープライズサポートプランにご加入のお客様は、テクニカルアカウントマネージャー（TAM）が対応させていただく場合がありますので、TAM にご相談ください。

AWS では上述の通り障害やメンテナンスが発生します。
AWS 基盤側の不具合であった場合には不具合改修を実施するものの、不具合解消時期や個別での解消報告は行われません。

そのため、AWS 側の不具合についてのフィードバックなどでケース起票する際には不具合解消時期や報告の案内ができないことを理解したうえで起票しましょう。

不具合が解消したかどうかについては都度ケース起票すれば案内できる旨が記載されているので、改修状況が気になる場合には定期的にケース起票しましょう。

まとめ

今回は AWS の技術的なお問い合わせに関するガイドラインをあらためてながめてみて、問い合わせの際に注意すべきポイントを紹介しました。

あらためてポイントを整理します。

1 ケース＝ 1 質問で起票する
文脈依存性のない記述を心がける
障害内容の詳細な説明は行っていない
性能指標については案内していない
メンテナンスの実績や頻度については案内していない
AWS 内部の仕組みについては案内していない
AWS 基盤の不具合改修の時期は案内していないが、改修状況は都度ケース起票で確認可能

AWS サポートを最大限活用して迅速な問題解決やスピーディな開発を目指しましょう。