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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

⾃⼰紹介

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

本題

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

よくある事例

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

個⼈的な思い

Slide 39

Slide 39 text

個⼈的な体感

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

42 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神通常の緊急度程度では、しっかり調査して、極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変

Slide 43

Slide 43 text

43 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神通常の緊急度程度では、しっかり調査して、極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖

Slide 44

Slide 44 text

44 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神通常の緊急度程度では、しっかり調査して、極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖ △△のログ提供を︕

Slide 45

Slide 45 text

45 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神通常の緊急度程度では、しっかり調査して、極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの最上位の緊急度を選択すると⼀気に豹変〇〇はどうでしょう︖ △△のログ提供を︕ □□をお試しください︕

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

49 クラウドに合わせた設計をそもそもホワイトペーパーで 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

Slide 50

Slide 50 text

50 クラウドに合わせた設計をそもそもホワイトペーパーで 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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

No content