前回までのあらすじ

第2回目の学習では「AWSのアクセス権」についてまとめました。もしよろしければご覧ください。

AWS Well-Architectedとは

AWSが提供するクラウドアーキテクチャのベストプラクティスをまとめたフレームワークのことです。
公式サイトによると

AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを使用することによって、信頼性が高く、安全で、効率的で、費用対効果が高く、持続可能なシステムを設計して運用するための、アーキテクチャに関するベストプラクティスを学ぶことができます。

今回はこのAWS Well-Architectedについて理解するために記事を書いていきたいと思います。私なりの解釈が入る箇所があるので、間違っているところがあればご教授いただければと思います。

6つの柱

運用上の優秀性（Operational Excellence）

システムの実行とモニタリング、およびプロセスと手順の継続的な改善に焦点を当てています。主なトピックには、変更の自動化、イベントへの対応、日常業務を管理するための標準化などが含まれます。

システムの運用を効率化し、プロセスと手順を改善していくことでシステムの運用全体を最適化するためのプラクティスが書かれています。

具体的な中身

運用のコード化

手動のプロセスをコード化（Infrastructure as Code）し、自動化することで信頼性と効率性を向上させる。

小さな変更の頻繁な実行

変更を少しずつ頻繁に行うことで、リスクを最小限に抑えつつ迅速に改善を反映する。

運用手順を定期的に改善

作業者へのヒアリングや、障害対応のシミュレーションを行うなどして定期的に手順を改善し、システムの運用手順を定期的に改善する。

障害対応の準備

障害や問題発生時に迅速に対応できるようにどんなリスクが潜んでいるのか、どんな障害が発生し得るのかを予想しておく。

継続的な改善

システムの運用上に発生した障害について今後同じ障害が起きないようにシステムや手順の改善を繰り返し行う。

セキュリティ（Security）

情報とシステムの保護に焦点を当てています。主なトピックには、データの機密性と完全性、ユーザー許可の管理、セキュリティイベントを検出するためのコントロールが含まれます。

つまりは、システムを運用する上で行うべきセキュリティのプラクティスが書かれています。

具体的な中身

強力なアイデンティティ管理

最小権限の原則に従い、必要最低限のアクセス権を付与する。

すべてのレイヤーでの保護

ネットワーク、アプリケーション、データといったすべてのレイヤーでセキュリティ対策を実施する。

監視と監査

すべてのアクセスや操作をログに記録し、異常を検知できる仕組みを構築する。

データの保護

送信データや保存データの暗号化、バックアップの定期実行。

セキュリティの自動化

セキュリティの検知を自動化したり、セキュリティをコード化する。

データの手動処理の禁止

データ処理の自動化による、手動処理を禁止する。

セキュリティイベントに備える

システムが直面するセキュリティイベントを想定し、それに対応できるよう準備する。

信頼性（Reliability）

期待通りの機能を実行するワークロードと、要求に応えられなかった場合に迅速に回復する方法に焦点を当てています。主なトピックには、分散システムの設計、復旧計画、および変化する要件への処理方法が含まれます。

つまりは、障害の発生を前提として復旧手順、復旧の自動化についてのプラクティスが書かれています。

具体的な中身

フェイルオーバーの準備

障害が発生しても、別のリソースに自動的に切り替わるフェイルオーバーを設計。

スケーラブルなアーキテクチャ

トラフィックの変動に応じてリソースを自動的にスケーリング(水平方向)できるようにする。

バックアップとリストアのテスト

データのバックアップを定期的に行い、その復元手順をテストしておく。

リカバリの自動化

システム障害やサービス停止からの自動復旧を可能にする。

キャパシティーを推測することをやめる

需要の変化に対応してリソースの増減が容易なため、設計段階でキャパシティーを予測することは不要になる。

オートメーションで変更を管理する

インフラ構築をコード化することで自動化する。

パフォーマンス効率（Performance Efficiency）

