AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。

なお、サポート全般についての一般的な情報は、AWS サポートをご参照ください。
サポートレベル毎の技術サポートへのアクセスについては、AWS サポートのプラン比較をご参照ください。

全般的な留意事項

基本情報の入力について

  • サービス/カテゴリー
    お問い合わせ内容に最も近い項目をご選択いただくことで、適切な回答が早期に得られる可能性が高まります。
  • お問い合わせ言語
    日本語を選択します。英語での技術支援をご希望の場合には English を選択します。
  • 連絡方法
    多くの場合、Web を推奨します。連絡方法の詳細については、連絡方法(Web、電話、Chat)の選択についてをご参照ください。
     

緊急度の設定について

  • 適切な緊急度の設定は問題の円滑な解決にとって重要です。
  • お客様ビジネスへの影響度に応じて、サポートケースの緊急度を選択します。詳細については、緊急度レベルと応答時間の別表をご参照ください。
  • 件名や本文に「緊急」等と記載されても、緊急度は上がりません。
  • 状況確認の結果によっては、サポートエンジニアが緊急度を下げるご協力をお願いする場合があります。
  • サポートケースを起票した後は、緊急度を変更することはできません。起票後に緊急度を変更したい場合には、サポート対応中に緊急度を上げたい場合をご参照ください。

連絡方法(Web、電話、Chat)の選択について

  • ビジネスサポート以上のお客様には電話や Chat による連絡方法も提供されていますが、詳細な情報共有は Web が最も確実で適しています。
  • 電話や Chat でご連絡いただいた際に、調査を必要とし、その場で回答できない場合もあります。その場合、調査後に Web での回答を提案させていただきます。お客様を長時間拘束することなく、回答を提供させていただきますので、ご協力をお願いいたします。
  • 以下のような場合は、電話や Chat をご活用ください。
    -複雑な状況において、AWS との問題認識に差異が生じていないか確認をしたい場合
    -Web で書き切れない情報を補足したい場合
    -どのような情報を提供してよいか分からない場合、等
    なお、サポートエンジニアが電話での会話をご提案することもあります。
     

電話と Chat 利用時の留意点について

  • ビジネスサポート以上のお客様が対象となります。
  • 電話はコールバック方式です。サポートセンターの Web 画面で電話番号をご入力ください。その際、Web 画面上に留意事項が掲載されていますので、ご参照ください。
  • 窓口が混み合っている場合、電話や Chat がすぐに繋がらない場合があります。予めご了承ください。
  • サポートケースの担当エンジニアがアサインされた後に電話や Chat をいただいても、その担当エンジニアが対応するとは限りません。調査報告については Web でのご連絡をお待ちいただいた方が結果的には早道です。
  • 電話や Chat は、会話中に問題の解決をお約束するものではありません。また、問題解決までの時間を早めるものでもありません。問題解決までに期限がある場合は、ケース起票時に適切な緊急度を指定いただき、サポートケース上で緊急度の背景や期限について補足いただくことがベストプラクティスです。

解決したい課題を明確にする

解決したい課題を明確にご記載ください

 
× いま、ELB は、メンテナンス中ですか?

https://myweb***.com/index.html ELB (ELB名***)に、外部からアクセスできなくなりました。早期に復旧させたいです。対応策を教えてください。
  • 慌てていると、説明を省略して前段のような質問になってしまうかもしれません。
  • お客様の課題がクリアに伝われば、結果的に解決を早めます。
 


障害と判断した状況をご共有ください

 
× 東京リージョンの EC2(i-***)が、応答しません。
東京リージョンの EC2(i-***)が、オンプレからの ping に反応しません。
  • 障害と判断した理由にあたる情報を具体的にご提供ください。
  • 例文のように「アクセス元」の情報もご提供ください(経路障害の可能性もお調べできます)。

 


