5本の柱ごとに自分なりの解釈を書いていきたいと思います。
※誤りがあればコメント頂けると嬉しいです。
今回は信頼性についてです。

信頼性とは

インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や⼀時的なネットワークの問題といった中断の影響を緩和する能⼒

信頼性の柱は壊れにくく、復旧が容易な状態であることが目標となります。
信頼性に不可⽋なAWS のサービスは Amazon CloudWatchです。

信頼性の指標(RASIS)

項目	概要	算出式
Reliability（信頼性）	故障が回復してから次に故障するまでの平均時間。長いほど信頼性が高い。作業ミスがシステムの故障となりえる。	MTBF(Mean Time Between Failures) = 累積使用時間 / 故障件数
Availability（可用性）	稼働率	稼働率 = MTBF / (MTBF + MTTR)
Serviceability（保守性)	故障が発生したときに復旧に要する平均時間。短いほど信頼性が高い。	MTTR(Mean Time To Repair) = 累積修理時間 / 故障件数
Integrity(保守性、完全性)	データに誤りがない状態を保つ能力	-
Security（機密性)	セキュリティ	-

参考ページ
[障害対策の基礎知識 RASIS] (http://blog.father.gedow.net/2012/08/14/system-reliability-indicator-rasis/)

設計の原則

信頼性には、5 つの設計の原則があります。

・復旧⼿順をテストする
　⇒障害試験は行っても復旧手順の試験までは行っていないことが多い。
　　オートメーションで疑似障害を発生させることができ、
　　以前の障害のシミュレートができる。
　　これによりテストしたことがないコンポーネントに対して障害が発生するリスクを低減できる。

・障害から⾃動的に復旧する
　⇒障害の検知とオートメーションを組み合わせることで自動復旧を実現する。

・⽔平⽅向にスケールしてシステム全体の可⽤性を⾼める
　⇒１つの大規模なリソースを複数に分割し、障害の影響を軽減。

・キャパシティーを推測しない
　⇒実測値を元にキャパシティを設定

・オートメーションで変更を管理する
　⇒変更作業をドキュメント化（⇒手作業を認めない）することでミスがなくなる。
　　オートメーションに対する変更を管理する。

ベストプラクティス

⾼い信頼性を達成するため、システムの基盤について⼗分に計画し、モニタリングを実施する必要があります。需要や要件の変更に対応するためのメカニズムも必要です。障害を検出し、⾃動的に修復できるシステムを設計することが必要です。

基盤、変更管理、障害の管理に分けて対応方針を記載している。

基盤

お客様はストレージデバイスのサイズといったリソースのサイズ
と割り当てを需要に応じて⾃由に変更できます。

オンプレと違い設計不要。基本的には制限がない。（制限の意識が必要なサービスもある）
DDOSなどの攻撃からシステムを守るサービスなども利用可能。

・関連するAWSサービス
　AWS IAM、Amazon VPC、AWS Trusted Advisor、AWS Shield

変更管理

AWS を使⽤すると、システムの動作をモニタリングし、KPI への応答を⾃動化できます。

※KPI（Key Performance Indicator）：重要業績評価指標

長期的にリソース状況の傾向を見ることが簡単に行える。
リソース状況によって、サーバ台数の増減が自動で行える。
変更作業はCloudFormationなどを利用して、原則は自動化する。

・関連するAWSサービス
　AWS CloudTrail、AWS Config、Amazon Auto Scaling、Amazon CloudWatch

障害の管理

どのようなシステムでも、ある程度複雑になると障害が発⽣することが予想されます。そのため、それらの障害をどのように検出して対応し、再発を防⽌するかが問題です。

問題検知と復旧の自動化。
テストプロセスも自動化する。
（どうやってどこまで自動テストやるのか調査中⇒CDKでPythonのunittest検証中）

・関連するAWSサービス
　Amazon CloudWatch、AWS CloudFormation、Amazon S3、AWS KMS

レビューシート実践

信頼性障害管理データをどのようにバックアップしていますか？

□ バックアップが必要なデータを特定し、手動でバックアップを実施している
□ バックアップを自動化している(RDSとEBSのスナップショットなど)
⇒自動バックアップできている部分もあるが、手動バックアップの部分もある。
□ 定期的なリカバリテストでバックアップがRTO、RPOを満たすことを確認している
⇒リカバリテストはやったことがない
□ バックアップはセキュリティ保護され、暗号化されている
⇒権限制御は行われているが、基本的には暗号化していない

参考ドキュメント

〇AWS Well-Architected
(日本語 201907)
https://d1.awsstatic.com/whitepapers/ja_JP/architecture/AWS_Well-Architected_Framework.pdf?sc_icampaign=aware_well_architected_jp_wa_framework&sc_ichannel=ha&sc_icontent=awssm-3366&sc_iplace=content&trk=awssm-3366_aware_well_architected_jp_wa_framework

〇Well-Architected_review_sheet
https://d1.awsstatic.com/webinars/jp/pdf/services/Well-Architected%E3%83%92%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%B7%E3%83%BC%E3%83%88%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88.77c25d2afd0a69894be16b95aae6a423011f5a1f.xlsx