【レポート】【初級】クラウドを検討し始めたばかりのお客様より AWS へよく頂く質問と考え方 #AWSSummit

1. Introduction

• AWSを検討し始めのお客様に知ってほしいこと＝「アマゾンのイノベーションを支えるカルチャー」
  • これを理解しているorいないで技術相談の進み方が大きく違うと登壇者の方は実感

Our Vision:

Amazonのはじまり

1. 顧客体験を提供
2. トラフィックの増加
3. 売り手の増加
4. 品揃えの増加

上記１〜４がループする＋低コスト構造、低価格化への取り組み＝また新たな顧客体験に繋がる

• AWSにはすぐに使える165を超えるサービスが提供されている
  • 提供のスピードは早い
  • お客さまの声による新サービス提供と機能改善を行なっている
  • 90%以上はお客様の声がもとになっているサービス！

AWSが行なっている新機能開発プロセスの進め方について

Working Backwards

• お客様を起点に、そこからプロダクトに向かって考えるようにしている
• ここで重要なのはプレスリリースを先に書くこと
• プレスリリースを先にかき、FAQをまとめ、顧客体験を詳細に詰める
• 通常のようにプレスリリースを最後に作っていると
  • プレスリリースのための開発が長引くと目的がわからなくなってしまう

プレスリリースから書き始めることで目的を見失わず、最後まで顧客体験に沿ったプロセスが進められる

Working Backwards 5 questions

1. お客様は誰ですか？
2. そのお客様のもつ課題や新しいチャンスは何ですか？
3. もっとも重要な顧客に提供できる価値は明確ですか？
4. どのお客様が必要としているか知っていますか？
5. 顧客体験はどう変わりますか？

2. AWSのサービスの機能に関するご質問

例：Amazon FSx for Windowsファイルサーバを構築した後で、ストレージ容量を変更可能か？

A. 構築初期に容量を指定することは可能ですが、構築したあとで変更できません。

• お客様によってはこの回答に少しがっかりするかもしれない

上記のカルチャーを元にこの質問について考えてみると、以下のような考え方も可能

1. 現時点ではできないけれど、近い将来提供される可能性はあり
2. 他のAWSサービスで代替できるかもしれない

サポートとしては回答をもらって終わりなのではなく、お客様の用途・要件を伺った上で解決に向けたディスカッションをしたい

• 回答のみを求めるお客様であると、上記についてディスカッションできないケースも
• 非常に勿体無いため、個別相談などを行い一緒に改善に向けてのプロセスを回させて頂きたい

関連するAWSのサービスを理解することの大切さ

• 例に出てきた FSx から派生するサービスだけでも下記のようにたくさんある
  • リージョン
  • VPC
  • S3
  • AD Service
  • DX
  • VPN gateway
  • EC2
  • etc...

お客様のAWSについての理解度も重要なファクター

3. AWS上のセキュリティに関するご質問

例：AWS上に個人情報（重要な情報）を置いている事例はありますでしょうか？

A. 事例の紹介は可能

そもそもの話として、セキュリティはAWSにおける最優先事項

• セキュリティはお客様との責任共有モデル
• AWS担当範囲は多くの第三者期間認証を取得している
• 日本では数十万を超えるお客様がAWS上でシステムを構築している

4. AWS上のお客様のシステムの構成・コストに関するご質問

例：「EC2インスタンスタイプはm5.large（2vCPU, 8GiBメモリ）で大丈夫でしょうか？」

A. アプリケーションによって必要なスペックは異なる、負荷テストを行なっていただき、必要なスペックをご確認ください。

• 人によっては面倒な回答だと感じるかもしれない

アマゾンにおけるカルチャーの考え方をもう一つ紹介

「Is it a one-way or a two-way door decision?（一度決めると後戻りができない決定なのか？後戻りができる決定なのか？）」

• 後戻りができるケースである事が多いはず
• 組織の都合で後戻りができない場合も存在する
  • ただ、そういった文化はイノベーション進めにくい組織となってしまう
• オンプレミスならone-wayだったかもしれないが、AWSは従量課金、サーバースペックの変更ができるため後戻りしやすい

実験を許容する文化

「もしAmazonが、より大きな失敗をしていなければ、それは長期的には危険な兆候です。」（Amazon創業者の言葉）

• AWSは失敗のリスクを小さくする仕組みを提供している
• 必要な時に必要なだけ、低価格で使える
• 従量課金についても継続的な値下げを行なっている、72回の自主的な値下げを実施
• これらはサービスの個々の料金をお客様に限りなく還元するため

例：「構成の料金はいくらでしょうか？」

• AWS Simple Monthly Calculatorをオススメ
• インスタンスのスペックや台数に基づいた見積もりに有用
• ただし全てのサービスに対応しているわけではない

AWSは従量課金制のため、まずはスモールスタートで使ってみて、少量の課金で利用内訳を確認してみる

例：「どのAWSのサービスを使ったら良いかわからない」

• 顧客体験を起点に、そこからAWSのサービスに向かって考える
• 顧客体験を良くするには、どのAWSのサービスを使うべきかを検討する

DB選定による例

• 開発者が慣れていたという理由でRDSを選定したシステム（と仮定）
• リリース当初は問題なかった

• ユーザの増加にともない、3年後にスケールアップまたはスケールアウトする必要が出てきてしまった
  • スペックが上がるとコストも上がってしまう
  • RDSのスペック変更はダウンタイムも発生してしまう

そもそも

• 最初に顧客体験を元にデータベース選択していた？
• 今までのスキルやRDBの便利さだけを考えるのではなく、顧客体験に基づいてAWSのデータベースサービスを選択してほしい
• 例えばDynamoDB

クラウドにおけるアーキテクチャの設計原則（一部抜粋）

• スケーラビリティ
• サーバではなく、サービスの利用　マネージドサービスの活用
• ワークロードに最適なデータベースの選定
• 単一障害点の排除

例；「AWS上のシステム構成案を作成しました！この構成で良いでしょうか？」

• 素晴らしいことです！ぜひ個別相談会でご相談ください
• その際には、顧客体験に基づいたディスカッションをさせていただきたい

個別相談会に参加できない。。

• W-A Frameworkをオススメ
  • システム設計・運用の大局的な考え方とベストプラクティス集