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

2024年7月29日に開催された AWS Startup Meetup 大阪 ReBoot でお話しした際に使用したスライドです。
スタートアップ向けのイベントということもあり、「デベロッパー」プランや「ビジネス」プランを中心に解説するとともに、有償プランの「デベロッパー」プラン特有の注意点や、有償プラン全般にわたる注意点についてを解説しています。
また、マルチアカウント時代特有の注意点についても触れていますので、ご参考となれば幸いです。

Transcript

1. AWS Support のススメ - AWS パートナー企業のテクサポの中の⼈⽬線 - [AWS Startup Meetup ⼤阪 ReBoot] 株式会社サーバーワークス 市野 和明（JAWS-UG 神⼾） 2024-07-29
2. ⽬次 1. ⾃⼰紹介 2. 本題 3. 個⼈的な思い
3. ⾃⼰紹介
4. 4 はじめまして 名前︓市野 和明（いちの かずあき） 所属︓株式会社サーバーワークス マネージドサクセス部 テクニカルサポート課 好きな AWS サービス︓ AWS CLI （テクサポとして） 嫌いな AWS サービス︓ Amazon FSx for Windows 趣味︓ミクが好き、酒を飲む @kazzpapa3
5. 5 テクサポの中の⼈としての 恨みつらみ ベストプラクティス 以前、JAWS-UG 北陸新幹線 で登壇した際の資料が AWS テクニカルサポート内でプチバズりしたそうなのです。 私が普段サポート業務やってて思う、恨みつらみ もっとこうすればいいのに って思いを書いていますので、AWS に限らずなんらかのサポートに問い合わせ をするロールの⽅は⼀読いただけると嬉しいです。
6. 本題
7. 7 みなさん AWS Support はご利⽤されていますか︖
8. 8 みなさん AWS Support はご利⽤されていますか︖ 有料のデベロッパープラン以上をお使いの⽅︖
9. 9 プラン選択どうしよう︖ 重要度設定と応答速度の観点 プランにより選択できるケースの重要度が変わります。 https://aws.amazon.com/jp/premiumsupport/plans/
10. 10 プラン選択どうしよう︖ 費⽤⾯の観点 どのプランも最低請求額 or ⽉額 AWS 使⽤料に対するパーセンテージのどちらか⾼い⽅、という課⾦ https://aws.amazon.com/jp/premiumsupport/pricing/
11. 11 プラン選択どうしよう︖ 双⽅を考慮した上で、どちらをより重要視するか︖ が判断基準になるのかと思います 費⽤ 緊急度・ 応答速度
12. 12 プラン選択どうしよう︖ 双⽅を考慮した上で、どちらをより重要視するか︖ が判断基準になるのかと思います おそらくスタートアップの皆様であれば 「デベロッパー」か「ビジネス」どちらにしようか︖という選択となるのでは︖
13. 13 「デベロッパー」プランの留意点 ケースの重要度で「本番」システムに対して起きている障害を選択できない https://aws.amazon.com/jp/premiumsupport/plans/
14. 14 「デベロッパー」プランの留意点 ケースの重要度で「本番」システムに対して起きている障害を選択できない 営業時間の概念がある https://aws.amazon.com/jp/premiumsupport/plans/
15. 全プラン共通の留意事項 ところで、AWS サポートにも SLO があります
16. 16 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定があります 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
17. 17 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることには注意が必要 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
18. 18 例えば ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 エンタープライズプランを契約しているお客様で、 「ミッションクリティカルなシステムのダウン」を選択したときには、 おおむね 15分以内には初回の回答をもらえることとなります。 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
19. 19 ただし… ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 ただし SLO は初回応答のみで、2ターン⽬以降には設定がない 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
20. どのアカウントでサポート契約をしておくのが良いか
21. 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. 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
23. クロスアカウントでのサポートを 受けられないという現実
24. 24 クロスアカウントについての⾔及 AWS サポート「よくある質問」ページに以下の⾔及があります https://aws.amazon.com/jp/premiumsupport/faqs/?nc=sn&loc=6
25. 25 クロスアカウントについての⾔及 リソースを保有するアカウントからの問い合わせのみ応答をすると⾔及 https://aws.amazon.com/jp/premiumsupport/faqs/?nc=sn&loc=6 サポートエンジニアには、(1 つのアカウントのユーザーまたはロールの下で⾏動している)誰かが、 別のアカウントにあるリソースへのアクセス許可を付与されたかを判断する⽅法がありません。 セキュリティとプライバシーの懸念があるため、具体的な詳細については、該当するリソースのアカウント所 有者とだけお話しさせていただきます。
26. よくある事例
27. 27 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している
28. 28 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している
29. 29 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している 同様の構成をとっている開発アカウントでは事象が再現しない
30. 30 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している 同様の構成をとっている開発アカウントでは事象が再現しない この状況で、開発アカウントでのみ 「デベロッパー」プランを契約していた場合
31. 31 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している 同様の構成をとっている開発アカウントでは事象が再現しない この状況で、開発アカウントでのみ 「デベロッパー」プランを契約していた場合 本番アカウントで発⽣していることを問い合わせできない
32. 32 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している 同様の構成をとっている開発アカウントでは事象が再現しない 本番アカウントで発⽣していることを問い合わせできない 開発アカウントでは事象の再現ができないため 開発アカウントのリソースとしても問い合わせもできない この状況で、開発アカウントでのみ 「デベロッパー」プランを契約していた場合
33. 33 対応していてよく⾒かける光景 本番アカウント、開発アカウントの2つを保有している 本番アカウント内で AWS 起因と⾒られる障害が発⽣している 同様の構成をとっている開発アカウントでは事象が再現しない 本番アカウントで発⽣していることを問い合わせできない 開発アカウントでは事象の再現ができないため 開発アカウントのリソースとしても問い合わせもできない そもそも論、双⽅のアカウントの物理基盤が違う、物理的な AZ が異なる ことが考えられ、双⽅のアカウントの条件が異なる可能性は⼤きい 同じように⾒えるエラーが異なる要因が原因である可能性は否定できない この状況で、開発アカウントでのみ 「デベロッパー」プランを契約していた場合
34. 34 結局 保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましい
35. 35 結局 保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましい ただし、アカウントの性質（内包するワークロードの重要度など）によっては、 アカウントごとにプランのレベルを変える選択肢はありうる 本番環境は「ビジネス」プラン 開発環境やステージング環境は「デベロッパー」プラン など
36. 36 結局 保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましい ただし、アカウントの性質（内包するワークロードの重要度など）によっては、 アカウントごとにプランのレベルを変える選択肢はありうる 本番環境は「ビジネス」プラン 開発環境やステージング環境は「デベロッパー」プラン など ビジネスを守りたい、迅速な復旧が必要、など 顧客やビジネスを守るための必要費⽤と認識する⽅が良い
37. 37 結局 保有するアカウントには、何らかの有償サポートプランがあった⽅が望ましい ただし、アカウントの性質（内包するワークロードの重要度など）によっては、 アカウントごとにプランのレベルを変える選択肢はありうる 本番環境は「ビジネス」プラン 開発環境やステージング環境は「デベロッパー」プラン など ビジネスを守りたい、迅速な復旧が必要、など 顧客やビジネスを守るための必要費⽤と認識する⽅が良い そのためビジネスオーナーの正しい理解を得て、 費⽤を勝ち得るように働きかけることが望ましい
38. 個⼈的な思い
39. 個⼈的な体感
40. 40 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神
41. 41 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象
42. 42 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象 ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの 最上位の緊急度を選択すると⼀気に豹変
43. 43 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象 ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの 最上位の緊急度を選択すると⼀気に豹変 〇〇はどうでしょう︖
44. 44 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象 ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの 最上位の緊急度を選択すると⼀気に豹変 〇〇はどうでしょう︖ △△のログ提供を︕
45. 45 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象 ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの 最上位の緊急度を選択すると⼀気に豹変 〇〇はどうでしょう︖ △△のログ提供を︕ □□をお試しください︕
46. 46 好きな AWS サービスに AWS Support を挙げていないものの AWS のサポートエンジニアはマジ神 通常の緊急度程度では、しっかり調査して、 極⼒、⼀回の回答で課題解決を⽬指す返答をもらえているなぁと、いう印象 ただし、「ビジネス/ミッションクリティカルなシステムのダウン」などの 最上位の緊急度を選択すると⼀気に豹変 〇〇はどうでしょう︖ △△のログ提供を︕ □□をお試しください︕ 上記のように考えられる可能性・観点が⽮継ぎ早に⾶んでくる その連絡に圧倒されて、問い合わせ者側でもそれ相応の対応速度が求められる ただ、考えられる観点を、おそらく優先順位をつけて案内くれるので ビジネスの復旧速度は半端ない
47. AWS さんのオフィス内で、あまり⼤きな声では⾔えないが… なるべくサポートに頼らなくても済む⽅法（超主観）
48. 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
49. 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
50. 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
51. 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. 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. 53 このような質問の背景には… 障害が起こるはずがない、起こってもらっては困る という考えが根底にあるのでは︖ 正常な状態が保持され続けることを前提にしている可能性がある 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/
54. 54 このような質問の背景には… AWS が管理する範囲は責任を持って管理してもらわないと困る
55. 55 このような質問の背景には… AWS が管理する範囲は責任を持って管理してもらわないと困る 管理の責任と説明や情報開⽰については、 「技術的なお問い合わせに関するガイドライン」に記載の以下の考え⽅が重要 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/
56. 56 おわりに クラウドならではの設計思想に基づいて 適切なサポートプランを契約して より良い AWS ライフを︕