#AWSSummit AWS テクニカルサポートとエンドカスタマーの 中間地点から見える より良いサポートの活用方法 [AWS Summit Japan 2025 / Community Mini Stage] JAWS-UG 神戸 @kazzpapa3 / ICHINO Kazuaki 2025-06-26 

#AWSSummit 自己紹介 2 @kazzpapa3 

#AWSSummit ● 名前：市野 和明（いちの かずあき） ● 所属：株式会社サーバーワークス 　　　マネージドサービス部 AWSサポート課 ● 好きな AWS サービス： 　　　 AWS CloudTrail, AWS CLI ● （テクサポとして） 嫌いな AWS サービス： AWS Billing（請求ロジックが難解すぎる） ● 趣味：初音ミクが好き、酒を飲む ● 　 @kazzpapa3 はじめまして 3 @kazzpapa3 

#AWSSummit ● AWS パートナー企業所属で「リセラー」という立場になります ● 雑にいうと AWS さんから AWS アカウントを仕入れてお客様に再販しています ● その関係性からお客様は AWS に直接問い合わせできず、 われわれが間に入って対応しています ● 立場上、双方の中間地点から見える風景から喋ってますが、個人の意見です 4 @kazzpapa3 弊社（リセラー） お客様 AWS AWS アカウント お問い合わせ わたしの立場について 

#AWSSummit ● AWS パートナー企業所属で「リセラー」という立場になります ● 雑にいうと AWS さんから AWS アカウントを仕入れてお客様に再販しています ● その関係性からお客様は AWS に直接問い合わせできず、 われわれが間に入って対応しています ● 立場上、双方の中間地点から見える風景から喋ってますが、個人の意見です 5 @kazzpapa3 弊社（リセラー） お客様 AWS AWS アカウント お問い合わせ わたしの立場について 【補足】 SRE や CSM といった特定案件の専任チームではないため お客様の設計思想や環境内の詳細な実装内容などの個別事情を踏まえず、 AWS 技術仕様上どうか？の観点ですべてのお客様のお問い合わせにフラットに 対応しています （このスタンスは AWS テクニカルサポートも同一と認識しています） 

#AWSSummit はじめに結論 6 @kazzpapa3 

#AWSSummit ● AWS が提供している「ガイドライン」を把握していることで、 より迅速な課題解決のためにどのような情報があれば良いかがわかるだけでな く、AWS が開示しない、回答しにくい回答範囲があることがわかる ● AWS が推奨する設計原則に沿っていると事象に見舞われる確率を下げること ができるとともに、そもそもそういった使い方を AWS が想定していることを あらかじめ知っておく ○ ベストプラクティスに沿っていない（予算などから沿わない判断をしてい るものを含む）場合、発生しうるものだと理解しておき、許容する ● 実装や設計・発生した事象によっては問い合わせが不要とできる （結果的に問い合わせしても一緒）なケースは存在する ベストプラクティスを正しく理解すると問い合わせ自体減らせる 7 @kazzpapa3 

#AWSSummit 4月15日 いろいろありましたね 8 @kazzpapa3 

#AWSSummit ● 主に関西在住の AWS Community Builders (通称 CBs) に新たに就任された 方々と既存の CBs たちで AWS さんの大阪オフィスで集まろう、 と企画していた前日の出来事でした ● 事象についてはみなさまご存知の通り プライマリおよびセカンダリ電源の供給が中断されたことが原因となり、 東京リージョンの apne1-az4 で基盤障害が発生しました ● CBs たちで集まる会では、 「今朝出勤したら問い合わせ、まあまあありましたw」なんて言っていました いろいろありました 9 @kazzpapa3 

#AWSSummit ● 弊社のリソースで影響を受 けたものは？網羅的に案内 ください ● なぜ発生したのか？ AWS として再発防止策はど う考えている？ ● 世間では騒がれているよう ですが、弊社のリソースに は影響がありません @kazzpapa3 

#AWSSummit 11 @kazzpapa3 それぞれのお問い合わせを 深掘り…の前に 

#AWSSummit ガイドラインの存在 12 @kazzpapa3 技術的なお問い合わせに関するガイドライン 出典：技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ ）ページより抜粋 

#AWSSummit ● 効率的かつ迅速な課題解決のために、 サポートケース起票の際に役立つポイントが例文付きで記載されています ○ 当初該当のページは日本語での記載のみでしたがいつからか英語翻訳も付記されるようになって おり、多国籍なチーム構成でも活用できる文書になっています [1] 技術的なお問い合わせに関するガイドライン 13 @kazzpapa3 [1] インターネットアーカイブ Wayback Machine によると 2023年05月07日 時点でのアーカイブまでは日本語表記のみでした https://web.archive.org/web/20230507002757/https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ 

