AWS Well-Architected Tools のレンズカタログで選択出来る全てのレンズの設計原則と柱をまとめてみた

いわさです。

本記事は「Japan AWS Ambassadors Advent Calendar 2023」の 17 日目の記事です。

AWS Well-Architected Lens について

AWS re:Invent 2023 で、AWS Well-Architected Tool にレンズカタログという機能が登場しました。

AWS Well-Archited には特定の技術領域やドメインに最適化した「レンズ」という、拡張フレームワークが存在しています。
このレンズは AWS 公式に用意されているものから、オープンソースベースで用意されているものまでいくつか存在します。

AWS Well-Archited Tool にはこれまでも Serverless、SaaS あたりの公式レンズは存在していたのですが、上記アップデートでレンズカタログとして機能追加されたタイミングで改めて公式レンズがいくつか追加されています。

そして、マネジメントコンソール上ではありませんが公式レンズのカタログ自体は実は以前から存在しています。

それぞれのレンズがどういうものか知っているか？

Well-Archited Framework 自体は、AWS 上でワークロードを設計される方であれば当たり前のように使っている方が多いと思います。
ただ、私の観測範囲ではレンズについてはまだまだ普及していない印象があります。

この数年で私は SaaS Lens をよく使うようになったのですが、SaaS ワークロードを設計する上では必須のノウハウが詰まっています。
これは他のレンズについても知っておかねばと思ったのですが公式レンズの数も多く、それぞれのドキュメントもなかなかボリュームがあります。

公式レンズ自体は Well-Architected Tool のレンズカタログと、公式ドキュメントから以下の公式レンズが存在していることを確認することが出来ます。（厳密には公式ドキュメント側は国によってレンズの増減があるようです。例えば言語を日本にすると「FTR レンズ」が表示されます。今回は英語で確認しています。）

レンズ名	ドキュメントあり	Well-Architected Tools あり
Serverless Applications Lens	○	○
SaaS Lens	○	○
Container Build Lens	○	○
SAP Lens	○	○
IoT Lens Checklist	○	○
Data Analytics Lens	○	○
Machine Learning Lens	○	○
Healthcare Industry Lens	○	○
Government Lens	○	☓
Hybrid Networking Lens	○	☓
Games Industry Lens	○	☓
Streaming Media Lens	○	☓
Financial Services Industry Lens	○	☓
HPC Lens	○	☓
M&A Value Creation Lens	☓	○

今回は上記のうち、ドキュメントとレンズカタログどちらも存在しているレンズ全てについて、これらを採用したときに、例としてアーキテクチャー上でどのような技術やサービスが取り入れられるのか、柱ごとにまとめてみました。

実際には Well-Architected 上は背景やそれによって実現したいこと、トレードオフなどもっとたくさんの情報があります。
今回はアーキテクチャー上の実装視点でどのような考慮が発生し得るのかを把握するためにまとめました。

それぞれのレンズの各柱で3行まとめをしています。今回は具体的な実装例や戦略について敢えてフォーカスしました。実際には柱で推奨される内容はもっとふわっとしたものであり、これらの実装は例に過ぎず、また、採用しないほうが良い場合すらあります。今回は公式レンズの実装例についてイメージしやすいように敢えてまとめに盛り込んでいます

Serverless Applications Lens

Serverless Applications Lens は AWS でサーバーレスワークロードを構築するためのベストプラクティスに準拠しています。
設問数は 9 で、公式レンズの中でおそらく最も規模が小さいレンズです。ドキュメント一式もさらっと見れるはずなので、まだ内容を把握してない方は是非チェックしてみてください。

それぞれのレンズにも Well-Architected と同様に設計原則が定められています。

• 関数は単一機能を持つよう設計し、トランザクションは効率的でコストを考慮し、迅速な実行が求められる。
• サーバレスアプリケーションは同時実行性を生かし、トレードオフを同時実行性に基づいて検討する必要がある。
• アプリケーションが高耐久性を必要とする場合、関数実行環境は短命であり、状態は状態マシン実行ライフサイクルを通じて操作され、永続ストレージを優先する。

