エバンジェリストの知識と経験を1冊にまとめた　AWS開発を《成功》させる技術

著者 : 高岡将 佐々木亨

• SBクリエイティブ (2023年6月28日発売)

作品紹介・あらすじ

AWS認定資格では手に入らない実践的なノウハウを集成

システムを構築する際にクラウドを利用することが一般的になりましたが、クラウドは手軽に使える一方で、その恩恵をきちんと享受し、適切にシステムを運用するためには「クラウドの本質とサービスの性質を踏まえた要件・構成・運用の理解」が欠かせません。

本書はそうした「クラウドならではの要件・構成・運用の理解」を得るための知識と情報を1冊に集成。元AWSテクニカルエバンジェリストの著者たちが、数多くの開発・運用経験から獲得した、インフラやクラウドアーキテクチャのパターン化されたノウハウを1冊で提供します。

＜本書のポイント＞
・AWSでのシステム開発・運用経験を豊富に持つ著者たちによる書き下ろし！
・研修や資格試験では得られない、実際のシステム開発・運用における考え方と勘所が学べる！

＜本書の効果＞
（1）実装するシステムやサービスが適切にクラウドを利用しているか判断できる
・設計、開発、運用のすべての局面で、安全性やコストなども含め適切にコントロールできる
・クラウドシステム開発の初期検討時の参考資料としても使える


（2）クラウドシステム開発の「あるべき姿」として、現場の共通認識（プロトコル）に使える
・企画・経営とエンジニアが考える期待値を合わせ、同じプロトコルで議論できるようになる
・事例をもとにクラウドシステム開発の共通イメージを持つことができる
・中途参画や新卒など新たに加わるメンバーを短期間で戦力にできる

感想・レビュー・書評

[honnyomimannさんの感想 · 2024年2月9日]

AWSある程度知っている人ならすらすら読める．
AWSのシステム設計，構築，運用について経験に基づいた示唆がたくさん．

AWS極めたい個人エンジニア向けの本ではない．大企業サラリーマン向け．

著者はNTTデータ先端技術株式会社の執行役員

クラウドネイティブ世代とオンプレ世代の間にある溝をどう埋めるのかが根底にある課題だなと感じる．筆者のような両方を理解し，かつ所属組織でその方針を活かせるポジション，いわばスーパービジネスマンがいれば話が早いがそんな人材は多くないだろう．

片方がもう片方に寄り添う．その結果ビジネス上のメリットがあることをしっかり整理した上でクラウドシフトをゆっくり進めるのが重要．
一夜過ぎたらDX，クラウドシフトできていたなんていう銀の弾丸的テクニックはないんだなと改めて感じる．

第6章のハンズオンのテーマはマルチアカウント環境の構築．なんとも渋いが，事業会社のAWSやっていきたいマンには刺さるいいテーマだと思った．

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

オンプレミス世代とクラウドネイティブ世代ではシステムに対して抱く感覚と用いる言語が異なる→噛み合わないことも．　p.23

WF or アジャイル
・仕様がころころかわる　→アジャイルが向いている
・疎結合で変更しやすい　→ アジャイルが向いている

金融系，公共系→WFの傾向
Web系　→ アジャイルの傾向
※あくまで傾向
実際は「変更不可能な要件」「変更可能な要件」が入り混じる．クラウドでは「インフラ部分はWFで，アプリ部分はアジャイルで」も一択

システムアーキテクチャはいろいろ
・モノリシック
・サービス志向
・マイクロサービス　（サービスをAPIごとに分割）

AWS Well Archtected Lens → 金融や機械学習など特定業界などに沿ったベスプラ

AWS ホワイトペーパー　→事例検索
https://aws.amazon.com/jp/whitepapers/

AWS Trusted Advisor：ベスプラに沿っているかチェック
コスト最適，セキュリティ，耐障害性，パフォーマンス，サービスクォータ


システムの特徴を踏まえたアーキテクティング
エンタープライズ系システム…
利用者が読みやすい→需要予測はできるものとしてオートスケーリングはわざわざ入れない．
パッケージを入れることが多い→マネージドサービス対応不可な場合あり．ライセンス管理に注意（OS識別，物理コア比例など）

