Amazon Web Services ブログ

Category: Management Tools

AWS 持続可能性のベストプラクティスに照らした AWS リソースの評価、監査、評価

このブログでは、お客様が AWS Config を使用して、AWS Well-Architected framework の持続可能性の柱のベストプラクティスに照らした AWS リソースの大規模に評価、監査、評価する方法について説明します。

AWS Chatbot は Amazon Q Developer に名称が変わりました

本日、AWS Chatbot が Amazon Q Developer に名称変更されたことを発表します。これにより、生成 AI を活用した機能を通じて、開発者の生産性が向上します。
今回の変更は単なる名称変更ではなく、チャットベースの DevOps 機能の強化を意味します。AWS Chatbot の実績ある機能と Amazon Q の生成 AI 機能を組み合わせることで、クラウドリソース管理をより直感的かつ効率的に行えるツールを開発者に提供します。

AWS を活用した公共部門向けデータ配信

組織が情報に基づいた意思決定を行い、イノベーションを促進するためには、データの共有が不可欠です。 アマゾン ウェブ サービス (AWS) は、大規模なデータを安全に配信するためのさまざまなツールとサービスを提供しています。 公共の利益のためにオープンデータの公開、ビジネス目的でのプライベートデータセットの収益化、さらには社内での協業などの用途で、AWS は必要なインフラストラクチャとサポートを提供します。詳細については、この投稿をお読みください。

AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止

可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。

アプリケーションは、トラフィックへの応答 (または作業の実行) を停止し、ログ集約サーバーが復旧するのを待つべきでしょうか? (正確な監査ログがサービスの可用性よりも優先されますか?)
アプリケーションは、ログサーバーがバッファを使い切る前に復旧することを期待してログをバッファリングしながらトラフィックに対応し続けるべきでしょうか? ログ送信先が利用できないレアケースにおいてログが失われるリスクを受け入れるべきでしょうか?

コンテナのログドライバーでは、このトレードオフは上記 1 の考慮事項に対して「ブロッキング」の設定パラメータ、2 の考慮事項に対して「ノンブロッキング」の設定パラメータで実装されています。AWS ブログの「Choosing container logging options to avoid backpressure」では、Rob Charlton がこのトレードオフを探求し、AWSLogs コンテナログドライバーのデフォルトの「ブロッキング」モードでアプリケーションがどのように動作するかをテストする方法を説明しています。

この記事では、「ノンブロッキング」 について詳しく説明し、AWSLogs ログドライバーを使用したログ損失の試験結果を示します。

Upbound Group が最新の POS プラットフォームを AWS で構築

Upbound Group Inc. (NASDAQ: UPBD) は、テキサス州 Plano に本社を置くオムニチャネルプラットフォーム企業です。 消費者の進化するニーズや期待に応える、革新的で包括的、かつテクノロジー主導の金融ソリューションを提供することに力を入れています。 Upbound Group の顧客向け事業部門には、Rent-A-Center® や Acima® などの業界をリードするブランドが含まれ、店舗をベースとしたさまざまな小売チャネルおよびデジタル小売チャネルでもブランド企業と消費者とが容易に取引できるようにしています。