そして、Well-Architected Framework と同様にそれぞれの柱があり、設問やリファレンスアーキテクチャー的なものが用意されています。

運用上の優秀性の柱

• Amazon CloudWatch Logs、Embedded Metric Format (EMF)、Lambda PowerTools、AWS X-Rayを利用して監視とトレースを実施。
• サーバーレス環境でのマイクロサービスアプローチを採用し、サービスやレイヤーが一元的に管理されるようにCI/CDを導入する。
• CI/CDを用いてデプロイプロセスを管理し、散在しがちなリソースを統合的にコントロール。

セキュリティの柱

• Amazon API Gatewayでのオーソライザーや相互TLS（mTLS）を使用。

信頼性の柱

• 非同期API呼び出しにおける再実行ポリシーとスロットリングの実装。
• API GatewayやAWS AppSyncでの呼び出しタイムアウト設定。
• デッドレターキューやリトライロジックの実装、Sagaパターンを活用したロールバックメカニズムの考慮。

パフォーマンス効率の柱

• API Gateway、AWS Step Functionsの選択肢と設定に関する基本的な検討、Lambdaの同時実行数の管理。
• 各種AWSサービスにおけるキャッシング戦略の実施。

コスト最適化の柱

• AWS LambdaにおけるCompute Optimizerの活用とAWS Gravitonプロセッサの使用可能性の検討。
• サーバーレスアーキテクチャでのAWSサービス統合によるコスト効率化。

SaaS Lens

SaaS Lens は、AWS 上で Software as a Service (SaaS) ワークロードの設計、デプロイ、アーキテクチャを行う際のベストプラクティスです。

設問の数は 14 で、Serverless Lens に次いで規模の小さいレンズです。

• 万能のSaaSアーキテクチャは存在せず、ビジネスのニーズやドメインの特性、コンプライアンス要件、市場のセグメントなどに応じてアーキテクチャが異なる。
• サービスを分解する際は、マルチテナントの負荷や分離の要件に基づいており、データのプールやサイロ化なども検討する必要がある。
• テナントリソースは常に分離し保護されるべきであり、SaaSシステムの成功はセキュリティモデルに大きく依存する。

私が一番よく扱う公式レンズです。要はマルチテナントうまいことやってサービスも成長できるように DevOps でうまいことやっていこうや、ということなのですが SaaS Lens を知るまで意識出来ていなかったことも多く、是非使って頂きたいレンズです。

運用上の優秀性の柱

• プールされたリソースモデルにおいてテナントごとにリソース使用状況を可視化する。
• テナントの自動オンボーディングプロセスを実装する。
• フィーチャーフラグを用いたデプロイメント戦略を採用する。

セキュリティの柱

• アイデンティティプロバイダ(IdP)を利用してテナントコンテキストを管理する。
• テナント間の分離を確保するセキュリティ対策を施す。

信頼性の柱

• ノイジーネイバー問題を回避するためのスロットリング機能を実装する。
• 各テナントの使用率を計測し、監視する。
• クロステナントアクセスを想定したテストを実行する。

パフォーマンス効率の柱

• SaaS特有のメトリクスに基づいたスケーリング戦略を採用する。
• システム全体ではなく、各テナントごとのパフォーマンスを観測する。

コスト最適化の柱

• マルチテナンシー環境において、テナントごとのコストを計測する仕組みを導入する。

Container Build Lens

Container Build Lens はコンテナーの設計と構築プロセスに関するベストプラクティスです。

• イメージサイズの最小化と複数ステージによるビルドを通じて、セキュリティとパフォーマンスを強化。
• 標準化、イメージのバージョン制御とスキャン戦略の実施によりセキュリティポリシーの整合性を保つ。
• コンテナはステートレスに設計し、予測可能で横断的なパフォーマンスを実現する。

コンテナワークロードに慣れている方には当たり前の要素も多いと思いますが、イメージサイズやスキャン、最小権限など基本的なところは網羅されてる印象ですね。

運用上の優秀性の柱

• 各環境で一貫したテストを行うために同じイメージを使用する。
• CI/CDビルドプロセスを導入して自動化を促進する。
• コンテナのヘルスチェックを実施し、ログを外部からアクセス可能にする。