Web系…
利用者が読めない→キャパシティ予測しない．オートスケーリングする．
アプリ改修多い→ CI/CD

なぜクラウドを選ぶ…? ->メリットがあるから
・ハードウェア管理の開放
・キャパシティ予測からの開放
・スモールスタートの実現
・自動化したい
・開発スピード上げたい
・世界中にスケールしたい

オートスケーリングの難しさ…
→モニタリング指標が，別の原因で高まり不要なスケールアウトを起こしたり，既に生じている影響を拡大させる．　p68

EDoS攻撃→クラウド破産攻撃

VPCPとTGWの使い分け p73：
VPCPは帯域制限がない．TGWは50Gbps制限
TGWのほうがレイテンシー（通信遅延）あり
セキュリティG参照不可など

ダイレクトコネクトの提供範囲：
AWS~AWSパートナー企業の施設．
自社〜AWSパートナー企業の施設の間は自分たちで手配必要

Site-to-Site VPN: IPSec VPNで拠点ーAWSを接続


”アカウント”いろいろ：
AWSそのもの→ 管理アカウント（請求アカウント），メンバーアカウント（Organizations上の区別）
コンソールアカウント→ルートアカウント，IAMユーザ
その他アカウント：OSアカウント，サービス・アプリアカウント，


IAMポリシー作成パターン：
ホワイトリスト型：許可ポリシーのみ付与
ブラックリスト型：禁止操作を指定．
ハイブリッドパターン
IAMユーザ・ロールに付与できる管理ポリシーは最大20
IAMポリシーに記載できる文字数は6144文字

予防的統制→Organizationsのポリシーは万能ではない．
→必要権限の中で起こる事故はどうしようもない→発見的統制


DRはどこまでやる？→RPO，RTO，RLO次第
RLO：システムをどのレベルまで復旧するか
バックアンド＆リストア，パイロット，ウォームスタンバイ等

ログ・監視：
AWS上のZabbixやHinemos→オンプレの名残．
CWやOpenSearch Serviceなどのマネージドサービスで代替できないか？を考えても良い．
SaaS製品もあるが，海外性の場合海外DCで保存される可能性がある点は注意

運用の自動化：
システムリリース前に全自動化することは無理．
走りながら成長させるマインドが必要．

AWSのリソース作成方法は三種：
・GUI操作
・CLI操作
・IaC

IAMユーザ・ロールによる請求情報アクセスの許可はルートユーザでないとできない．


SecurityHub
->起動時に監査用アカウントを指定
→監査アカウント上でHubの開始操作が必要．
→監査アカウントでの開始後，メンバーアカウント追加は自動反映
→CISBやベスプラ，PCIDSSに対応

自動化の実践優先度
・難易度の高低
・価値の高低
→実装難度が低く，効果的なものから実施すべき

[sou (08thse)さんの感想 · 2024年1月31日]

「ちょっと使ってみよう」や「PoC」の次、ちゃんと AWS 環境を回すためにはどうするか、というレベル感かなと思いました。

[Yuichi Takeuchiさんの感想 · 2023年7月14日]

技術とあるが、技術的な深堀りはされてなくて、クラウドアーキテクチャの基本的な考え方や概念、ツールの紹介に留まる。マネージャーが知っておくべき話中心だと思った。
僕はこの本で言うところの『フルスタックを目指す開発エンジニア』だけれども、それには内容的に物足りず、あくまでも触りとして、の読み物と感じた。触りとしてはControl Towerの設定方法など、やや敷居の高そうに見える構成の解説など参考になったものもある。マルチアカウントアーキテクチャ大事の気持ちになれました。

[Yuichi Takeuchiさん · 2023/07/14]

技術と書いてあるが、技術的に深堀りはされてなくて、クラウドアーキテクチャの考え方、概念、基本的なツールの紹介など、マネージャーとして理解しとくレベルの話中心だとおもった。
僕はこの本で言うところの、フルスタックを目指す開発エンジニアであるけど、あくまでもさわりとしては良いと思った。読みやすいし。

著者プロフィール

「2023年 『エバンジェリストの知識と経験を1冊にまとめた　AWS開発を《成功》させる技術』 で使われていた紹介文から引用しています。」