「AWSクラウド設計完全ガイド」早速読みました&オススメかつ一部のエンジニアは必読書にしてもいいと思いました!
...という, 現役のエンジニア・システムアーキテクトおよびSREである私の読書感想文エントリーとなります.
私の前職の同僚たち（それも社内で本当に強い連中*1）の共著で最初から期待しか無かったのですが, その期待値をめっちゃ超えてきた（ただし読み手として注意も必要, 後述します）のですごく良かった*2です, 紙もですがKindle（電子書籍）もすぐ買いました.
何が良かったか一言で言うと,
「タイトル通り『AWSの設計ガイド』として成立しているかつ, Google CloudやAzureなど他でも転用できるようなノウハウや知見, 気づきが言語化されている.」
という所です.
特に第3章「実行アーキテクチャの設計」はAWS関係なく, Public Cloud全般を扱う人は皆読んでほしいぐらいにアーキテクチャパターンやノウハウが満載です, 一つ一つは別の書籍や公開情報で知られている事ではありますが（極端な新規性があるわけではない）, 横並びにいい感じに言語化しているのは本当に良いなと思いました.
そんな「AWSクラウド設計完全ガイド」の感想を手短に書きます, 気になる方はお付き合いください.
※本ブログの引用部分は書籍文中もしくは出版社の紹介ページからの引用となります.
なお一応私の立ち位置を明確にしておくと,
- 執筆者の全員が前職の同僚で, 半数は実際に一緒した人です.
- このブログは執筆者および出版社とは全く関係ありません, 私が勝手に感想を書いているだけです*3.
- 書籍そのものは紙もKindleも私費で購入したものです, つまり貰っていません*4.
多少のバイアスは入るかもですが, あくまで1人のエンジニアとしての感想ブログであるとご認識ください🙏
TL;DR
「AWSクラウド設計完全ガイド」はクラウドを扱うエンジニアにとって必読書になりえる, ただし用法用量にはご注意ください.
書籍の感想
「AWSクラウド設計完全ガイド」は第1章から7章まで以下の構成で執筆されています.
- 第1章 エンタープライズシステム基盤設計のアプローチ
- 第2章 AWSにおけるインフラストラクチャ選定のアプローチ
- 第3章 実行アーキテクチャの設計
- 第4章 データ連携アーキテクチャの設計
- 第5章 開発アーキテクチャの設計
- 第6章 監視・運用アーキテクチャの設計
- 第7章 生成AIサービスBedrockの活用方法
どの章も取り扱っている事柄において過不足無く仕上がっています.
すべての章を解説したいお気持ちもありますが, （私の）ブログ執筆時間および全体の文量に配慮したうえで,
- エンタープライズシステムの検討とPublic Cloud（第1章の感想）
- システムの種類ごとの設計アプローチ（第3章の感想）
- 「AWSクラウド設計完全ガイド」で解決しないこと（この本のスコープに入っていないこと）
以上に絞って感想と解説を記載したいと思います.
エンタープライズシステムの検討とCloud
「第1章 エンタープライズシステム基盤設計のアプローチ」の感想です.
本書籍の監修の1人である福垣内さんが執筆した賞となります.
本書籍の玄関でありオンボーディングと言えるこの章では,
- エンタープライズシステムの検討アプローチ
- AWS でのアーキテクチャ設計のアプローチ
以上について紹介と解説がされています.
エンタープライズシステムの検討アプローチ はAWSに関係なく, 「要件定義（機能要件/非機能要件）」「アーキテクチャの定義」などのTipsを広く浅く, わかりやすく記載されています.
個人的には,
- ソフトウェアアーキテクチャパターンの一つ「レイヤードアーキテクチャ*5」
- 非機能要件のトレードオフ
についてわかりやすく説明している辺りが良かったです（シンプルですが絵図がいいです&気になる方は本を読みましょう）.
この辺はエンタープライズおよびエンジニア・アーキテクト以外に説明する時に悩ましいポイントなので尚の事良かったです.
AWS でのアーキテクチャ設計のアプローチ は
- マネージドサービスとは何か? 採用する時に気にすることは??（SLAなど）
- 冗長化構成. DR（Disaster Recovery, 災害復旧計画）などの要件がある場合に知っておくべきこと.
- よくありがちなバッチ処理. RDSなどのマネージドDBを使う時は実行環境に注意だよ, とか.
文量は少ないものの, 「オンプレミスと同じ感覚でやると危ないよ*6」というのがシュッと書かれているのは良いと思いました.
上記の意味では, AWS でのアーキテクチャ設計のアプローチ の記載内容は具体のサービス名を除けば他のPublic Cloudでも言えること*7なのでこちらも汎用性が高い内容となっています.
AWSの専門書ですが, AWSな方以外（それこそ今の私がそう）でも十分読み応えがある一冊となっています.
システムの種類ごとの設計アプローチ
「第3章 実行アーキテクチャの設計」の感想です.
AWSのクラウドアーキテクチャのみならず, Go言語などアプリケーション（バックエンド）側についても非常に造詣が深い崎原さんが執筆した章となります.
まず章の目次をご覧ください.
- エンタープライズシステムの基本パターン
- SoR の実現パターン
- SoE の実現パターン
- SoI の実現パターン
- バッチを用いたSoI 系システム
- 処理の基本パターン
- アプリケーションの実現パターン
この書籍の中でも特にページとトピックスが多く, 非常に読み応えがある章となっています.
- エンタープライズシステムに関わらず, 考えるべき「SoR」「SoE」「SoI」ごとの実現パターン.
- バッチ処理や並列実行処理, 配信セマンティック*8のパターン.
- MVC, SPA, BFFなどWeb系の人もお馴染みなアプリケーションのパターンでホスティングするときの勘所.
以上を抑えています.
一つ一つの感想を書くと大変なので省略します*9が, AWSでの参考になるのは勿論, AWSじゃなくても普通に読み物として勉強になりました.
私はちょっとAWSから遠ざかっているので結構新鮮に読めたのと, Google Cloudだと,
といった事例集やblueprintsのサンプルが充実しているのですが, AWSで当てはめるパターンは案外無い気がするのでその意味でも価値がある章だと思いました.
「AWSクラウド設計完全ガイド」はどの章もいいですが, システムアーキテクト的には迷ったら第3章から読むといいかもしれません（題材次第ですが）.
この本で解決しないこと
第1章, 第3章の解説だけでも「これって必読やん」感ある「AWSクラウド設計完全ガイド」ですが, （おそらく書籍のスコープの関係上）記載されていない, この本だけでは解決しないこともあります（「『AWSクラウド設計完全ガイド』はクラウドを扱うエンジニアにとって必読書になりえる, ただし用法用量にはご注意ください.」の「用法用量」の話です）.
- AWSの権限管理. 具体的にはIAMやそのロールの取り扱い.「最小権限の原則に従って実装するには」みたいな話題は別の書籍やドキュメントを追う必要があります.
- ネットワーク関係の話. 「第2章 AWSにおけるインフラストラクチャ選定のアプローチ」にVPCなどのソリューションの説明, 第3章に実装パターンごとの例はあるものの, これらが現実のプロジェクトやプロダクトで真似できるものではありません（あくまで紹介&パターン説明の必要性で載っているだけと認識）.
- クラウドのセキュリティ全般. 「DDoS喰らわないための構成」みたいなパターンがあるわけではなく, これも各章でソリューションごとにガードレール等の機能が紹介されているに留まります.
この辺を期待している方は別の書籍やドキュメントを探すか, これらに明るい人と働く（か, 生成AIと会話しながら進める*10）など別の手段を取る必要があります&これらの要件はプロダクト・プロジェクトの要件次第で変わる, 再現性が低い箇所となるのでそのつもりでやっていきましょう.
結び&「一流のアーキテクト」とは
「AWSクラウド設計完全ガイド」早速読みました！という事で,
- エンタープライズシステムの検討とPublic Cloud（第1章の感想）
- システムの種類ごとの設計アプローチ（第3章の感想）
- 「AWSクラウド設計完全ガイド」で解決しないこと（この本のスコープに入っていないこと）
以上にフォーカスした感想を紹介しました.
気になったらぜひ手にとって, 買って読んでください.
色々と感想を書きましたが.
- AWSでシステム作るならとりあえずECS使えばいいよね.
- App Gateway + Lambda + Dynamo DBの組み合わせが最強パターンや〜！
なんて考えている方こそぜひ手にとって読んで, 考えてみてほしいなと.
ECSだけでは非同期処理はできない（できるけど大変な実装&クラウドネイティブっぽくなくなる）, App Gateway + Lambda + DynamoDBの組み合わせはちょっとしたシステム作りには最強*11だけど, 「検索機能を充実させたい」「Dynamo DBのコストが(ry」みたいな「再現性高いトラブル」を避ける意味でも本当にオススメです*12.
「一流のアーキテクト」というのはWhyからゼロベースでHowに落とし込める強者の事を言うんやで.
※shinyorkeさん個人の感想と意見です
というのが私の持論なのですが, そんなつよつよマンの一歩を踏み出す意味でも読むと良いかもしれません, 書いている人たち本当に強いので.
最後に私信的な話を一つ.
前職であるアクセンチュア, 特に同じ組織に在籍していて在職中は壁打ち相手になったりなってもらったりして苦楽を共にした福垣内さん, 崎原さん*13を始めとした執筆者の皆様がこのような良い書籍をデリバリーしてくれたのは我が事のように嬉しく思いますし, こうして感想ブログを書けることに幸せを感じています&改めてご出版おめでとうございました！
「AWSクラウド設計完全ガイド」はエンタープライズのみならず, Web界隈や生成AI時代のクラウドネイティブなアプローチに役立つと思いますのでぜひ読んでやってください.
最後までお読みいただきありがとうございました.
*1:これは盛っているつもりは無く, マジです.
*2:ちなみにですが1日で読破しました.
*3:が, 近い執筆者の方には一言断りを入れています.
*4:ただし, 著者に会うタイミングでサインはもらおうと思っています笑
*5:この本の話題ではないのですが, ドメイン駆動とかHowで言う前に「どのレイヤーで解決すべきか×機能要件」的なWhyで考えてくれよって思っています. 世間一般の設計的な議論を見ていていつも思う.
*6:この説明が一冊で済むのがこの本の隠れた価値なのかなとも思っています.
*7:この辺はまさにCloud Native的な発想かなと. なお手前味噌ですが自分的なCloud Native（生成AI時代に気をつけよう）な話題は会社のブログに書きました.
*8:いわゆるイベント処理. 「Exactly Once」とか「At-Least Once」とか理解に苦労する所です.
*9:第3章だけでも単一の書籍として成立するのでは?ぐらいの充実した内容です.
*10:なお生成AIに頼るにしても, （2025年現在の状況では）専門知識によっていい感じのプロンプトを作る必要があるので結局自分で学べっていう事になります.
*11:書籍でも第3章にてSoRのFaaSパターンとしてAPI Gateway + Lambdaが紹介されています. 実際そうだし, めちゃくちゃ便利なパターンであることは認めつつ. いくらなんでも最強扱いし過ぎでは?説あります. 負荷対策やキャッシュ戦略頑張らないと死に至るだけに.
*12:別の文脈として, 最近の転職での選考にありがちな「技術課題」「アーキテクチャに関するディスカッション&ホワイトボードプログラミング」対策という意味でも有効です. 一つのアーキパターンしか知らない人は詰むので（経験者語る）.
*13:具体のエピソードは言えませんが, 「がうちさん（福垣内さん）とアーキテクチャを会話する会」みたいな雑談会があって, 私や崎原さん含めて色んな議論したなあと読んでて思い出しました. また私の卒業に関しても快く送り出してくれた&退職後も応援してもらったりと本当に感謝しています.