セキュリティの柱

• コンテナ内部での最小権限の原則を適用する。
• イメージの脆弱性スキャンを定期的に実行する。
• 署名されたイメージを使用し、機密データのイメージ内へのハードコーディングを避け、永続データは外部で管理する。

信頼性の柱

• コンテナに対してCPUとメモリの制限を設定する。
• テストプロセスとビルドパイプラインを通じてコンテナの信頼性を確認する。
• ソース管理とタグ付けを用いてイメージのバージョンを管理する。

パフォーマンス効率の柱

• コンテナイメージのサイズ削減を通じて、プル時間の短縮を目指す。
• 単一プロセスのコンテナイメージを作成し、不要なファイルを除外する。

コスト最適化の柱

• 重複や古いイメージを削除することでコンテナレジストリを最適化する。
• イメージビルドプロセスを効率化する。
• イメージプルやスケールアウトの速度を最適化し、コストを低減する

持続可能性の柱

• Graviton ハードウェアで実行する

SAP Lens

AWS 上で SAP ワークロードを設計する際のベストプラクティスです。

このレンズは公式ドキュメントの構成が他と異なっており、設計原則ページが用意されておらずそれぞれの柱で設計原則にも触れられている形でした。 そのせいか、柱の数は 22 にも関わらず公式ドキュメント上のボリュームが物凄くて、今回のブログを挫折しそうになりました。

SAP ワークロードのベストプラクティスは AWS のドキュメントのみでなく、SAP のドキュメントと併せて読み込む必要があってかなり時間がかかります。
ただし内容が SAP に特化したガイドラインやツールが多いので、しっかり読み込む必要がありますね。
SAP on AWS で登場しそうな概念が盛り沢山です。

運用上の優秀性の柱

• SAPワークロード監視のためにAWS Data Providerを活用し、SAP Solution ManagerでEarlyWatch Alertレポートを生成。
• Solution Managerによるエンドユーザーエクスペリエンスモニタリングと外部インターフェースの監視を実施。
• SSM Automationでsapcontrolコマンドを使用し、SAP認定ビルドおよびデプロイメントシステムを導入し、SAP NetWeaverのパッチフォワードとカスタム開発を組み合わせてロールバック機能を提供。

セキュリティの柱

• SAPワークロードを非SAP環境から独立させ、インバウンド・アウトバウンドトラフィックとSAPサポート接続に関するセキュリティ要件を適用する。
• AWS Launch Wizard for SAPを使用して、HANAベースのSAPソリューションのセキュリティコンポーネントのセットアップを自動化する。
• SAPのセキュリティガイダンスに従い、定期的にセキュリティノートと更新情報をレビューし、SAPユーザーと認証イベントの履歴ログを保存してSIEMと統合する。

信頼性の柱

• クラスタリングソリューションを利用してSAPデータベースおよびSAPセントラルサービスの単一障害点を防ぐ。
• SAPアプリケーション層をスケールアウトし、可用性を高めるためにWebディスパッチャーを活用する。
• Amazon CloudWatch Application Insights for SAPを導入し、SAPツールを使用してアプリケーションコンテキストにおける監視データを管理する。

パフォーマンス効率の柱

• SAP Application Performance StandardのベンチマークとEarlyWatch Alertレポートを参照し、SAP Quick SizerとSAP HANA Sizing Reportsを使用してサイジング要件を見積もる。
• SAPガイダンスに従い、製品、データベース、オペレーティングシステムとAmazon EC2インスタンスタイプの互換性を確認する。
• ネットワークレイテンシー測定にNIPINGを使用し、SAP HANAのスケールアウトの際はプレイスメントグループを活用する。適切なEC2インスタンス選択とSAPアプリケーションに適合したストレージの検討を行う。

コスト最適化の柱

• 単一ホストインストールパターンの適用可能性を評価し、必要ない場合は回復力やスケーラビリティ機能を省略する。
• セカンダリSAP HANAデータベースのメモリプリロードを無効にしてスタンバイメモリ消費を減らし、コストを削減する。
• 非本番環境のSAP HANAで推奨される作業メモリの50％が必要か評価し、SAP Runtime Databaseのライセンスモデルやデータアーキテクチャのオプションを検討する。