最終的に実現したいことと現在の状況を詳しくご共有ください

 
× 「Error: Invalid parameters なんとか」って、どういう意味ですか?
× 「Error: Invalid parameters. Exceeding capacity limit」は、どういう時に出ますか?
*** を実現するために、CLIで「xcmd ??? -o –k –v:33」と投入したら、「Error: Invalid parameters. Exceeding capacity limit」とメッセージが出て、失敗しました。どうしたら良いでしょうか。コマンド投入時刻は日本時間の本日 15:52、Request ID は *** です。
  • ご質問内容が省略されている場合、内容の確認にお時間を必要としますので、省略せずにご記載をお願いいたします。
  • コマンドの間違い、コマンド投入者の権限不足、AWS 基盤の一時的障害など、さまざまな可能性をお調べします。
  • 「最終的に実現したいこと」に近づくための別の方法をご案内することがあります。

状況を正確に共有する

対象リソースとリージョンを明記してください

 
× Web サーバについて質問です。
東京リージョンの EC2(i-***)について質問です。
  • リソースの指定は、インスタンス名ではなく、インスタンスIDでお願いいたします。

 


事象の発生時刻(タイムゾーン付き)と継続状況についてお知らせください

 

発生時刻は 10 月 27 日の 15:52 です。
発生時刻は 10 月 27 日の 15:52(日本時間)です。
発生時刻は 10 月 27 日の 15:52(日本時間)です。現在も続いています。
発生時刻は 10 月 27 日の 15:52(日本時間)です。現在は収束しています。
  • サポートエンジニアの切り分けがしやすくなり、迅速な回答につながります。
  • なお、あまり古い事象は詳細調査ができない場合がありますのでご留意ください。

 

ログ類や画面キャプチャの共有をご検討ください

  • エラーに関わる情報を幅広く提供いただけると早期に解決できる場合があります。
  • OS やアプリケーションの調査は原則的にはお客様に行っていただく内容となります。ただし、問題の切り分けを目的として、サポートエンジニアからログ類や画面キャプチャの提供をお願いする場合があります。
  • 初期の起票段階でログ類やキャプチャを添付いただくことで、サポートエンジニアから共有をお願いする連絡が不要となり、その分、解決までの時間が短くなる可能性があります。
  • ファイルサイズが大きく、サポートケースに添付できない場合は別の共有方法をご案内いたしますのでご連絡ください。
  • 機密情報が含まれる場合は、確実にマスクしてください。
  • ログのフォーマットを変更している場合は、その情報も添付してください。
  • あまり一般的でないアプリケーションは、対応できない場合があります。

経緯を共有する

事象を再現する手順の共有をお願いいたします

  • 調査の途上で切り分けを行うために、AWS サポートの検証環境で再現検証をする場合があります。非常に強力なトラブルシューティング手段です。
  • その場合は事象の再現に必要な最小限のコード、利用データ、環境設定情報をご提供いただくことで調査がスムーズに進みます。共有をご検討ください。
  • ご提供いただく際には、機密情報が含まれないようご留意ください。

 


すでに試した対応策があればご教示ください

 
×
いろいろやっていますが、うまくいきません。

下記の URL の手順は試しましたが、最後のステップで*** というエラーがでます。

https://docs.aws.amazon.com/***/***

  • お客様の課題に対し、サポートエンジニアからさまざまな対応策をご案内することがあります。このとき、お客様がすでに実施済みの(有効でないことがお客様には分かっている)対応策をご案内してしまうことがあります。
  • このような事態を避けるためにも、お客様で実施済みの対応策があれば、可能な限りご共有ください。
  • 例文の通り、実施された対応策が有効でないと判断した理由もお知らせください。手順の一部を変更することで、対応策が有効になる場合があります。

その他の TIPS

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

 
× Lambda のトラブルシューティングと RDS の仕様確認を1ケースで質問する

Lambda のトラブルシューティングで1ケース、RDS の仕様確認で1ケース、計2ケースを起票する
  • 1つのサポートケースには、一時点で、1人のサポートエンジニアが対応しますので、独立性の高い質問は、複数のケースに分けて起票いただくと対応を迅速化できる場合があります。
  • もちろん相互に関連の強い質問は1ケースにご記載ください。迷った際は、書きやすい形でご記載ください。サポートエンジニアがサポートケースの分割をご提案する場合もあります。


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

 
×
新会計システムが、また動かなくなりました。ステ環では動きます。
ELB (ELB 名***)について質問です。以前の問合せ(ケース ID=****)の関連です。具体的には日本時間昨日正午から……
  • お客様がどのような状況に直面されているのか、サポートケースごとに、具体的にサポートエンジニアに伝わるようご記載ください。
  • お客様組織内の独自の用語等は使わずにご質問ください。
  • 過去のケースを参照する場合は、ケース番号をご記載ください。


リソースを削除された場合、原因追及が難しくなる場合があります

削除したリソースの、過去の事象についてお問い合わせをいただいても、十分な調査が困難な状態となっている可能性があります。

 

サポート対応中に緊急度を上げたい場合

 
×
最初は緊急度=低で起票しましたが、至急対応をお願いします。
新たに高い緊急度のサポートケースを起票し、緊急度を上げたいサポートケースのケース ID を引用し、緊急度の変更を依頼する
  • 件名や本文に「緊急」等と記載されても、緊急度は変更されませんのでご注意ください。
  • 現在の AWS サポートの仕組みでは、当初設定された緊急度をお客様が事後的に変更することができません。お手数ですが、高い緊急度で新しいサポートケースを起票し、当初のサポートケースの緊急度の変更をご依頼ください。

 

複数のアカウントをまたがるサービスについてのお問い合わせ

  • 複数のアカウントをまたがるサービスがお客様の期待通りの動作をしない場合、お問い合わせいただく際には、可能であればサービスの両端(2つ)のアカウントからそれぞれ起票いただけると、解決までの時間が短縮される可能性があります。
  • ひとつのアカウントのみから起票いただいた場合、AWS サポートでは、もう片方のアカウントのリソースや設定について調査することができません。この場合、サポートエンジニアよりお客様に対し、もう片方のアカウントからも起票いただくようお願いする場合があります。詳細については、AWS アカウント ID を超えたお問い合わせをご参照ください。
  • お客様において2つのアカウントのどちらに問題があるか切り分けが困難な場合は、両アカウントからの起票を推奨いたします。

ご案内が難しいご質問

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

  • サポートケースでは、起票されたアカウント ID に関するお問い合わせに回答します。
  • お客様のセキュリティを守る観点から、同一企業内のアカウント ID や同一 AWS Organizations 内のアカウント ID であっても、起票アカウント ID と異なるアカウント ID に関連するお問い合わせには、そのサポートケースの中では回答しておりません。
  • 誤って、お問い合わせ対象ではないアカウント ID から起票してしまった場合、サポートケースをクローズし、お問い合わせ対象のアカウント ID から新しいサポートケースを再度起票してください。その際、お問い合わせ内容は再度、具体的にご記載ください。

 

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

  • 障害発生は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発生率の低減に努めておりますが、障害の発生を完全に防ぐことは困難です。
  • このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を行っています。
  • たとえば EC2 において、お客様が AWS 基盤の異常を検知した場合、不安定なリソースは廃棄していただき、新たに別の EC2 を調達していただく等、クラウドの特性を活かしたアクションが可能です。
  • AWS では、障害内容の詳細なご説明は行っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活用や、一次復旧を優先する方法をご案内することで、お客様の課題を迅速に解決することを目指します。

 

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

  • AWS では各サービスの性能指標についてご案内しておりません(ドキュメントで公開されているものはこの限りではありません)。
  • 「性能」の多くは、お客様の環境やワークロードに依存します。一般的にご案内できる情報を AWS が持ち得ない点をご理解ください。
  • お客様ご自身の環境で実際に測定していただくことが、適切な指標になりうると考えております。実測したい環境を容易に複製し、破棄できるのがクラウドのメリットです。ご活用ください。

 

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

  • AWS ではメンテナンスの実績や頻度についてご案内しておりません。
  • AWS が実施するメンテナンスは、お客様に AWS を安心してご利用いただくためのものです。お客様のご利用への影響を小さくするため、AWS は改善に努めておりますが、残念ながら、お客様のご利用に影響が出るメンテナンスの発生をゼロに抑えることはできません。
  • またメンテナンスにつきましては、セキュリティへの対応等、やむをえず緊急で行われる場合もあり、過去の頻度から将来的なメンテナンスの頻度を予測することは適切ではありません。予めご了承ください。

 

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

  • ご質問の背景を共有いただくことで、適切な情報をご案内できる場合があります。
 
×
Multi AZ 構成の RDS が切り替わる仕組みや利用している技術を教えてください。

