Amazon Web Services ブログ

Category: AWS Well-Architected

日本の SaaS ビジネスのさらなる成長のために、AWS Japan がソフトウェア企業に提供する「AWS SaaS 支援プログラム」の提供を開始

みなさん、こんにちは。事業開発統括本部、ソリューション事業開発本部、SaaS 領域の事業開発をしている三石です […]

新しいレンズカタログで、AWS Well-Architected Review の範囲を広げる

AWS Well-Architected Tool (WA Tool) は、最新の AWS のアーキテクチャのベストプラクティスに基づいてワークロードを定義し、レビューすることを支援します。これにより、ワークロードの強みと改善点を特定することができます。

KPI - テクノロジーからビジネスへのエンタープライズジャーニー

KPI – テクノロジーからビジネスへのエンタープライズジャーニー

AWS は、KPI (Key Performance Indicators: 主要業績評価指標) が明確に定義され、追跡され、調整された組織が、クラウドトランスフォーメーションのジャーニーで成功していると理解しています。しかし、KPI を定義して追跡することは難しい課題です。組織が連携して成果を追跡し、そうすることに価値があるとしても、最初から KPI に注目することが難しい組織もあります。
このブログ記事では、架空の企業 (AnyCompany) が KPI を導入するまでのジャーニーを、複数の顧客とともに取り組んだ実際の経験に基づいて説明します。

AWS Trusted Advisor による運用上の優秀性の継続的な最適化

2023 年 10 月 26 日、Trusted Advisor は新しく運用上の優秀性のチェックカテゴリーを追加し、AWS Config と統合したことで、すべてのカテゴリーで合わせて 64 の新しいベストプラクティスチェックを提供しました。このローンチにより、AWS 環境の運用準備状況が改善され、Trusted Advisor チェックの適用範囲が広がり、AWS Well-Architected Framework のベストプラクティスとの整合性を高めることができます。
本ブログ投稿では、新しい運用上の優秀性カテゴリーについて詳しく説明し、Trusted Advisor が運用リスクと最適化の機会の特定にどのように役立つかをサンプルシナリオを通して説明します。

Well-Architected Framework Review の実施方法 – パート 3

これまでのブログ投稿で、Well-Architected Framework Review(WAFR) を実行するための最初の 2 つのフェーズについて説明しました。 最初のフェーズは準備で、2 番目のフェーズはレビューを実施することです。 このブログ投稿では、3 番目のフェーズである改善について詳しく説明します。

Well-Architected Framework Review の実施方法 – パート 2

Well-Architected Framework Review (WAFR) を成功させるには、準備、レビュー、改善の 3 つのフェーズがあります。このブログシリーズのパート 1 では、準備フェーズについて説明しました。このパートでは、第 2 フェーズ、つまり実際のレビューにおけるベストプラクティスについて詳しく説明します。

Well-Architected Framework Review の実施方法 – パート 1

AWS では、あらゆるものにベストプラクティスがあり、ワークロードに対して実施する Well-Architected Framework Review(WAFR) も例外ではありません。チームの経験、ワークロードの複雑さ、レビューする柱、後に取り上げるその他の要因など、複数の要因によって、WAFR は大掛かりな取り組みになる可能性があります。これらのベストプラクティスを認識していることは、チームがレビューに投資している時間がアーキテクチャのリスクを特定し、それらに対処するという期待される結果につながることを確実にするための鍵となります。この 3 部構成のブログシリーズでは、AWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有します。パート 1 では、レビューの準備方法をお話しします。パート 2 では実施方法をカバーし、パート 3 ではアーキテクチャのリスクを特定し、それらを修正するための計画を作成する方法をカバーしています。

Let’s Architect! アーキテクチャにおけるレジリエンシー

レジリエンスは、効率的に設計されたシステムにとって重要であることが明らかになっています。これが、AWS クラウドプラットフォームでホストされるワークロードの信頼性と可用性を確保する上でレジリエンスが基本的な役割である理由です。
この Let’s Architect! の新版では、継続的なサービスの提供と中断の回避に重点を置いて、回復力のあるアーキテクチャを構築するためのベストプラクティスをいくつか紹介します。

責任共有モデルとAWS Resilience Hub

AWS Resilience Hub は、アプリケーションにおけるレジリエンスの定義、追跡、管理を支援するために設計された AWS サービスです。このサービスでは、AWS Well-Architected のベストプラクティスを使用してワークロードのレジリエンスを理解し、改善するのに役立ちます。また、レジリエンスと運用上の推奨事項の両方を提供することで、お客様は目標復旧時点 (RPO) と目標復旧時間 (RTO) に関する組織およびワークロード毎の要件を一貫して満たすことができます。
このブログ記事では、レジリエンスのための責任共有モデルと、それが AWS Resilience Hub サービスを使用する際の考慮事項にどのように影響するかを見ていきます。