はじめに
合格しました
というわけで合格体験記です。こういうの一度書いてみたかったんだ
とはいえ勉強法に関する良質な記事はすでにたくさんありますし、私自身も「実務経験＋参考書＋問題集」という王道ド真ん中を通ってきたため、新しそうなことを書ける感じはしません。困った
で、少し違った視点から何か役立ちそうなトピックがないかと考えまして、今回は、
「Well-Architectedも一緒に勉強するといいってみんな言うけど、実際どの部分がどんな感じで試験に役に立つの？」
「そもそもWell-Architectedって何？」
という観点からまとめてみたいと思います。
Well-Architected Frameworkとは
AWS公式が提供する、AWSを利用する上でのベストプラクティス集です。
「これに則って実装すればOK！」 というものではなく、 あくまでも「作ったものはベストプラクティスに沿っているか」「沿っていない時は、なぜ沿っていないのか（意図的なのか、考慮漏れなのか）」を検討するための指針となります。
どう役に立ったのか
AWS SAA（ソリューションアーキテクト - アソシエイト）試験では、Well-Architected Frameworkの「5つの柱」にもとに問題が出題されています。
AWS 認定ソリューションアーキテクト – アソシエイトの認定では、顧客要件に合わせて AWS の Well-Architected ソリューションを設計およびデプロイする際に必要となる能力を備えていることを確認します。
また、SAA-C02の試験ガイドにおいても、テスト分野として5つの柱（から運用上の優秀性の柱を除いたもの）をベースにしたテスト分野が紹介されています。
つまり、AWS SAAを参考書等で勉強をすることでWell-Architectedに沿ったシステム構築ができるようになり、一方でWell-Architectedを理解することで、AWS SAAの出題に対して「なぜその選択肢がベストプラクティスなのか」という観点で解答できるようになる、という相互の関係があります。
ここでは例として、「テスト環境を作りたい」というシチェーションへの対応を考えてみます。
これに関連するWell-Architected Frameworkの項目は以下のページです。
コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。
「複数の環境を使用する」の項では、本番に近い環境をIaC（Infrastructure as Code）で作成してテストすることが推奨されており、あわせて運用上のポイントやメリットについても説明されています。また、この項の関連項目としてCloudFormationが紹介されています。
もちろん参考書や問題集を何周かすれば難なく答えにたどり着けるような例ではありますが、
- 参考書：CloudFormationの機能がわかる
- 問題集：CloudFormationを使うシチュエーションがわかる
- Well-A：ベストプラクティスとしてCloudFormationを使うべき理由がわかる
の3点セットで覚えられるとよく定着しますし、試験中に思い出すためのきっかけにもなりますし、何より確信をもって解答できるようになるため、大変自信につながります。ここが一番の役立ちポイントだったかと思います。
Well-Architectedの5つの柱と試験分野
ここからはWell-Architected Frameworkと試験分野について、関連するAWSサービスを抜粋しながら紹介していきます。
私なりの解釈で噛み砕いた内容のため、一部ざっくりしすぎて不正確な点があるかもしれません。予めご了承ください。
運用上の優秀性の柱
組織の構築などマネジメント側の話も多い柱ですが、アーキテクトの観点から身も蓋もない表現をするならば 「いかに運用をラクにするか」 という話がこの柱の主な話題になるかと思います。
手間を省いたり、障害を防止したり、安全にテストをしたりするにはどうするのがよいのか、という分野になります。
Well-Architectedの「設計原則」から引用すると "運用をコードとして実行する" 、すなわちCloudFormationやOpsWorksなどのIaCなどがこの柱のポイントとして挙げられています。
また、Elastic Beanstalkなどを使用して環境構築の手間を省いたりする話もこのカテゴリに含まれています。
デプロイ管理システムを使用して変更を追跡および実装します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力が減ります。
「労力が減ります。」 いい言葉ですね。労力が減ることで 仕事をしなくて済む より価値のある作業に人的リソースを割り当てられる というような表現は、AWSの資料では頻繁に見かけるイメージがあります。
そのほか、障害検知（Well-Architectedでは「ワークロードの正常性の把握」といったりする）の観点で、CloudWatchやCloudTrailなども関連サービスとして名前が出てきます。
ちゃんとログを取り、ちゃんと障害検知を仕掛けておけば、のちのち何か起きたときに面倒なことにならなくて済むと考えれば、これも一種の労力の削減でしょうか。
なお、運用上の優秀性の柱に関してはSAA-C02のテスト分野に対応するカテゴリが無いので、配点上はどこか別の分野に吸収されているものと思われます。さよなら……
セキュリティの柱 / セキュアなアプリケーションとアーキテクチャの設計
「セキュリティ要件への準拠」「ストレージと転送データの暗号化」「リソースの権限管理」といった内容の柱です。
非常に範囲が広く勉強が大変な分野ですが、幸いWell-Architectedの上記ページではプラクティスごとに関連項目としてサービスが紹介されていますし、内容も一問一答といった粒度のためいくらか飲み込みやすくなっています。
それでもセキュリティのためのサービスとしてWAF, GuardDuty, ACM, KMS, Shield, IAMなどを押さえたうえで、セキュリティ関連の設定についてS3, RDS, EBS, ALB, VPC, CloudFrontなどなどへの個別への対応も考えないといけない分野ではありますので、それはそれはもう巨大な知識領域になります。
（個別にAWS Certified Security - Specialtyの試験ができるのも納得ですね……）
あとは実際の構成例として「適切なユーザーにのみデータを配信する方法」などもこのカテゴリに入るかと思います。
例えば いにしえの呪文「直リン禁止です！」 は、WAFでリファラ制限をかけて画像リンクを外部から利用できないようにするといった方法で対応可能です。例えが古すぎますかね？
ともかく繰り返しになりますが、範囲が広く、それでいて実践的な分野ですので、Well-Architectedと参考書の合わせ技でしっかり習得できればAWSの活用の幅がかなり広がってくるかと思います。
信頼性の柱 / レジリエントアーキテクチャの設計
「可用性」「フェイルオーバー」などがキーワードになる柱です。早い話が分散させたりスケールさせたりしましょうね、という内容です。
分散やスケールというと、Route 53のフェイルオーバールーティングやELBとAuto Scalingの組み合わせ、RDSのマルチAZ構成にAurora Serverless などが思い浮かぶところですが、Well-Architected FrameworkではSQSが頻繁に登場してくる印象があります。
「データが壊れる」「サーバーが落ちる」以上に、「メッセージ（処理の命令）が失われる」というトラブルは頻発します。「SNSからLambdaに連係したがLambdaが3連続でエラーを吐いた」とか、「DynamoDBのキャパシティに引っかかって書き込みがコケた」とか、「たまたまプライマリが落ちてセカンダリへ切り替えているタイミングだった」とか、「スケールが間に合わなかった」とか、とにかくあちこちでメッセージはロストします。
そんなときでも、メッセージを一度SQSに入れておくことで、処理に失敗したメッセージをキューに保持して再試行したり、後続処理だけスケールして性能低下を防いだりといった手段で信頼性を高められる、というメリットがあります。
さすが最古のAWSサービスとでもいうべきか、ベストプラクティスな設計の中心にはしばしばSQSが存在しているようです。
また、「壊れる前に検知する」「壊れたときに復旧しやすくする」という観点で、CloudWatchやX-Rayなどの利用もこの柱では推奨されています。
パフォーマンス効率の柱 / 高パフォーマンスアーキテクチャの設計
「レイテンシー」「オートスケーリング」「キャッシュ」あたりがこの柱のキーワードです。必要な性能を実現するために、適切なサービスを必要な分だけ使いましょうというテーマです。
このあたりはセキュリティの柱と同じく、Well-Architected Frameworkでサービス名を挙げながら細かく触れられている部分ですので、「試験対策としてのWell-Architected」の効果が高い部分ではないか思います。
（そして、セキュリティの柱と同じく範囲がデカいです。）
ところで、パフォーマンスとコストのバランスをどう取っていくかという点は実際の設計でもしばしば話題に上がるところです。費用を安く抑えるためのポイントは次の「コスト最適化の柱」で触れられますが、一方で小規模な開発ではなかなか出番のないような高額で高性能なサービス（ElastiCacheやDynamoDB Acceleratorなど）の出番を学べるのがこの「パフォーマンス効率の柱」でもあります。
コスト最適化の柱 / コスト最適化アーキテクチャの設計
お安くAWSを使うためのノウハウが詰まった柱です。みんな大好きコスト最適化。
Well-Architected Frameworkでは「使う分だけ払う」「使う量が分かっている時は先払いで割引を受ける」という観点で、（主にEC2の）オートスケーリングとキャパシティー予約について触れられています。そのほか、Organizationの一括請求や、マネージドサービスの活用による 「人的コスト」の削減 などもこの柱の話題です。
このあたりの話は、他の柱と内容が重複している部分も多いのかなというように感じます。
人的コストの削減は「運用上の優秀性の柱」と近いものがありますし、EC2のオートスケーリングは「信頼性の柱」「パフォーマンス効率の柱」でも触れられている内容です。
あるAWSサービスに対して複数の観点からメリットや意義を説明できるようになる（例：Auto Scalingについて「可用性」「パフォーマンス」「コスト」の観点で説明できるようになる）という点は、Well-Architectedが試験準備に役立つ大きなポイントかと思います。
また、1つの「やりたいこと」に対して複数のアーキテクチャを比較検討するという観点もコスト最適化やパフォーマンス効率での重要なポイントです。
RDSの性能が足りていないとひとくちで言っても、解決策として垂直スケーリングする、リードレプリカを配置する、Auroraに移行する、ElastiCacheを導入するなどさまざまな方法を取ることができます。
その中から「要件（コスト・性能・耐久性など）に合わせて検討し、適切な方法を選びましょう」というのがWell-Architectedの重要なテーマであり、そして試験で問われる部分でもあります。
おわりに
というわけで、Well-Architected Frameworkを読んでおくと、
- AWSのベストプラクティスを踏まえた設計が分かる
- ユースケースごとに関連するサービスが分かる
というメリットがあるよというお話でした。
受験者行動規範があるため出題内容には触れられませんでしたが、試験対策としては Well-Architectedを知っておくと「設問の意図が分かる」「解答の手がかりが増える」「シチュエーションとサービスが紐づく」 というメリットがあるという点をお伝えできていれば……と思います。
もちろん最速合格とは程遠い、ある意味で試験対策としては回り道な方法ではありますが、実際に仕事などでAWSを使っていく上でWell-Architectedの考え方は非常に役に立つ内容になっています。
「資格取得を急がず、かつ取得がゴールではない方」「今後もAWSを実務で使っていく方」「少しでも試験に自信と安心感を持って臨みたい方」は、ぜひ参考書等と合わせてWell-Architected Frameworkに目を通してみてはいかがでしょうか。
余談1: どれくらい時間かかった？
この手のエントリだと取得までの時間も記載するのが一般的ですよね！（偏った知見）
ただ私の場合相当遅めで、4月にクラウドプラクティショナーを取得してから8月までと考えると実質3～4か月くらいかけたことになります。
とはいえ勉強自体も本腰入れてガッツリ取り組んだというよりは、ヒマなときに参考書をつまみ読みして……というくらいの熱量でのんびり進めていましたので、トータルの「勉強時間」としては30～50時間くらいに収まるかと思います。
少し期間をあけて反復学習したほうが覚えやすいってエビングハウスさんも言っていますし……？
余談2: 資格取得して実務で役立ってる？
バッチリです。 1つ例をご紹介します。
先日マネジメントコンソールでEC2関連の作業を行っている際、io1タイプのEBSボリュームがなぜかポツンと1つだけあることに気づきました。試験の参考書知識で「io1は結構高い」と分かっていたので確認してみたところ、「しばらく前に作ったボリュームで、DB処理のために不定期に1,000IOPSくらいの性能が必要になる。容量が小さいのでgp2だとバーストを使い切ってしまう。」ということでこの設定になっている模様でした。
これを 「データベースをEC2でホストしています。ストレージには1,000 IOPS程度の性能が必要です。この要求を満たすコスト最適なストレージタイプは何ですか。」 というような問題だと考えるならば……現時点での答えはgp3です。IOPSはベースラインで3,000もありますし、なによりio1よりずっと低コストです。
スループットもベースラインで足りそうでしたが、もしもっと必要だとしてもなおio1よりは安くなる計算でした。ということでボリュームタイプを変更し、これだけで月70ドル以上のコスト削減を実現することができました。
……とこんな感じで、試験勉強もなかなか活きてくるなぁと感じている今日この頃です。普段EC2はあまり触らないほうですので、この辺りは受験勉強しなければ気づけなかった部分かなと思います。
自分が普段あまりやらない範囲のサービスを勉強するきっかけとして、SAA試験の受験はなかなか役に立っているなと感じています。
ソリューションアーキテクト試験、おすすめです。皆様もぜひいかがでしょうか。