Multi AZ 構成のRDSがフェイルオーバーする条件を教えてください。現在、監視システムの設計をおこなっています。
  • 例文の前段のようなご質問への回答は通常いたしかねますが、後段のようにご質問の具体的な背景を共有いただけると、お役に立てる情報を回答できる場合があります。

 

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

 

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

  • お客様が AWS 基盤の不具合により影響を受けた場合、サポートエンジニアは、お客様に回避策等のご案内を差し上げるとともに、サービス開発チームに不具合改修のエスカレーションを行う場合があります。
  • この場合、不具合が解消する期日についてはお約束することができません。また、不具合が解消された際であっても、AWS サポートからお客様には個別にご連絡を差し上げることができません。
  • このようなご要望がある場合には、お客様から新規にケースを起票いただき、不具合が解消したか否かについてお問い合わせをいただくようご案内しております。お客様にはお手数をおかけしておりますが、ご協力をお願いいたします。
  • エンタープライズサポートプランにご加入のお客様は、テクニカルアカウントマネージャー(TAM)が対応させていただく場合がありますので、TAM にご相談ください。

お客様からの評価

AWS のサービスそのものについて

  • 各サービスの機能追加、改善のご要望を承っています。
  • サポートケースに直接ご記入ください。サポートエンジニアが承り、サービス開発チームに連携いたします。
  • 実現のお約束や、実現時にご連絡を個別に差し上げることはできかねますが、お客様の声をサービス開発チームにフィードバックすることは、AWS のサービス改善にとって有益であると考えています。

 

サポートエンジニアの対応品質について(回答毎)

  • サポートエンジニアの対応品質についてのご評価にご協力ください。サポートセンターから、回答ごとに星☆ による評価を実施いただけます。
  • 星☆ による評価の方法や詳細については、AWS サポートからの回答欄にある星☆ についてをご一読ください。
  • AWS サービス、ならびに AWS へのご意見は、この星☆ による評価ではなく、前項でご案内したとおり、サポートケースのテキストにてお伝えください。

 

AWS サポートからの回答欄にある星☆ について

  • その欄の回答を担当したサポートエンジニアの対応品質をお客様がご評価いただける仕組みです。テクニカル・スキル、 コミュニケーション・スキルなどの観点から総合的にご評価ください。
  • 評価の入力方法ですが、サポートエンジニアの対応にご満足いただいているのであれば ☆5、多少改善して欲しい点があれば ☆4、強いご不満をお持ちであれば ☆1 というように 5 段階でご検討いただき、☆のアイコンをクリックいただければ完了です。また、いったん入力した評価を事後的に変更いただくことも可能です。その際は、対象の回答の ☆ のアイコンをクリックし直してください。
  • お客様からいただいた評価について具体的なご意見をおうかがいする場合があります。起票いただいたアカウント宛にメールもしくは電話でご連絡させていただくことがあります。AWS サポートの品質向上に役立てたいと考えておりますので、率直なご意見をいただければと思います。ご協力のほどよろしくお願いいたします。

 

サポート全体の品質について(ケース終了時)

  • サポートケースのクローズ時に送付されるメールでアンケートが案内されますのでぜひご記入ください。
  • サポート全体の品質向上のための非常に重要なフィードバックとなります。ご協力をお願いいたします。
     

課題が解決した際のお願い

終わりよければすべてよし

  • サポートエンジニアからの回答を得て、お客様の課題が解決した場合、サポートケースをそのままにされることなく、解決した旨をケースにご記載いただき、クローズいただくようお願いいたします。
  • お客様ご自身で課題を解決した場合であっても、同様に、解決された状況をサポートケース上にご記載いただき、クローズすることを推奨いたします。
  • 後日、同じアカウント内の他のお客様が同様の課題に直面した際に、過去の実績として、課題解決の有効な手がかりとなる可能性があります。
  • また、AWS サポートにおいても、回答の有効性や、サポートエンジニアが気づけなかった解決方法について情報共有をいただくことで、今後のサポート品質向上につながりますので、ぜひご協力をお願いいたします。
     

Guidelines for technical inquiries

Note: The following is the informal English translation of Japanese Guidelines (技術的なお問い合わせに関するガイドライン). Multiple customers in Japan requested us to provide English version. We hope this document helps many people.

