AWSがわかる人になる

はじめに

AWSがさわれる人と、AWSがわかる人（設計できる人）の違いについて考える機会があったので、それを記事にしてみました。
SRE視点寄りの内容であることをご理解ください。

プロダクトを知る

最適なアーキテクチャを導き出すにはプロダクトを理解する必要があります。例えば、無料会員の割合が多いプロダクトでユーザ数課金のサービスを導入すると、利益率に影響を与える恐れがあります。

• 会員数の推移
• 無料会員と有料会員の比率
• 無料会員でも収益に繋がる or 有料会員になってはじめて収益に繋がるのか？
• 会員あたりが持つデータ量
• レイテンシがどの程度ユーザ体験に影響を及ぼすか
• ユーザーがサービスを一番使う時間帯はあるか（偏りはあるか）

開発組織を知る

チームの割り方によって、どのレイヤーをどのチームが管理するのかが変わります。
例えば、開発チームとインフラチームが分かれているかどうか。牽制目的でチームを分けている場合、インフラチームは安全弁的な役割が求められていることが多いでしょう。
組織体制やガードレールについて常に考えることで、より適切なAWSアカウント分割設計やCI/CDパイプライン設計が可能になります。

AWSサービスを知る

基本情報技術者試験やTCP/IPなどを理解することが大切です。プロトコルの限界は、AWSサービスの限界でもあります。
これらの基礎を理解していないと、過度な期待をしてしまったり、サポートに毎回問い合わせることになり、非効率です。

また、AWSには、似た機能を提供するサービスが複数存在します。それらがどのような背景で提供されるに至ったのかを調べたり考える習慣を身につけるとよいでしょう。
下図はAWS公式が公開しているMQとSQSの使い分けチャートです。

AWSサービスのアプデ内容を知る

AWSサービスは日々アップデートされており、昨日までのベストプラクティスが、ある日突然バッドプラクティスになる可能性があります。
下記のような観点を持ち、日々のアップデートに向き合うことで、より柔軟で最適なアーキテクチャを考案できるようになります。

• 新機能がどういった背景から実装されたのか？
• 新機能により既存のアーキテクチャをどう改善できるか？

さいごに

何から手をつけるべきかで言えば、まずはBlack Beltの資料を読みつつサービスを触る、でいいと思います。楽しいと思えることからはじめましょう💪

Appendix

AWSのみではなくより広い話であれば、こちらのスライドも参考になるかもしれません。
ソフトウェアエンジニアと技術力 / developer-lifework

AWSとの向き合い方の参考になる資料も貼っておきます。ビルディングブロック、カスタマーオブセッションという考え方は、AWSを触るうえでとても大事な価値観です。
Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate