AWS Support のススメ- AWS パートナー企業のテクサポの中の人目線 -

AWS Support のススメ - AWS パートナー企業のテクサポの中の⼈⽬線 - [AWS Startup Meetup
⼤阪 ReBoot] 株式会社サーバーワークス市野和明（JAWS-UG 神⼾） 2024-07-29

⽬次 1. ⾃⼰紹介 2. 本題 3. 個⼈的な思い

⾃⼰紹介

4 はじめまして名前︓市野和明（いちのかずあき）所属︓株式会社サーバーワークスマネージドサクセス部テクニカルサポート課好きな AWS
サービス︓ AWS CLI （テクサポとして）嫌いな AWS サービス︓ Amazon FSx for Windows 趣味︓ミクが好き、酒を飲む @kazzpapa3

5 テクサポの中の⼈としての恨みつらみベストプラクティス以前、JAWS-UG 北陸新幹線で登壇した際の資料が AWS テクニカルサポート内でプチバズりしたそうなのです。私が普段サポート業務やってて思う、恨みつらみ
もっとこうすればいいのにって思いを書いていますので、AWS に限らずなんらかのサポートに問い合わせをするロールの⽅は⼀読いただけると嬉しいです。

本題

7 みなさん AWS Support はご利⽤されていますか︖

8 みなさん AWS Support はご利⽤されていますか︖ 有料のデベロッパープラン以上をお使いの⽅︖

9 プラン選択どうしよう︖ 重要度設定と応答速度の観点プランにより選択できるケースの重要度が変わります。 https://aws.amazon.com/jp/premiumsupport/plans/

10 プラン選択どうしよう︖ 費⽤⾯の観点どのプランも最低請求額 or ⽉額 AWS 使⽤料に対するパーセンテージのどちらか⾼い⽅、という課⾦ https://aws.amazon.com/jp/premiumsupport/pricing/

11 プラン選択どうしよう︖ 双⽅を考慮した上で、どちらをより重要視するか︖ が判断基準になるのかと思います費⽤緊急度・応答速度

12 プラン選択どうしよう︖ 双⽅を考慮した上で、どちらをより重要視するか︖ が判断基準になるのかと思いますおそらくスタートアップの皆様であれば「デベロッパー」か「ビジネス」どちらにしようか︖という選択となるのでは︖

13 「デベロッパー」プランの留意点ケースの重要度で「本番」システムに対して起きている障害を選択できない https://aws.amazon.com/jp/premiumsupport/plans/

14 「デベロッパー」プランの留意点ケースの重要度で「本番」システムに対して起きている障害を選択できない営業時間の概念がある https://aws.amazon.com/jp/premiumsupport/plans/

全プラン共通の留意事項ところで、AWS サポートにも SLO があります

16 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定があります「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

17 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定がありますただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることには注意が必要「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

18 例えば⽬安となる初回応答時間の設定がありますただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることにも注意が必要エンタープライズプランを契約しているお客様で、「ミッションクリティカルなシステムのダウン」を選択したときには、おおむね 15分以内には初回の回答をもらえることとなります。「AWS
サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

19 ただし… ⽬安となる初回応答時間の設定がありますただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることにも注意が必要ただし SLO は初回応答のみで、2ターン⽬以降には設定がない「AWS サポート
プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

どのアカウントでサポート契約をしておくのが良いか

21 昨今のベストプラクティス⼤昔、単⼀の AWS アカウント内に VPC を分離して、開発環境、本番環境などの環境を同居させて管理する⼿法が⼀般的でした AWS Cloud
Virtual private cloud (VPC) Private subnet Public subnet Virtual private cloud (VPC) Private subnet Public subnet Virtual private cloud (VPC) Private subnet Public subnet Develop env. Staging env. Production env.

22 昨今のベストプラクティス⼤昔、単⼀の AWS アカウント内に VPC を分離して、開発環境、本番環境などの環境を同居させて管理する⼿法が⼀般的でしたただ、現在では、AWS アカウント⾃体を⽤途別に分離し管理する
マルチアカウントが推奨されています。 AWS Cloud Virtual private cloud (VPC) Private subnet Public subnet Develop account AWS Cloud Virtual private cloud (VPC) Private subnet Public subnet Staging account AWS Cloud Virtual private cloud (VPC) Private subnet Public subnet Production account

クロスアカウントでのサポートを受けられないという現実

24 クロスアカウントについての⾔及 AWS サポート「よくある質問」ページに以下の⾔及があります https://aws.amazon.com/jp/premiumsupport/faqs/?nc=sn&loc=6

25 クロスアカウントについての⾔及リソースを保有するアカウントからの問い合わせのみ応答をすると⾔及 https://aws.amazon.com/jp/premiumsupport/faqs/?nc=sn&loc=6 サポートエンジニアには、(1 つのアカウントのユーザーまたはロールの下で⾏動している)誰かが、別のアカウントにあるリソースへのアクセス許可を付与されたかを判断する⽅法がありません。セキュリティとプライバシーの懸念があるため、具体的な詳細については、該当するリソースのアカウント所有者とだけお話しさせていただきます。

よくある事例

27 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している

28 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している

29 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している同様の構成をとっている開発アカウントでは事象が再現しない