We always want to resolve your issues efficiently and quickly. This page provides you some points to consider to create effective Support Cases.

For general information of AWS Support, refer to [AWS Support].
For details of the help you can get, refer to [AWS Support Plans].

General notes

Basic information

  • Service/Category
    By selecting the correct Service/Category of the issue, you will get our response faster.
  • Language
    Select your preferred contact language.
  • Contact method
    We recommend using Web in general. Refer to [Contact Method (Web, Phone, or Chat)] for details.
     

Severity

  • Setting an appropriate Severity is important for smooth resolution.
  • Select the Severity according to your business impact. Please refer to [the separate table for definition].
  • Adding words like “Urgent” in your Support Case won't escalate the Severity.
  • We may ask your approval to lower the Severity depending on the situation.
  • Once you have created your Support Case, you can’t change the Severity. If you want to change the Severity, refer to [Escalating the Severity].

Contact methods (Web, Phone, Chat)

  • Customers with a Business Support plan or higher can use Web, Phone, or Chat as a Contact method. We recommend Web as the best method for sharing detailed information efficiently.
  • When you contact by Phone or Chat, we may not be able to provide immediate suggestions during live conversation if we need further investigation. In such cases, we will propose to provide the investigation result later via Web. This is the best way to avoid keeping you on-line for a long time.
  • Use Phone or Chat in the following situation.
    -To confirm whether we understand your issue precisely in a complex situation
    -To provide additional information difficult for you to write down
    -To understand what information you should provide
    In some situations, we may propose a phone conversation even if you choose Web.
     

Contacting via Phone and/or Chat

  • If you subscribe to Business Support plan or higher, you can use Phone and Chat to contact us.
  • If you choose Phone, you will receive a phone call from us. Enter your phone number in the Support Center referring to the notes at the page top.
  • Please understand that you may not be able to start a conversation immediately when our Phone and/or Chat are busy.
  • While your Support Case is handled by our Support Engineer, if you contact us via Phone or Chat, you may not be able to speak with the same Support Engineer.Waiting for our Web response would be the fastest way for you to get our investigation result.
  • We don’t guarantee to resolve your issue during live conversation on Phone or Chat. Live conversation may not help to speed up our dive-deep investigation.If you want your issue resolved by a certain time, select the appropriate Severity and describe the details of your business situation when you create your Support Case.

Identify the problem you want to solve

Describe the issue you want to solve very clearly

Example  
Do Not
Is the ELB under any maintenance now?
Do https: //myweb***.com/index.html ELB (ELB name ***) is not accessible from outside. I want to restore it ASAP. Please tell me what to do.
  • When you are in a rush, you may tend to write a question like the first example.
  • If we could understand your issue clearly, we can speed up the resolution.

 

Describe how you confirm the issue
Example  
Do Not
EC2 (i-***) in Tokyo Region does not respond.
Do EC2 (i-***) in Tokyo Region does not respond to ping from on-premise.
  • Provide specific information of how you confirmed the issue
  • Provide information of the "access source" as shown in the second example (we can check the possibility of route failure).

 

Share the details of your current situation and your final goal

Example  
Do Not What does "Error: Invalid parameters bla bla bla” mean?
Do Not In what situation do we see "Error: Invalid parameters. Exceeding capacity limit"?
Do I was trying to do ****. When I submit the command "xcmd ??? -o -k -v: 33" on CLI, the message "Error: Invalid parameters. Exceeding capacity limit" appears and it fails. How can I make this work? The command submission time is 15:52 JST, and the Request ID is ****.
  • Describe your issue in as much detail as possible. If your Support Case is missing important points, we may take time to ask you for more information.
  • Then we can investigate various possibilities, such as wrong command syntax, insufficient permissions, and temporary failure of AWS infrastructure, etc.
  • We may suggest other possible ways for you to get closer to "your final goal".

Share the accurate situation

Provide resource ID + Region in question

Example  
Do Not I have a question about the web server.
Do I have a question about EC2 (i-***) of Tokyo Region.
  • Please specify the resource by instance ID, not instance Name.

 

Provide the start time of your issue (with time zone) and the current situation