IoT Lens

AWS で Internet of Things (IoT) ワークロードを設計・構築・運用するためのベストプラクティスです。
柱の数は 29 です。こちらも SAP Lens と同様にとんでもないドキュメント量で、ここでも挫折しそうになりました。

https://docs.aws.amazon.com/wellarchitected/latest/iot-lens/general-design-principles.html

• データの取り込みと処理は分離し、オフライン状態でも機能する設計を行い、エッジで効率的なデータ処理を実現する。
• ソリューションにパーソナライゼーションを取り入れ、デバイスが定期的にステータスを報告する機能を持たせる。
• ゲートウェイを活用してエッジコンピューティングとクラウド間のブリッジングを行い、IoTの各レイヤーにセキュリティを徹底する。

エッジデバイスを運用するためにどういうふうにクラウド側を設計すべきとか、通常のアプリケーション実装のみだと考慮しきれないだろうなという点が観点として多く含まれている印象でした。
これは IoT ワークロードに関連する際はチェックリストとして IoT Lens を毎回使ったほうが良いのではなかろうか。

運用上の優秀性の柱

• JITP、JITR、フリートプロビジョニングでのデバイス認証、クラウドとファームウェアの修復計画と継続的テストの実施。
• デバイスからのメッセージを自動修復プロセスにルーティングし、AWS IoT Core フリートインデックスでインサイトを提供。
• IoTアプリケーション変更時の影響を軽減する段階的アップグレードとトレーニング実施。

セキュリティの柱

• 各IoTデバイスにX.509証明書を割り当て、TLS 1.2で認証し、証明書のローテーションと更新を可能にする。
• デバイス認証とアクセス制御の強化には一貫した命名規則と事前定義されたMQTTトピックのアクセス権限設定を使用する。
• デバイスの挙動と通信ログのセキュリティ監視のためにAWS IoT Device DefenderとAmazon CloudWatch Logsを利用する

信頼性の柱

• IoTデバイスのファームウェア戦略を策定し、クラウドアプリケーションはデータ整合性の維持と水平スケーリングを管理する。
• IoTトラフィックピーク時の自動スケーリングメカニズムを監視し、ランダム化要素を取り入れたファームウェアでデバイスの同時操作を防ぐ。
• Amazon S3でのファームウェアバージョン管理とAWS CloudFormationによるIoTリソース管理を活用し、エッジデバイスでのデータ蓄積と災害復旧計画を実施する。

パフォーマンス効率の柱

• IoTアプリケーションのパフォーマンスを分析するために、デバイスの健康状態やネットワーク遅延といったデータを利用してセキュリティプロファイルを設定し、異常を検出する。
• NTPやRTCを使用してデバイスの正確なタイムスタンプ取得を保証し、タイムスタンプを各メッセージに追加しながら負荷試験でIoTアプリケーションの耐性を検証する。
• IoTデバイスとクラウドのパフォーマンス監視を行い、適切なパフォーマンス指標に基づいてパフォーマンスのボトルネックを特定し、最適化する

コスト最適化の柱

• IoTイベントのバッチ処理と集約を行い、AWSのマネージドサービスを利用して全体的な処理時間とストレージ要件を削減する。
• エッジデバイス上でのデータ処理を強化し、AWS IoT Greengrassを利用して転送と処理のロジックを動的に調整する。
• データの収集からアーカイブまでのパイプラインを評価し、スケーラビリティに対応できるソリューションを選定して管理コストを最小化する

持続可能性の柱

• AWS IoT CoreのBasic Ingestを用いて費用なしでデータをサポートされるAWSサービスに送信し、データフローを最適化する。
• MQTTを使用して効率的かつ信頼性の高いコミュニケーションを実現し、必要に応じてQoSレベルを選定する。
• AWSカスタマーカーボンフットプリントツールでAWS製品の使用による炭素排出量を視覚化し、排出量のトレンドを分析する。

Data Analytics Lens

分析ワークロードのベストプラクティスで、設問数は 15 です。こちらも設計原則の専用ページが存在していないせいか、ボリュームの各柱のページが膨大で、三回目の挫折です。