IT およびコンピューティングリソースの構造化および合理化された割り当てに重点を置いています。主なトピックには、ワークロードの要件に応じて最適化されたリソースタイプやサイズの選択、パフォーマンスのモニタリング、ビジネスニーズの増大に応じて効率を維持することが含まれます。

つまりは、システムのリソースを最適化し、リソースの効果的な活用についてのプラクティスが書かれています。

具体的な中身

最新技術の活用

クラウドネイティブなサービスを活用し、継続的に最新技術を導入してパフォーマンスを向上させる。

弾力的なスケーリング

必要なときに必要なだけのリソースをスケーリングする設計。

負荷テストとモニタリング

継続的なモニタリングを行い、ボトルネックを発見したら適切な対策を講じる。

グローバル展開

最小のコストでサービスをグローバルに展開する。

サーバーレスアーキテクチャーの使用

サーバーを用意せずにサービスを利用できるサーバーレスアーキテクチャーを使用し、OSやミドルウェアの管理する負担を軽減する。

より頻繁に実験

さまざまなシステム構成を実践し、検証した上で適切なシステム構成を選択する。

適切なアプローチを選択

クラウドサービスの利用方法について学び、常に最適なアプローチを使用できるよう考慮する。

コスト最適化（Cost Optimization）

不要なコストの回避に重点を置いています。主なトピックには、時間の経過による支出の把握と資金配分の管理、適切なリソースの種類と量の選択、および過剰な支出をせずにビジネスのニーズを満たすためのスケーリングが含まれます。

つまりは、無駄を省き、効率的にリソースを使用してコストを削減するためのプラクティスが書かれています。

具体的な中身

不要なリソースの停止

使っていないリソースや過剰なリソースを特定し、停止または削除する。

適切なインスタンスタイプの選定

ワークロードに最適なサイズのインスタンスを選び、リソースの無駄を減らす。

オンデマンドとリザーブドインスタンスの活用

必要に応じてリザーブドインスタンスやスポットインスタンスを活用し、コストを削減する。

クラウド財務管理の実装

AWSを利用する組織は時間とリソースを投入する必要がある。

全体的な効率を測定する

システムの利用状況を測定し、生産性の向上やコストの削減状況を把握する

差別化につながらないインフラ管理に費用や負担をかけるのをやめる

クラウドサービスやマネジメントサービスを利用することで、インフラ管理に費用や負担をかけない。

持続可能性

持続可能性の柱は、実行中のクラウドワークロードによる環境への影響を最小限に抑えることに重点を置いています。主なトピックには、持続可能性の責任共有モデル、影響についての把握、および必要なリソースを最小化してダウンストリームの影響を減らすための使用率の最大化が含まれます。

つまりは、環境に配慮した、コスト最適化とのバランスを考えたシステム会社についてのプラクティスが書かれています。

具体的な中身

オンデマンドリソースの利用

必要なときに必要なリソースのみを使用し、過剰なリソースを削減する。

エネルギー効率の高いサービスの選択

より少ないリソースで高いパフォーマンスを実現するAWSサービスの活用。

利用するリージョンの最適化

最も効率的で環境負荷の少ないリージョンを選択する。

コンピューティングリソースの最適化

過剰なインスタンスサイズを避け、適切なサイズのインスタンスを選び、リソース使用量を最適化する。

ストレージとネットワークの最適化

必要なデータだけを保存し、アーカイブや削除を自動化することで、ストレージの効率を最大化する。データの転送も最適化することで、ネットワークの無駄なトラフィックを削減。

効率的なソフトウェア設計

ソフトウェア自体も効率的に設計し、リソースの無駄を減らす。

影響を把握する

利用者がシステムの変更や改善が、持続可能性のために与える影響を把握する。

持続可能正目標を設定する

持続可能性の目標を設定し、目標を達成するためのシステム構成を設計する。

まとめ

ベースに持っておきたい知識