#AWSSummit 技術的なお問い合わせに関するガイドライン ● 効率的かつ迅速な課題解決のために、 サポートケース起票の際に役立つポイントが例文付きで記載されています ○ 当初該当のページは日本語での記載のみでしたがいつからか英語翻訳も付記されるようになって おり、多国籍なチーム構成でも活用できる文書になっています [1] ● AWS 公式のガイドラインではありますが、その考え方は AWS にとどまらず 広く一般的に利用可能なものだと考えられます ○ そのため AWS に限らず何らかの SaaS などに問い合わせをする可能性のあるロールの方はぜひ 一読いただきたい文書です 14 @kazzpapa3 [1] インターネットアーカイブ Wayback Machine によると 2023年05月07日 時点でのアーカイブまでは日本語表記のみでした https://web.archive.org/web/20230507002757/https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ 

#AWSSummit このガイドラインのなかで ● 障害の原因の開示についての考え方が述べられています 15 @kazzpapa3 出典：技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ ）より抜粋 

#AWSSummit このガイドラインのなかで ● 障害の原因の開示についての考え方が述べられています 16 @kazzpapa3 出典：技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ ）より抜粋 ＜お客様の課題の本質＞ ● AWS を使う＝あくまで手段 ● 本来の目的はクラウドを利用して構築したシステム/サービスが稼働し続けることのはず 

#AWSSummit クラウドに合わせた設計を - Design for failure - 17 @kazzpapa3 “Everything fails, all the time.” – Werner Vogels 出典：Designing for failure: Architecting resilient systems on AWS ( https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf )より抜粋 

#AWSSummit ● AWS Whitepaper で “Design for failure” と題された論文がありました [1] ○ その冒頭で、次のように述べられています。 ○ “Everything fails all the time.” – Werner Vogels Design for failure 18 @kazzpapa3 [1] Design for failure アーカイブ済 ( https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html ) よ り抜粋 

#AWSSummit ● AWS Whitepaper で “Design for failure” と題された論文がありました [1] ○ その冒頭で、次のように述べられています。 ○ “Everything fails all the time.” – Werner Vogels ● 現在のドキュメントでは少し言葉を変えて AWS Well-Architected Framework の Reliability（信頼性の柱）の Design principles として以下の ように述べられています [2] ○ Automatically recover from failure（障害から自動的に復旧する） ○ Test recovery procedures（リカバリ手順をテストする） ○ Scale horizontally to increase aggregate workload availability（水平方向にスケールして総 合的なワークロードの可用性を高める） ○ Stop guessing capacity（容量を推測しない） ○ Manage change through automation（自動化で変更を管理する） Design for failure 19 @kazzpapa3 [1] Design for failure アーカイブ済 ( https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html ) よ り抜粋 [2] Design principles（ https://docs.aws.amazon.com/wellarchitected/latest/framework/rel-dp.html ）より抜粋（括弧内は日本語版ドキュメントの表記） 

#AWSSummit ● また、先に紹介した「技術的なお問い合わせに関するガイドライン」でも 触れられており、密接に関連した考え方と言えます Design for failure 20 @kazzpapa3 出典：技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ ）より抜粋 

#AWSSummit ● また、先に紹介した「技術的なお問い合わせに関するガイドライン」でも 触れられており、密接に関連した考え方と言えます Design for failure 21 @kazzpapa3 出典：技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ ）より抜粋 問い合わせに関するガイドラインでも触れているということは、 Design for Failure の考え方に立脚した回答が返ってくるということの裏返し 

#AWSSummit 有償サービス※ に対して SLA が提供されているが、 適用条件が定められている ※いわゆる GA しているサービス SLA、SLO を 正しく理解する 22 @kazzpapa3 出典：AWS Service Level Agreements (SLAs) ( https://aws.amazon.com/legal/service-level-agreements/ )より抜粋 

#AWSSummit ● AWS Service Level Agreements (SLAs) として公開されています ○ AWS では常に英語版ドキュメントが優先されますが、特に SLA のページは日本語版がほぼ古い SLA、SLO を正しく理解する 23 @kazzpapa3 

#AWSSummit ● AWS Service Level Agreements (SLAs) として公開されています ○ AWS では常に英語版ドキュメントが優先されますが、特に SLA のページは日本語版がほぼ古い ● 例えば EC2 では「インスタンスレベル」と「リージョンレベル」の２つ定義 されている ○ 単体でインスタンスを利用しているか、マルチ AZ で同時にデプロイしているかで異なる SLA、SLO を正しく理解する 24 @kazzpapa3 出典：AWS Service Level Agreements (SLAs) ( https://aws.amazon.com/legal/service-level-agreements/?nc1=h_ls&aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.s ort-order=asc&awsf.tech-category-filter=*all&aws-sla-cards.q=EC2&aws-sla-cards.q_operator=AND ) より抜粋 