運用上の優秀性の柱

• ソースシステムのデータ品質を検証し、データ品質マトリックスを評価してカタログに統合し、データ到着を常にモニタリングする。
• アナリティクスジョブのスケジュールの開始時刻を追跡し、異常を検知した場合にアラームを発する仕組みを実装する。
• アナリティクスジョブおよびアプリケーションの変更をバージョン管理システムで実施し、本番環境への導入前に徹底的なテストを行う。

セキュリティの柱

• 「プライバシー・バイ・デザイン」原則に従い、システム設計の全段階で個人データのプライバシーを組み込む。
• ソースデータ所有者がデータ分類定義し、アナリティクスワークロードがデータ保護ポリシーを適用する。
• データ所有者によるセキュリティ分類設定と監査、報告を組み込んだデータ分類プロセスの実施

信頼性の柱

• ビジネスステークホルダーと協力してデータパイプラインをビジュアル化し、主要なアーキテクチャコンポーネントとデータフロー依存関係を特定する。
• 分析およびETLジョブのスケジュール、失敗通知、再試行ポリシーを監視ツールと緊急アクションプランで管理する。
• 災害復旧計画を策定し、RPOとRTOに基づきバックアップとリストアの機能をテスト、中央データカタログとデータガバナンスポリシーを整備する。

パフォーマンス効率の柱

• AWSのデータ分析サービスを用途に応じて選択し、Amazon Redshift、Amazon Kinesis、Amazon QuickSightなどを活用する。
• パフォーマンス評価と最適化のために区分されたコンピューティングパフォーマンスメトリクスを設定し、監視、評価、ベンチマークテストを実施する。
• Amazon EBS、Amazon S3、Amazon EFSなどAWSのストレージサービスを評価し、ワークロードに適したストレージオプションを選択・最適化する。

コスト最適化の柱

• Amazon EC2 SpotインスタンスやAmazon Redshift RA3インスタンスタイプを活用して分析ワークロードのコストを最適化する。
• 分析系ジョブのコストをコントロールするためAmazon EC2リザーブドインスタンスやセービングプランを利用し、コスト効率を追求する。
• 分析ワークロードの不規則な変動に対応するためオンデマンドインスタンスやオートスケーリングを使い、過剰なプロビジョニングを避ける。

持続可能性の柱

• レポートの更新頻度と必要性を見直して、不要なメトリクスを排除し、持続可能な影響を評価する方法を導入する。
• 開発チームにデータ最小化のマインドセットを促進し、継続的改善プロセスでカーボンメトリクスに対する改善を定量化する。
• データライフサイクル管理とデータの保持ポリシーを実装し、不使用時はデータを削除またはアーカイブする

Machine Learning Lens

こちらは機械学習ワークロードのベストプラクティスで設問数は 20 です。

上記設計原則を3行でまとめると次のような感じになるのですが、あまり機械学習に特化した内容がここでは書いてないですね。ただ、実際の柱について読んでいくと、SageMaker Clarify使ってみろとか、具体的な実装例について触れられていることが多い印象でした。

• 所有権の明確な割り当てと保護策を実施し、システムの耐障害性を高める。
• コンポーネントの再利用と再現可能性を確保してリソースを最適化し、コストを削減する。
• 自動化と継続的な改善を通じて効率性を向上させ、環境への影響を最小化する。

運用上の優秀性の柱

• 従業員のML技術知識向上を図り、企業全体で責任あるAI利用を促進し、特定のML分野での効率を上げる。
• ビジネス要件に基づくモデルの説明可能性合意を確立し、SageMaker Clarifyでバイアスと説明可能性を評価。
• プロダクション環境でのモデル挙動をリアルタイムで監視し、不具合やバイアスを検知し対応する監視インフラを設計。

セキュリティの柱

