【Community Stage レポート】 AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法 #AWSSummit

【Community Stage レポート】 AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法 #AWSSummit

AWS サポートとの効果的な向き合い方について、実践的で貴重な知見を共有いただきました。
Clock Icon2025.06.30

コーヒーが好きな emi です。

本記事は 2025 年 6 月 25 - 26 日の 2 日間幕張メッセで開催された AWS Summit Japan 2025Community Stage 視聴レポートとなります。

セッション概要

日時:2025年6月26日(木)12:30 - 12:50
タイトル:AWS テクニカルサポートとエンドカスタマーの中間地点から見える、より良いサポートの活用方法
登壇者:AWS Community Builder 市野 和明
会場:AWS Summit Japan 2025 ミニステージ Community Stage

リセラーのテクニカルサポート部門に所属する立場から、AWS からの回答を引き出しにくいような質問や根本的な考え方を理解していれば質問する必要がなかったような問い合わせを一例として紹介します。 AWS として公開しているドキュメントや考え方を紹介し AWS のスタンスをあらかじめ理解しておくことで、より良いサポート体験が受けられる可能性を秘めていることを解説します。

https://pages.awscloud.com/summit-japan-2025-aws-expo-booth.html#ministage

登壇資料

https://speakerdeck.com/kazzpapa3/aws-tekunikarusapototoendokasutamanozhong-jian-di-dian-karajian-eruyoriliang-isapotonohuo-yong-fang-fa

セッション内容

市野さんはリセラーであるサーバーワークスでテクニカルサポート業務に従事されており、お客様からの問い合わせを直接受ける立場にあります。この中間的な立場から見えてきた、AWS サポートとの効果的な向き合い方について貴重な知見を共有いただきました。

1. Design for Failure の重要性

市野さんは AWS の基本概念である 「Design for Failure」 の重要性を強調されました。これは AWS の CTO Werner Vogels 氏の有名な言葉 「Everything fails, all the time(すべてのものはいつか壊れる)」 に基づく考え方です。

  • 障害の発生を防ぐことよりも、障害があっても使い続けられる構成を考えることが重要
  • AWSもこの考え方を前提としてサポートを提供している

2. サポートガイドラインの理解

AWS にはテクニカルサポートのガイドラインが公開されており、これを理解することで効果的なサポート活用が可能になります。
https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

  • 例文も用意されている
  • 英語版も利用可能
  • 障害原因の詳細開示についての考え方が明記されている

3. 障害対応に関するAWSの基本方針

障害詳細の開示について

  • AWS は障害の詳細説明を行わない方針
  • 詳細説明よりも課題解決を迅速に行うことを優先
  • 監視や一時復旧を重視している

この方針の背景

  • AWS を使うのはお客様のビジネスの本質ではない
  • AWS でしか制御できないことは開示しない

4. SLA/SLO の正しい理解

  • SLA(Service Level Agreement)と SLO(Service Level Objective)の正しい理解が重要
  • 適用条件が定められている
  • SLA/SLO のページは日本語版の情報が特に古いため、英語版の最新情報の確認を推奨

https://aws.amazon.com/legal/service-level-agreements/?nc1=h_ls&ams%23interactive-card-vertical%23pattern-data.filter=%257B%2522filters%2522%253A%255B%255D%257D

5. 効果的でない問い合わせパターン

避けるべき問い合わせ例

  • 個別リソースへの影響確認(ヘルスダッシュボードで確認可能)
  • 障害の詳細原因追求
  • 日本の会社向けの書面要求

6. 推奨される対応方法

  • 推奨構成に沿わない場合、障害時に 「推奨構成じゃないから」 と指摘される可能性が高い
    • マルチ AZ 構成がとられていない構成で発生した障害の問い合わせに対しては 「マルチ AZ 構成を推奨します」 という回答になってしまう

ベストプラクティスとの向き合い方

  • ベストプラクティスが絶対的に正しいわけではない
  • 沿わない判断をする場合もある
  • その場合はリスクを許容する姿勢が重要

市野さんのコミュニティ活動

市野さんはテクニカルサポートという立場から得られる知見を積極的にコミュニティで共有されています。

  • 成功事例と失敗事例の両方を知りたい
  • AWS とお客様のギャップを理解し、それを伝えたい

まとめ

  • AWSのガイドラインを理解してから問い合わせる
  • Design for Failureの実践、障害を前提とした設計を心がける
  • ベストプラクティスを理解し、ベストプラクティスを逸脱する設計でサービスを運用する場合はリスクを許容する

リセラーという中間的な立場だからこそ見えてくる AWS サポートとの効果的な向き合い方について、実践的で貴重な知見を共有いただきました。

また、すごく気持ちが分かるのですが、市野さんの名前が表示されたブースの写真を市野さんが 「すげ~~!」 と言いながら撮っていたのが楽しかったです。和やかなブースでした。(その後私もまったく同じことをしました)

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.