AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。
なお、サポート全般についての一般的な情報は、AWS サポートをご参照ください。
サポートレベル毎の技術サポートへのアクセスについては、AWS サポートのプラン比較をご参照ください。
全般的な留意事項
- サービス/カテゴリー
お問い合わせ内容に最も近い項目をご選択いただくことで、適切な回答が早期に得られる可能性が高まります。 - お問い合わせ言語
日本語を選択します。英語での技術支援をご希望の場合には English を選択します。 - 連絡方法
多くの場合、Web を推奨します。使い分けは後述します。
- 適切な緊急度の設定は問題の円滑な解決にとって重要です。
- お客様ビジネスへの影響度に応じて、サポートケースの緊急度を選択します。別表をご参照ください。
- 件名や本文に「緊急」等と記載されても、緊急度は上がりません。
- 状況確認の結果によっては、サポートエンジニアが緊急度を下げるご協力をお願いする場合があります。
- ビジネスサポート以上のお客様には電話や Chat による連絡方法も提供されていますが、詳細な情報共有は Web が最も確実で適しています。
- 電話や Chat でご連絡いただいた際に、調査を必要とし、その場で回答できない場合もあります。その場合、調査後に Web での回答を提案させていただきます。お客様を長時間拘束することなく、回答を提供させていただきますので、ご協力をお願いいたします。
- 以下のような場合は、電話や Chat をご活用ください。
-複雑な状況において、AWS との問題認識に差異が生じていないか確認をしたい場合
-Web で書き切れない情報を補足したい場合
-どのような情報を提供してよいか判らない場合、等
なお、サポートエンジニアが電話での会話をご提案することもあります。
- ビジネスサポート以上のお客様が対象となります。
- 電話はコールバック方式です。サポートセンターの 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. Exceed capacity limit」は、どういう時に出ますか? |
◯ | *** を実現するために、CLIで「xcmd ??? -o –k –v:33」と投入したら、「Error: Invalid parameters. Exceeding capacity limit」とメッセージが出て、失敗しました。どうしたら良いでしょうか。コマンド投入時刻は日本時間の本日 15:52、Request ID は *** です。 |
- ご質問内容が省略されている場合、内容の確認にお時間を必要としますので、省略せずにご記載をお願いいたします。
- コマンドの間違い、コマンド投入者の権限不足、AWS 基盤の一時的障害など、さまざまな可能性をお調べします。
- 「最終的に実現したいこと」に近づくための別の方法をご案内することがあります。
状況を正確に共有する
例 | |
× | 東京リージョンの EC2(i-***)が、応答しません。 |
◯ | 東京リージョンの EC2(i-***)が、オンプレからの ping に反応しません。 |
例 | |
△ |
発生時刻は 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
例 | |
△ |
Lambda のトラブルシューティングと、課金体系を1ケースで質問する |
◯ |
Lambda のトラブルシューティングで技術系のお問い合わせ1ケース、Lambda の課金体系について、非技術系のお問い合わせ1ケース、計2サポートケースを起票する |
- 1つのサポートケースには、一時点で、1人のエンジニアが対応しますので、独立性の高い質問は、複数のケースに分けて起票いただくと対応を迅速化できる場合があります。
- もちろん相互に関連の強い質問は1ケースにご記載ください。迷った際は、書きやすい形でご記載ください。サポートエンジニアがサポートケースの分割をご提案する場合もあります。
例 | |
× |
新会計システムが、また動かなくなりました。ステ環では動きます。 |
◯ | ELB (ELB 名***)について質問です。以前の問合せ(ケース ID=****)の関連です。具体的には日本時間昨日正午から…… |
- お客様がどのような状況に直面されているのか、サポートケースごとに、具体的にサポートエンジニアに伝わるようご記載ください。
- お客様組織内の独自の用語等は使わずにご質問ください。
- 過去のケースを参照する場合は、ケース番号をご記載ください。
例 | |
× |
最初は緊急度=低で起票しましたが、至急対応をお願いします。 |
◯ | 新たに高い緊急度のサポートケースを起票し、緊急度を上げたいサポートケースのケース ID を引用し、緊急度の変更を依頼する |
- 件名や本文に「緊急」等と記載されても、緊急度は変更されませんのでご注意ください。
- 現在のサポートの仕組みでは、当初設定された緊急度をお客様が事後的に変更することができません。お手数ですが高い緊急度で新しいサポートケースを起票し、当初のサポートケースの緊急度の変更をご依頼ください。
- 複数のアカウントをまたがるサービスがお客様の期待通りの動作をしない場合、お問い合わせいただく際には、可能であればサービスの両端(2つ)のアカウントからそれぞれ起票いただけると、解決までの時間が短縮される可能性があります。
- ひとつのアカウントのみから起票いただいた場合、AWS サポートでは、もう片方のアカウント側の設定について確認することができません。この場合、サポートエンジニアよりお客様に対し、もう片方のアカウントからも起票いただくようお願いする場合があります。(参考:AWS アカウント ID を超えたお問い合わせ)
- お客様において2つのアカウントのどちらに問題があるか切り分けが困難な場合は、両アカウントからの起票を推奨いたします。
ご案内が難しいご質問
- サポートケースでは、起票されたアカウント ID に関するお問い合わせに回答します。
- お客様のセキュリティを守る観点から、同一企業内のアカウント ID や同一 AWS Organizations 内のアカウント ID であっても、起票アカウント ID と異なるアカウント ID に関連するお問い合わせには、そのサポートケースの中では回答しておりません。
- 誤って、お問い合わせ対象ではないアカウント ID から起票してしまった場合、サポートケースをクローズし、お問い合わせ対象のアカウント ID から新しいサポートケースを再度起票してください。その際、お問い合わせ内容は再度、具体的にご記載ください。
- 障害発生は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発生率の低減に努めておりますが、障害の発生を完全に防ぐことは困難です。
- このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を行っています。
- たとえば EC2 において、お客様が AWS 基盤の異常を検知した場合、不安定なリソースは廃棄していただき、新たに別の EC2 を調達していただく等、クラウドの特性を活かしたアクションが可能です。
- AWS では、障害内容の詳細なご説明は行っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活用や、一次復旧を優先する方法をご案内することで、お客様の課題を迅速に解決することを目指します。
- AWS では各サービスの性能指標についてご案内しておりません(ドキュメントで公開されているものはこの限りではありません)。
- 「性能」の多くは、お客様の環境やワークロードに依存します。一般的にご案内できる情報を AWS が持ち得ない点をご理解ください。
- お客様ご自身の環境で実際に測定していただくことが、適切な指標になりうると考えております。実測したい環境を容易に複製し、破棄できるのがクラウドのメリットです。ご活用ください。
- AWS ではメンテナンスの実績や頻度についてご案内しておりません。
- AWS が実施するメンテナンスは、お客様に AWS を安心してご利用いただくためのものです。お客様のご利用への影響を小さくするため、AWS は改善に努めておりますが、残念ながら、お客様のご利用に影響が出るメンテナンスの発生をゼロに抑えることはできません。
- またメンテナンスにつきましては、セキュリティへの対応等、やむをえず緊急で行われる場合もあり、過去の頻度から将来的なメンテナンスの頻度を予測することは適切ではありません。予めご了承ください。
- ご質問の背景を共有いただくことで、適切な情報をご案内できる場合があります。
例 | |
× |
Multi AZ 構成の RDS が切り替わる仕組みや利用している技術を教えてください。 |
◯ |
Multi AZ 構成のRDSがフェイルオーバーする条件を教えてください。現在、監視システムの設計をおこなっています。 |
- 例文の前段のようなご質問への回答は通常いたしかねますが、後段のようにご質問の具体的な背景を共有いただけると、お役に立てる情報を回答できる場合があります。
- サポートセンターからご案内することが難しいため、コンプライアンス専用のお問い合わせ窓口をご案内することがあります
- お客様を担当している AWS 社員から回答させていただく場合があります。
- お客様が AWS 基盤の不具合により影響を受けた場合、サポートエンジニアは、お客様に回避策等のご案内を差し上げるとともに、サービス開発チームに不具合改修のエスカレーションを行う場合があります。
- この場合、不具合が解消する期日についてはお約束することができません。また、不具合が解消された際であっても、AWS サポートからお客様には個別にご連絡を差し上げることができません。
- このようなご要望がある場合には、お客様から新規にケースを起票いただき、不具合が解消したか否かについてお問い合わせをいただくようご案内しております。お客様にはお手数をおかけしておりますが、ご協力をお願いいたします。
- エンタープライズサポートプランにご加入のお客様は、テクニカルアカウントマネージャー(TAM)が対応させていただく場合がありますので、TAM にご相談ください。
お客様からの評価
- 各サービスの機能追加、改善のご要望を承っています。
- サポートケースのテキストに直接記入いただいて構いません。エンジニアが承り、サービス開発チームに連携いたします。
- 実現のお約束や、実現時にご連絡を個別に差し上げることはできかねますが、お客様の声をサービス開発チームにフィードバックすることは、AWS のサービス改善にとって有益であると考えています。
- サポートケースをクローズされる際に自動で送付されるメールの末尾の URL からも、コメントを投稿することができます。
- エンジニアの対応品質についてのご評価にご協力ください。サポートセンターから、回答ごとに星による評価を実施いただけます。
- 星による評価の方法や詳細な説明はこちらをご一読ください。
- AWS サービス、ならびに AWS へのご意見は、この星による評価方法ではなく、サポートケースをクローズされる際に自動で送付されるメールの URL でお伝えください。
サポートケース画面の、AWSサポートからの回答欄にある星☆は何ですか?
- その欄の回答を担当したエンジニアの対応品質をお客様がご評価いただける仕組みです。テクニカル・スキル、 コミュニケーション・スキルなどの観点から総合的にご評価ください。
- 評価の入力方法ですが、エンジニアの対応にご満足いただいているのであれば ☆5、強いご不満をお持ちであれば ☆1 というように 5 段階でご検討いただき、☆のアイコンをクリックいただければ完了です。また、いったん入力した評価を事後的に変更いただくことも可能です。その際は、対象の回答の ☆ のアイコンをクリックし直してください。
- お客様からいただいた評価について具体的なご意見をおうかがいする場合がございます。起票いただいたアカウント宛にメールもしくは電話でご連絡させていただくことがあります。AWS サポートの品質向上に役立てたいと考えておりますので、率直なご意見をいただければと思います。ご協力のほどよろしくお願いいたします。
- なお、エンジニアの対応品質以外の、AWS サービスの品質や仕様についてのご評価・コメントにつきましては、ケースクローズ時にお送りしているアンケートをご利用ください。
- サポートケースのクローズ時に送付されるメールでアンケートが案内されますのでぜひご記入ください。
- サポート全体の品質向上のための非常に重要なフィードバックとなります。ご協力をお願いいたします。
課題が解決した際のお願い
- サポートエンジニアからの回答を得て、お客様の課題が解決した場合、サポートケースをそのままにされることなく、解決した旨をケースにご記載いただき、クローズいただくようお願いいたします。
- お客様ご自身で課題を解決した場合であっても、同様に、解決された状況をサポートケース上にご記載いただき、クローズすることを推奨いたします。
- 後日、他のお客様が同様の課題に直面した際に、過去の実績として、課題解決の有効な手がかりとなる可能性があります。
- また、AWS サポートにおいても、回答の有効性や、サポートエンジニアが気づけなかった解決方法について情報共有をいただくことで、今後のサポート品質向上につながりますので、ぜひご協力をお願いいたします。