#AWSSummit ● 障害が起こり得ない、起こるはずはない、起こってもらっては困る という考えを捨てる ● 事象発生時、影響を受けているリソースを捨て、 新たなリソースを作ることで速やかな復旧ができる設計をする ● そもそも AWS 自身が、 そのようにサービスを利用してもらうことを想定している これらドキュメントからわかること 25 @kazzpapa3 

#AWSSummit 26 @kazzpapa3 それぞれのお問い合わせを もう一度見てみる 

#AWSSummit AWS Health Dashboard に「影響 を受けたリソース」が記載されてい ます ただ、そもそも AWS サービスひと つひとつをつぶさにどれが正常だっ たか、異常だったサービスがなかっ たかを網羅的に知ることよりも、そ れらを活用して構築しているサービ スとして正常に稼働していたかの観 点の方が有用では？ ● 弊社のリソースで影響を受 けたものは？網羅的に案内 ください ● なぜ発生したのか？ AWS として再発防止策はど う考えている？ ● 世間では騒がれているよう ですが、弊社のリソースに は影響がありません @kazzpapa3 

#AWSSummit “ガイドライン” で見た通り 利用者側が Uncontrollable なも のに対しての情報開示が、お客 様の本質的な課題解決に影響し ない、と考えているため開示し ない、としている その背景として障害発生率の低 減に努めているが 0 にすること はできないと AWS 自身自認して いる “故障を前提とした設計” を推奨 ● 弊社のリソースで影響を受 けたものは？網羅的に案内 ください ● なぜ発生したのか？ AWS として再発防止策はど う考えている？ ● 世間では騒がれているよう ですが、弊社のリソースに は影響がありません @kazzpapa3 

#AWSSummit 世間がざわついていることから 疑心暗鬼になった例ではないか AZ 自体も物理建屋の集合体である と推定されるので、影響を受けな かったリソースもあったはず ただ、運用中のサービスやシステム にダウンタイムが発生せず、それが 設計の通りであったのであれば、そ れで良しでは？ ● 弊社のリソースで影響を受 けたものは？網羅的に案内 ください ● なぜ発生したのか？ AWS として再発防止策はど う考えている？ ● 世間では騒がれているよう ですが、弊社のリソースに は影響がありません @kazzpapa3 

#AWSSummit ● 弊社のリソースで影響を受けた ものは？網羅的に案内ください ● なぜ発生したのか？ AWS として再発防止策はどう考 えている？ ● 世間では騒がれているようです が、弊社のリソースには影響が ありません もしかしたら、今回の事象においては、 弊社（ひいては AWS テクニカルサポート）へ の 問い合わせが不要だったかもしれません 

#AWSSummit 31 @kazzpapa3 見かけた中で これは問い合わせしないと わからなかったな…という例 

#AWSSummit @kazzpapa3 ● お客様の提供サービスで 意図しないダウンタイムが発生 ● 設計上、単一障害点となりうるポ イントはすべて冗長化されている ● 客観的に見ても ベストプラクティスに沿っている ように見える 

#AWSSummit AWS テクニカルサポートへ問い合 わせたところ、あるサービスのコン トロールプレーン側で想定外の事象 が発生していた それに起因して発生してしまったと のこと （だいぶぼかして書いています） @kazzpapa3 ● お客様の提供サービスで 意図しないダウンタイムが発生 ● 設計上、単一障害点となりうるポ イントはすべて冗長化されている ● 客観的に見ても ベストプラクティスに沿っている ように見える 

#AWSSummit ● AZ 障害のような場合、採用している実装と発生した事象によっては 「やむを得ない」となるか「一大事となるか」が変わってくる ● ベストプラクティスや推奨される構成があらかじめ提示されている以上 問い合わせをしても、以下のようなベストプラクティスに沿うことを推奨する 案内が返ってくるのみに留まる可能性は十分考えられます 大変恐れ入りますが〇〇は、マルチ AZ 構成となるよう ご利用いただくことを推奨させていただいており… ● またどのような利用方法や設計をとっていても、 障害の詳細についての回答を得られないことは同一です ４例を見比べてみると 34 @kazzpapa3 

#AWSSummit 結論 35 @kazzpapa3 

