AWS運用入門を読んでみましたので、感想を残します
はじめに
おすすめポイント
AWSの運用について全般的に学べる！
AWSにあまり詳しくないが、運用を知りたい人には勉強になることが多いと思われます！
買いましょう！
各章の感想
1章
システム運用の３分類で今の業務でどう対応するか
- 業務運用：アプリの中身は見ていないので、今は担当しない
- 基盤運用：この本の解説部分！パッチ適用や定期メンテナンス、監視は担当している！
- 運用管理：運用ルール設定だが、一部実装した機能をどう運用していくかで頭を悩ませているとこ
構成図は、大事！
構成図のないAWSを見ようとしたけど、かなり時間がかかりそうだった
構成図をつくってもらったら理解がすごい進んだ経験がある
個人で作った奴は構成図ちゃんと作ってた⇒ akashikaikyouohasi/spa-by-terraform
2章、3章、4章
資格取得でだいたいわかってるので流し読み
5章 ログ運用
記録
いつ、誰が、何をしたかがわかるもの！
ログ運用で必要な４つの観点
- ログ設定：取得するログやローテションなどの設定
- ログ転送：どこに送るか。ログデータを２次利用するためにローカルから使いやすいところに送る！
- ログ保管：保管先。どれだけ保持するかも
- ログ利用：どのように閲覧、分析できるようにするか
何を取得して、どう保管して、どう分析するかを設計しないといけない！
保管という観点において、S3はつよいね
S3は格納できるデータの総量と数に制限はないから、容量という点は心配しなくていい！
CloudWatch Logs Insightsでは、パイプ（|）で区切るんだ
コマンドラインっぽいね
AthenaはCSVやTSVだけでなく、JSONやORC、Logstashなど様々なデータ形式に対応しているのは知らなんだ
ワークグループの存在は知っていたが、「保存したクエリ」と「クエリ結果のS3出力」設定が分離できるんすねぇ
Athenaはスキャンしたデータ量に応じて料金がかかるから、パーティション化は大事！
あまりパーティション化してないと、ちょっとしたスキャンで毎回10Gとか読み込んじゃうからね
CloudWatch Logs InsightsよりAthenaの方がコスト面はいいね
基本はAthenaで、アラートとか緊急そうなのだけCloudWatchかな
6章 監視
各コンポーネントから情報を計測・収集し、問題が起こった場合にいち早く知ること
監視で必要な作業
- 監視ツールの導入：要はCloudWatch
- メトリクスの監視：いつ・何が・どういう状態と値であったかの情報！
- アラートの通知：運用者への通知
ただメトリクス監視しても意味なくて、顧客影響が出ていないならそこまで慌てなくていいのではと最近思い中。
CPU使用率が90%を超えている！が、レスポンスタイムは悪くなっていないのであれば、高効率でリソースが使えているということになる。のように
EC2のオートリカバーは明示的に設定したことないな…
合った方がいい
通知については、現場で似たようなことしてるのであまり新しい知識はなかったかなー
7章 パッチ適用
読む前に一番気になっていた章
部分的に修正・更新するための追加分のプログラム
問題を修正するのに全部インストールしなおしは効率が悪いから！
サンプルアーキテクチャはPatch Managerでいろいろやっている
Patch Manager自体はパッチ適用の自動化のみの機能のため、実際は付随する作業もあると考えられるので、Step Functions？とかで適用になるのかな
台数が多いと手動は無理なので、なにかしら自動化は必須かと
実務でもっとめんどくさい構成でやってしまっていたので、残念ながら新しい発見はあまりなかった
8章 バックアップ/リストア運用
AWSのほとんどのサービスは増分バックアップとのことだが、あまり意識したことはなかった！
AMIを取得するとEBSスナップショットも取られる関係。
包含関係？になるのかな
AuroraのバックトラックはMySQLだけだったのか
AWS Backupが重要だが、自分はほとんど触ったことないですね
バックアッププラン、復旧ポイント、バックアップボールトが主要コンポーネント！
EC2とRDSをまとめてバックアッププランでバックアップとれるのか！便利ねぇ
復旧ポイント単位でリストアできるんだ
ファーストタッチペナルティとは、リストア後に初めてデータアクセスがあってからEBS上にデータをコピーする際に発生するIOが高くなる現象。
これも知らなかった！
DBインスタンス識別子とAuroraクラスター識別子は変更できるのが、意外と重要かも
9章 セキュリティ統制
不特定多数の第三者から情報資産を守り、安全な状態を維持すること
情報資産：経営資源のヒト・モノ・カネ・情報の４つのうちの１つ
情報資産の維持管理改善のために情報セキュリティマネジメントシステム(ISMS)がある
そこで定義されているセキュリティ３要素
- 機密性(Confidentiality)：アクセス制御と権限管理的なこと。IAMが対応する
- 完全性(Intefrity)：情報が改ざんされていないこと。KMSでの暗号化、WAFでの防御、適切なバックアップなどが対応
- 可用性(Availability)：障害時に影響を最小限にして稼働し続けること。マルチAZ・リージョン、バックアップの自動化などが対応
ただ、リスクを０にすることはできない！
セキュリティ対策のジレンマは３点
- コストの問題：セキュリティを強化すれば金もかかる
- 周囲の理解が必要：セキュリティ対策は利益につながらず、脅威を防ぐもの。つまり、マイナスにならないようにするものなので、意識的に考えないとおろそかになりやすい
- ウイルスなどの攻撃手法の進化：常に新しい脅威がでてくるので、その時点でゼロリスクにできても、時間が経つと新たな脅威に晒されてしまう
セキュリティ標準としてPayment Card Industry Security Standards CouncilのPCIデータセキュリティスタンダード(PCI DSS)がある
Security Hubのセキュリティ基準のPCI DSSってこれのことだったのか…
結局、セキュリティリスクは０にできないなら、早期発見と迅速な対処をしていくという観点が重要！
これは発見的統制でのアプローチ
予防的統制もあって、脅威が顕在化することを未然に防ぐというアプローチもある
セキュリティの柱の７つの設計原則
- 強力なIdentity基盤の実装：IAMすね
- トレーサビリティの実現：CloudTrailとか
- 全レイヤーでセキュリティを適用する：多層防御
- セキュリティのベストプラクティスを自動化する：自動化で効率よく！
- 伝送中および保管中のデータの保護：暗号化しよ
- データに人の手を入れない：手作業しない！誤操作するよ
- セキュリティイベントに備える：備える
KMSのリソースベースポリシーはIAMポリシーよりも評価が優先される！
たとえAdministrator権限であろうとも
クラウドサービスの設定不備で個人情報流出の恐れが増加しているので、Configで設定不備を検知するの大事！
検知したらすぐ修復することで影響範囲を最小にできる
ただ、修復アクションがSSM Documentsのみなのは難易度高い気が
10章 監査準備
経営や業務の活動が適切かどうか、第三者視点で監査人が評価すること
問題があれば、意見を表明して組織体を正しい方向へ導くこと
本書ではシステム監査のみに絞って解説
システム監査の目的は、経営戦略上の目標達成に寄与すること！
IT部門は、監査に必要なログなどの情報提供をしなければならない
なので、エンジニアも他人事ではないぞ
CloudTrailの解説で、ダイジェストファイルの検証方法は知らなかった
CLIでやるんだ
Configだと削除されたAWSリソースも確認できるのか
言われてみれそりゃそうか
11章 コスト最適化
- クラウド財務管理を実践する：料金体系の理解
- 経費支出と使用量の認識：料金の把握と不要リソース削除
- 費用対効果の高いリソース：適切なサービスとスペックの利用
- 需要の管理とリソースの提供：オートスケーリング
- 継続的最適化：サービスは更新されていくので継続的にやっていこう
NOT コスト削減。コスト最適化をしよう！
AWS Cost Anomaly Detectionを設定すると、コストの異常値が数日というスパンで早く検出可能！！
だいたい月1でしかみないから便利そう
Cost Explorer, Budgets, Cost Anomaly Detectionを駆使してコストを最適化しよう！
Systems Manager Quick Setupは高速にEC2のセットアップやResource Scheduler設定ができるのがいいね！
これも知らない機能だった
まとめ
個人的には、実際に運用もしているので、似たことをしていたので知識の整理にはなりました
細かいTipsとして知らないことが知れたのは非常に良かった！
運用したことがない！という人は、運用の色々が知れるのでとても参考になる書籍だとおもいました！
