Amazon Web Services ブログ
Category: Architecture
エージェントワークスペースで機微情報を扱う方法
コンタクトセンターのエージェントは、複雑なワークフローを伴うトピックでもお客様をサポートしています。ステップバイステップガイドはエージェント向けのワークフロー機能ですが、操作する際、エージェントは機密データや極秘データを収集・入力することも頻繁にあります。そのようなデータは、通話ログやスクリーン録画に記録されるべきではありません。 このブログ記事では、Amazon Connect のコンタクトフローで機密情報を収集するステップバイステップガイドを呼び出す際に、自動的に録画を一時停止し、ワークフローが完了したら録画を再開するソリューションを説明します。
デジタル庁、リファレンスアーキテクチャと生成 AI を活用したアーキテクチャのレビューで政府システムの移行を促進
2021 年 9 月、日本はデジタル庁の創設とガバメントクラウドの取り組みを開始しました。デジタル庁は、デジタ […]
テナントポータビリティ: SaaS アプリケーションのティア間でテナントを移動する
今日の急速に変化する Software as a Service (SaaS) 環境において、テナントのポータビリティは、競争力を維持しようとする SaaS プロバイダーにとって重要な機能です。テナントのティア間の円滑な移動を可能にするポータビリティにより、企業は変化するニーズに適応できます。しかし、ティア移動のリクエストに手動で対応することは大きなボトルネックとなり、スケーラビリティを阻害し、多大なリソースを必要とします。テナントの数とポータビリティのリクエストが増加するにつれ、このアプローチはサステナブルではなくなり、より効率的な解決策を実装することが不可欠になります。
KPI – テクノロジーからビジネスへのエンタープライズジャーニー
AWS は、KPI (Key Performance Indicators: 主要業績評価指標) が明確に定義され、追跡され、調整された組織が、クラウドトランスフォーメーションのジャーニーで成功していると理解しています。しかし、KPI を定義して追跡することは難しい課題です。組織が連携して成果を追跡し、そうすることに価値があるとしても、最初から KPI に注目することが難しい組織もあります。
このブログ記事では、架空の企業 (AnyCompany) が KPI を導入するまでのジャーニーを、複数の顧客とともに取り組んだ実際の経験に基づいて説明します。
非構造化金融データに隠された関連性を Amazon Bedrock と Amazon Neptune で発見する
アセットマネジメント業務において、ポートフォリオマネージャーは、リスクと機会を把握し投資判断を導くために、投資 […]
SAP BTP on AWS で耐障害性の高いアプリケーションを構築
このブログでは、トレーニングコース「Build Resilient Applications on SAP BTP with Amazon Web Services」について紹介し、概要を説明します。
SAP と AWS が共同で実施するこのコースは、両社の戦略的な連携の一環として、受講者に両社の強みを最大限に生かすための知識を提供することを目的としています。トレーニングを通して、クリーンコアアプローチを円滑に実装でき、受講者は両社の利点を簡単に活用できるようになります。
MYCOM OSI が Amazon FSx for NetApp ONTAP で SaaS ストレージを最適化した方法
“Kubernetes 上のデータ”は、パフォーマンス、回復力、信頼性、総所有コスト(TCO)を最適化する、クラウドネイティブなマイクロサービスベースのソフトウェアソリューションを構築するために不可欠な、急速に進化する革新的分野です。Kubernetes アプリケーションの多くは、ブロックストレージ、共有ファイルシステム、オブジェクトストレージなどの永続ストレージとデータサービスへのアクセスを必要とします。
この投稿では、MYCOM OSI が Amazon FSx for NetApp ONTAP を採用することで、どのようにコストパフォーマンスを改善したかについて説明します。また、大規模で複雑な通信事業者のアシュアランスデータセットの処理を最適化するソリューションを特定するために、ストレージオプションをどのように評価したかを探ります。
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 ではアーキテクチャのリスクを特定し、それらを修正するための計画を作成する方法をカバーしています。