#AWSSummit ● AWS が提供している「ガイドライン」を把握していることで、 より迅速な課題解決のためにどのような情報があれば良いかがわかるだけでな く、AWS が開示しない、回答しにくい回答範囲があることがわかる ベストプラクティスを正しく理解すると問い合わせ自体減らせる 36 @kazzpapa3 

#AWSSummit ● AWS が提供している「ガイドライン」を把握していることで、 より迅速な課題解決のためにどのような情報があれば良いかがわかるだけでな く、AWS が開示しない、回答しにくい回答範囲があることがわかる ● AWS が推奨する設計原則に沿っていると事象に見舞われる確率を下げること ができるとともに、そもそもそういった使い方を AWS が想定していることを あらかじめ知っておく ○ ベストプラクティスに沿っていない（予算などから沿わない判断をしてい るものを含む）場合、発生しうるものだと理解しておき、許容する ベストプラクティスを正しく理解すると問い合わせ自体減らせる 37 @kazzpapa3 

#AWSSummit ● AWS が提供している「ガイドライン」を把握していることで、 より迅速な課題解決のためにどのような情報があれば良いかがわかるだけでな く、AWS が開示しない、回答しにくい回答範囲があることがわかる ● AWS が推奨する設計原則に沿っていると事象に見舞われる確率を下げること ができるとともに、そもそもそういった使い方を AWS が想定していることを あらかじめ知っておく ○ ベストプラクティスに沿っていない（予算などから沿わない判断をしてい るものを含む）場合、発生しうるものだと理解しておき、許容する ● 実装や設計・発生した事象によっては問い合わせが不要とできる （結果的に問い合わせしても一緒）なケースは存在する ベストプラクティスを正しく理解すると問い合わせ自体減らせる 38 @kazzpapa3 

#AWSSummit 余談 Community Mini Stage なのでコミュニティについてちょっとだけ 39 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です コミュニティに参加するモチベーション（超主観） 40 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です ● そのため、いろいろなアーキテクチャや実装、設計について 成功事例も失敗事例も知りたい、というモチベーションで参加しています コミュニティに参加するモチベーション（超主観） 41 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です ● そのため、いろいろなアーキテクチャや実装、設計について 成功事例も失敗事例も知りたい、というモチベーションで参加しています ● 今回お話ししたような内容は AWS テクニカルサポートとお客様の間で感じる ギャップや違和感に由来していて、それをお伝えしたい気持ちもあります コミュニティに参加するモチベーション（超主観） 42 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です ● そのため、いろいろなアーキテクチャや実装、設計について 成功事例も失敗事例も知りたい、というモチベーションで参加しています ● 今回お話ししたような内容は AWS テクニカルサポートとお客様の間で感じる ギャップや違和感に由来していて、それをお伝えしたい気持ちもあります ○ ただ、コミュニティや勉強会にご自身の時間を割いて参加されている方は 私が呼びかけたいようなことはすでにできている・理解いただいている方がほとんど コミュニティに参加するモチベーション（超主観） 43 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です ● そのため、いろいろなアーキテクチャや実装、設計について 成功事例も失敗事例も知りたい、というモチベーションで参加しています ● 今回お話ししたような内容は AWS テクニカルサポートとお客様の間で感じる ギャップや違和感に由来していて、それをお伝えしたい気持ちもあります ○ ただ、コミュニティや勉強会にご自身の時間を割いて参加されている方は 私が呼びかけたいようなことはすでにできている・理解いただいている方がほとんど ○ 本当に呼びかけたいような方は残念ながら来ていただけていないことが多い気がしています コミュニティに参加するモチベーション（超主観） 44 @kazzpapa3 

#AWSSummit ● 私自身が従事するロールの特性から、特定の AWS サービスを能動的に活用す るというよりも、お問い合わせをいただいて初めて拝見する環境に対して、や や受動的に向き合っている感覚です ● そのため、いろいろなアーキテクチャや実装、設計について 成功事例も失敗事例も知りたい、というモチベーションで参加しています ● 今回お話ししたような内容は AWS テクニカルサポートとお客様の間で感じる ギャップや違和感に由来していて、それをお伝えしたい気持ちもあります ○ ただ、コミュニティや勉強会にご自身の時間を割いて参加されている方は 私が呼びかけたいようなことはすでにできている方がほとんど ○ 本当に呼びかけたいような方は残念ながら来ていただけていないことが多い気がしています ○ そのため、私の登壇に限らず、今回のイベント参加で何かしら参考になった点などあれば、 自組織に持ち帰ってそれとなく広めていただけると幸いです コミュニティに参加するモチベーション（超主観） 45 @kazzpapa3 

#AWSSummit 46 @kazzpapa3 Share your Lessons