30 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している同様の構成をとっている開発アカウントでは事象が再現しないこの状況で、開発アカウントでのみ「デベロッパー」プランを契約していた場合

31 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している同様の構成をとっている開発アカウントでは事象が再現しないこの状況で、開発アカウントでのみ「デベロッパー」プランを契約していた場合本番アカウントで発⽣していることを問い合わせできない

32 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している同様の構成をとっている開発アカウントでは事象が再現しない本番アカウントで発⽣していることを問い合わせできない開発アカウントでは事象の再現ができないため開発アカウントのリソースとしても問い合わせもできない
この状況で、開発アカウントでのみ「デベロッパー」プランを契約していた場合

33 対応していてよく⾒かける光景本番アカウント、開発アカウントの2つを保有している本番アカウント内で AWS 起因と⾒られる障害が発⽣している同様の構成をとっている開発アカウントでは事象が再現しない本番アカウントで発⽣していることを問い合わせできない開発アカウントでは事象の再現ができないため開発アカウントのリソースとしても問い合わせもできない
そもそも論、双⽅のアカウントの物理基盤が違う、物理的な AZ が異なることが考えられ、双⽅のアカウントの条件が異なる可能性は⼤きい同じように⾒えるエラーが異なる要因が原因である可能性は否定できないこの状況で、開発アカウントでのみ「デベロッパー」プランを契約していた場合

34 結局保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましい

35 結局保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましいただし、アカウントの性質（内包するワークロードの重要度など）によっては、アカウントごとにプランのレベルを変える選択肢はありうる本番環境は「ビジネス」プラン開発環境やステージング環境は「デベロッパー」プランなど

36 結局保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましいただし、アカウントの性質（内包するワークロードの重要度など）によっては、アカウントごとにプランのレベルを変える選択肢はありうる本番環境は「ビジネス」プラン開発環境やステージング環境は「デベロッパー」プランなどビジネスを守りたい、迅速な復旧が必要、など顧客やビジネスを守るための必要費⽤と認識する⽅が良い

37 結局保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましいただし、アカウントの性質（内包するワークロードの重要度など）によっては、アカウントごとにプランのレベルを変える選択肢はありうる本番環境は「ビジネス」プラン開発環境やステージング環境は「デベロッパー」プランなどビジネスを守りたい、迅速な復旧が必要、など顧客やビジネスを守るための必要費⽤と認識する⽅が良い
そのためビジネスオーナーの正しい理解を得て、費⽤を勝ち得るように働きかけることが望ましい

個⼈的な思い

個⼈的な体感

40 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神

41 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神通常の緊急度程度では、しっかり調査して、
極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象

極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変

極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖

極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖ △△のログ提供を︕

極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖ △△のログ提供を︕ □□をお試しください︕

極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖ △△のログ提供を︕ □□をお試しください︕ 上記のように考えられる可能性・観点が⽮継ぎ早に⾶んでくるその連絡に圧倒されて、問い合わせ者側でもそれ相応の対応速度が求められるただ、考えられる観点を、おそらく優先順位をつけて案内くれるのでビジネスの復旧速度は半端ない

AWS さんのオフィス内で、あまり⼤きな声では⾔えないが… なるべくサポートに頼らなくても済む⽅法（超主観）

48 クラウドに合わせた設計をそもそもホワイトペーパーで Design for failure と⾔っている “Everything fails all
the time.” – Werner Vogels Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

the time.” – Werner Vogels 障害が起こり得ない、起こるはずはない、起こってもらっては困るという考えを捨てる Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

the time.” – Werner Vogels 障害が起こり得ない、起こるはずはない、起こってもらっては困るという考えを捨てる事象発⽣時、影響を受けているリソースを捨て、新たなリソースを作ることで速やかな復旧ができる設計をする。 Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

51 ⼀定数いただくお問い合わせインスタンスステータスチェックで、「StatusCheckFailed_System」が起こったのはなぜか︖ AWS として、この問題を引き起こさない具体的な改善策を提⽰してほしい Status checks for Amazon
EC2 instances https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

52 ⼀定数いただくお問い合わせインスタンスステータスチェックで、「StatusCheckFailed_System」が起こったのはなぜか︖ AWS として、この問題を引き起こさない具体的な改善策を提⽰してほしいインスタンスの retirement を知らせる通知が来た期⽇の延期をしてほしい
そもそも、retirement が起きないようにしてほしい Status checks for Amazon EC2 instances https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html Instance retirement https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html

53 このような質問の背景には… 障害が起こるはずがない、起こってもらっては困るという考えが根底にあるのでは︖ 正常な状態が保持され続けることを前提にしている可能性がある技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

54 このような質問の背景には… AWS が管理する範囲は責任を持って管理してもらわないと困る

55 このような質問の背景には… AWS が管理する範囲は責任を持って管理してもらわないと困る管理の責任と説明や情報開⽰については、「技術的なお問い合わせに関するガイドライン」に記載の以下の考え⽅が重要技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

56 おわりにクラウドならではの設計思想に基づいて適切なサポートプランを契約してより良い AWS ライフを︕

AWS Support のススメ- AWS パートナー企業のテクサポの中の人目線 -

AWS Support のススメ- AWS パートナー企業のテクサポの中の人目線 -

More Decks by kazzpapa3

Other Decks in Technology

Featured

Transcript