AWS Well-Architectedフレームワークとは？
AWSを利用するためのベストプラクティスをまとめたもの。
AWS Well-Architectedフレームワークの3つの構成要素
1. ホワイトペーパー
- レビュープロセス
- 5本の柱
- 設計の原則
- ベストプラクティス
2. Well-Architected Tool
- ワークロード管理
- レビュー結果の管理
3. 支援するソリューションアーキテクト
- 構築
- 設計
- 運用
- レビュー
ホワイトペーパーの５本の柱
3つの構成要素の中のホワイトペーパーの5本の柱。
5本の柱は、Well-Architected を体系立てる基本的な考え。
クラウド全般についての一般的な設計原則
そもそも、クラウド全般の一般的な設計原則は以下です。
- 実際に稼働して計測し、確実なキャパシティ設計をする
- 本番環境と同じスペックおよび構成でテストし、リリース後の障害発生を減らす
- 環境構築は自動化し、再現性を高める
- データを収集しデータに基づいた意思決定を行う
- 頻繁にデプロイしてリスクを減らす
- ゲームデーを利用して緊急事態に備える
柱1:運用上の優秀性
オンプレと比べる、オンラインでのリリースのしくいやインフラをコードで管理する仕組みがある、
そのため、小規模なリリースを頻繁に行ったり、再現性が高いリリースを行えまる。
AWSもリリースのために使えない時間帯や制限事項はない。
運用上の優秀性についての設計原則
- 運用をコードとして実行する
- ドキュメントをコードと一緒に管理する
- 小規模なリリースを頻繁にし、戻せるようにする
- 定期的に運用手順を見直す
- 障害を予想し、準備する
- 運用上のすべての障害から学ぶ
柱2:コスト最適化
AWSは、従量課金制で費用節約可能。
需要のピークに合わせてサーバーを用意できる。
コスト最適化についての設計原則
- 費用を追跡する、必要に応じてアラームを設定する
- 不要な時間は停止する
- 需要に合わせたリソース最適化を行う
- マネージドサービスを積極的に活用する
- 購入オプションを活用しコスト削減する
柱3:信頼性
AWSでは、サーバーが突然落ちるかもしれない、データセンターが突然停止するかもしれないという前提で設計する。
サービスをいかに継続させるかが信頼に繋がる。
信頼性についての設計原則
- RPOとRFO
- Multi-AZ
- Multi-Region
- ELB
- Auto Scaling
- リソースのモニタリング
- バッグアップリストア
- AWSの制限
柱4:パフォーマンス効率
AWS提供しているサービスを理解し、適切で使うことでパフォーマンス効率をあげることができる
柱5:セキュリティ
セキュリテ対策を行う際の基本的に考え方「多層防御」
複数のセキュリティ対策を行うことで、リスクを下げる
セキュリティのベストプラクティス
- 認証情報の管理
- データの保護
- 脆弱性管理
- 監視とログ管理
- インシデント発生時のプロセスを準備