• MLライブラリとパッケージの使用に関連してデータ利用許諾、プライバシー契約、およびライセンス条項の準拠をレビューし、データの権限を検証し、パッケージリポジトリへの参照を含むライフサイクル構成を作成。
• パーソナルデータの保護のために、AWS Glue Databrewなどを使用してデータの暗号化、難読化、プライバシーの向上を図り、アクセス制御は最小権限の原則に基づいて適用。
• Amazon SageMaker等を用いて、機密データの自動分類、データ及びモデルの暗号化、MLワークフローの記録・追跡、データライフサイクル管理、及びセキュリティ強化のプラクティスを実装。

信頼性の柱

• アプリケーションの中断を引き起こさずにMLモデルの変更を導入できるよう、APIを活用して柔軟なアプリケーションデザインを実現し、API変更は中央リポジトリまたはドキュメントサイトに記載。
• マイクロサービスアーキテクチャを採用し、再利用可能な単一目的コンポーネントをAWS LambdaやAWS Fargate上のDockerコンテナで実行することで、変更管理を容易にする。
• AWS Glue Data CatalogとData Wranglerを使用してMLワークロードに読み込まれたデータ資産を追跡、ETLプロセスを統合し、AWS Data PipelineやSageMaker Pipelinesを利用してデータパイプライン自動化を実施。

パフォーマンス効率の柱

• 重要なパフォーマンス指標（KPI）をビジネス価値へリンクさせ、最小許容精度と最大許容誤差を設定し、モデルのエラーコストとビジネスリスクを定量化する。
• プリビルドされたAIサービスや機械学習リソースの利用可能性を検討し、AWSのマネージドAIサービスを評価してビジネスユースケースとMLワークロードのバランスを取る。
• ビジネス目標に沿ったKPIを設定し、Amazon SageMaker Experimentsでメトリクスを評価し、Amazon SageMaker Model Monitorでモデルのリアルタイム監視を行う

コスト最適化の柱

• MLプロジェクトが研究目的か開発目的かを特定し、長期的な投資収益率（ROI）を評価し、AWSのタグ付けを利用してコストを追跡し、プロジェクトやビジネスユニットごとにROIを明確にする。
• Amazon SageMakerを利用してモデル構築、トレーニング、デプロイを実行し、AWSの事前トレーニング済みのAIサービスを活用し、ワークロードの価格モデル分析を実施してコスト削減を図る。
• ML導入の代替案を評価し、問題解決策としてAmazon SageMaker AutopilotやSageMaker Clarifyを検討し、MLモデルが既存の解決策よりも優れているかを評価する。

持続可能性の柱

• シンプルなアルゴリズムから複雑なアルゴリズムへ徐々に移行し、モデルの圧縮技術を用いて効率化を図り、不要なトレーニング成果物やログデータは定期的にクリーンアップする。
• スケーラブルなリソース活用のためAmazon SageMakerのオンデマンドインスタンスやマルチモデルエンドポイントを利用し、負荷の低い時にバッチ推論を実行することで効率化を図る。
• MLワークロードでのリソース使用量を把握し、AWSの再生可能エネルギープロジェクトがあるリージョンを優先し、サーバレスおよびイベント駆動のデータパイプラインを管理サービスを利用して構築する。

Healthcare Industry Lens

ヘルスケアワークロードを設計、デプロイ、管理する方法のベストプラクティスで設問数は 27 です。ここで四回目の...

• 該当規制や品質フレームワークに合致するようにシステムを設計し、自動化で運用リスクを軽減。
• 機密データの完全な暗号化、全アクションのロギング、データへの最小権限の適用を徹底。
• 最新の通信プロトコルを採用し、相互運用性を促進と障害からの自動復旧計画を実装。

ヘルスケアと聞いて抱く第一印象と同じで、情報の保護やガバナンスについて中心的に触れられていますね。

運用上の優秀性の柱

• フォーマルなリスク管理プログラムを作成し、AWS共有責任モデルおよびセキュリティ文書をレビューしてクラウドガバナンスのポリシーとプロシージャを策定する。
• 機密データを含むワークロードを隔離し、AWSアカウント、VPC、Amazon S3バケットを用いたアクセス制御を実施し、AWS ConfigやAWS X-Rayでクラウド環境のリソース構成を管理する。
• インフラをコードとして管理するためにAWS Config、AWS CloudFormation、AWS CDK、Terraform、Service Catalogを使用し、AWS Lambdaを活用してコンプライアンスの自動評価を実行する。