Example  
Fair The issue started at 15:52 on October 27.
Fair The issue started at 15:52 on October 27 (JST)
Good The issue started at 15:52 on October 27 (JST). It is ongoing now.
Good The issue started at 15:52 on October 27 (JST). It is recovered now.
  • Providing the exact time helps us to troubleshoot.
  • Note that we can't investigate issues that are too old.

 

Share your logs and/or screen captures

  • If you share a wide range of evidences of your issue, we may reach an early resolution.
  • In general, you are responsible for investigation of the OS and Application layers. However, we may ask you to share their logs and/or screen captures for troubleshooting.
  • If you create your Support Case with such information attached, we don’t have to ask you to share them. Then we might be able to resolve your issue quickly and efficiently.
  • If you can’t attach them due to large file size, tell us and we will provide an alternative way.
  • Mask confidential information before sharing.
  • If you have changed the log format, tell us how you changed it.
  • We may not be able to understand the logs if the applications are proprietary.

Share the history of your issue

Share the steps to reproduce your issue

  • We might try to reproduce your issue in our test environment. It is a very effective way of troubleshooting.
  • You can help us by providing the minimum steps to reproduce your issue, such as the code, data, configurations, etc.
  • Again, remove any confidential information from them.

 

Let us know if you tried any counteraction before you created the Support Case.

Example  
Do Not I've tried many things, but all didn't work.
Do I have tried the recovery procedures described in the following URL, but I got a **** error at the last step.
https://docs.aws.amazon.com/***/***
 
  • We may provide various suggestion to solve your issue. This may include the counteraction you have already confirmed ineffective.
  • To avoid such situations, provide information of what you have already tested.
  • As in the second example, tell us why you understood your counteraction was ineffective. By changing parts of it, we may find it works.

Other TIPS

1 question to 1 Support Case

Example  
Do Not
Request the troubleshooting of Lambda and ask the specifications of RDS in one Support Case.
Good Create 2 Support Cases. One is for Lambda troubleshooting. The other is for RDS specifications.
  • One Support Engineer handles each single Support Case at a time. For independent questions, we recommend creating separate Support Cases so we may be able to handle them efficiently.
  • Of course, you can put relevant multiple questions in one Support Case. If you are not sure, create Support Cases and put questions as you like. We may propose to split or combine Support Cases.


Don't use context-dependent wording

Example  
Do Not The New ACCT System has stopped again. STEN is OK, though.
Do I have a question about ELB (ELB Name ***). It is related to the previous Case (caseID = ****). From 12:00pm yesterday (JST) …
  • Create the Support Case to tell us what issue you are facing in detail and specifically.
  • Don't use internal terms of your project.
  • If you need to refer to your past Support Cases, give us the Case IDs as shown in the second example.

Questions about deleted resources

If you ask about the past events of deleted resource, it may be difficult for us to investigate sufficiently.

 


Escalate the Severity

Example  
Do Not Request an urgent response in your Support Case with low Severity.
Do Create a new Support Case with the required Severity, and request us to change the Severity of your original Support Case with its Case ID.
  • Note that even if you put words like "Urgent!" in your Support Case, the Severity won't be escalated automatically.
  • You can't change the Severity after you create a Support Case. You can ask us to escalate the Severity by creating a new Support Case with a higher Severity.

 

Questions about a service across multiple AWS accounts

  • If you see the issue on a service used across multiple accounts, we recommend you to create a Support Case from each account.
  • We can't investigate the resources of the account other than the account you created the Support Case from. We may ask you to create a Support Case from the other account. Refer to [Questions of resources in other account]
  • If you can’t find which of the two accounts has the resource(s) causing the issue, we recommend you to create two Support Cases from each account.
     

Difficult Questions to answer

Questions of resources in other AWS accounts

  • We answer questions about the account where you created your Support Case from.
  • For security purposes, even if the account ID belongs to the same company or the same AWS Organizations, we won’t answer question about any account other than the account you created the Support Case from.
  • If you accidentally create a Support Case from the wrong account, close the Support Case, sign in to the correct account, then create your new Support Case. Write the same question without any omission.

Question about the cause of a failure of AWS infrastructure

  • Failures are unpredictable and unavoidable. Although AWS makes every reasonable effort to analyze and reduce failures, it is difficult to prevent them entirely.
  • For this reason, AWS recommends "Design For Failure" for all Customers. We also provide monitoring services, service resources, and best practices.
  • For example, if you find an instability of EC2 infrastructure, you can terminate it and create new EC2. Taking advantage of such AWS feature, you can take action to mitigate your impact easily and quickly.
  • AWS doesn’t explain the detailed cause of failures since we think that such disclosure won't essentially contribute to your workaround strategy. Instead, we want to mitigate your business impact by providing the best practices of monitoring and/or possible workarounds to prioritize restoration.

Question about performance indexes

  • AWS doesn’t provide performance indexes of each service (except for those published).
  • Performance depends on your environment and workload. We do not have general information that fits all customer situations.
  • You can measure performance in your environment with your workload. We believe that such result should be the best suited indexes for your future use. Taking advantage of AWS features, you can easily create your test environment by copying from your production, and delete it after measurement.

 

Questions about past records of our maintenance

  • AWS doesn't provide past records of maintenance.
  • Maintenance is for all customers to use our Services safely. AWS makes efforts to reduce the impact on you, however, it is impossible to eliminate maintenance with minimum downtime.
  • Under critical situations, we might have unavoidable, immediate maintenance, such as security patching. You can't predict future maintenance frequency from past records.

Question about AWS internal architecture

  • If you share the background of your questions, we might be able to provide the suitable guidance.
Example  
Do Not Tell us the detailed mechanism or technology of Multi AZ RDS failover.
Do Tell us the conditions for failover of Multi AZ RDS. We are currently designing our monitoring system.
  • We can't answer questions like the first example, however, if you share the background like in the second example, we might be able to help you efficiently.

 

Questions about AWS Compliance

  • AWS Support can’t answer such questions. Instead, we will guide you to the "AWS Compliance Contact Us" webform.
  • AWS Sales Team may contact you later.

 

Proactive notification of bug-fixes of AWS infrastructure

  • If we found that you were impacted by the failure of AWS, we will provide you some workarounds and then escalate the incident to our Service Team.
  • In this case, we can’t guarantee the date of the fix. Also, when the Service Team completes the fix, AWS Support has no way to provide a proactive notice to you.
  • If you want to confirm that the fix was completed, open a new Support Case to ask. We apologize for the inconvenience but we ask for your cooperation.
  • If you subscribe to Enterprise Support plan, you can consult with your Technical Account Manager (TAM) to help you.

Your Evaluation

About AWS Services

  • We accept your request for improvement or new features for all AWS Services.
  • Provide your request in your Support Case. Support Engineers will share them with the Service Team.
  • We can't guarantee its implementation. Even if it was implemented, we have no way to notify you individually. Still, we believe that sharing your feedback with the Service Team is beneficial for both you and AWS.

 

About communication quality of Support Engineer

  • Provide your evaluation on the quality of our response by selecting the number of stars in the Support Center. Refer to [About Star☆ for each response] for more details.
  • If you want to provide your feedback on AWS services or AWS itself, do not use the Star☆ rating. You can write your feedback in your Support Case as we said above.

 

About Star☆ for each response

  • You can evaluate the quality of our response with this Star☆ rating. Rate your total impression, considering our technical skill, communication skill, etc.
  • If you are satisfied with a response, rate Star☆5. If you want us to improve a bit, rate Star ☆4. If you have a very strong complaint, rate Star ☆1. You can change your rating later, just re-click the Star.
  • We may contact you by email or phone to hear the specific reason of your rating. We would be happy to get your honest opinion to improve our activity.

 

About the overall quality of our support

  • When your Support Case is closed, you will get an email with a feedback link. Please click on it.
  • Your feedback is important for us to improve the overall quality of AWS Support.
     

After your issue is resolved

All is well that ends well

  • If you resolved your issue with our help, update your Support Case to let us know, then close the Case.
  • If you resolved your issue by yourself, we still recommend updating your Support Case and writing how you resolved it.
  • Your update would help your colleagues working in the same AWS Account when they face a similar issue.
  • It would also help us to know whether our suggestion was beneficial for you or missing some technical aspect. Knowing such situations, we can improve our support activities, so please share how you resolved your issue.