セキュリティの柱

• データ分類戦略を策定し、AWSのガイダンスを参照してカテゴリとアクセス制御を定義し、Amazon Macieを利用してS3データを自動分類し、AWS IAMでアクセス管理を行う。
• AWS内で必要なセキュリティコントロールの実装、ネットワークアクセス制限、セキュリティパッチの適用、個人保護健康情報(PHI)のAmazon GuardDutyによる継続的な監視を行い、セキュリティ事件への対応計画を策定する。
• AWS KMSとAWS CloudHSMを使用したデータ暗号化を実施し、AWS Configを利用して暗号化されていないリソースの監視、Amazon S3バケットポリシーでセキュアな通信を強制し、HTTPSのみ許可する設定を行う。

信頼性の柱

• AWS Direct Connectを使用して、オンプレミスとAWS間で安定した接続を確立し、医療アプリケーションの可用性を向上させる。
• AWS Direct Connectの耐障害性ツールキットを用いて99.99%のSLA達成を目指し、アプリケーションの冗長性を確保する。
• 公衆インターネットのフォールオーバー機能とVPNルーティングを用いて冗長性を強化し、AWS Transit Gatewayを使用してAmazon VPCへVPN接続を行う。

パフォーマンス効率の柱

• AWS Nitro Systemを活用して、ハードウェアアシスティッドのインスタンストランジット暗号化を行い、セキュリティとパフォーマンスのバランスを取る。
• Auto ScalingとAmazon EC2を用いてコンピュートリソースを需要に応じて動的に調整し、古い通信プロトコルに対してVPNやIPsecメッシュによる暗号化を実施する。
• Amazon S3とAmazon EBS io2ブロックストレージを使用して高いデータ耐久性を確保し、Well-Architected Frameworkに基づいてストレージパフォーマンス要件を特定して適用する。

コスト最適化の柱

• 内部外部の要件に基づいたデータ保持ポリシーを定義し、Amazon S3のライフサイクルポリシーを活用して低アクセスデータの自動アーカイブを設定する。
• インフラをコードとして利用し、AWS Backupでデータ保持ポリシーの準拠管理を実施する。
• AWS Backup Audit Managerを使用して、データライフサイクルポリシー違反を自動検出し、ポリシー施行を集中化・自動化する。

持続可能性の柱

• ワークロードインフラストラクチャをスケーリングしてユーザーの行動パターンと需要に合わせ、ピーク時に活動する外来ケア配信などのワークロードはビジネス時間中に調整し、オフピーク時にはリソース使用量を削減する。
• 医療ワークフローを再設計し、オーナーやステークホルダーと協力してワークロードの削除やリファクタリングを行い、クラウドアーカイブを使用して廃止されたコンポーネントからのデータ保持コストを抑制する。
• データ保持プロセスを自動化してビジネスや規制の要件に沿った最小限の健康データを維持し、ストレージクラスを最適化してコストを管理しつつ、不要なデータの削除やアーカイブを自動化する。

さいごに

本日は AWS Well-Architected Tools のレンズカタログで選択出来る全てのレンズの設計原則と柱をまとめてみました。

まず、全体を通してこれらは公式ドキュメントからまとめたものになりますのでベストプラクティスがこれだというつもりはありません。
実際に SaaS Lens では多くのプラクティスが有効なものなのですが、中にはこれは実運用だと厳しいのでは？というものもありました。デザインパターンのように形骸化していたりアンチパターンな項目も可能性にあると念頭に置きつつ利用するのが良いと思います。

正直いうと機械学習、データ分析あたりはふわっとしてるなという印象で、実態に即したものなのかが判断出来ませんでしたが、慣れ親しんでいる、SaaS、サーバーレス、コンテナあたりは基本的なことが網羅されている印象なので積極的に活用して良いのではないかなと思ってます。

各レンズの柱を3行まとめしただけでも結構なボリュームとなり、うわぁという感じですが、まだ公式レンズを使ったことが無かった方は今回存在を知って頂き、機会があれば是非思い出して使って頂けると幸いです。